Closed Bug 1203993 Opened 7 years ago Closed 7 years ago
Newest proposed homescreen doesn't contain performance markers
46 bytes, text/x-github-pull-request
|Details | Review|
46 bytes, text/x-github-pull-request
|Details | Review|
In order to continue to performance test applications and device startup, the newest proposed homescreen must also implement the same performance markers that the current verticalhome does. Specifically, it must implement: navigationLoaded navigationInteractive visuallyLoaded contentInteractive fullyLoaded Not implementing these will break performance testing.
Eli, could you give a quick summary of what each of these states represents, especially with regards to a homescreen? (more specifically, I don't understand the difference between the first 3) We should be prepared for fullyLoaded to regress some due to pinned pages too.
The implementation details vary from app to app, so they can mean something somewhat different for each app. The definitions of each state is defined on MDN . If that's not clear, let me know. I think it's OK to regress fullyLoaded which can be somewhat transient. visuallyLoaded is the marker we use to determine official regressions.  https://developer.mozilla.org/en-US/Apps/Build/Performance/Firefox_OS_app_responsiveness_guidelines#Implementation
My guess for Homescreen would go like this: navigationLoaded - the chrome of the homescreen is ready (so, HTML/CSS code is in place) navigationInteractive - the chrome has all the bindings attached and can be interacted with visuallyLoaded - the content of the homescreen that is displayed "above the fold" is loaded into DOM contentInteractive - the content of the homescreen that is displayed "above the fold" is interactive fullyLoaded - all background tasks that are part of the startup are completed, everything is in memory and applications is passively waiting for events. Now, in terms of "chrome" vs "content" in the homescreen app my understand is that the app has almost no interactive chrome and all icons that user interact with, and the groups with the icons to fold them are all dynamically configurable so they are the "content" of the app. Depending on if the search box is a configurable element of the homescreen it may be part of chrome or part of content. So, if search box is content, then basically you can fire navigationLoaded and navigationInteractive in the DOMContentLoaded listener. If you do need some JS before the user interface of the homescreen is ready, fire those two after that part is done. Then, if I understand correctly, you read from some DB the list of apps/pinned websites, groups the icons are in and maybe whether to show the search box and where. Then you inject all of that into DOM and then you can fire visuallyLoaded. Then you make all of that interactive, so once that is done, fire contentInteractive. Those two may be fired at the same time if you attach listeners at the same time as you inject into DOM. Lastly, finish everything below the fold and any background caching (like, loading data for searchbox or what not) and fire fullyLoaded. That's where we will measure memory. In the future we may use the last mark to analyze app resources for faster startup.
This is a quickie and I'm procrastinating, so I'll take it.
Assignee: nobody → chrislord.net
Status: NEW → ASSIGNED
Comment on attachment 8661724 [details] [review] [gaia] Cwiiis:bug1203993-new-homescreen-performance-markers > mozilla-b2g:master LGTM!
Attachment #8661724 - Flags: review?(gmarty) → review+
Comment on attachment 8661724 [details] [review] [gaia] Cwiiis:bug1203993-new-homescreen-performance-markers > mozilla-b2g:master Just reading the back cover of this PR, everything seems to be in order, primary that fullyLoaded occurs after all other initialization JS has executed. I do have one question: in the first promise of `populateApps`, `resolve()` is called before the performance markers. Will this have any unintended side effects of possibly running more code before the performance markers have had a chance to register? I just worry about the timings of these 2 markers being more variant if they are triggered after `resolve()` instead of before.
Attachment #8661724 - Flags: feedback+
(In reply to :Eli Perelman from comment #7) > Comment on attachment 8661724 [details] [review] > [gaia] Cwiiis:bug1203993-new-homescreen-performance-markers > > mozilla-b2g:master > > Just reading the back cover of this PR, everything seems to be in order, > primary that fullyLoaded occurs after all other initialization JS has > executed. > > I do have one question: in the first promise of `populateApps`, `resolve()` > is called before the performance markers. Will this have any unintended side > effects of possibly running more code before the performance markers have > had a chance to register? I just worry about the timings of these 2 markers > being more variant if they are triggered after `resolve()` instead of before. I purposefully call it after resolve, as during JS execution, the user definitely won't be able to interact with the app (looking at where the markers are in verticalhome, I realise this may put new homescreen at a disadvantage) - I assume the performance measurement is meant to be more about the perceived performance than a pure measurement of how long specific tasks take. We can change these in the future if we don't think it's measuring what we want to measure, but I feel this would be a more useful measure than if we put it before the resolve.
@cwiiis great explanation, thanks!
Gah, I forgot one! The appLaunch marker denotes the start time of launching an app. I'm not sure if you are using mozapp.js at all, but if not, you will need to trigger appLaunch at the appropriate time: https://github.com/mozilla-b2g/gaia/blob/4ff6ec7ea4ccf76f891bc5cb7b28d0376c852535/shared/elements/gaia_grid/js/items/mozapp.js#L341
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → FxOS-S7 (18Sep)
n?me for follow-up wrt comment #10.
Comment on attachment 8664974 [details] [review] [gaia] Cwiiis:bug1203993-new-homescreen-app-launch-perf-marker > mozilla-b2g:master Add the appLaunch performance marker.
Attachment #8664974 - Flags: review?(eperelman)
Attachment #8664974 - Flags: review?(eperelman) → review+
You need to log in before you can comment on or make changes to this bug.