Your site runs over HTTP/2 and a colleague argues that because requests are multiplexed on one connection, you should stop concatenating JavaScript into large bundles and stop worrying about serving assets from a second asset hostname. Which HTTP/1.1-era practices genuinely should go, and where does "requests are free now" break down?

## What HTTP/1.1 forced frontends to do Under HTTP/1.1 a browser opens a small number of parallel connections per origin — around six in practice — and each connection carries one request at a time. That single constraint produced most of the delivery folklore of the era: **concatenate** scripts and stylesheets so there are fewer requests to queue, **sprite** small images into one sheet for the same reason, **inline** critical resources into the HTML so they need no request at all, and **shard** assets across `static1.example.com`, `static2.example.com` and friends so the browser would open several sets of connections and get more parallelism. Every one of those is a workaround for a limit on *concurrent requests*, not a statement about what is inherently good design. Once the limit changes, the workarounds have to be re-argued from scratch. ## What multiplexing changed HTTP/2 carries many concurrent requests over a single connection, so the queueing that motivated concatenation and sprites largely disappears. Two consequences follow directly. First, **domain sharding is now a net cost.** An extra hostname means another DNS resolution, another TCP connection and another TLS handshake before the first byte of the first asset on it can move — round trips that the already-warm main connection has finished paying. It also splits your traffic across connections that cannot be prioritised against each other, so the browser has less ability to decide what matters most. Retiring shards is one of the few unambiguous wins here. Second, **fine-grained splitting became affordable.** Shipping fifteen chunks instead of one is no longer the disaster it was in 2013. That is a real change, and it enables better caching: a monolithic bundle is invalidated in full by a one-line change, whereas separate chunks let unchanged code stay in the user's cache across deploys. ## Where "requests are free" breaks down Four costs survive multiplexing, and a senior answer names them. **Compression ratio.** Each response is compressed independently. Compressors work by finding redundancy within their input, so a single 300 kB file compresses much better than thirty 10 kB files with the same total content — repeated tokens and the compressor's warmed-up state do not carry across file boundaries. Shattering a bundle into very small pieces can measurably increase total bytes on the wire even though it reduced no code. **Per-request overhead that is not connection setup.** Each request still costs header frames, a cache lookup at the edge, possible origin work, and bookkeeping in the browser. Individually small, collectively real once you are into the hundreds. **Discovery chains.** The expensive shape is not many requests — it is *serial* requests. If chunk A must be fetched and parsed before the browser learns chunk B exists, you have added a round trip that no amount of multiplexing removes. A flat set of fifty requests issued at once behaves very differently from five requests issued in a chain of five depths. **Cache churn.** Splitting too finely means a single dependency bump can change many chunk hashes at once, or force the entire chunk graph to be re-fetched — the opposite of the caching benefit that motivated splitting. One more: HTTP/2 puts everything on one TCP connection, so a lossy network degrades all streams together; HTTP/3 improves that situation, but it changes none of the byte, parse or compression arguments above. ## The workable default Drop sharding, drop sprites, keep inlining strictly for genuinely render-blocking critical content (inlining trades cacheability for one fewer round trip, so it should be small and deliberate). Ship a moderate number of chunks — enough that caching works across deploys and that the first screen does not pull in code it never runs, few enough that compression ratio and request bookkeeping stay sane. "A dozen or two" is a very different regime from "three" and from "two hundred". ## Proving it The argument is settled by measurement, not by protocol trivia. Compare total compressed transfer bytes before and after — not raw bytes, since the compression effect is the whole point — and look at whether the request waterfall is wide (parallel, fine) or deep (chained, expensive). Then confirm with field data rather than a single fast-network local run, because the connection-setup savings from removing a shard show up mainly for users on slow, high-latency networks.