From HTTP/1.1 to HTTP/2

HTTP/1.1 can reuse a TCP connection with keep-alive, but responses on one connection arrive in order. If one response is slow, everything behind it waits. That is head-of-line blocking at the HTTP layer.

Browsers worked around this by opening several connections per origin, often six at a time. That helped, but each connection still had its own queue.

HTTP/2 changed the transport shape. Messages become binary frames. Several independent streams share one TCP connection. A slow API response does not have to block a CSS file behind it on the same connection.

HTTP/2 also compresses headers with HPACK. That helps when many requests repeat the same cookies, user agents, and accept headers. Less bytes on the wire on every request.

The application semantics do not change. A GET is still a GET. A 404 is still a 404. Browsers and servers negotiate the protocol during the TLS handshake. Your route handlers stay the same.

Check which version curl uses:

curl -I --http2 https://flaviocopes.com/

The first line should read HTTP/2 200. Force HTTP/1.1 to compare:

curl -I --http1.1 https://flaviocopes.com/

You get HTTP/1.1 200 instead. Same page, different wire protocol.

In Chrome DevTools, add a Protocol column to the Network panel. Modern sites often show h2 for HTTP/2 on most requests.

Every stream in HTTP/2 still shares one ordered TCP connection. If a TCP packet is lost, all streams on that connection can stall until the retransmit arrives. That is transport-level head-of-line blocking. HTTP/3 addresses it by moving to QUIC over UDP.

Be careful assuming HTTP/2 fixes slow APIs. Multiplexing helps parallel asset loading. It does not make your database queries faster.