During FxOS days we spent a lot of time designing the "bootstrapping" stages of the app/system.
We came up with 5 stages: 1) navigationLoaded 2) navigationInteractive 3) visuallyLoaded 4) contentInteractive 5) fullyLoaded https://hacks.mozilla.org/2015/06/performance-testing-firefox-os-with-raptor/ https://developer.mozilla.org/en-US/docs/Archive/B2G_OS/Developing_Gaia/Raptor/Responsiveness_guidelines The idea of those stages was that those milestones should be both - observable, and actionable. 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% Bound | | --------------------- | -------- | -------- | ------ | ------ | ------- | --------- | | navigationLoaded | 1013.267 | 1003 | 922 | 1202 | 56.836 | 1033.605 | | navigationInteractive | 1068.467 | 1059.500 | 974 | 1256 | 58.811 | 1089.512 | | visuallyLoaded | 1366.367 | 1363.500 | 1274 | 1524 | 57.182 | 1386.829 | | contentInteractive | 1960.900 | 1958 | 1851 | 2127 | 65.373 | 1984.293 | | fullyLoaded | 3622.900 | 3597 | 3440 | 3809 | 106.969 | 3661.178 | | uss | 19.270 | 19.285 | 19.008 | 21.062 | 0.360 | 19.398 | | pss | 23.501 | 23.517 | 23.232 | 25.317 | 0.363 | 23.631 | | rss | 39.722 | 39.732 | 39.461 | 41.523 | 0.360 | 39.851 | 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 PerformancePaintTiming: https://github.com/WICG/paint-timing 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 window happens) 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 etc.) 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 loaded 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? :) zb. _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
