During FxOS days we spent a lot of time designing the "bootstrapping" stages of
We came up with 5 stages:
The idea of those stages was that those milestones should be both - observable,
That means that we wanted to measure when the app reports to have its chrome
ready, but also let the app/system perform particular actions only in reaction
to some stage reached.
It's amazing to me how far we got this concept. There was a good standardized
cli tool to measure the performance of each app on the device against those
benchmarks. You could run it at any point and it produced output like this:
`make raptor --app sms --runs 30`
| Metric | Mean | Median | Min | Max | StdDev | 95%
| --------------------- | -------- | -------- | ------ | ------ | ------- |
| navigationLoaded | 1013.267 | 1003 | 922 | 1202 | 56.836 |
| navigationInteractive | 1068.467 | 1059.500 | 974 | 1256 | 58.811 |
| visuallyLoaded | 1366.367 | 1363.500 | 1274 | 1524 | 57.182 |
| contentInteractive | 1960.900 | 1958 | 1851 | 2127 | 65.373 |
| fullyLoaded | 3622.900 | 3597 | 3440 | 3809 | 106.969 |
| uss | 19.270 | 19.285 | 19.008 | 21.062 | 0.360 |
| pss | 23.501 | 23.517 | 23.232 | 25.317 | 0.363 |
| rss | 39.722 | 39.732 | 39.461 | 41.523 | 0.360 |
and there was a beautiful dashboard showing the visualization of the change
over time against master.
Those stages translate quite well to the current proposal for
1) First Paint - when the first paint happens in reaction to the new content
(for example background changes for a website or the first paint with Firefox
2) First Contentful Paint - when the first paint with DOM in it happens. In our
case, the first paint with the Firefox chrome painted
3) Time to Interactive - when chrome becomes interactive
and I can imagine a few more based on what we designed for FxOS:
4) Visually Loaded - when the main chrome stops moving (lazy loaded icons added
5) Content Visually Loaded - when the about:newtab content seems visually stable
6) Fully Loaded - when the chrome and the initial content (about:newtab) are
What's important here is that not only we can read them and track them and I
believe they'd serve us better than tpaint/ts_paint/sessionrestore, but you can
schedule things to load after reaching a certain phase.
For example, we would measure memory of the browser only after fullyLoaded, but
for the UX we'd look into "Visually Loaded" since that's when the user
considers the app to be ready (when things stop moving around).
I can imagine a lot of our code could be scheduled to run after fully loaded
happens, and not interfere with the bootstrap.
It would also make it possible to schedule code that has to be loaded before
chrome becomes interactive, and postpone the code that shouldn't block chrome
interactivity to be bootstrapped after that.
When I switched from working on FxOS to working on Firefox I remember missing
the cleanness of the fxos solution a lot.
Your post brought back the sentiment, but maybe this time, it's something we
can make actionable? :)
dev-platform mailing list