HTTP/2, HTTP/3, and Connection Overhead

The plain-language idea

Under HTTP/1.1, a single TCP connection could only have one request in flight at a time; browsers worked around this by opening a handful of parallel connections per domain (commonly six), but that cap was still real and still limiting. Two performance techniques existed specifically because of this constraint:

• Bundling everything into one big file (one giant JS bundle, one CSS file, image spritesheets) — fewer total requests meant less contention for those limited, one-at-a-time connections.
• Domain sharding — splitting assets across multiple subdomains (img1.example.com, img2.example.com) specifically to get more parallel connections, since the six-per-domain cap was per-domain, not per-page.

HTTP/2 introduced multiplexing: many requests can now travel over a single connection concurrently, interleaved, instead of queueing one at a time. That directly removed the specific problem both workarounds existed to solve — which is a real part of why aggressive bundling and domain sharding are now often net-negative under HTTP/2 rather than a free win: sharding now just adds unnecessary extra connection setups, and monolithic bundling now just delays smaller, independently-cacheable files that could otherwise load concurrently.

HTTP/3 goes further, replacing TCP with QUIC, a transport built on UDP. This targets HTTP/2's one remaining weakness: on a single TCP connection, one dropped packet blocks every multiplexed stream on that connection until it's retransmitted — a problem called head-of-line blocking, and it exists at the TCP layer, below where HTTP/2's own multiplexing operates, so multiplexing alone couldn't fix it. QUIC's streams are independent at the transport level, so a dropped packet on one stream doesn't stall the others.

See it in a real thing: checking what your deployment actually serves

$ curl -I --http2 https://example.com/
HTTP/2 200
...

The practical takeaway is plain: before reaching for an HTTP/1.1-era workaround, check what protocol your actual deployment serves over. Most CDNs and modern hosts serve HTTP/2 or HTTP/3 by default today, which means the connection-parallelism problem bundling/sharding were built to solve may simply not apply to your deployment anymore — and applying the old technique anyway adds real cost (unnecessary domain lookups, monolithic bundles that can't be split or cached independently) for a problem that no longer exists on your infrastructure.

What people usually miss

Watch out

• Domain sharding is frequently a net negative under HTTP/2, not just unnecessary. Each extra domain still needs its own DNS lookup, TCP handshake, and TLS negotiation — real cost that HTTP/2's multiplexing already made unneeded on a single connection.
• Head-of-line blocking has two different layers, and HTTP/2 only fixed one. HTTP/2 multiplexing removed the application-layer one-request-at-a-time limit; the transport-layer blocking (one dropped TCP packet stalling every stream) remained until HTTP/3's QUIC addressed it directly.
• This is a protocol/infrastructure fact, not a code-level toggle. Whether a page is served over HTTP/2 or HTTP/3 depends on the server/CDN configuration, not application code — checking it is a deployment question, not a bundler setting.
• Aggressive bundling still has real, separate reasons to be sized carefully (covered in the code-splitting lesson) — the point here isn't "never bundle," it's that "bundle as much as possible because of connection limits" specifically stopped being the reason to do it.
• Old advice doesn't automatically stop applying just because a newer protocol exists — if a deployment is still actually serving HTTP/1.1 for some reason, the old techniques can still be genuinely relevant there; the fix is checking, not assuming either way.

Why this matters in interviews

"Why doesn't this app shard its images across multiple domains anymore?" or "should we still bundle everything into one file?" are real questions that test whether a candidate understands why an old technique existed, not just that it's out of fashion — tracing the reasoning back to HTTP/1.1's one-request-per-connection limit is what makes the answer land as understanding instead of trend-following.