The numbers coming from performance.timing API show a major difference in the performance of DOM loading for webapps vs. local apps. on Unagi phone. NAME emulator+loc Unagi+web Unagi+loc performance.navigationStart 0 0 0 (…) performance.responseEnd 0 1 121 performance.domLoading 1 221 469 performance.domInteractive 16 334 983 performance.domContentLoadedEventStart 25 332 1181 performance.domContentLoadedEventEnd 25 333 1181 performance.domComplete 25 366 1189 performance.loadEventStart 25 366 1189 NAME UnaNoOOP+web UnaNoOOP+local performance.navigationStart 0 0 (…) performance.responseEnd 0 11 performance.domLoading 229 383 performance.domInteractive 285 809 performance.domContentLoadedEventStart 366 1182 performance.domContentLoadedEventEnd 366 1182 performance.domComplete 400 1182 performance.loadEventStart 400 1182 The visible difference is between responseEnd and domLoading and another between domLoading and domInteractive.

Steps to reproduce: - take the source of the file from URL and place it instead of any local app index.html (or add another local app) - reboot Unagi - open Gaia browser and navigate to URL - open the custom app In order to gather numbers for the cold boot reboot the phone between repeating the query.

More data. I decided to try to move the test outside of Settings app into it's own little perfapp. This resulted in speedups in dom loading! NAME desktop Unagi+Settings Unagi+perftest p.t.navigationStart: 0 0 0 p.t.responseEnd: 24 44 10 p.t.domLoading: 30 501 139 p.t.domInteractive: 43 978 273 p.t.domContentLoadedEventStart: 44 993 283 p.t.domContentLoadedEventEnd: 45 993 283 p.t.domComplete: 46 1016 301 p.t.loadEventStart: 46 1016 301 My only ideas was that maybe application.zip size impacts this, so I removed everything from settings application.zip shrinking it from 700kb to 11kb. No difference. In my perftest app I'm getting stable result with no variance, in Settings the variance on domLoading and domInteractive is ~10, but this is an average from 5 cold loads. The numbers for the same code loaded from the web on Gaia::Browser are similar to PerfTest, so that's probably how far we can get with current DOM engine. This branches into two questions: 1) Why is Settings app that much slower? 2) Are there any low hanging fruits to lower the DOM cost for the webapp on Unagi?

we can ignore the Settings app. It's bug 808919 - Settings app is loaded during boot. So, the core of the bug is: DOM loading takes ~300ms on Unagi. Can we reduce this number?

I measured difference between loading almost empty HTML file and full settings app HTML (uncommented all sections): NAME min HTML long HTML p.t.navigationStart: 0 0 p.t.responseEnd: 10 11 p.t.domLoading: 139 157 p.t.domInteractive: 273 547 p.t.domContentLoadedEventStart: 283 664 p.t.domContentLoadedEventEnd: 283 664 p.t.domComplete: 301 664 p.t.loadEventStart: 301 664 The current dirty hack to comment out all sections and then innerHTML one by one when requested saves another ~300ms. Is there a way to shave it?

We now have a case where we need to load big HTML file but we show just a small portion of it at the time - Gaia's Settings app ( https://github.com/mozilla-b2g/gaia/blob/master/apps/settings/index.html ). The way we avoid paying for it right now is by commenting out everything and loading by injecting comment's content via innerHTML into it's block. That's hardly the good example for how to write webapps. Henri: would it be possible to lazy load hidden HTML blocks?

(In reply to Zbigniew Braniecki [:gandalf] from comment #5) > The way we avoid paying for it right now is by commenting out everything and > loading by injecting comment's content via innerHTML into it's block. (In theory, you are supposed to use <script type="non-js/type">...</script> for that, not comments, where "non-js/type" is something that is not a known JS, VBScript or Dart MIME type and unlikely to be a MIME type of a future scripting language [as unlikely as it is that we'd ever support a non-JS scripting language].) > Henri: would it be possible to lazy load hidden HTML blocks? The hiddenness couldn't depend on CSS. It would have to depend on markup. And if it depended on markup, the parser would still have to parse the block somehow to see where it ends. The closest thing coming up in the feature pipeline is the Chrome-proposed <template> element, but it involves creating as many DOM nodes as there are start tags at the time of the initial document parse. Thus, if early node creation is your bottleneck, <template> won't help you. So, no.

Does this still occur on 1.3 or 1.4 on current hardware? (unagi is deprecated)

Refreshing the needinfo for comment 7

removing NI from old bugs.

I should not be allowed near computers...

Firefox OS is not being worked on