Closed Bug 812437 (butter-delivery) Opened 7 years ago Closed 2 years ago

[meta] Reduce app load time

Categories

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

ARM
Gonk (Firefox OS)
defect

Tracking

(tracking-b2g:backlog)

RESOLVED WONTFIX
tracking-b2g backlog

People

(Reporter: zbraniecki, Unassigned)

References

(Depends on 1 open bug)

Details

(Keywords: meta, perf, Whiteboard: [c=progress p= s= u=])

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.
Depends on: 809668, 812396, 811593
Depends on: 812441
Depends on: 812451
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.
> 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.
There are also certain ideas in bug 781613 that may help reduce the load time
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.
Depends on: 812643
Depends on: 781613
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.
No longer depends on: 812451
Keywords: perf
I'm going to reuse this old bug as a meta for some other bugs/tools I want to add on this subject.
Alias: butter-delivery
OS: Mac OS X → Gonk (Firefox OS)
Hardware: x86 → ARM
Summary: [tracking] Reduce app booting time → Tracking: Reduce app load time
Whiteboard: [u=profiliing s= p= c=]
Whiteboard: [u=profiliing s= p= c=] → [c=progress p= s= u=]
Depends on: 990003
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
Component: Gaia → Performance
Keywords: meta
Priority: -- → P2
Summary: Tracking: Reduce app load time → [meta] Reduce app load time
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
[Tracking Requested - why for this release]:
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.