HTTP/2 vs HTTP/3: Where QUIC Actually Beats TCP on Real Connections

TCP was designed decades before multiplexed HTTP requests existed, and its core guarantee — that data arrives in the exact order it was sent, with nothing skipped — is exactly what creates the problem for HTTP/2. When a browser is pulling a dozen resources over one HTTP/2 connection and a single packet belonging to any one of them gets dropped somewhere on the network, TCP won't hand any of the following data to the browser until that missing packet is retransmitted and arrives, even though the other eleven resources' data may have already arrived intact.

That's head-of-line blocking in concrete terms: one lost packet stalls everything behind it in the connection's strict order, not just the resource it belonged to. HTTP/2's multiplexing reduced connection overhead, but it inherited this specific weakness directly from the transport layer underneath it, and no amount of clever HTTP-layer design fixes a problem that originates in TCP itself.

On a stable wired connection with near-zero packet loss, HTTP/2's head-of-line blocking rarely triggers in practice, because there's simply nothing being lost to stall behind — which is why lab benchmarks on clean connections sometimes show HTTP/2 and HTTP/3 performing close to identically. The gap opens specifically under real-world conditions where packet loss is common: mobile networks switching between cell towers, Wi-Fi with interference, or any connection with meaningful jitter.

Mobile networks are the clearest case, because packet loss there isn't an edge case — cell handoffs, signal fluctuation and network congestion make some level of dropped packets a routine part of a mobile session. HTTP/3's QUIC connections also survive an IP address change during a handoff without a full reconnect, something TCP-based HTTP/2 can't do, which compounds the advantage specifically for visitors browsing on the move rather than sitting at a fixed desk.