Closed Bug 812643 Opened 13 years ago Closed 7 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: 7 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.