A platform is considering moving customer traffic to HTTP/3. What does it actually improve, for whom, and what does it complicate?

What it genuinely improves

• Head-of-line blocking across streams. In HTTP/2 over TCP, a lost packet stalls every multiplexed stream because TCP delivers in order. QUIC's per-stream delivery means only the affected stream stalls. This is the real improvement and it matters most on lossy networks.
• Connection establishment. Combining transport and cryptographic handshakes reduces setup to fewer round trips, and resumption can be effectively zero round trips. On a high-latency mobile connection this is visible.
• Connection migration. A connection survives a change of network path, so switching from mobile data to Wi-Fi does not break in-flight requests.

Who actually benefits

Users on mobile networks with meaningful loss and variable connectivity — which for a consumer product in many markets is most users, and for a desktop-heavy enterprise product on stable networks is almost nobody.

The honest framing is that the benefit is concentrated in exactly the population that is hardest to test against, which is why measured results vary so widely between organisations.

What it complicates

• UDP-based transport is blocked or throttled on some corporate and public networks, so a fallback to HTTP/2 is mandatory and must be tested, not assumed.
• Observability tooling built around TCP does not apply. Packet capture, connection metrics and many network appliances need replacing or updating.
• Middlebox behaviour is less predictable, and diagnosing a QUIC problem inside a corporate network is materially harder.
• Congestion control moves into userspace, which is an advantage for tuning and a new surface for regressions.

The decision

Enable it at the edge, keep HTTP/2 as fallback, and measure by network type rather than in aggregate. The aggregate number will be unimpressive because it averages the users who benefit with those who do not; the per-cohort number is where the decision is.

And treat it as an edge concern only — there is no reason to run it inside a controlled datacentre network, where loss is negligible and the complexity buys nothing.