HTTP/1 connections are limited to one request on the connection at a time and head-of-line blocking. HTTP/2 connections will also be pooled but are able to sustain many more concurrent requests because of multiplexing, while also setting certain requests as higher priority. It's a major improvement for high volume services.

The performance and features are why Google's gRPC uses it as the foundation for microservice communications at scale and low-latency.

>HTTP/1 connections are limited to one request on the connection at a time and head-of-line blocking.

This is true, however this limitation just increases the size of the connection tool needed for the same concurrency. I'm not saying HTTP/2 isn't better, I'm saying its less better for middleware than end user connection optimization.

If you have 100k people who've opened e.g. websocket connections to your backend, I doubt you're going to structure things as a 100k-socket connection pool open to your backend. You've probably either:

A. got that scaled across at least 100 backend servers, even if those servers' CPUs are almost entirely idle; or

B. have chosen a completely different, extremely roundabout architecture involving client async requests with HTTP 202 responses + client polling of a "status of server-side promises" endpoint; or

C. are effectively manually doing what HTTP2 does automatically, by having a "stateful-connection load-balancer server" (e.g. SocksJS) that mediates between long-lived client connections, and short-lived RPC requests with async responses from your backend.

Whereas, with HTTP2, that could very easily be one machine, taking in those 100k nearly-idle connections, and passing them over one TCP socket to one backend.