Closed Bug 1203993 Opened 7 years ago Closed 7 years ago

Newest proposed homescreen doesn't contain performance markers

Categories

(Firefox OS Graveyard :: Gaia::Homescreen, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED
FxOS-S7 (18Sep)

People

(Reporter: Eli, Assigned: cwiiis)

References

Details

(Whiteboard: [systemsfe])

Attachments

(2 files)

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.
Flags: needinfo?(eperelman)
Whiteboard: [systemsfe]
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 [1]. 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.

[1] https://developer.mozilla.org/en-US/Apps/Build/Performance/Firefox_OS_app_responsiveness_guidelines#Implementation
Flags: needinfo?(eperelman)
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
Attachment #8661724 - Flags: review?(gmarty)
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.
Keywords: checkin-needed
@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
https://github.com/mozilla-b2g/gaia/commit/0d18a51dabfe28c0d993366a3436a07247a5e3b1
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → FxOS-S7 (18Sep)
n?me for follow-up wrt comment #10.
Flags: needinfo?(chrislord.net)
Comment on attachment 8664974 [details] [review]
[gaia] Cwiiis:bug1203993-new-homescreen-app-launch-perf-marker > mozilla-b2g:master

Add the appLaunch performance marker.
Flags: needinfo?(chrislord.net)
Attachment #8664974 - Flags: review?(eperelman)
Keywords: checkin-needed
Attachment #8664974 - Flags: review?(eperelman) → review+
You need to log in before you can comment on or make changes to this bug.