812437 - (butter-delivery) [meta] Reduce app load time

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Performance, defect, P2)

Description

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

As stated in bug 809668 and bug 811593 starting an empty app from the moment the user clicks on the app icon and the moment the "onload" event is fired takes around 1 second on Unagi.

There are many ways we can reduce this overhead.

Dependencies will come after a short commercial break. Stay tuned.

Comment 1

[Borja Salguero [:borjasalguero]]

Hi there, one of the issues that we detected in the WF in SF was that during the transition of 'opening-iframe' the iframe loading process is 'stopped' until the transition is over. One of the main points would be use a separate DOM element with the snapshot for making the transition and keep the iframe loading behind. Once the transition is over we will substitute our new 'DOM Snapshot element' with the iframe loaded, so booting time should be reduced. 
As well we are using a transition with .5 seconds for 'opening', and after talking with UX we could reduce it a little bit in order to have a better user experience.

Comment 2

[Justin Lebar (not reading bugmail)]

> during the transition of 'opening-iframe' the iframe loading process is 'stopped' until 
> the transition is over.

Last time I looked at this, this was because the main process runs with nice -1, while the opening process runs with nice 0.  Therefore the animation takes CPU away from actually loading the app, which is silly.

Comment 3

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

There are also certain ideas in bug 781613 that may help reduce the load time

Comment 4

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

So what we have here is:

 - index.html fetchStart may be slow: bug 812643
 - index.html domInteractive may be slow: bug 812441
 - onload XHR is slow: bug 811593

I don't have a test yet to measure impact of adding <links/> and <script src=""/> on onload, but it seems that it's slow as well.

Comment 5

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

My numbers here were skewed by bug 812643.

The reality of a simple app is:

 - fetching it costs ~10ms
 - parsing/loading DOM ~300ms
 - loading multiple additional resources (css/js) ~300ms
 - loading additional XHR resource (l10n) ~100ms

That means that without minification we should have the app ready in ~700ms (assuming multiple CSS/js and l10n files).

If we minify css/js I expect we can shave ~100-200ms off the load time and get to ~500ms.

My hope is that we can shave two last items: resource loading and XHR to get closer to the numbers we have for index.html fetch.

Comment 6

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

I'm going to reuse this old bug as a meta for some other bugs/tools I want to add on this subject.

Comment 7

[Mike Lee [:mlee]]

We now have a template (empty) app used to track minimum app load time:

https://datazilla.mozilla.org/b2g/?branch=master&device=hamachi&range=30&test=cold_load_time&app_list=template&app=template&gaia_rev=40abb245b1e61df6&gecko_rev=a7d685480bf2&plot=median

Comment 8

[:Eli Perelman]

Just as a heads-up, we do have established goals for which we want applications to be interactive by:

https://developer.mozilla.org/en-US/Apps/Build/Performance/Firefox_OS_app_responsiveness_guidelines

Comment 9

[Bobby Chien]

[Tracking Requested - why for this release]: