1203993 - Newest proposed homescreen doesn't contain performance markers

Status: RESOLVED FIXED

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

Description

[:Eli Perelman]

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.

Comment 1

[Chris Lord [:cwiiis]]

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.

Comment 2

[:Eli Perelman]

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

Comment 3

[Zibi Braniecki [:zbraniecki][:gandalf]]

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.

Comment 4

[Chris Lord [:cwiiis]]

This is a quickie and I'm procrastinating, so I'll take it.

Comment 5

[GitHub Autolander Bot]

Attachment: [gaia] Cwiiis:bug1203993-new-homescreen-performance-markers > mozilla-b2g:master

Comment 6

[Guillaume Marty [:gmarty]]

Comment on attachment 8661724 [details] [review]
[gaia] Cwiiis:bug1203993-new-homescreen-performance-markers > mozilla-b2g:master

LGTM!

Comment 7

[:Eli Perelman]

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.

Comment 8

[Chris Lord [:cwiiis]]

(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.

Comment 9

[:Eli Perelman]

@cwiiis great explanation, thanks!

Comment 10

[:Eli Perelman]

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

Comment 11

[Carsten Book [:Tomcat]]

https://github.com/mozilla-b2g/gaia/commit/0d18a51dabfe28c0d993366a3436a07247a5e3b1

Comment 12

[Chris Lord [:cwiiis]]

n?me for follow-up wrt comment #10.

Comment 13

[GitHub Autolander Bot]

Attachment: [gaia] Cwiiis:bug1203993-new-homescreen-app-launch-perf-marker > mozilla-b2g:master

Comment 14

[Chris Lord [:cwiiis]]

Comment on attachment 8664974 [details] [review]
[gaia] Cwiiis:bug1203993-new-homescreen-app-launch-perf-marker > mozilla-b2g:master

Add the appLaunch performance marker.

Comment 15

[Carsten Book [:Tomcat]]

https://github.com/mozilla-b2g/gaia/commit/acb0960253777968bcb88f6f7fd295da80be7377