HTTP/3 vs HTTP/2: Where the New Protocol Stands in Real-World Tests
HTTP/3 has moved from a niche experiment to a broadly available option in the year since Cloudflare first enabled it. The protocol remains an IETF draft, but adoption has been steady: more than 113,000 zones on Cloudflare's network now serve HTTP/3 traffic, putting real websites in front of browser implementers. Google Chrome shipped experimental support at launch, and Firefox nightly builds, Chromium-based browsers like Opera and Microsoft Edge, and Safari's Technology Preview have all since added the protocol.
Standardization Status and Momentum
The QUIC Working Group has been iterating through document drafts, with each revision meant to converge on a final RFC. Cloudflare launched with support for Draft-23 and has tracked every subsequent version, currently at Draft-27. The bar for spec changes has risen with each draft, meaning the protocol running in production closely matches what is likely to be ratified as the final standard.
Why HTTP/3 Was Built
The headline benefit of HTTP/3 is its handling of multiplexed streams. HTTP/2 runs over TCP, so a single lost packet stalls every stream sharing that connection — a problem known as head-of-line blocking. HTTP/3 runs over UDP via QUIC, and a dropped packet only interrupts the affected stream while the others continue flowing.
The protocol also introduces 0-RTT connection resumption. Subsequent connections skip the server's TLS acknowledgement step, allowing the client to begin requesting data almost immediately rather than waiting out a full handshake. The result is faster page loads, particularly for repeat visits.
Measuring the Gains
Time to first byte (TTFB) benchmarks on Cloudflare's network show a measurable improvement from 0-RTT support. The first byte arrives in an average of 176ms over HTTP/3 versus 201ms over HTTP/2 — roughly 12.4% faster.
Not all performance differences come from the protocol specification itself. Congestion control is left to the implementation, and the choice of algorithm has a clear impact. The QUIC specification recommends Reno as a safe default but allows any algorithm. Cloudflare began with New Reno, then moved to CUBIC, which improves throughput for larger transfers under packet loss. Its HTTP/2 stack, by contrast, runs BBR v1 over TCP. That makes direct comparisons less clean than they might appear.
Synthetic Tests Show a Mixed Picture
For a small 15KB test page, HTTP/3 loads in an average of 443ms versus 458ms for HTTP/2. At 1MB, HTTP/2 pulls slightly ahead: 2.30 seconds versus 2.33 seconds for HTTP/3. The gap tracks closely with the congestion control differences between the two stacks.
Real-World Page Load Times
To move beyond synthetic benchmarks, Cloudflare set up WebPageTest instances across multiple regions loading real pages over both protocols, with Cloudflare's Browser Insights capturing backend timings. The live measurements of blog.cloudflare.com show HTTP/3 trailing HTTP/2 by 1-4% on average in North America, with similar results in Europe, Asia, and South America.
The lingering deficit likely stems from the same root cause as the larger-file synthetic results: CUBIC on HTTP/3 versus BBR v1 on HTTP/2. Where the protocols use comparable congestion control, HTTP/3 demonstrates advantages; where it does not, HTTP/2's tuned TCP stack still holds an edge.
Outlook
HTTP/3 already delivers faster connection startup and better resilience to packet loss in multiplexed sessions. Cloudflare sees its implementation as competitive — better in some scenarios, roughly equivalent in others — and is continuing to tune congestion control, prioritization, and system capacity as the standard approaches finalization. Users who want to experiment can enable HTTP/3 from the Cloudflare dashboard and test with a nightly build of a major browser.
