Not sure I agree here. The binary protocol aspect of HTTP/2 is already a massive benefit, especially when combined with the ability to omit redundant headers.

Not sure I agree here. The binary protocol aspect of HTTP/2 is already a massive benefit, especially when combined with the ability to omit redundant headers. Consider e.g. just a basic API with Bearer tokens - those tokens are sent once instead of on each request. Cloudflare saw a 53% reduction in ingress volume size (https://blog.cloudflare.com/hpack-the-silent-killer-feature-of-http-2/ https://blog.cloudflare.com/hpack-the-silent-killer-feature-...). These changes restore something that had been lost - efficient use of the available bandwidth - GET requests fit in one packet. W.r.t. head of line blocking, all you have to do is find a website that shows a hundred pictures or loads a hundred scripts and you can see the benefit. It's true that the benefit is minor if you're already webpacking and spriting everything, but restoring performance to naive implementations that just use the img tags is not a minor benefit. See this website for example: https://imagekit.io/demo/http2-vs-http1 https://imagekit.io/demo/http2-vs-http1. HTTP/3 adds a lot more complexity than HTTP/2 added, for a smaller benefit, but.. that's how these things go. Our processors reorder instructions too. Even if it's only single digit percent, optimization are worth it. A few percent in the processor, a few percent in the OS, a few percent from the network, a few percent from the JIT - these things add up.