A team is migrating their CDN to support HTTP/3 because somebody said it is faster. After a week of work, the Lighthouse score is unchanged, the p99 latency is unchanged, and the engineer who pushed for the change cannot point to a single user-visible win. The migration was real work and produced no benefit, because for that workload (a desktop web app on cable internet) the differences between HTTP/2 and HTTP/3 are essentially invisible.

HTTP/3 is a real improvement. It is also one of those upgrades that gets oversold. The wins are concentrated in specific workloads: mobile, lossy networks, CDN-served static assets, real-time. For everything else, the gap from HTTP/1.1 to HTTP/2 was the big jump, and HTTP/2 to HTTP/3 is incremental. This post is the technical difference, the cases where it actually matters, and the cases where it does not.

Quick recap of the protocol generations

HTTP/1.1 (1997). One request per TCP connection at a time. Browsers worked around this by opening 6+ connections per host. Lots of TCP overhead, lots of head-of-line blocking.

HTTP/2 (2015). Multiple requests multiplexed over one TCP connection. Header compression (HPACK). Server push (rarely used in practice). Adoption: ~95% of browsers, ~80% of websites.

HTTP/3 (2022). Multiplexing over QUIC instead of TCP. QUIC is a UDP-based transport with built-in TLS. Major fix: when one packet is lost, only one stream stalls; HTTP/2 over TCP stalls all streams.

The single most important change: head-of-line blocking at the transport layer is gone.

In HTTP/2 over TCP, a single dropped packet stops all multiplexed streams until that packet is retransmitted. Your CSS, JS, fonts, images: all paused waiting for one lost byte. On a clean wired network this is rare. On mobile, with packet loss in the 0.5-2% range, it is common and visible.

QUIC handles loss per-stream. A drop affecting the CSS does not stop the JS from making progress. The protocol adapts loss control per stream rather than per connection.

That is the big idea. Other improvements:

• 0-RTT resumption: returning users skip the TLS handshake on subsequent connects. Saves ~100 ms per connection.
• Connection migration: a phone switching from Wi-Fi to LTE keeps its QUIC connection alive (TCP would have to renegotiate). Saves a stall during network changes.
• Improved congestion control by default (BBR, etc.).

When HTTP/3 wins meaningfully

The wins are concentrated, not universal:

Mobile users on lossy networks. Packet loss in the 1-3% range is where HTTP/3’s stream-isolated retransmission shines. Sites like Instagram and Facebook saw ~10% reduction in time-to-first-byte and ~5-15% LCP improvement after HTTP/3 rollout, almost entirely on mobile.

Many small assets. A page loading dozens of small JS chunks benefits more than one loading a single big bundle. The multi-stream advantage compounds with the number of streams.

CDN-served static content. Cloudflare, Fastly, AWS CloudFront all support HTTP/3 with minimal configuration. The wins for CDN traffic are real, especially for global users on suboptimal networks.

Long-lived connections that survive network changes. Mobile apps, real-time apps. Connection migration is a meaningful UX win.

When HTTP/3 doesn’t matter

A site with these characteristics will see ~zero improvement:

• Desktop users on stable broadband.
• Single-page app with one big JS bundle.
• Same-origin API calls served alongside the main bundle (already on a warm connection).
• B2B / enterprise traffic from corporate networks (where UDP-based protocols may be blocked).

The “HTTP/3 will make my site faster” expectation is mostly wrong if the user’s network is good. Most desktop benchmarks show HTTP/3 within 1-2% of HTTP/2.

Operational realities

A few things to know before flipping HTTP/3 on:

UDP gets blocked. Some corporate firewalls and ISPs drop UDP traffic on non-standard ports, or rate-limit it. Browsers fall back to HTTP/2 in that case, so HTTP/3 is additive, not replacing, but you do not get the wins for those users.

Servers are catching up. Nginx supports HTTP/3 since 1.25 (2023) but it is still considered experimental. Caddy has had it for years. HAProxy added it in 2.6. Most CDN edge servers are mature; origin servers may not be.

Observability tooling. Some monitoring tools (older versions of Wireshark, some packet captures) do not understand QUIC well. Ensure your tooling supports it before you have an incident.

0-RTT replay attacks. Early data sent in a 0-RTT request can be replayed by an attacker. Mitigations: only allow 0-RTT for idempotent requests (GET, OPTIONS), reject 0-RTT for state-changing requests. CDNs handle this by default; check before relying on it for self-hosted.

Practical advice for getting the actual win

If you want HTTP/3’s benefits with minimal effort:

1. Use a CDN that supports it natively. Cloudflare (free tier), Fastly, AWS CloudFront. Flip a switch in their dashboard. Done.
2. Verify with curl --http3 (with a recent curl build):

   curl --http3 -v https://example.com 2>&1 | grep -i alt-svc

3. Check Alt-Svc headers are advertising HTTP/3:

   alt-svc: h3=":443"; ma=86400

4. Watch real user metrics for mobile users specifically. Lighthouse on a fast desktop will not show the difference.

If you self-host, the lift is meaningfully higher. Wait for nginx/HAProxy/your-stack to have stable HTTP/3 support and good documentation.

What HTTP/2 is still doing for you

A reminder: most of the latency reduction over HTTP/1.1 came from HTTP/2. If you are on HTTP/2, you already have:

• Multiplexed connections (no more 6-connection workaround)
• Header compression (HPACK)
• Stream prioritization (less so in practice; most servers don’t honor it well)
• Connection reuse for SSE and other long-lived streams

The transition from HTTP/1.1 → HTTP/2 was the big win. HTTP/3 is a smaller additional improvement.

What about HTTP/2 server push?

Spec’d, optimistically marketed, rarely works well in practice. The Chrome team removed support in 2022 because it caused more harm than good, pushing assets the browser already had cached, increasing waste. Most CDNs deprecated it too.

If you were waiting for HTTP/2 push to be useful, stop waiting. Use HTTP early hints (103) instead, supported by modern Chrome and Cloudflare/Fastly, which lets the server send a Link: rel=preload hint before the full response is ready.

TLS 1.3 is the unsung hero

HTTP/3 includes TLS 1.3 by default. A separate but related improvement worth verifying:

openssl s_client -connect example.com:443 -tls1_3

TLS 1.3 reduces handshake from 2 round-trips to 1 (or 0 with resumption). Combined with 0-RTT, returning users skip a noticeable amount of overhead.

Even if you are not on HTTP/3, ensuring TLS 1.3 is enabled on your servers is a free latency win.

A few that pair with HTTP/2/3 but are independent:

• Strict-Transport-Security (HSTS): forces HTTPS. Required for HTTP/2 / HTTP/3 in browsers.
• Content-Encoding: br (Brotli) for static assets. 20-30% smaller than gzip for HTML/JS/CSS.
• Vary: Accept-Encoding: ensures CDN serves the right compressed variant.

Brotli has more impact on bytes-on-the-wire than the protocol upgrade. Make sure it is enabled.

When to actually migrate

Three triggers that mean it is worth the effort:

1. Significant mobile user share (>30%) on lossy networks.
2. CDN migration is on the roadmap anyway; flip it on then.
3. Real-time / WebSocket-heavy apps where connection migration is a UX feature.

If none of those apply, leave HTTP/3 for the platform team’s “nice to have” backlog. The ROI is not there.

The takeaway

HTTP/3 is a real improvement focused on lossy networks and mobile. For most desktop / broadband traffic, it is within statistical noise of HTTP/2. The right adoption path is “turn it on at the CDN if you have one,” not “rewrite the load balancer.” Watch real user metrics, especially mobile p75/p95, before declaring victory.

Don’t oversell the migration to your team. The gap from HTTP/1.1 to HTTP/2 was the headline. HTTP/2 to HTTP/3 is an asterisk on the headline.

A note from Yojji

The kind of architectural judgment that distinguishes “this upgrade will move user-visible metrics” from “this upgrade is fashionable” is the kind of senior engineering Yojji’s teams bring to client work, including the network and CDN choices that compound into a faster site without churn for its own sake.

Yojji is an international custom software development company founded in 2016, with teams across Europe, the US, and the UK. They specialize in the JavaScript ecosystem (React, Node.js, TypeScript), cloud platforms, and full-cycle product engineering, including the protocol and infrastructure decisions that decide whether a site is genuinely faster or just appears modern.