Closed Bug 812643 Opened 12 years ago Closed 6 years ago

webapp's CSS/JS resources for index.html fetch time is slow

Categories

(Core Graveyard :: DOM: Apps, defect)

Product:
Core Graveyard
Component:
DOM: Apps
Platform:
ARM
Gonk (Firefox OS)
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: zbraniecki, Unassigned)

References

(
URL
)

Details

(Keywords: perf) 

Spin off of bug 811593.

It takes roughly a second to load empty index.html file on Unagi.

according to performance.timing.* numbers a significant amount of this time is taken between navigationStart and fetchStart (around 121ms).

If we turn off OOP it drops down to 5ms.
The performance numbers:

NAME                                     desktop+localHTTP  emulator+local  Unagi+web  Unagi+local
performance.navigationStart              0                  0               0          0
performance.unloadEventStart             3                  0               0          0
performance.unloadEventEnd               3                  0               0          0
performance.fetchStart                   0                  0               1          121
performance.domainLookupStart            1                  0               1          121
performance.domainLookupEnd              1                  0               1          121
performance.connectStart                 0                  0               1          121
performance.connectEnd                   0                  0               1          121
performance.requestStart                 2                  0               1          121
performance.responseStart                2                  0               1          121
performance.responseEnd                  2                  0               1          121

NAME                                     UnaNoOOP+web       UnaNoOOP+local  
performance.navigationStart              0                  0               
performance.unloadEventStart             0                  11               
performance.unloadEventEnd               0                  11              
performance.fetchStart                   0                  11               
performance.domainLookupStart            0                  11              
performance.domainLookupEnd              0                  11              
performance.connectStart                 0                  11              
performance.connectEnd                   0                  11              
performance.requestStart                 0                  11              
performance.responseStart                0                  11              
performance.responseEnd                  0                  11
URL: http://www.braniecki.net/i.html
Summary: webapp strartup time is slow → webapp's index.html fetch time is slow
Steps to reproduce:
 - replace Settings app index.html with the one from the URL
 - upload to Unagi
 - reboot
 - launch Settings app

(for DOM perf I filed bug 812441)
After some chatting on IRC:  this isn't about actual HTTP performance--network perf is fine (<1 ms for localhost load).  The slowness is specifically loading out of process using the app:// protocol (i.e. reading jar files).  It seems to actually take longer than loading off of (localhost) network does.  

I'm not sure which bug component app:// stuff should live it, or even who knows that code.  Guessing bent or sicking does.
Component: Networking → DOM: Apps
One second might be a tad long - is this bad enough to block?
blocking-basecamp: --- → ?
one second is definitely slow and degrades user experience, but that's not only this bug.
It's a result of at least four bugs:
 - this one
 - DOM loading delay (bug 812441)
 - potentially subsequent resources load slowness bug like <link/> and <script/> (not filed yet - and this may be the same bug as this one, don't know yet - working on a testcase)
 - XHR load (important for L10n resource loading) - bug 811593
I moved my test to a separate app and it seems that there's a difference depending if the index.html is fired in settings app or as a separate app:

NAME                            desktop Unagi+myapp     Unagi+Settings  Unagi+web
p.t.navigationStart:            0       0               0               0
p.t.fetchStart:                 0       10              99              0
p.t.domainLookupStart:          1       10              99              0
p.t.domainLookupEnd:            1       10              99              0
p.t.connectStart:               0       10              99              0
p.t.connectEnd:                 0       10              99              0
p.t.requestStart:               1       10              99              0
p.t.responseStart:              18      10              99              0
p.t.responseEnd:                18      10              99              0
p.t.domLoading:                 19      138             425             322

Also, not sure why the numbers for the web are so low (this is cold boot, there should be no caching, right?)
>  not sure why the numbers for the web are so low

If unagi+web is using localhost, those numbers might be ok (A simple Websocket create-then-shutdown-connection test I created for bug 770718, which does two network round trips instead of one still take ~3.6ms on localhost).   If it's to a server with any real latency than the numbers are bogus.  What does 'ping hostname' report?
Unless of course the resource is in the HTTP cache.  But even then 0ms is pretty fast :)
(In reply to Jason Duell (:jduell) from comment #7)
> >  not sure why the numbers for the web are so low
> 
> If it's to a server with any real latency than the numbers are
> bogus.  What does 'ping hostname' report?

It's to www.braniecki.net/i.html - cold boot (so I assume no cache?)

There's no ping on android, but I fired it from my laptop (same network - SF office):
zbraniecki@Zbigniews-MacBook-Pro:~/projects/gaia (perftest %)$ ping www.braniecki.net
PING www.braniecki.net (173.236.134.223): 56 data bytes
64 bytes from 173.236.134.223: icmp_seq=0 ttl=55 time=12.821 ms
64 bytes from 173.236.134.223: icmp_seq=1 ttl=55 time=14.460 ms
64 bytes from 173.236.134.223: icmp_seq=2 ttl=55 time=12.981 ms

So the numbers do look bogus - do you want me to file separate bug?
So it gets more interesting. I now see two conditions that affect index.html+resources load.

First one is wherever it's Settings app or my custom perftest app. I don't know why Settings behaves differently but it's very reproducable.

Second is the number of CSS <links/> and JS <scripts/> referenced by the index.html. This is to be expected but the numbers are quite high. We can minify the CSS/JS (bug 812396) but it would still be worth to look into why the numbers are that high.


Empty custom app index.html:
navStart: 0
fetchStart: 13
domLoad: 139
domInt: 286
domContStart: 296
domComplete: 316
loadEvent: 316

Empty Settings index.html:
navStart: 0
fetchStart: 101
domLoad: 390
domInt: 746
domContStart: 913
domComplete: 917
loadEvent: 917

This confirms the numbers from Comment 6

Now, let's add <links/> and <scripts/> - http://pastebin.mozilla.org/1945376 - I made sure to turn off all scripts inline activity (so it only loads the source and parses it)

custom app index.html:
navStart: 0
fetchStart: 13
domLoad: 140
domInt: 512
domContStart: 614
domComplete: 616
loadEvent: 616

Settings index.html:
navStart: 0
fetchStart: 99
domLoad: 357
domInt: 1341
domContStart: 1505
domComplete: 1505
loadEvent: 1522

So with empty app, adding those resources increases the time until onload from 300ms to 600ms on Unagi. That's pretty significant and would be worth investigating.

For Settings app it increases by 600ms from 900ms to 1500ms. I have no idea why.
D'uh! I just figured out what's wrong with settings app vs. custom app!

I added timestamp to window.onload on both apps and despite me starting custom app first, settings had lower timestamp!

It's bug 808919 - Settings app is loaded during boot.

So we can ignore Settings app numbers, they're all skewed because the app is loaded during booting.

This means that for an empty app loading locally resources from settings app costs ~300ms. Can we improve that timing?
Summary: webapp's index.html fetch time is slow → webapp's CSS/JS resources for index.html fetch time is slow
This bug is a bit too much all over the map to block on it. But please don't stop investigating here though and once we have concrete things that we know are wrong file separate bugs on those and nominate for blocking.

I think trying to figuring out what's going wrong here will be very hard by simply poking at performance.timing.*. Someone needs to run this through a profiler or a debugger.
blocking-basecamp: ? → -
Keywords: perf
Product: Core → Core Graveyard
Core Graveyard / DOM: Apps is inactive. Closing all bugs in this component.
Status: NEW → RESOLVED
blocking-basecamp: - → ---
Closed: 6 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.