Regarding #4 isn't this a bit cheating, who doesn't use keep-alive. Also what about request pipelining? Doesn't that basically do the sane thing what http/2 is doing?
You'd be surprised how many servers don't have keep-alive enabled, it's much more common than I'd like.
I'm a great fan of HTTP/2 but I'd like to see realistic tests!
But that doesn't fit the narrative. Did Google ever test against pipelining? Did IETF? No, they didn't. Did Google ever show the effect of head-of-line blocking on page load speed, especially when spread over several independent TCP connections? No, they didn't. Why didn't they do this basic research before pushing their new protocol?
They just said "it's 40% faster! rubber stamp this because it's in Chrome!" and some of their fans even created stacked demos where pipelining wouldn't be used (perhaps unintentionally, but still invalid comparisons).
I think if you read back though people like Will Chan's and others blogs it becomes clear that pipelining doesn't work reliably enough outside a test lab environment plus HoL blocking is still an issue for it
Will Chan is the guy that wrote "it’s unclear what these intermediaries are". Oh well, there's some bad software out there, let's just make a whole new protocol /s. Fix the bad software, or at least find out what it is. If it's malware causing the problems, you don't need to make a whole new protocol you can just get rid of the malware.
https://bugzilla.mozilla.org/show_bug.cgi?id=264354 https://www.chromium.org/developers/design-documents/network...
It's a fair bet that the reason these companies didn't find out what was causing the very few failures was because it was due to SuperFish or other illicit software. Some people's computers having malware isn't a good reason disable pipelining.
Firefox found far from universal success even after years of testing and blacklisting known-noncompliant servers:
http://bitsup.blogspot.com/2012/11/a-brief-note-on-pipelines...
(the actual blacklist at the time http://hg.mozilla.org/mozilla-central/file/1d122eaa9070/netw...)
Opera's implementation apparently relied on some non-trivial heuristics but they apparently weren't well documented and were discontinued with the transition to Blink.
Similarly, it's easy to find cases where people discovered real problems in the wild with the iOS implementation:
http://tech.vg.no/2011/12/14/safari-on-ios-5-randomly-switch...
(This also affected Mozilla: https://bugzilla.mozilla.org/show_bug.cgi?id=716840)
https://github.com/AFNetworking/AFNetworking/issues/528
It's easy to understand why people decided that it wasn't worth investing so much time in this when HTTP/2 would deliver significant additional benefits and by using TLS as a starting point could provably avoid the worst tampering proxies entirely.
Also the OP test gave similar order of magnitude.
It looks like HTTP2 will be awesome for mobile!
If you have a low-latency connection close to the server you can easily find cases where HTTP/1 is still competitive – e.g. in this case using Akamai's demo with a 2ms ping time to their closest CDN node:
https://www.dropbox.com/s/9zo844ue7ehwg58/Screenshot%202015-...
(That's presumably due to the HTTPS setup – even with caching disabled, that page takes ~.8 seconds on a reload)
The catch, of course, is recognizing that this is not the case for most people and so even if we're personally not seeing a huge benefit on a fast computer in an office, it's still of huge benefit to anyone on a cellular network, flaky wifi, saturated ISP connection on another continent.