HTTP/2 Is Here, and It Wants Its Optimizations Back

The web’s transport protocol received its first real revision since 1997 this spring, and the anniversary math deserves a moment. HTTP/1.1 carried every page load we have ever analyzed. It predates Google, predates this agency, and predates most of the practices built on top of it.

Its successor, HTTP/2, was finalized as RFC 7540 in May. It arrives with browser support already broad. The major browsers shipped ahead of the ink drying. And it does its work at a layer most site owners never think about, which is exactly why it is worth covering. The protocol change retires a decade of performance folklore that we, among others, taught. The unlearning is as practical as the learning was.

The headline capability is multiplexing. HTTP/1.1 handled one request at a time per connection, forcing browsers to open a handful of parallel connections and queue everything else. HTTP/2 weaves many requests and responses over a single connection. Header compression shaves the repeated overhead. Priority rules let important resources jump the line.

The waiting-room problem that shaped front-end performance practice for fifteen years is, at the protocol layer, solved. Which means the workarounds are now the overhead, and the optimization guide gets the rare pleasure of a rewrite by deletion.

The folklore this retires, item by item

• Sprite sheets. Packing many small images into one file existed to avoid many requests. Under multiplexing, many small requests are cheap. The sprite’s costs (whole-sheet cache busting for one icon’s change, the maintenance choreography) stop buying anything. The SVG-and-icon-font direction our Retina coverage pushed was already replacing sprites. HTTP/2 finishes the argument.

• Aggressive concatenation. Bundling every script and stylesheet into monoliths traded cache granularity for fewer requests. The trade reverses. Smaller, logically split files let a one-line change invalidate one small file rather than the monolith, and multiplexing makes the extra requests free. Sane bundling survives. The point is that the request-count terror driving extreme concatenation is over.

• Domain sharding. Spreading assets across subdomains to trick browsers into more parallel connections now actively fights the protocol. Each shard is a separate connection that gives up multiplexing’s benefits, plus extra DNS and TLS setup. Sharding moves from folk remedy to measurable harm, and sites that adopted it have an actual un-migration to schedule.

• Inlining-for-requests. Embedding assets in pages to skip requests loses its rationale. HTTP/2’s server-push feature offers a protocol-level replacement for the legitimate cases, though push’s best practices are young enough that our advice is to watch rather than deploy.

What survives, because it was never about requests

The unlearning has boundaries worth marking, because the folklore’s retirement does not touch the fundamentals we teach.

Bytes still cost what they cost. Image discipline, compression, and the page-weight budgets serious projects carry are protocol-independent, and a three-megabyte page is slow on any HTTP.

Latency still governs cellular experience. Caching still beats transferring. CDNs still shorten distances. And the server-response fundamentals of the caching ladder still set the floor.

HTTP/2 removes a specific class of overhead: connection scarcity and its workarounds. It does not repeal the math of weight, which remains most of most sites’ problem. Budgets stay. Sprites go. The distinction is the whole update.

The verification pass, and the sharding un-migration

Two practical notes for the implementers before the close.

Checking is pleasantly simple. The browser dev tools now report the protocol per request, and the online checkers confirm a domain’s support in seconds. The afternoon after your CDN flips the switch, confirm the h2 in the network panel and log the before-and-after timing on your heaviest templates for the performance file. Our early client numbers show the expected shape. The biggest gains land on request-heavy pages over slower connections. Which is to say, precisely the cellular mobile case the year’s traffic milestones keep centering.

The sharding un-migration deserves its own line item where it applies. Bringing assets back onto the primary hostname is template and configuration work with a redirect-hygiene pass attached. The old shard hostnames should redirect permanently, per canonical rules. Sites that sharded hard in the 2010-era push should schedule it rather than absorb it. Half-un-sharded states combine both eras’ costs.

The pattern is familiar from every era transition. Yesterday’s optimization becomes today’s cleanup ticket. The cleanup is real but bounded. The sites that maintain deliberately cross in an afternoon while the improvised ones discover their sharding was never documented. The inventory, as always, is the speed.

Adoption: refreshingly passive, with one prerequisite

The adoption story is the gentlest yet. Browsers are ready now and negotiate the protocol on their own. Servers and CDNs are rolling support through 2015, and the CDN tier, per the down-market pattern our infrastructure coverage tracks, is making it a checkbox. Sites need no markup changes, no redesign, nothing but a supporting front end.

The one prerequisite with teeth: browsers are implementing HTTP/2 over encrypted connections only. That makes HTTPS the de facto ticket of admission, and adds one more compounding return to the TLS migrations our security coverage has urged since Firesheep and the ranking nudge formalized last summer.

The sequencing for most sites is therefore simple. Complete the HTTPS migration you already owed. Enable HTTP/2 at the CDN or server when offered. Verify in the browser tools. Then schedule the folklore cleanup as ordinary maintenance rather than a project. Un-shard. De-sprite as work touches things. Loosen the bundling.

Real speed, delivered at the infrastructure layer, for configuration effort. The kind of win that comes along perhaps once a protocol generation. Take it. Retire the folklore with honors. It was correct in its era, which is what folklore usually is. And let the next optimization guide be shorter than the last. Shorter guides are usually the sign the platform grew up.

And note the compounding chain for the strategy file. Firesheep argued for HTTPS. The ranking signal paid it. Now the faster protocol requires it. The security migration we have urged since 2010 keeps acquiring returns its original case never claimed. Good foundations do that. It is most of why we call them foundations.