HTTP/2 Is Ready — What It Actually Means for Your Site

HTTP/1.1 has carried the web since 1997 — a protocol designed for pages made of one HTML file and a handful of images, now hauling applications that load a hundred resources per view. We've spent two decades inventing workarounds for its limitations: sprite sheets, concatenated bundles, domain sharding, inlined assets. Entire chapters of performance advice are really just apologies for the protocol underneath.

HTTP/2 — standardized as RFC 7540 in May of last year — is the first real fix, and as 2016 closes it has crossed from "interesting" to "deployable." Every major browser supports it, nginx and other mainstream servers ship it, big sites run it in production, and adoption is somewhere around one in ten websites and climbing steadily. Here's what actually changes, how to turn it on, and — the part most articles skip — which of your hard-won optimizations are now working against you.

What HTTP/2 actually changes

The headline features, in descending order of impact:

• Multiplexing kills head-of-line blocking. HTTP/1.1 handles one request at a time per connection — a slow response blocks everything queued behind it, which is why browsers open six parallel connections per host and still end up waiting. HTTP/2 interleaves any number of concurrent requests and responses over a single connection, as independent streams. The six-connection workaround, and the waiting, largely disappear.
• One connection instead of six. A single, long-lived, well-tuned TCP connection replaces the pack. That's fewer handshakes, fewer slow-starts, less duplicated overhead — and it plays much better with TLS, since you pay the handshake once.
• Header compression. HTTP/1.1 re-sends nearly identical headers — cookies, user-agent, accept lines — with every single request, uncompressed. HTTP/2's HPACK encoding compresses them and avoids re-sending what hasn't changed. On a page making dozens of requests, this alone saves real bytes and round trips.
• Server push. The server can send resources the browser hasn't asked for yet — pushing your stylesheet alongside the HTML that references it, saving a round trip. Promising, but young: cache interactions are subtle, and it's easy to push bytes the browser already had. Treat it as an experiment, not a default.
• It's binary. Framing is binary rather than text, which makes the protocol more efficient and less ambiguous to parse. Invisible to your users and your application code — your app still sees ordinary requests and responses.

In practice, HTTP/2 means HTTPS

The specification technically permits unencrypted HTTP/2. The browsers do not: Chrome, Firefox and the rest only negotiate HTTP/2 over TLS. If your site is plain HTTP, this entire upgrade is unavailable to you — full stop.

We've argued the case for HTTPS on every site before — free certificates, the search-ranking signal, integrity against ad-injecting networks. HTTP/2 adds the bluntest incentive yet: the encrypted version of your site gets a faster protocol than the unencrypted one ever will. "HTTPS is slower" has fully inverted — the fastest configuration available today requires it.

Enabling it — nginx in one line (plus one gotcha)

If you're on nginx with TLS already configured, HTTP/2 support (in nginx since 1.9.5, released last year) is almost anticlimactic:

server {
    listen 443 ssl http2;
    server_name example.com;

    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
}

Reload, and modern browsers start speaking HTTP/2 to you while older clients transparently fall back to HTTP/1.1 on the same port. Apache users have mod_http2 as of 2.4.17, still marked experimental — usable, but mind the release notes.

The gotcha: check your OpenSSL version. Browsers select HTTP/2 during the TLS handshake via an extension called ALPN, which requires OpenSSL 1.0.2 — and Chrome dropped support for the older NPN mechanism this year. On distributions shipping older OpenSSL (Ubuntu 14.04 being the common case), nginx will happily accept your http2 directive while Chrome silently negotiates plain HTTP/1.1. Verify what's actually being served rather than trusting the config:

curl -sI --http2 https://example.com -o /dev/null -w '%{http_version}\n'

Recent curl prints 2 when HTTP/2 was negotiated. Browser dev tools show it too — add the Protocol column in the Network tab.

The old tricks you should start unwinding

This is the counterintuitive part: several canonical HTTP/1.1 optimizations range from useless to actively harmful under HTTP/2.

• Domain sharding — spreading assets across img1.example.com, img2.example.com — existed purely to escape the six-connection limit. Under HTTP/2 it's pure cost: it splinters your beautiful single multiplexed connection into several, each paying its own DNS lookup, TCP setup and TLS handshake, and it defeats header compression across hosts. Consolidate.
• Excessive concatenation — shipping one giant bundled JS or CSS file — made sense when every request was expensive. With cheap multiplexed requests, monolithic bundles mostly hurt caching: change one line and every client re-downloads the entire bundle. A handful of sensibly split files caches far better. (A handful — hundreds of tiny files still lose to per-request overheads. Moderation, not reversal.)
• Sprite sheets and inlined assets — same trade: they saved requests at the cost of cache granularity and complexity, and the requests they save are no longer expensive.

The practical advice for the transition: don't rip everything out on day one. Enable HTTP/2, measure with real timings, then unwind sharding first (clearest win), and de-concatenate gradually as part of normal work. And since HTTP/1.1 clients still exist, you're serving both worlds for a while — measure both.

Verify the upgrade from the outside

A protocol migration is exactly the kind of change that looks done before it is done — the config says http2, but an old OpenSSL, a middlebox, or a CDN tier quietly downgrades real visitors, and the certificate that TLS-only HTTP/2 now depends on becomes one more thing that can silently expire. The pattern we recommend all year applies here too: make the change, then verify it continuously from where your users are.

CompleteStatus checks your site from the outside — response times you can compare before and after the switch, TLS handshake and certificate expiry monitoring for the HTTPS layer HTTP/2 rests on, and alerts the moment any of it regresses. Create a free account, baseline your response times this week, flip on HTTP/2 next week, and enjoy one of the rare upgrades where the line on the graph visibly moves in the right direction.