[daper]

The way I look at the major improvements in the two recent HTTP versions is:

HTTP/2 was needed to better utilize the bandwidth by keeping the TCP connection busy without silence period. That means instead of "request - RTT delay - response - RTT delay - request - RTT delay- response ..." we have "request - request - request - response - response - response ..." without pauses between responses. These pauses in HTTP/1.1 cause the congestion windows drop to initial value and slow start after each response. For HTTP/1.1 the workaround was to establish multiple TCP connections to fetch resources in parallel. This + using multiple domains for assets was best practice with HTTP/1.1 and is not needed (or even discouraged) with HTTP/2.

The above change has a drawback: for links with high latency and lower reliability a single packet loss is causing this whole pipline to stall. The cause is how TCP retransmission + congestion control works. This is in contrast to multiple HTTP/1.1 connections where just single connection would stall and take time to recover to full speed. This has bigger impact on performance in wireless connections and content like live video streaming so something that the world move to.

To fix that HTTP/2 moves congestion control to upper layer that understand what is transmitted. Loss of single packet no longer causes the whole pipeline stall, it affects only the resource for which the loss occurred.

This all is needed especially in mobile networks. In older times the a good CDN was used to put content close to the user (or at least terminate the TCP connection close to the user) lowering the round trip time, TLS handshake time. With mobile connections becoming more popular this doesn't work because the big delay is in the "last mile" - in mobile link. You just can't move the CDN's server closer to cut this latency.

Of course there are also other improvements like faster connection establishment (with TLS).