HTTP/3 and QUIC, explained (and why your site feels faster)
Every few years the web gets a new version of HTTP, and HTTP/3 is the biggest change in a while — it threw out TCP entirely. What that means in plain terms, and why your phone notices more than your desktop.
HTTP/3 moves the web onto QUIC, a transport built on UDP instead of TCP. It fixes two long-standing problems: connection setup takes fewer round trips, and one lost packet no longer stalls everything behind it. The benefit is largest on mobile and long-distance connections. You do not change your site to get it — your CDN speaks it and older clients fall back automatically.
Imagine you are downloading a page over a slightly unreliable connection — a train, a busy café, anywhere with a couple of bars of signal. Twelve files are in flight. One packet, belonging to a single image, goes missing.
Under TCP, everything stops. Not just the image — the CSS, the fonts, the other eleven files. TCP guarantees in-order delivery, so it holds everything that arrived after the missing packet in a buffer and refuses to hand any of it to the browser until the retransmission arrives. That is head-of-line blocking, and it is the reason a page can freeze halfway through loading and then arrive all at once.
HTTP/2 was supposed to solve this. It let a browser multiplex many requests over one connection instead of opening six, which fixed head-of-line blocking at the HTTP layer — but all those streams still travelled inside one TCP connection, so a lost packet still stalled all of them at the transport layer. HTTP/2 moved the problem down a level rather than removing it.
Fixing it properly meant changing the transport. And you cannot change TCP — it is implemented in operating system kernels and middleboxes across the entire internet, and getting all of them to update is not a plan. So QUIC was built on top of UDP instead, in user space, where it can actually be deployed and updated.
What QUIC does differently
Independent streams
QUIC understands that a connection carries multiple separate streams, so a lost packet only blocks the stream it belonged to. Your missing image packet stalls that image. The CSS and the fonts keep arriving. On a clean wired connection this changes nothing, because nothing is being lost. On a mobile connection with 2% packet loss it changes a great deal.
A faster handshake
Opening a TLS-over-TCP connection means a TCP handshake, then a TLS handshake — typically two to three round trips before you can send a request. QUIC merges them: the transport and cryptographic handshakes happen together, usually in one round trip. On a connection with 150ms of latency, that saves 150 to 300 milliseconds on every new connection.
Returning visitors can do better still. QUIC supports 0-RTT resumption, where a client that has connected before sends its first request with the handshake rather than after it. There is a caveat — 0-RTT data can be replayed by an attacker, so it should only carry idempotent requests — but for fetching a page it is a real saving.
Connection migration
TCP identifies a connection by the combination of source IP, source port, destination IP and destination port. Change any of them and it is a different connection, which is why walking out of your house and switching from Wi-Fi to cellular kills your download. QUIC identifies connections by a connection ID that travels with them, so the same connection survives the network change and the download continues.
When HTTP/3 does not help much
Worth saying plainly, because the benchmarks people post tend to come from the best case.
On a fast, stable, wired connection with no packet loss, HTTP/3 and HTTP/2 perform very similarly. The handshake saving is real but small in absolute terms when latency is 10ms, and there is no loss for stream independence to help with. If you test only from your office you may conclude the whole thing is marketing.
There are also environments where UDP is throttled or blocked outright — some corporate networks, some older middleboxes. Clients handle this by falling back to HTTP/2, which is why HTTP/3 is advertised rather than mandated: a server announces it via the Alt-Svc header, and a client that cannot make QUIC work simply carries on over TCP. Nobody gets stranded.
QUIC also encrypts almost everything, including most transport metadata that was visible in TCP headers. That is good for privacy, and mildly annoying for network operators who used to debug by reading packet headers — which is a fair summary of why adoption took as long as it did.
What you actually have to do
Very little. HTTP/3 is negotiated automatically between browser and server, so the practical step is confirming that whatever sits in front of your site offers it. If your traffic goes through a CDN, that is where HTTP/3 terminates, and enabling it is usually a toggle. Your origin can keep speaking HTTP/1.1 to the edge and nobody minds — the leg that benefits is the one crossing the public internet to a phone.
To check what a browser negotiated, open DevTools, go to the Network tab, and add the Protocol column. You are looking for h3. Note that the very first request to a domain often shows h2, because the browser has to connect before it can learn that HTTP/3 is available; the upgrade happens on subsequent requests.
Frequently asked questions
What is HTTP/3?
HTTP/3 is the third major version of the HTTP protocol, standardised in 2022. Its defining change is that it runs over QUIC, a transport protocol built on UDP, rather than over TCP as HTTP/1.1 and HTTP/2 do. This removes transport-level head-of-line blocking and shortens connection setup, which makes pages load more reliably on lossy and high-latency connections.
What is QUIC?
QUIC is a transport protocol built on UDP that provides the reliability, ordering and congestion control TCP offers, but with independent streams, a combined transport and TLS handshake, and connection identifiers that survive network changes. It was designed in user space rather than the operating system kernel, which is what made it deployable across the existing internet.
Is HTTP/3 faster than HTTP/2?
On mobile, lossy or high-latency connections, yes — noticeably. It saves one to two round trips on connection setup and stops a single lost packet from stalling every other stream. On a fast, stable wired connection with no packet loss the difference is small, because neither problem is occurring. The benefit scales with how unreliable the network is.
Do I need to change my website to support HTTP/3?
No. HTTP/3 is negotiated between the browser and whatever server terminates the connection, so enabling it on your CDN or edge is sufficient. Your application code, HTML and origin server do not change, and your origin can continue to speak HTTP/1.1 to the edge. Browsers that cannot use HTTP/3 fall back to HTTP/2 automatically.
How can I tell if my site is using HTTP/3?
Open your browser's developer tools, go to the Network tab, and enable the Protocol column — requests served over HTTP/3 show as h3. The first request to a domain often shows h2 because the browser must connect before it learns HTTP/3 is available, advertised through the Alt-Svc response header; subsequent requests use h3.
Why does QUIC use UDP instead of TCP?
Not because UDP is faster, but because TCP cannot practically be changed. TCP is implemented in operating system kernels and network middleboxes worldwide, so any modification would take a decade to deploy. Building on UDP let QUIC implement its own reliability and congestion control in user space, where browsers and servers can ship updates independently.
HTTP/3 swaps TCP for QUIC to fix slow handshakes and head-of-line blocking. You do not rewrite anything — you make sure your edge speaks it and let clients negotiate. The payoff lands where it matters most: phones, weak signals, and visitors a long way from your origin.
See how NordicCDN does this for your site:
Mads has worked in IT — mostly hosting — since he was 16. He took an early stake in a SaaS company and helped grow it through to its acquisition by Visma, has built and run data-center networks, and served as CTO of a Danish data center. He started NordicCDN to make fast, secure infrastructure simple to use.
