How to Measure Real-World HTTP/3 Gains

This guide is part of HTTP/2, HTTP/3 & Connection Management, within Network & Server Response Optimization. Enabling HTTP/3 is often a single toggle at the CDN. Knowing whether it helped is harder. Lab tests on fast, clean connections show little difference. Field data is noisy, and naive comparisons of HTTP/2 and HTTP/3 users are biased: users who get HTTP/3 tend to be repeat visitors (who have already received Alt-Svc), on networks that allow UDP, often with warmer caches — all of which make them faster regardless of protocol.

A sound measurement records the protocol per navigation, segments by network conditions where the benefit is expected, and compares like with like — ideally through a controlled rollout where the CDN enables HTTP/3 for a random share of users or for a period, so the populations are comparable.

Rapid Diagnosis

• Confirm HTTP/3 is advertised: check for alt-svc: h3=":443" in responses, or an HTTPS DNS record.
• Check protocol in DevTools: add the Protocol column in the Network panel; h3 indicates HTTP/3.
• Check RUM for nextHopProtocol on the navigation entry.
• Check the h3 share: a low share may indicate discovery problems or UDP blocking.

Root Cause Analysis: Why Measurements Mislead

1. Discovery bias. First visits typically use HTTP/2; HTTP/3 users are disproportionately repeat visitors.

2. Network bias. Networks that block UDP (some corporate networks) are excluded from h3.

3. Small average effects. Benefits concentrate in a subset of users, diluted in averages.

4. Lab conditions. Fast, lossless lab connections hide QUIC's main advantages.

Step-by-Step Resolution

1. Record protocol and network context in RUM

import { onTTFB, onLCP } from 'web-vitals';
const nav = performance.getEntriesByType('navigation')[0];
const ctx = {
  protocol: nav.nextHopProtocol,                         // 'h2', 'h3', 'http/1.1'
  rtt: navigator.connection?.rtt, ect: navigator.connection?.effectiveType,
  repeat: nav.type === 'reload' || document.cookie.includes('seen=1'),
};
onTTFB((m) => navigator.sendBeacon('/rum', JSON.stringify({ metric: 'TTFB', value: m.value, ...ctx })));
onLCP((m) => navigator.sendBeacon('/rum', JSON.stringify({ metric: 'LCP', value: m.value, ...ctx })));
// trade-off: Network Information API values are Chromium-only and coarse; use
// country and device class as additional segments for other browsers.

2. Segment by network quality

Compare TTFB and LCP by protocol within segments: RTT buckets, effective connection type, country, device class, first vs repeat visit.

3. Run a controlled rollout

Enable HTTP/3 for a random share of traffic (some CDNs support percentage rollouts), or alternate weeks with it on and off, and compare the full populations rather than h2 versus h3 users.

4. Check for regressions

Look for segments where HTTP/3 performs worse (some networks handle UDP poorly) and confirm browsers fall back correctly.

Verification

A credible result shows: a stable h3 share; TTFB and LCP improvements in high-RTT and lossy segments; little or no change for fast connections; and a controlled comparison that agrees in direction with segment analysis. Document the method alongside the result, since protocol gains are often questioned.

Worked Example: A Global News Publisher

A publisher enabled HTTP/3 at its CDN and initially reported a 36% TTFB improvement by comparing h3 and h2 sessions. A closer look showed that 82% of h3 sessions were repeat visits versus 41% of h2 sessions. The team ran a two-week alternating rollout (HTTP/3 enabled on alternate days) and segmented by RTT. The controlled TTFB improvement was 11% overall: 3% for RTT under 50ms, 14% for 100–200ms, and 27% above 300ms. LCP p75 improved by 140ms in South Asia and Africa, and by about 20ms in Western Europe. HTTP/3 stayed enabled, and the team added HTTPS DNS records to get HTTP/3 on first visits.

First-Visit HTTP/3 with HTTPS DNS Records

Browsers normally learn about HTTP/3 from Alt-Svc in a previous response, so the very first connection uses HTTP/2. DNS HTTPS records (type 65) let the browser discover HTTP/3 support during the DNS lookup and connect with QUIC immediately. Many DNS providers and CDNs can publish them automatically. After adding them, first-visit h3 share should rise noticeably, which matters most for sites with many new visitors, such as news and search landing pages.

Presenting the Results

Protocol changes attract scepticism, so present results in a way that holds up. Show the controlled comparison first (HTTP/3 on versus off for comparable populations), then the segment breakdown by RTT or region, then the h3 adoption share. Include confidence intervals or at least daily values, so readers can see the effect is consistent rather than a single noisy day. Note what the change cost: for CDN-hosted sites usually nothing, for self-hosted servers some CPU. A short write-up like this also documents why HTTP/3 must stay enabled when someone later proposes disabling it to debug an unrelated problem.

Common Mistakes

• Comparing h2 and h3 users directly. Mixes protocol effects with visit type and network.
• Reporting only averages. Gains concentrate in high-latency segments.
• Testing only in the lab. Clean connections hide QUIC's strengths.
• Ignoring fallback health. Some networks need HTTP/2 to work reliably.

Edge Cases

Connection migration. HTTP/3 survives network changes; long sessions on mobile benefit, which page-load metrics do not capture.

0-RTT resumption. Repeat connections can send data immediately; it brings replay considerations for non-idempotent requests.

Server CPU. QUIC can use more CPU than TCP on servers; CDNs absorb this, self-hosted servers should monitor it.

Firefox and Safari. Both support HTTP/3, but nextHopProtocol reporting and Network Information support differ; segment by browser.

FAQ

Related

• HTTP/2, HTTP/3 & connection management — the topic overview.
• Diagnosing head-of-line blocking — the problem HTTP/3 solves.
• Time to First Byte (TTFB) optimization — connection time within TTFB.