Reference guide · performance · Published 2026-08-16 · 3 min read
HTTP/3 and QUIC explained
HTTP/3 and QUIC explained: how connections map to streams, what it fixes, and how to verify your CDN or origin is serving it.
- ·The big change
- ·Verify your site
- ·When it matters
The big change: a connection that is not one connection
HTTP/1.1 opens one TCP connection per request (or reuses a small pool). HTTP/2 multiplexes many requests over one TCP connection, but a single packet loss on that connection stalls every stream behind it. HTTP/3 keeps multiplexing and fixes the stall, by replacing TCP and TLS inside the protocol with QUIC, which runs over UDP port 443.
Three transport facts drive the improvement:
- 0-RTT and 1-RTT resumption. QUIC carries a connection ID that survives IP and port changes, so a phone moving between Wi-Fi and mobile does not restart the handshake. Combined with session resumption, repeat visits can send data on the very first round trip.
- Independent streams. In QUIC, each stream is congestion-controlled on its own. If one stream drops a packet, the others keep moving, which is exactly the fix for the HTTP/2 head-of-line blocking problem.
- No TLS on top of TCP. TLS 1.3 is integrated into the QUIC handshake, which removes a round trip versus the TCP+TLS+HTTP/2 stack.
Do you need to do anything?
In practice, HTTP/3 is a server (or CDN) transport choice, activated the moment the edge supports it, and negotiated by Alt-Svc (h3=":443"). There is nothing to write in your markup. Cloudflare enables QUIC automatically on its edge, Fastly and Akamai do the same, and your origin rarely needs to speak it at all because the CDN terminates it. The checklist to confirm your site:
curl -I --http3 https://example.com/ 2>&1 | head -n 3- Look for
HTTP/3in the response line, or run an online QUIC test. - Timeline truth: verify with browser logs,
chrome://net-internals/#http3, or a curl with--http3-only. - The evidence shows in DevTools: the request protocol column reads
h3instead ofh2, and the certificate panel showsQUIC (1.3)once enabled.
When HTTP/3 is a real win (and when it is not)
| Situation | Likely effect |
|---|---|
| Long-distance, high-loss tails (mobile, noisy networks) | Real: QUIC's per-stream loss recovery cuts stalls that hurt LCP on weak connections |
| Wi-Fi to mobile handoff | Real: connection IDs let the session survive the address change |
| Already behind a CDN with fast TTFB | Little to gain: HTTP/2 + CDN already removed most of the transport overhead |
| Corporate LAN / WAF that filters UDP | A block turns the Alt-Svc offer into a fallback to HTTP/2; the site still works, just without the h3 path |
The transport metrics your tests care about are actual TTFB and the CDN-first architecture, not the protocol itself. HTTP/3 narrows the first-connection gap, but a misconfigured origin, no CDN, or a slow backend dominates the delta.
Adoption caveats that are easy to miss
Alt-Svcstrength and expiry means a CDN edge that flips the header but keeps origin on HTTP/2 just showsh2in DevTools for most clients; the real signal is the CDN's own UI reporting HTTP/3.- UDP passthrough on firewalls/NAT can be flaky; QUIC clients fall back to TCP+TLS automatically, so a suddenly-broken HTTP/3 setup shows as slow, not broken.
- Business WAF appliances that block UDP:443 can silently force everything to the HTTP/2 fallback. If you operate such a chain, an "enable HTTP/3" checkbox on a CDN is cosmetic until the network path allows it.
The handshake and ALPN/H2 articles build the transport context HTTP/3 completes, and TTFB shows where the transport actually shows up in measurements.