Performance

HTTP/2

Also called HTTP/2.

HTTP/2 is the HTTP version that sends many requests and responses at once over a single TCP connection. It replaces the six-sockets workaround of HTTP/1.1 with multiplexed streams.

How it is measured

Check the Protocol column in the Network panel for `h2`. Streams share one connection, headers are compressed with HPACK, and the server can set priorities.

It removes the need for domain sharding and sprite sheets, but a single lost TCP packet still stalls every stream on that connection, a limit known as head-of-line blocking at the transport layer.

Worked example

A page requesting 62 assets over HTTP/1.1 across six connections finishes at 4,300 ms on a 120 ms RTT link. The same page over HTTP/2 on one connection finishes at 2,650 ms. On a lossy mobile link at 3 percent packet loss, the HTTP/2 time rises to 3,900 ms.

Bundling all the files into one to save requests now makes caching worse, because a one-line change invalidates the whole bundle.

How it differs

HTTP/2 multiplexes over TCP. HTTP/3 does the same over QUIC and UDP, so a lost packet only blocks its own stream. Connection reuse is the broader idea, and HTTP/2 makes it the norm rather than something to configure.

Common errors

Still concatenating everything out of habit. Sharding assets over several hostnames and defeating multiplexing. Assuming HTTP/2 fixes a slow server. Serving it without TLS, since browsers require HTTPS. Not checking that the CDN actually negotiates h2 to the visitor.

In practice

Check your Protocol column and confirm h2 or h3 on your main host. Drop domain sharding, keep bundles to a sensible granularity, and look at third parties still on HTTP/1.1.

See also

HTTP/3, Connection reuse

Sources

Count this on a real site.

Watch my website