HTTP/3 now carries a third of the web — and QUIC is just getting started

Roughly 30% of all web traffic now flows over HTTP/3, according to data from the HTTP Archive and Cloudflare's annual Year in Review. Google serves more than 90% of its own requests — Search, YouTube, Gmail — over QUIC. Meta routes the majority of its CDN traffic the same way. Fastly, Cloudflare, and AWS CloudFront all have HTTP/3 enabled by default. This is no longer an experimental protocol. It is the default transport for the web's largest properties, and the share of traffic it carries is growing by roughly 3–5 percentage points per year.

The Problem HTTP/2 Left Unsolved

HTTP/2 arrived in 2015 and fixed a real problem: HTTP/1.1's head-of-line blocking at the application layer, where one slow response blocked everything behind it in the same connection. HTTP/2 introduced multiplexing — multiple logical streams over a single TCP connection — and header compression via HPACK. Page load times improved measurably, particularly on high-latency links.

But HTTP/2 kept TCP as its transport layer, and TCP has its own head-of-line blocking problem that multiplexing cannot fix. TCP guarantees ordered delivery: if one segment is lost, all subsequent segments — even those belonging to completely independent HTTP/2 streams — must wait for the lost segment to be retransmitted before TCP delivers them to the application. On a connection with 1% packet loss, this can stall multiple independent resource streams simultaneously. On a mobile network with 2–3% packet loss (typical for LTE on the edge of coverage), the latency impact compounds severely.

TLS handshakes were the second problem. HTTP/2 over TLS 1.2 required 2 round trips (RTTs) before any application data could flow — one for TCP's SYN/SYN-ACK/ACK, one for the TLS negotiation. On a mobile connection with 80ms RTT, that's 160ms of setup overhead before the first byte of content. TLS 1.3 reduced this to 1-RTT, but TCP's own 3-way handshake remained unavoidable. Connection migration — what happens when you move from Wi-Fi to cellular — meant TCP connections broke and had to restart from scratch.

What QUIC Actually Is

QUIC is a transport protocol that runs over UDP. It was designed by Google in 2012, deployed internally around 2013, and standardized by the IETF as RFC 9000 in May 2021. HTTP/3 (RFC 9114) is simply HTTP semantics layered on top of QUIC instead of TCP.

The key architectural decisions in QUIC:

• UDP-based multiplexing with independent streams: QUIC implements stream multiplexing at the transport layer, not the application layer. Each stream has its own flow control and loss recovery. A lost packet affects only the stream it belongs to — other streams continue delivering data without interruption. This eliminates TCP's head-of-line blocking at the transport level.
• Built-in TLS 1.3: QUIC does not layer TLS on top of the transport; TLS 1.3 is integral to the protocol. The handshake and encryption negotiation happen simultaneously with connection establishment. A fresh QUIC connection requires 1-RTT before application data flows — one round trip fewer than TLS 1.2 over TCP.
• 0-RTT connection resumption: When a client reconnects to a server it has spoken to before, QUIC can send application data with the very first packet using 0-RTT mode. The client uses session ticket data from the previous connection to encrypt the request immediately. On a typical mobile reconnection — switching between Wi-Fi and cellular — this means the first HTTP request can go out before the handshake completes, cutting perceived latency to near zero for repeat visits.
• Connection migration: QUIC identifies connections with a 64-bit Connection ID, not a 4-tuple of IP addresses and ports. When your device changes IP address — moving from Wi-Fi to 5G, or switching between cellular towers — the QUIC connection continues without interruption. No TCP reset, no new handshake, no dropped streams. The server receives packets from the new IP address referencing the same Connection ID and continues seamlessly.

Performance Evidence: What the Numbers Show

The performance gains from QUIC are most pronounced under two conditions: high packet loss and frequent network transitions. Google published internal A/B test results showing that QUIC reduced search latency by 8% at the median and by up to 28% at the 99th percentile (tail latency) compared to HTTPS over TCP. YouTube's QUIC data showed a 15% reduction in rebuffering events.

Cloudflare's 2023 benchmarks on HTTP/3 vs HTTP/2 over a simulated 1% packet loss network showed median page load time improvements of 12–18% for resource-heavy pages. At 3% packet loss — realistic for congested mobile networks — the improvement grew to 25–35%. On a clean, low-latency connection with 0% packet loss, the performance difference between HTTP/2 and HTTP/3 is small (under 5%), because TCP's head-of-line blocking only manifests when segments are lost.

The 0-RTT resumption benefit is harder to isolate but measurable. Meta reported that enabling 0-RTT for returning visitors on its CDN reduced time-to-first-byte (TTFB) by 30–60ms on mobile connections, which translates directly to faster Largest Contentful Paint (LCP) scores — the Core Web Vital most correlated with user experience and Google Search ranking.

One caveat: 0-RTT carries a replay vulnerability. An attacker who captures 0-RTT data can replay it to send duplicate requests. This is why 0-RTT is safe for idempotent requests (GET, HEAD) but must be disabled or carefully handled for state-changing operations (POST, payments). Modern server implementations handle this automatically, but it's worth knowing the constraint exists.

Who Runs HTTP/3 Today

The adoption landscape as of mid-2026 is substantial:

• Cloudflare: HTTP/3 enabled by default for all customers since 2020. Cloudflare also operates one of the most-used QUIC implementations (quiche), which is open-source and used by Firefox and other projects.
• Google: Runs QUIC internally for Search, YouTube, Gmail, Google Drive, and Maps. The Chrome browser has shipped QUIC support since 2015. Google's QUIC implementation (quic-go and the C++ cronet) is the reference implementation for much of the ecosystem.
• Meta: Runs HTTP/3 for Facebook, Instagram, and WhatsApp CDN traffic. Meta maintains its own QUIC implementation (mvfst), open-sourced in 2019, used in production at billions-of-users scale.
• Fastly, Akamai, AWS CloudFront: All offer HTTP/3 as a CDN option, with Fastly enabling it by default since 2022.

On the server software side: nginx added QUIC/HTTP/3 support in v1.25.0 (released June 2023) as a stable feature. Caddy has shipped HTTP/3 enabled by default since v2.4. LiteSpeed and its open-source variant OpenLiteSpeed have had HTTP/3 support since 2020. Apache httpd offers HTTP/3 via the mod_quic module, still experimental as of Apache 2.4.55. The H2O server has QUIC support. Node.js has an experimental QUIC API. The Deno runtime supports HTTP/3 natively.

What Web Developers Need to Do

For most developers using a CDN or cloud load balancer, HTTP/3 is already on — verify it, don't enable it. If you're managing your own server infrastructure, here's the practical path:

Verify HTTP/3 is active:

• Use curl --http3 https://yourdomain.com -I and check for HTTP/3 in the response line. Requires curl built with QUIC support (curl --version | grep HTTP3).
• In Chrome DevTools: open the Network panel, right-click the column headers, enable "Protocol". HTTP/3 connections show as h3. HTTP/2 shows as h2.
• Firefox DevTools shows the same in the Network panel's Protocol column.
• Cloudflare's quic.cloud checker and the http3check.net tool provide quick external verification.

Enable HTTP/3 on nginx (1.25+): Add listen 443 quic reuseport; alongside your existing listen 443 ssl; directive, then add add_header Alt-Svc 'h3=":443"; ma=86400'; to advertise QUIC to browsers. The Alt-Svc header is how clients discover that HTTP/3 is available — the first connection will use HTTP/2, and subsequent connections will upgrade to HTTP/3.

Enable HTTP/3 on Caddy: Nothing to configure — Caddy enables HTTP/3 by default when TLS is active. Confirm via the DevTools protocol column.

Firewall configuration is a common blocker: QUIC runs on UDP port 443. Many corporate firewalls block or rate-limit UDP traffic. If HTTP/3 fails to negotiate, browsers fall back to HTTP/2 automatically — end users see no errors, but they also don't get QUIC. If you're debugging why HTTP/3 isn't being used on a specific network, check whether UDP/443 is open.

Don't manually tune congestion control for QUIC yet. QUIC implementations use BBR (Bottleneck Bandwidth and RTT) congestion control by default, which outperforms CUBIC (TCP's default) on most modern networks. Unless you have specific, measured performance problems, the defaults are correct.

0-RTT: Most server implementations enable 0-RTT for GET requests automatically. If your application issues state-changing operations on page load (unusual but possible), audit those request types. The standard guidance is to treat 0-RTT data as potentially replayed and design accordingly — use idempotent tokens or check application-layer state.

The Road Ahead

HTTP/3 and QUIC are not done evolving. QUIC version 2 (RFC 9369, published 2023) adds improvements to connection migration and introduces a new version negotiation mechanism. WebTransport — a browser API that exposes QUIC streams and datagrams directly to JavaScript — is shipping in Chrome and Firefox, enabling low-latency bidirectional communication without the overhead of WebSocket. MASQUE (Multiplexed Application Substrate over QUIC Encryption), an IETF working group protocol, builds VPN-like tunneling on QUIC and is already deployed in iCloud Private Relay.

For the web developer who understands TCP and HTTP, QUIC is the same problem solved properly: reliable, ordered delivery where it's needed (per stream), without the global ordering constraint that makes TCP pathological on lossy links. The protocol is stable, the tooling exists, and the performance evidence is unambiguous. If your traffic runs through a modern CDN, your users are already benefiting. If it doesn't, the upgrade path is a single nginx configuration line.