HTTP/3 & QUIC Setup Guide (2026)

Q: Will HTTP/3 break old browsers or clients?

No. Negotiation is opportunistic via the Alt-Svc header. Browsers and clients that don't speak HTTP/3 silently use HTTP/2 (or HTTP/1.1) over TCP. There's no flag day and no breakage.

Updated: May 26, 2026

HTTP/3 is faster than HTTP/2 on most real-world networks because it runs over QUIC, a UDP-based transport that removes TCP's head-of-line blocking, finishes the TLS handshake in one round trip, and survives network changes without dropping the connection. In 2026, HTTP/3 carries roughly 35% of global web traffic and is enabled by default on Cloudflare, Fastly, Akamai, Caddy, and recent Nginx builds. For mobile users on lossy networks, switching delivers 20–60% faster page loads and measurable Largest Contentful Paint improvements of 100–300 ms.

I've shipped HTTP/3 on three production sites now (one was a news site with brutal mobile traffic from spotty cellular), and the field data lines up neatly with the benchmarks. So let's dig into what changed, what to actually configure, and the handful of gotchas that bit me.

HTTP/3 replaces TCP with QUIC over UDP, killing transport-layer head-of-line blocking and merging the TLS 1.3 handshake into connection setup.
0-RTT resumption lets returning visitors send request data in the very first packet, cutting reconnect latency to near zero.
On stable desktop networks the gain over HTTP/2 is small (~5%), but on mobile or lossy links HTTP/3 commonly improves load time by 20–60%.
Real-world measurements show LCP improvements of 100–300 ms after enabling HTTP/3, which directly improves Core Web Vitals.
Caddy and Cloudflare enable HTTP/3 with zero configuration; Nginx 1.25+ supports it natively after a small config change and a UDP/443 firewall rule.
Connection migration keeps the same QUIC session alive when a phone switches from Wi-Fi to cellular, preventing stalls during navigation.

What is HTTP/3 and how is QUIC different from TCP?

HTTP/3 is the third major version of the Hypertext Transfer Protocol, standardized as RFC 9114 in June 2022. The headline change is the transport layer. Instead of TCP, HTTP/3 runs on top of QUIC, a transport protocol that lives on UDP and ships its own congestion control, loss recovery, and encryption.

The difference matters because TCP, despite decades of refinement, has structural limits the modern web keeps bumping into. Three of them are gone in QUIC:

Head-of-line blocking is eliminated at the transport layer. In TCP, every byte must arrive in order. So if one packet carrying CSS is lost, every JavaScript and image packet stuck behind it waits for retransmission. QUIC streams are independent, so a lost image packet never blocks the CSS stream.
The handshake is one round trip, not two. TCP's three-way handshake and the subsequent TLS 1.3 handshake usually need 2 RTTs before the first byte of HTTP. QUIC integrates TLS 1.3 into its own handshake and finishes both in a single RTT (and 0 RTTs for returning clients using 0-RTT resumption).
Connections survive network changes. QUIC identifies sessions by a connection ID rather than the IP/port four-tuple. When your phone switches from Wi-Fi to cellular mid-download, the QUIC connection migrates without renegotiating. TCP would have dropped and reconnected.

Because QUIC is encrypted end to end (TLS 1.3 is mandatory, not optional), middleboxes can no longer see or rewrite the transport headers. That makes the protocol harder for ISPs to ossify and easier for the IETF to evolve. Multipath QUIC and improved congestion control are already in draft. The practical implication for site owners is that HTTP/3 isn't a swap-in optimization; it's a different transport with different operational characteristics. Knowing what changed at the wire level is what lets you debug it when something acts up.

Is HTTP/3 faster than HTTP/2?

In most production conditions, yes. But the size of the win depends almost entirely on network quality. Synthetic benchmarks consistently show the spread:

Scenario	HTTP/2	HTTP/3	Improvement
Stable desktop (low latency, 0% loss)	1.50 s	1.42 s	~5%
Cross-continent (US to EU, 150 ms RTT)	2.10 s	1.55 s	~25%
Mobile (4G with 2% packet loss)	3.40 s	1.65 s	~52%
Returning visitor (warm cache, 0-RTT)	0.95 s	0.40 s	~58%
High packet loss (5%, unstable Wi-Fi)	5.20 s	2.30 s	~56%

The pattern is consistent: the worse the network, the bigger the gain. On a fast fiber connection in the same city as your origin, HTTP/3 buys you very little because TCP's weaknesses never surface. The moment you add real latency or any packet loss, head-of-line blocking and slow handshakes become measurable. And that's exactly where most of your mobile traffic lives.

So the takeaway is this. HTTP/3 isn't a magic speedup for users who already have great connectivity. It's an insurance policy against the conditions a meaningful percentage of your real audience experiences every day: bus rides, train tunnels, congested cells, hotel Wi-Fi. If your RUM data shows a long tail of slow connections, the long tail is precisely where HTTP/3 pays you back.

Does HTTP/3 improve Core Web Vitals?

HTTP/3 most directly improves Largest Contentful Paint and Time to First Byte, with secondary effects on Cumulative Layout Shift and Interaction to Next Paint that come from smoother resource delivery. Field studies from CDN providers and engineering blogs in 2025–2026 consistently report LCP reductions in the 100–300 ms range after enabling HTTP/3, with the larger reductions concentrated on mobile traffic.

The mechanism is straightforward. LCP is gated by three things: connection setup time, server processing time, and resource download time. HTTP/3 attacks the first and third:

TTFB drops because the merged QUIC + TLS 1.3 handshake completes in 1 RTT (or 0 RTT on resumption) instead of 2 RTTs. For a 150 ms cross-continental RTT, that's 150–300 ms shaved off every cold connection. The article on reducing TTFB end-to-end covers the other levers, and HTTP/3 stacks on top of them.
LCP resource download is faster on lossy networks because head-of-line blocking no longer stalls the LCP image behind a lost CSS packet. The LCP sub-part breakdown guide shows where these milliseconds map onto the timeline.
CLS becomes more predictable because fonts and images arrive on more consistent schedules. Late-arriving resources are a common silent cause of layout shifts.

What HTTP/3 does not fix: server-side latency, oversized JavaScript bundles, render-blocking CSS, slow third-party scripts, or anything that happens after the bytes hit the browser. If your TTFB is 1.2 seconds because of a slow database query, HTTP/3 shaves 100 ms off the connection setup and leaves the remaining 1.1 seconds untouched. Treat HTTP/3 as a multiplier on the rest of your performance work, not a substitute for it.

How do I enable HTTP/3 on my server?

The exact steps depend on your stack, but the prerequisites are the same in all three cases: UDP/443 must be open at every firewall, TLS 1.3 must be configured, and you need a server build that includes QUIC support. Below are minimal working configurations for the three deployments that cover the majority of sites in 2026.

Caddy: zero configuration

Caddy enables HTTP/3 by default whenever TLS is active. The only thing you usually need to do is make sure the UDP port is exposed if you run Caddy in Docker:

# docker-compose.yml
services:
  caddy:
    image: caddy:2.8
    ports:
      - "80:80"        # HTTP/1.1 (for redirects + ACME)
      - "443:443"      # HTTP/1.1 + HTTP/2 over TCP
      - "443:443/udp"  # HTTP/3 over QUIC (UDP), required
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile:ro
      - caddy_data:/data

A minimal Caddyfile that makes HTTP/3 explicit looks like this:

{
  # Global options. Listed protocols are the negotiated set.
  servers {
    protocols h1 h2 h3
  }
}

example.com {
  root * /var/www/site
  encode zstd gzip   # negotiate Zstandard first, gzip fallback
  file_server
}

Nginx 1.25+: explicit listener

Nginx added stable HTTP/3 support in 1.25.0 via the bundled ngx_http_v3_module. You compile it with --with-http_v3_module (most distro packages now include it) and add a QUIC listener:

server {
    # Existing TCP listeners: HTTP/1.1 and HTTP/2
    listen 443 ssl;
    http2 on;

    # New: HTTP/3 over QUIC on UDP/443
    listen 443 quic reuseport;
    listen [::]:443 quic reuseport;

    server_name example.com;

    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    ssl_protocols       TLSv1.3;   # QUIC requires TLS 1.3

    # Advertise HTTP/3 to clients so they upgrade on the next visit
    add_header Alt-Svc 'h3=":443"; ma=86400' always;

    root /var/www/site;
    index index.html;
}

The Alt-Svc header is the discovery mechanism. The first request still comes in over HTTP/2 (because the browser can't yet know HTTP/3 is available), but the response advertises HTTP/3, and every subsequent request from that client uses it. Set ma (max-age) to 86400 (24 hours) as a reasonable default.

Refer to the official Nginx QUIC documentation for advanced tuning (0-RTT, congestion control, retry tokens). The QUIC Working Group page has links to every related RFC if you want to go deeper.

Cloudflare and other CDNs: a single toggle

If your origin sits behind Cloudflare, Fastly, or Akamai, the CDN terminates QUIC at the edge and you don't need to touch the origin server at all. On Cloudflare:

Open the dashboard for your zone.
Go to Speed → Optimization → Protocol Optimization.
Toggle HTTP/3 (with QUIC) on.

The toggle has been on by default for new zones since 2022. See the Cloudflare engineering writeup for context. Fastly and Akamai have equivalent defaults in their respective dashboards. One catch though: if your firewall blocks outbound UDP on port 443 (some corporate networks do), the CDN will silently fall back to HTTP/2 for those clients, which is correct behavior but worth knowing when comparing field data.

How do I check if a site is using HTTP/3?

Three verification techniques, from quickest to most thorough.

Browser DevTools

Open DevTools, go to the Network tab, right-click the column headers, and enable the Protocol column. Reload the page. Requests served over HTTP/3 show as h3; HTTP/2 shows as h2. The first request on a fresh visit is usually h2 because the browser hasn't yet seen the Alt-Svc hint. Subsequent loads should upgrade.

curl from the command line

curl 7.66+ ships with HTTP/3 support via the --http3 flag (you need a build compiled against an HTTP/3-capable TLS library, e.g., quictls):

# Check that the server advertises HTTP/3
curl -sI https://example.com/ | grep -i '^alt-svc:'
# alt-svc: h3=":443"; ma=86400

# Force an HTTP/3 request and report the negotiated version
curl --http3 -sI -o /dev/null -w '%{http_version}\n' https://example.com/
# 3

If the second command returns 2, HTTP/3 negotiation failed. Usually a firewall blocking UDP/443 or a missing QUIC listener at the origin. (I hit this exact issue once on a cloud security group that allowed TCP/443 but forgot UDP. Took me an embarrassing 20 minutes to notice.)

Field validation with the Network Information API

For real-user monitoring you can correlate slow LCP entries with the negotiated protocol. The nextHopProtocol field on each PerformanceResourceTiming entry reports the protocol that was used:

// Log the protocol used for each resource on this page
const entries = performance.getEntriesByType('resource');
const protocolCounts = entries.reduce((acc, entry) => {
  const proto = entry.nextHopProtocol || 'unknown';
  acc[proto] = (acc[proto] || 0) + 1;
  return acc;
}, {});

console.table(protocolCounts);
// { h3: 24, h2: 3, "http/1.1": 0 }

Stream this into your RUM pipeline and you can compare LCP distributions for h3 vs h2 sessions. The gap is usually obvious in the 75th and 95th percentiles where lossy networks dominate.

Common HTTP/3 pitfalls and how to avoid them

The protocol is mature, but its operational profile differs enough from TCP that several footguns recur in production rollouts. Honestly, every one of these has bitten me or someone on a team I've worked with.

UDP/443 blocked by firewalls. Many corporate networks, mobile carriers in restrictive regions, and older home routers drop or rate-limit UDP. Clients quietly fall back to HTTP/2, which is fine. But if you see zero HTTP/3 traffic from a region, suspect the network, not your config.
0-RTT replay attacks. 0-RTT data is replayable by design, so never use it for non-idempotent endpoints. Servers should reject 0-RTT for POST/PUT/DELETE by default; both Caddy and recent Nginx do this automatically.
Anti-DDoS appliances stripping QUIC. Some on-prem load balancers treat unrecognized UDP as suspicious and drop it. Check your edge appliances and explicitly allowlist UDP/443.
NAT rebinding stalls. Connection migration assumes the QUIC connection ID survives a network change. Some carrier-grade NATs aggressively rewrite the source port and break this. The symptom is a brief stall when switching networks. The QUIC stack retries; users notice nothing more than the equivalent of an HTTP/2 reconnect.
CPU cost is higher than TCP. Because QUIC's reliability and ordering happen in userspace rather than the kernel, expect 2–4× CPU per byte compared to TCP+TLS on the same hardware. For most sites this is invisible; for very high-throughput origins, plan capacity headroom.
Stale Alt-Svc caching. If you disable HTTP/3 temporarily, clients that cached Alt-Svc will keep trying for up to ma seconds. Set ma to a value that matches your tolerance for rollback latency; 86400 (one day) is a reasonable default.

A safe rollout plan for production

HTTP/3 is mature enough that "just enable it" is reasonable for most small and mid-sized sites. For larger deployments, a staged rollout reduces the surface area of any surprise:

Enable on a non-critical subdomain first. A documentation site, status page, or staging environment works well. Verify with curl and DevTools that h3 negotiates and that no client buckets show error spikes.
Open UDP/443 inbound at every layer: cloud provider security groups, on-prem firewalls, WAF appliances, load balancers. This is the single most common cause of "HTTP/3 enabled but no one is using it."
Add the Alt-Svc header on the production origin but keep the QUIC listener disabled. Clients will attempt HTTP/3, fail fast, and revert to HTTP/2, confirming end-to-end connectivity without committing.
Turn on the QUIC listener for 1–5% of traffic via your edge or a feature flag. Compare LCP, TTFB, and error rates between cohorts in your RUM.
Ramp to 100% over a week. Keep an eye on origin CPU and any custom WAF rules that examine TCP-specific signals (those need QUIC equivalents).
Audit your monitoring. Log nextHopProtocol in RUM, add an h3 dimension to your Core Web Vitals dashboards, and verify that synthetic tests (e.g., WebPageTest) are using the QUIC-capable agents.

Frequently asked questions

Do I need a special certificate for HTTP/3?

No. The same TLS certificate you already use for HTTPS works for HTTP/3. QUIC mandates TLS 1.3, but any modern Let's Encrypt or commercial certificate already supports it. The only requirement on the server side is that TLS 1.3 itself is enabled in your config.

Will HTTP/3 break old browsers or clients?

No. Negotiation is opportunistic via the Alt-Svc header. Browsers and clients that don't speak HTTP/3 silently use HTTP/2 (or HTTP/1.1) over TCP. There's no flag day and no breakage.

Should I disable HTTP/2 after enabling HTTP/3?

No. Keep both. The first request from any new client still arrives over HTTP/2 because the client hasn't yet learned that HTTP/3 is available. After the response advertises Alt-Svc, subsequent connections upgrade. Disabling HTTP/2 would degrade the first paint of every cold visit.

Does HTTP/3 work with server push?

HTTP/3 inherited the option but it's effectively deprecated. Chrome removed HTTP/2 push support in 2022 and never implemented it for HTTP/3. Use 103 Early Hints instead; it works over HTTP/2 and HTTP/3 and is what every major browser actually honors.

Why is my browser still showing HTTP/2 even though HTTP/3 is enabled?

Three likely causes, in order of frequency: (1) the response is the first one from this client, so the browser hasn't yet seen the Alt-Svc hint, so reload and check again; (2) a firewall between client and server is dropping UDP/443; (3) your CDN or proxy is terminating QUIC but talking to the origin over HTTP/2, which is normal and still gives you the QUIC benefits on the last mile.