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 <[email protected]> wrote: > On Monday, April 25, 2016, Ori Livneh <[email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');>> 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 >> [email protected] >> https://lists.wikimedia.org/mailman/listinfo/wikitech-l > > _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
