HTTP/2 vs HTTP/3: what actually changed

The protocol that delivers every web page has quietly had two major upgrades. HTTP/2 made loading many resources far more efficient; HTTP/3 went deeper and swapped out the transport underneath. You mostly don't have to do anything — but understanding the difference helps you know why modern sites feel snappier, and what to enable.

A quick history

Version	The big idea	Runs over
HTTP/1.1	One request at a time per connection	TCP
HTTP/2	Many requests share one connection (multiplexing)	TCP
HTTP/3	Same idea, but on a faster transport	QUIC (over UDP)

What HTTP/2 fixed

Under HTTP/1.1, a browser could only have a few connections per host, and each handled one request at a time — so pages with many assets queued up (the old "head-of-line blocking" at the request level).

HTTP/2 fixed this with multiplexing: many requests and responses share a single connection at once, interleaved. Plus header compression and server hints. The result: pages with lots of resources load much faster, without the old hacks (sprite sheets, domain sharding).

What HTTP/3 changed

HTTP/2 still runs over TCP — and TCP has its own head-of-line blocking: if one packet is lost, everything on that connection waits for the retransmission, even unrelated streams.

HTTP/3 solves this by ditching TCP for QUIC, a new transport built on UDP:

HTTP/3 / QUIC benefit	Why it helps
No TCP head-of-line blocking	A lost packet only stalls its own stream
Faster connection setup	Combines transport + encryption handshakes
Connection migration	Survives a network change (Wi-Fi → cellular) without reconnecting
Built-in encryption	TLS is baked in, not bolted on

The payoff is most noticeable on flaky or mobile networks, where packet loss and network switches are common.

Side by side

	HTTP/2	HTTP/3
Transport	TCP	QUIC (UDP)
Multiplexing	Yes (but TCP can stall it)	Yes (no transport-level blocking)
Setup speed	Two handshakes	One combined handshake
Network changes	Reconnect needed	Seamless migration
Best gains on	Resource-heavy pages	Flaky / mobile networks

Do you need to care?

Mostly, it's handled for you:

Your CDN, load balancer, or host likely supports HTTP/2 already, and increasingly HTTP/3 — often just a toggle.
There's nothing to change in your application code — it's a transport-layer upgrade.
The main action item: make sure HTTP/2 (and ideally HTTP/3) is enabled at your edge. It's free performance.

Practical takeaway: you don't rewrite anything for HTTP/3 — you enable it (usually at your CDN/host). It's a no-downside speed boost, especially for mobile users.

The bottom line

	In one line
HTTP/2	Many requests share one TCP connection (multiplexing).
HTTP/3	Same, but over QUIC/UDP — no TCP stalls, faster, mobile-friendly.
You	Just enable them at your edge; no code changes.

Each HTTP version chips away at the same goal: getting your bytes to users faster. HTTP/2 fixed request juggling; HTTP/3 fixed the connection itself. Flip them on at your CDN and your visitors — especially the mobile ones — feel the difference.