Started as quick thoughts, turned into more of an essay, so I've posted the bulk on mediawiki.org:
https://www.mediawiki.org/wiki/User:Brion_VIBBER/ResourceLoader_and_latency
tl;dr summary:
On slow networks, latency in loading large JS and HTML resources means things don't always work right when we first see them.
If we take advantage of HTTP 2 we could skip the concatenation of separate ResourceLoader modules to reduce latency until each module _runs_, without adding _network_ latency.
And if we're more clever about handling 'progressive enhancement' via JS _while_ an HTML page loads, we could reduce the time before large pages become fully interactive.
-- brion
Tangentially related, Chrome plans to drop support for SPDY and go HTTP/2 only this year, Edge already dropped support for SPDY, and other browsers may too. So before this is actually implemented, Wikimedia might want to upgrade web server software to support HTTP/2 (currently MediaWiki.org looks to only be using SPDY).
Though a sad realization is that IE11 only supports HTTP/2 on Windows 10 (other Windows versions will only support SPDY) and same goes for Safari only doing HTTP/2 on OSX 10.11+. Which is relevant because some webservers like Nginx intentionally drop the SPDY implementation in the release they implement HTTP/2.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]
On 2016-04-23 3:08 PM, Brion Vibber wrote:
Started as quick thoughts, turned into more of an essay, so I've posted the bulk on mediawiki.org:
https://www.mediawiki.org/wiki/User:Brion_VIBBER/ResourceLoader_and_latency
tl;dr summary:
On slow networks, latency in loading large JS and HTML resources means things don't always work right when we first see them.
If we take advantage of HTTP 2 we could skip the concatenation of separate ResourceLoader modules to reduce latency until each module _runs_, without adding _network_ latency.
And if we're more clever about handling 'progressive enhancement' via JS _while_ an HTML page loads, we could reduce the time before large pages become fully interactive.
-- brion _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Sunday, April 24, 2016, Daniel Friesen daniel@nadir-seen-fire.com wrote:
Tangentially related, Chrome plans to drop support for SPDY and go HTTP/2 only this year, Edge already dropped support for SPDY, and other browsers may too. So before this is actually implemented, Wikimedia might want to upgrade web server software to support HTTP/2 (currently MediaWiki.org looks to only be using SPDY).
Though a sad realization is that IE11 only supports HTTP/2 on Windows 10 (other Windows versions will only support SPDY) and same goes for Safari only doing HTTP/2 on OSX 10.11+. Which is relevant because some webservers like Nginx intentionally drop the SPDY implementation in the release they implement HTTP/2.
Yeah, transition will be "fun". We need to make sure we either have something that works well enough on both http 1.1 and 2 if we can't keep SPDY for the slightly older browsers, or play fun games with variant caching so we have a concatenated loader setup and a non-concatenated loader setup. :)
For those not familiar, SPDY is roughly the experimental predecessor of the new HTTP/2, providing most of the same benefits but not quite compatible with the final standard. As a transitional technology it's getting dropped from some of the things that are updating, but we're going to see some folks stuck on browser versions in the middle with SPDY but no HTTP/2... And others with older browsers that support neither:
http://caniuse.com/#feat=spdy http://caniuse.com/#feat=http2
-- brion
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]
On 2016-04-23 3:08 PM, Brion Vibber wrote:
Started as quick thoughts, turned into more of an essay, so I've posted
the
bulk on mediawiki.org:
https://www.mediawiki.org/wiki/User:Brion_VIBBER/ResourceLoader_and_latency
tl;dr summary:
On slow networks, latency in loading large JS and HTML resources means things don't always work right when we first see them.
If we take advantage of HTTP 2 we could skip the concatenation of
separate
ResourceLoader modules to reduce latency until each module _runs_,
without
adding _network_ latency.
And if we're more clever about handling 'progressive enhancement' via JS _while_ an HTML page loads, we could reduce the time before large pages become fully interactive.
-- brion _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org javascript:; https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org javascript:; https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Sun, Apr 24, 2016 at 1:39 AM, Brion Vibber bvibber@wikimedia.org wrote:
On Sunday, April 24, 2016, Daniel Friesen daniel@nadir-seen-fire.com wrote:
Tangentially related, Chrome plans to drop support for SPDY and go HTTP/2 only this year, Edge already dropped support for SPDY, and other browsers may too. So before this is actually implemented, Wikimedia might want to upgrade web server software to support HTTP/2 (currently MediaWiki.org looks to only be using SPDY).
Though a sad realization is that IE11 only supports HTTP/2 on Windows 10 (other Windows versions will only support SPDY) and same goes for Safari only doing HTTP/2 on OSX 10.11+. Which is relevant because some webservers like Nginx intentionally drop the SPDY implementation in the release they implement HTTP/2.
Yeah, transition will be "fun". We need to make sure we either have something that works well enough on both http 1.1 and 2 if we can't keep SPDY for the slightly older browsers, or play fun games with variant caching so we have a concatenated loader setup and a non-concatenated loader setup. :)
For those not familiar, SPDY is roughly the experimental predecessor of the new HTTP/2, providing most of the same benefits but not quite compatible with the final standard. As a transitional technology it's getting dropped from some of the things that are updating, but we're going to see some folks stuck on browser versions in the middle with SPDY but no HTTP/2... And others with older browsers that support neither:
http://caniuse.com/#feat=spdy http://caniuse.com/#feat=http2
We use Nginx for TLS and SPDY termination, which makes supporting both SPDY and HTTP/2 unfeasible. The plan is to replace SPDY support with HTTP/2 on or before Chrome does it on May 15 http://blog.chromium.org/2016/02/transitioning-from-spdy-to-http2.html. This is tracked in Phabricator as T96848 https://phabricator.wikimedia.org/T96848.
The browsers that support SPDY are all evergreen (self-updating by default), so I expect the migration to HTTP/2 will be quicker than what we are accustomed to with browser technology. But HTTP 1.1 won't go anywhere for an aeon.
On Sat, Apr 23, 2016 at 3:08 PM, Brion Vibber bvibber@wikimedia.org wrote:
Started as quick thoughts, turned into more of an essay, so I've posted the bulk on mediawiki.org:
https://www.mediawiki.org/wiki/User:Brion_VIBBER/ResourceLoader_and_latency
tl;dr summary:
On slow networks, latency in loading large JS and HTML resources means things don't always work right when we first see them.
If we take advantage of HTTP 2 we could skip the concatenation of separate ResourceLoader modules to reduce latency until each module _runs_, without adding _network_ latency.
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)
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?
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.
On Monday, April 25, 2016, Ori Livneh 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 javascript:; https://lists.wikimedia.org/mailman/listinfo/wikitech-l
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
wikitech-l@lists.wikimedia.org