Domains, CDN & Web Delivery

HTTP/2

Definition

The important change is framing. HTTP/1.1 sends a request as plain text and waits for the whole response before reusing the connection, so a browser opens six connections per host and still queues. HTTP/2 splits everything into binary frames tagged with a stream identifier, which means dozens of requests and responses interleave on a single connection. Header fields are compressed with HPACK, which keeps a table of previously sent headers on both ends — so the second request on a connection can refer to a long cookie or user-agent string by index rather than repeating it. Streams carry weights and dependencies so a browser can say the stylesheet matters more than an image below the fold. Server push was part of the original design and has since been removed from Chrome, so treat it as gone. Browsers only speak HTTP/2 over TLS, negotiating it during the handshake through ALPN, where the protocol identifier is h2.

Why It Matters

Under HTTP/1.1 the cost of an extra file was real, which is why the old advice was to inline everything, build CSS sprites and shard assets across several subdomains. HTTP/2 removes most of that cost: forty small files on one connection are no longer forty queued round trips, so those workarounds now do harm. Sharding in particular is actively counterproductive, because each extra host forces a separate DNS lookup, TCP handshake and TLS handshake — perhaps 200 ms each on a mobile connection — and splits the multiplexing benefit in two. What HTTP/2 does not fix is the underlying TCP connection: one lost packet stalls every stream on it, which is the problem HTTP/3 and QUIC were designed to solve.

How It Works

A browser opening a secure connection lists the protocols it supports in the TLS ClientHello, and the server replies choosing h2 if it can. From there, both sides exchange binary frames — HEADERS for the request or response metadata, DATA for the body, SETTINGS and WINDOW_UPDATE for flow control. Each request gets an odd-numbered stream id, and frames from different streams arrive interleaved, so a slow API response no longer blocks a stylesheet sitting behind it. Because HPACK's dynamic table is per connection, header overhead falls sharply after the first few requests. On the origin side nothing about your files changes: the same 'index.html' and the same assets are served, and most people get HTTP/2 simply because their CDN or web server enables it by default.

Real-World Example

A one-page site published on 99helpers at field-notes.99helpers.site loads 34 assets — an HTML file, two stylesheets, three scripts, an icon set and 27 thumbnails. Over HTTP/1.1 the browser would fetch those in waves of six, each wave waiting on the last. Over HTTP/2 they go out on one connection and finish in a single burst, cutting roughly a second off the full load on a mobile network without a single file changing.

Common Mistakes

  • Sharding assets across several subdomains out of habit — on HTTP/2 the extra handshakes cost more than the parallelism gains
  • Inlining large base64 images into HTML or CSS to save requests, which defeats caching and bloats every page view
  • Building a deploy around server push, which Chrome removed and which the 103 Early Hints response now covers better
  • Assuming HTTP/2 is available over plain HTTP — browsers negotiate it only during a TLS handshake

Related Terms

Put a file online in seconds

Drop in a document, an image, a page or a whole static website and share the link — free, with no build step and no server to set up.

Host a file free →