I also didn't really distinguish three separate perf points in my blurb: * time to first paint * time to bare page interactivity * time to enhanced page display / interactivity
Mainly I was concentrating on the third point, but the first two -- which y'all are already doing a great job on -- are even more important and should not regress or we will be sad pandas. :)
/me gets on a plane, will comment more later
-- brion
On Monday, April 25, 2016, Brion Vibber bvibber@wikimedia.org wrote:
On Monday, April 25, 2016, Ori Livneh <ori@wikimedia.org javascript:_e(%7B%7D,'cvml','ori@wikimedia.org');> wrote:
Not so straight-forward. Khan Academy tried unbundling JavaScript on HTTP/2 page views last November and found that performance got worse. They attribute the regression primarily to the fact that bundling improves compression. They concluded that "it is premature to give up on bundling JavaScript files at this time, even for HTTP/2.0 clients."
(http://engineering.khanacademy.org/posts/js-packaging-http2.htm)
Nice, I'll go read that. :)
On most browsers, we take advantage of localStorage pretty heavily in order to have a durable cache of individual modules. Without it, slight variations in the module requirements would occasion re-downloading a lot of JavaScript, as the browser had no way of reusing JavaScript and CSS delivered under a different URL. (Service Workers now provide more sophisticated means of doing that, but global browser support is still only at 53%.
We had to disable localStorage caching in Firefox because of the way it manages quotas. Is your primary mobile browser Firefox for Android / iOS?
Service workers are sounding more and more attractive here -- we could rewrite the requests as necessary to bundle when it makes sense etc, and avoid clogging up the synchronous, space-limited localStorage. Needs more research...
Lastly, we have good evidence that above-the-fold external CSS is a bigger contributor to page latency than JavaScript. Gabriel documented that pretty well in T124966 https://phabricator.wikimedia.org/T124966. That CSS is a bigger issue than JavaScript is not surprising (top-loaded CSS is render-blocking, whereas all of our JavaScript is loaded asynchronously), but the magnitude of its impact is impressive.
Krinkle is working on an arc of tasks that would get us there; T127328 https://phabricator.wikimedia.org/T127328 is the master task.
Awesome, I'll read up and comment!
-- brion
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l