On Sunday, April 24, 2016, Daniel Friesen <daniel(a)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
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(a)lists.wikimedia.org <javascript:;>
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org <javascript:;>
https://lists.wikimedia.org/mailman/listinfo/wikitech-l