[JonathonW]

The big thing that HTTP/2 brings as far as pipelining is concerned is that requests and responses can be multiplexed over the same connection to avoid the head-of-line blocking problem with HTTP/1.1. HTTP/1.1 requires pipelined responses to be sent strictly in the order they're requested; HTTP/2 can send responses in any order or even multiplexed/interleaved (hence the network activity graph from the OP).

Also, most browsers don't enable HTTP pipelining by default-- they'll reuse a connection if possible, but won't make multiple requests at once for compatibility reasons. Chrome even supported it for a while, but had to remove it because it didn't work (bugs in Chrome, bugs in servers, and the head-of-line blocking problem made it not worth keeping) [1].

[1] https://www.chromium.org/developers/design-documents/network...

[bsdetector]

Head of line blocking is mostly a theoretical concern not a practical one. Since browsers use 6+ connections at once, a large slow request will only hold up a few resources and usually doesn't affect the page load speed by much. In fact, as shown recently interleaving can actually slow down the page rendering. Then there's the priority system, an inversion of which caused Google Maps to load far more slowly over HTTP/2. The main problem solved by interleaving responses is when there are 6 slow resources that tie up all the connections causing deadlock, which is because of browsers capping the number of connections.

Google spread a lot of FUD in their push to get SPDY standardized. For instance they never compared to pipelining, which is relevant because Microsoft found that with pipelining HTTP was essentially just as fast. Google's mobile test where they claimed ~40% speedup used 1 SPDY TCP connection for the entire simulated test run of many sites vs new connections per site for HTTP -- a simple mistake? Maybe, but they didn't take any steps to correct it once they were made aware of it.