QUIC vs HTTP/2: what actually makes HTTP/3 faster
HTTP/3 is not "HTTP/2 but faster". It is HTTP/2 on a different transport – and virtually every advantage comes from that change, not from the protocol on top.
Head-of-line blocking: the real reason
HTTP/2 can send multiple requests in parallel over one connection (multiplexing), which solved a genuine HTTP/1.1 problem. But all those streams run through one TCP connection, and TCP guarantees the ordering of every byte.
Lose a single packet and TCP holds back everything that follows until it has been retransmitted – including data belonging to streams that have nothing to do with the lost packet. Ten parallel downloads, one lost packet, and all ten stall.
QUIC knows about the streams itself and manages them independently. Packet loss in stream 3 does not hold up stream 7. That is the heart of it – and the reason the difference is hard to notice on a clean wired connection and very noticeable on a crowded train.
Handshake: one round trip less
An HTTPS connection over TCP needs the TCP handshake first, then the TLS handshake – with TLS 1.3 that is two round trips before the first byte of payload moves.
QUIC merges the two: transport and encryption are established together, so one round trip is enough. Reconnecting to a known server can even go 0-RTT, with the first request riding along in the very first packet.
In numbers: at 30 ms latency that saves ~30 ms; at 200 ms mobile latency, ~200 ms. Which is why the effect is far more noticeable on a phone than at a desk.
Connection migration
A TCP connection is defined by IP address and port. When a phone switches from Wi-Fi to mobile data the IP changes, the connection dies, and everything starts over.
QUIC identifies connections by their own connection ID, independent of the IP. Switching from Wi-Fi to cellular therefore does not interrupt a running download. For classic websites this is an edge case; for streaming and long uploads it is a major advantage.
Where HTTP/3 does little
In fairness, there are cases where the gain is close to zero.
- Stable connections with little packet loss. No loss means no head-of-line blocking to avoid in the first place.
- Few, large files. Multiplexing pays off with many small requests.
- Server CPU. QUIC runs in user space rather than the kernel and is more compute-intensive than TCP. At very high throughput HTTP/3 can even be marginally costlier.
There is still hardly an argument against it: browsers fall back to HTTP/2 automatically when QUIC is unavailable. The risk is essentially nil and the gain for mobile visitors is real.
So what happens to HTTP/2?
HTTP/2 is not going away. Every HTTP/3-capable server keeps speaking HTTP/2, if only because the first connection runs over it (see Alt-Svc). The realistic split today: HTTP/3 for browsers that can and may use it, HTTP/2 as a solid foundation for everything else.
Whether your site offers both is something the HTTP/3 check tells you in seconds.
