HTTP/2 vs HTTP/3: what actually changed and what it means for your site

Why HTTP/1.1 had to go

A modern page needs dozens of resources — HTML, CSS, scripts, images, fonts. HTTP/1.1 could handle one request at a time per connection, so browsers opened six or so parallel connections per host and queued the rest. Every connection paid its own TCP and TLS handshake, and one slow response held up everything queued behind it on that connection. The workarounds of that era — sprite sheets, domain sharding, inlining — were all tricks to smuggle more resources through too few pipes.

What HTTP/2 fixed

HTTP/2 (2015) replaced the pipes with one: a single connection carrying many parallel streams. Any number of requests and responses interleave without queuing behind each other at the HTTP layer; headers are compressed instead of repeated in full on every request; the handshake cost is paid once.

For real sites this was the big jump — the six-connection juggling act disappeared, and pages with many small resources got dramatically faster. It is the protocol most of the web, and most CDNs, serve today. One honest footnote: HTTP/2 moved the head-of-line problem down a layer rather than eliminating it. All those parallel streams still ride one TCP connection, and TCP insists on delivering bytes in order — so a single lost packet pauses *every* stream until it is retransmitted. On clean networks that is rare; on a weak mobile signal it is the tax you pay.

What HTTP/3 changes underneath

HTTP/3 (2022) attacks that remaining tax by replacing TCP with QUIC, a transport built on UDP with TLS 1.3 folded in. Three things actually change. Handshakes get cheaper: transport and encryption are negotiated together, so a new connection costs one round trip instead of two or three — and reconnecting to a known server can cost zero. Packet loss stops being contagious: QUIC tracks streams independently, so a lost packet stalls only the stream it belonged to, not everything else in flight. And connections survive network changes: switching from Wi-Fi to mobile data migrates the connection instead of killing it.

Notice the pattern — every one of these wins is about imperfect networks. That is exactly where HTTP/3 shines: high-latency links, lossy Wi-Fi, mobile users in motion, long distances to the server.

The honest sizing: what each step is worth

On a good connection close to the server, HTTP/3 over HTTP/2 is typically a small single-digit-percent improvement — real, measurable, and invisible to a human. On a lossy mobile link at distance, it can be a large, felt difference. The jump from HTTP/1.1 to HTTP/2, by contrast, was big for nearly everyone. If your traffic is heavily mobile or far-flung, HTTP/3 matters to your tail latencies; if it is mostly desktop on decent networks, it is a refinement.

Meanwhile the things that dominate load time have not moved: how close the content is (edge caching), how heavy it is (images, compression), and how much of it blocks rendering. A cached, Brotli-compressed, image-optimized page over HTTP/2 beats an unoptimized page over HTTP/3 every single time — protocols decide milliseconds, delivery decides seconds. Our edge serves HTTP/2 today, which is where the decisive protocol gain lives; the delivery levers on top of it are where the rest of your speed budget goes.

Check what your site actually speaks

No guessing needed. In the browser, open DevTools → Network, enable the Protocol column, and read it: h2 means HTTP/2, h3 means HTTP/3. From a terminal, curl answers in one line. While you are there, look at the response headers for the cache status too — a protocol upgrade on an uncached origin round trip is polishing the wrong layer.

Inspect the negotiated protocol with curl

# which protocol does the server negotiate?
curl -sI --http2 https://www.example.com -o /dev/null -w 'protocol: %{http_version}\n'

# full picture: protocol + timing + cache status
curl -sI https://www.example.com -w 'protocol: %{http_version}  ttfb: %{time_starttransfer}s\n' | grep -i -E 'HTTP/|cache|protocol|ttfb'

A sane order of operations

Treat protocol as one lever on a board, not the board. First get the decisive wins: serve through an edge cache so content is close, compress text with Brotli, get images into WebP/AVIF at honest dimensions — these move seconds and every visitor benefits. HTTP/2 multiplexing is table stakes and already carries your requests in parallel. Then, if your field data shows mobile tail latencies are where you hurt, protocol refinements are worth attention — measured against your own numbers, not against a vendor benchmark.

The uncomfortable truth of protocol debates is that they are fun and mostly settled, while image weight and cache hit rate are boring and decisive. Optimize in that order.