This post was original published on Veduis
HTTP/3 has been shipping in production for several years now. Chrome uses HTTP/3 for roughly 20% of web traffic. Cloudflare, Fastly, and AWS CloudFront all support it. Google has used QUIC (the protocol underlying HTTP/3) in production since 2015. Understanding what changed and why matters for making informed decisions about your infrastructure configuration.
The motivation for HTTP/3 was one specific problem with HTTP/2: head-of-line blocking at the TCP layer. Fixing that problem required replacing TCP with a new transport protocol, which is why HTTP/3 is a more substantial change than HTTP/2 was.
The Problem HTTP/3 Solves
HTTP/2 solved head-of-line blocking at the HTTP layer by multiplexing multiple streams over a single TCP connection. In HTTP/1.1, you needed multiple connections to fetch multiple resources in parallel. HTTP/2 sends all resources over one connection with stream multiplexing.
But TCP has its own head-of-line blocking. If a TCP packet is lost, TCP halts all delivery on the connection until that packet is retransmitted and received. All HTTP/2 streams over that connection wait, even streams that did not depend on the lost packet. On reliable networks this is negligible. On mobile networks with 1-2% packet loss rates, it causes real performance degradation.
QUIC solves this by implementing streams at the transport layer over UDP. When a packet is lost, only the stream that depended on that packet stalls. Other streams continue delivering. On lossy networks (cellular, high-latency connections), this produces meaningful improvements. These gains compound with other optimizations covered in our CDN comparison guide, which benchmarks how major providers implement HTTP/3 at the edge.
What Changed
UDP Instead of TCP
QUIC runs over UDP rather than TCP. UDP has no built-in reliability or ordering — QUIC implements its own reliability, ordering, and congestion control on top. This is why QUIC can provide per-stream reliability without the connection-level head-of-line blocking that TCP imposes.
Some corporate firewalls and networks block or rate-limit UDP traffic, which means HTTP/3 may not work for a portion of your users. All HTTP/3 implementations fall back to HTTP/2 when HTTP/3 is unavailable, so this is not a hard dependency.
Integrated TLS 1.3
HTTP/3 requires TLS 1.3. TLS is integrated into QUIC at the transport layer rather than layered on top as it is with TLS over TCP. This enables 0-RTT connection establishment: a client that previously connected to a server can resume with zero round trips before sending application data.
Traditional TLS 1.2 required 2 round trips before any application data. TLS 1.3 over TCP reduced this to 1 round trip on initial connection and 0-RTT on resumption. QUIC gets the same 1-RTT initial / 0-RTT resumption performance, but with the transport-level QUIC benefits on top. If you are not yet managing your TLS certificates with automation, our guide on SSL/TLS certificate automation covers Let's Encrypt and ACME-based renewal — a prerequisite for any production HTTP/3 deployment.
Connection Migration
HTTP/3 connections are identified by a connection ID rather than by the 4-tuple (source IP, source port, destination IP, destination port) that identifies TCP connections. This means a connection can survive a change in the client's IP address or port — common when a mobile device switches from WiFi to cellular.
In practice, connection migration means HTTP/3 connections survive network transitions without re-establishing the connection and going through TLS negotiation again. For mobile users who frequently switch between WiFi and cellular, this eliminates the reconnection delay.
Multiplexed Streams Without Head-of-Line Blocking
QUIC streams are independent at the transport layer. A lost packet affecting stream 3 does not stall streams 1, 2, and 4. This is the core performance improvement over HTTP/2 for users on networks with any meaningful packet loss.
Browser Support and Adoption
HTTP/3 is supported by all major browsers: Chrome 87+, Firefox 88+, Safari 14+, Edge 87+. Clients always fall back gracefully to HTTP/2 or HTTP/1.1 if the server does not support HTTP/3 or if UDP is blocked at the network level.
Servers advertise HTTP/3 support via the Alt-Svc HTTP header:
Alt-Svc: h3=":443"; ma=86400
This tells the client that HTTP/3 is available on port 443, with the information valid for 86400 seconds (one day). The client uses HTTP/2 for the first connection, receives this header, and uses HTTP/3 for subsequent connections.
Enabling HTTP/3
Cloudflare
HTTP/3 is enabled automatically for all Cloudflare zones. You can verify it is enabled in the dashboard under Speed > Optimization > Protocol Optimization. No configuration is required.
To verify HTTP/3 is being used, check the cf-cache-status header or the network protocol in Chrome DevTools (right-click on columns in the Network tab to add the Protocol column). For a detailed look at how Cloudflare compares to other CDN providers on HTTP/3 and broader performance, see our CDN comparison: Cloudflare vs Fastly vs BunnyCDN.
Nginx (1.25+)
QUIC support was merged into Nginx mainline in version 1.25. Earlier versions require a patch or building from source with QUIC support.
# nginx.conf
http {
server {
listen 443 quic reuseport; # QUIC/HTTP/3
listen 443 ssl; # TCP/HTTP/2
ssl_certificate /etc/ssl/cert.pem;
ssl_certificate_key /etc/ssl/key.pem;
ssl_protocols TLSv1.3; # HTTP/3 requires TLS 1.3
# Advertise HTTP/3 support
add_header Alt-Svc 'h3=":443"; ma=86400';
# QUIC-specific settings
ssl_early_data on; # Enable 0-RTT
quic_retry on; # Mitigates reflection attacks
}
}
The reuseport option is required for QUIC. Without it, multiple worker processes cannot share the UDP port.
Security consideration: ssl_early_data on enables 0-RTT resumption. Early data is vulnerable to replay attacks. Do not enable 0-RTT for non-idempotent requests (POST, PUT, DELETE) without replay protection. Static asset servers are generally safe to enable it on.
Caddy
Caddy 2 enables HTTP/3 by default when serving HTTPS. No additional configuration is required.
Verifying HTTP/3 Is Working
# Using curl (requires curl 7.66+ with QUIC support)
curl --http3 -I https://yourdomain.com
# Using the h2load tool from nghttp2
h3load https://yourdomain.com --npn-list=h3
Chrome DevTools shows the protocol used for each request in the Network tab. h3 indicates HTTP/3. h2 indicates HTTP/2. http/1.1 indicates HTTP/1.1. The http3check.net tool lets you verify HTTP/3 support from your browser without any local tooling.
Performance Impact
HTTP/3 performance improvements are most significant:
On mobile networks with packet loss. The elimination of TCP head-of-line blocking directly helps when network conditions are degraded. Studies from Google and Cloudflare show 10-20% improvements in Time to First Byte on mobile networks under lossy conditions. These gains feed into your Core Web Vitals scores, particularly LCP on mobile devices where network conditions are less predictable.
On high-latency connections. The 0-RTT resumption and 1-RTT initial connection reduce connection setup overhead meaningfully when latency is already high.
For connections that survive network transitions. Mobile users who switch between WiFi and cellular benefit from connection migration.
HTTP/3 performance improvements on wired low-latency connections are more modest. The TCP head-of-line blocking issue is largely irrelevant when packet loss is near zero.
What Developers Do Not Need to Change
HTTP/3 is transparent at the application layer. Your HTTP headers, request formats, response formats, caching behavior, and authentication patterns are all unchanged. The change is at the transport and session layer, below where application code operates.
You do not need to rewrite any application code to support HTTP/3. You enable it at the server or CDN level, and clients that support it use it automatically.
The Alt-Svc header and HTTP/3 negotiation happen automatically. Your application code sees the same request objects regardless of whether the underlying transport is HTTP/1.1, HTTP/2, or HTTP/3. Your existing caching strategies — browser cache headers, CDN TTLs, and ETags — continue to work without modification under HTTP/3.
Practical Recommendation
If you use a CDN (Cloudflare, Fastly, AWS CloudFront), HTTP/3 is either already enabled or available with a single toggle. Enable it. The fallback to HTTP/2 is automatic and robust. The downside risk is near zero.
If you serve directly from your own infrastructure with Nginx 1.25+ or Caddy, enabling HTTP/3 requires the configuration changes above and opening UDP port 443 in your firewall rules. Test in a staging environment first and verify that your network allows UDP traffic on port 443.
The overhead of enabling HTTP/3 on modern infrastructure is low. The performance benefits for your mobile users and users on less-than-ideal network connections are real and accumulate meaningfully at scale.
