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

HTTP/1.1 has carried the web since 1997. It was designed for pages made of one HTML file and a few images, and it now carries applications that load a hundred resources per view. We've spent two decades working around its limits with sprite sheets, concatenated bundles, domain sharding and inlined assets. A lot of performance advice is really compensation 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 become practical to deploy. 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 rising. Here's what changes, how to turn it on, and which of your existing optimizations now work against you.

What HTTP/2 changes

The main features, roughly in order of impact:

• Multiplexing. HTTP/1.1 handles one request at a time per connection, so a slow response blocks everything queued behind it. That's why browsers open six parallel connections per host and still end up waiting. HTTP/2 interleaves any number of concurrent requests and responses over one connection as independent streams.
• One connection instead of six. A single long-lived TCP connection replaces the pack: fewer handshakes, fewer slow-starts, less duplicated overhead. It also suits TLS well, since you pay for the handshake once.
• Header compression. HTTP/1.1 re-sends nearly identical headers (cookies, user-agent, accept lines) uncompressed with every request. HTTP/2's HPACK encoding compresses them and avoids re-sending what hasn't changed. On a page making dozens of requests, that adds up.
• Server push. The server can send resources the browser hasn't asked for yet, such as a stylesheet alongside the HTML that references it, saving a round trip. It's promising but young: cache interactions are subtle, and it's easy to push bytes the browser already has. Treat it as an experiment.
• Binary framing. Framing is binary rather than text, which is more efficient and less ambiguous to parse. Your application code doesn't see any of this; it still gets ordinary requests and responses.

In practice, HTTP/2 means HTTPS

The specification permits unencrypted HTTP/2, but the browsers don't implement it: Chrome, Firefox and the rest only negotiate HTTP/2 over TLS. If your site is plain HTTP, this upgrade isn't available to you.

We've made the case for HTTPS on every site before. HTTP/2 adds a very direct incentive: the encrypted version of your site gets a faster protocol than the unencrypted one can. "HTTPS is slower" has turned around, because the fastest configuration available today requires it.

Enabling it on nginx (plus one gotcha)

If you're on nginx with TLS already configured, HTTP/2 (supported since nginx 1.9.5, released last year) is one word:

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 using HTTP/2 while older clients fall back to HTTP/1.1 on the same port. Apache has mod_http2 as of 2.4.17, still marked experimental, so read the release notes.

The gotcha is your OpenSSL version. Browsers select HTTP/2 during the TLS handshake through an extension called ALPN, which needs OpenSSL 1.0.2, and Chrome dropped support for the older NPN mechanism this year. On distributions with older OpenSSL (Ubuntu 14.04 is the common case), nginx accepts the http2 directive while Chrome quietly negotiates HTTP/1.1. Check what's actually 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.

Old tricks to start unwinding

Several standard HTTP/1.1 optimizations range from useless to harmful under HTTP/2.

• Domain sharding (spreading assets across img1.example.com, img2.example.com) existed to get around the six-connection limit. Under HTTP/2 it only costs you: it splits your single multiplexed connection into several, each paying its own DNS lookup, TCP setup and TLS handshake, and it defeats header compression across hosts. Consolidate.
• Heavy concatenation (one giant JS or CSS bundle) made sense when every request was expensive. With cheap multiplexed requests, monolithic bundles mostly hurt caching: change one line and every client downloads the whole bundle again. A handful of sensibly split files caches much better. Hundreds of tiny files still lose to per-request overhead, so aim for moderation, not the opposite extreme.
• Sprite sheets and inlined assets are the same trade. They saved requests at the cost of cache granularity and complexity, and those requests are no longer expensive.

Don't rip everything out on day one. Enable HTTP/2, measure real timings, unwind sharding first (the clearest win), and split bundles gradually as part of normal work. HTTP/1.1 clients will be around for a while, so measure both.

Verify the upgrade from outside

A protocol migration can look finished before it is. The config says http2, but an old OpenSSL, a middlebox or a CDN tier downgrades real visitors, and the certificate that HTTP/2 now depends on is one more thing that can expire unnoticed. Make the change, then keep verifying it from where your users are.

CompleteStatus checks your site from outside: response times you can compare before and after the switch, plus TLS and certificate expiry monitoring for the HTTPS layer HTTP/2 depends on, with alerts when any of it regresses. Create a free account, record a baseline this week, enable HTTP/2 next week, and compare.