Your product already runs on HTTP/2 behind a CDN. How would you decide whether enabling HTTP/3 is worth it, and how would you know afterwards whether it actually helped?

## Start from who your users are The decision is dominated by traffic profile, not by protocol elegance. - **Consumer mobile, worldwide, asset-heavy pages.** Strong case. High latency and non-trivial loss are exactly where HTTP/2's single TCP connection suffers, and where per-stream independence and faster handshakes convert directly into visible latency. - **Desktop broadband in one region.** Weak case. Loss is low, latency is low, HTTP/2 already removed the queueing. - **Server-to-server inside a datacenter.** Essentially no case. Sub-millisecond round trips, near-zero loss, and you would be adding UDP handling and CPU cost for nothing. - **First-visit-heavy traffic** such as marketing pages and one-and-done sessions. Moderate case: QUIC's combined transport and TLS 1.3 handshake saves a round trip versus TCP plus TLS, and DNS HTTPS records let the first connection already be h3. ## What HTTP/3 actually buys, stated honestly - **No cross-stream head-of-line blocking.** A lost packet delays only the streams it carried, instead of stalling every multiplexed request as it does over TCP. - **Faster setup.** QUIC merges the transport and TLS 1.3 handshakes into one round trip, and supports zero-round-trip resumption, with replay caveats for non-idempotent requests. - **Connection migration.** A connection is identified by a connection ID rather than the IP and port 4-tuple, so a phone moving from Wi-Fi to cellular keeps its connection instead of re-handshaking. - **Cleaner loss recovery.** Unambiguous packet numbering removes TCP's retransmission ambiguity, sharpening round-trip estimates. And what it does not buy: bandwidth, server-side speed, or anything for workloads whose bottleneck is application think-time. ## Cost and risk **With a CDN**, the marginal cost is close to zero. The CDN terminates QUIC, emits Alt-Svc, and often publishes the DNS HTTPS record; your origin leg is unchanged. It is a toggle you can turn off. This is why 'we are behind a CDN' usually resolves the decision to yes-try-it. **Self-hosted** is a genuine project: - QUIC does congestion control and loss recovery in userspace, so CPU per byte is meaningfully higher than kernel TCP unless you have UDP segmentation offload and a tuned stack. - Load balancing must route by QUIC connection ID; naive 4-tuple hashing breaks connection migration, which is one of the features you enabled it for. - DDoS posture changes: UDP amplification and address-validation handling need thought, and existing TCP-oriented scrubbing may not apply. - Observability is thinner. Most of the QUIC header is encrypted, so packet capture tells you far less; you need endpoint-side logging such as qlog and CDN-provided metrics. **Network reality**: a small but real slice of networks block or heavily throttle UDP on port 443. Clients race or fall back to h2, so users are not broken, but those users get no benefit and pay a small racing cost. This makes 'keep HTTP/2 enabled forever' a hard rule, not a transition step. ## How to verify it helped Set the measurement plan before flipping the switch. 1. **Protocol share.** What fraction of requests are actually served over h3? A disappointing number here usually means advertisement problems - missing DNS HTTPS record, short Alt-Svc max-age, clients that never got a first response - rather than a protocol that failed. 2. **Fallback and failure rate.** How often does a QUIC attempt fail and fall back to TCP, and on which networks? A high rate concentrated in particular networks is a UDP-filtering story. 3. **Field percentiles, segmented.** Real-user monitoring of time-to-first-byte and load metrics at p75 and p95, split by protocol *and* by network class (cellular, Wi-Fi, wired) and by region. Averages will hide the effect, because the benefit is concentrated in the bad tail. Beware selection bias: users who successfully negotiate h3 may be systematically on better-maintained networks, so prefer a randomised or geographic holdout over a naive h2-versus-h3 comparison. 4. **Cost and error metrics.** CPU, egress, and any change in connection error rates - for self-hosted deployments especially. ## The decision, compressed Behind a CDN with consumer mobile traffic: enable it, keep h2 as fallback, and verify with segmented field percentiles and h3 share. Self-hosted, datacenter, or low-request-count API traffic: the engineering cost is real and the benefit small, so spend the effort on payload size, caching and server time instead. Either way, the honest position is that HTTP/3 is a tail-latency improvement for bad networks, not a general speed-up.