Quick answer: HTTP/2 is the first major update to the protocol browsers use to fetch web pages since HTTP/1.1 in 1999. It was published as a standard in May 2015. Its main speed benefit is that a browser can request many files at once over a single connection, instead of queueing them across a handful of connections. To use it you need HTTPS, a server or CDN that supports it, and a reasonably current browser, which most of your visitors already have. Some old speed tricks, such as heavy file concatenation and domain sharding, matter less once it is on.
Most of the speed advice of the last ten years was written to work around the limits of HTTP/1.1. HTTP/2 removes some of those limits. That does not make a slow site fast on its own, but it does change which optimisations are worth your time.
Why HTTP/1.1 is slow for modern pages
A typical business web page loads dozens of files: HTML, stylesheets, scripts, fonts, images and tracking tags. Under HTTP/1.1:
- Each connection handles one request at a time. The browser asks for a file, waits for it, then asks for the next.
- Browsers open around six connections per domain to work around this, so at most about six files download in parallel from each domain.
- Every request sends a full set of headers, including cookies, often repeated word for word.
On a fast office connection this is tolerable. On a mobile network, where each round trip to the server takes longer, the waiting adds up.
What HTTP/2 changes
Multiplexing
This is the big one. HTTP/2 lets the browser send many requests over one connection at the same time, and the server can send the responses back interleaved. A small icon no longer waits behind a large image. In practice, pages with many small files benefit the most.
Header compression
HTTP/2 compresses headers with a scheme called HPACK, and avoids resending headers that have not changed. Cookie heavy sites see a noticeable reduction in the data sent with each request.
Binary framing
HTTP/1.1 is a text protocol. HTTP/2 splits messages into binary frames, which are quicker for machines to parse and less prone to errors. You will not notice this directly, but it is what makes multiplexing possible.
Stream priority
Browsers can tell the server which files matter most, such as the CSS needed to draw the page, so the server can send those first. How well this works depends on both browser and server.
Server push
The server can send files the browser has not asked for yet, on the assumption it will need them. For example, when the HTML is requested, the server can push the main stylesheet straight away. Push is powerful but easy to get wrong: if you push files the browser already has in its cache, you waste bandwidth. Treat it as something to test carefully rather than switch on everywhere.
What you need to use it
HTTPS
The HTTP/2 standard does not strictly require encryption, but every major browser only supports it over HTTPS. So in practice, no HTTPS means no HTTP/2. If you have not moved yet, our HTTPS migration guide covers the steps, and Let’s Encrypt now offers free certificates.
Your TLS setup also matters. Browsers expect TLS 1.2 with modern ciphers for HTTP/2. If your server still allows old protocols, review our guide to SSLv3 and POODLE while you are at it.
A server that supports it
- Nginx added HTTP/2 support in version 1.9.5, released in September 2015.
- Apache added the mod_http2 module in version 2.4.17, released in October 2015. It is still marked as experimental.
- IIS on Windows Server 2016 supports HTTP/2, but that version of Windows Server is not on general release yet.
- CDNs such as CloudFlare and Akamai already offer HTTP/2 at the edge, which can be the quickest route if your own server is older.
Many shared hosts are still on older server versions. Ask your host directly whether HTTP/2 is available on your plan.
Browser support
Current versions of Chrome, Firefox, Opera, Safari on OS X El Capitan and iOS 9, and Microsoft Edge all support HTTP/2. Internet Explorer 11 supports it on Windows 10 only. Browsers that do not support it simply fall back to HTTP/1.1, so switching it on does not lock anyone out.
How to check whether you are using it
- In Chrome, open Developer Tools, go to the Network tab, right click a column heading and turn on the Protocol column. You will see “h2” for HTTP/2 requests.
- Online HTTP/2 test tools will check a URL for you.
- Your server or CDN control panel may show it as a setting.
Check third party files too. Your own pages may load over HTTP/2 while scripts from other domains still use HTTP/1.1.
Old speed habits to rethink
Much of the classic speed advice still applies: compress images, cache files, keep pages lean. But a few habits were designed purely to work around HTTP/1.1.
Domain sharding
Spreading files across several subdomains (such as static1 and static2) let browsers open more parallel connections. With HTTP/2, one connection is better, and sharding can actually slow things down by forcing extra connection setups. If you shard, consider consolidating.
Heavy concatenation
Combining every script into one big file reduced request counts. With multiplexing, many small files are cheaper, and keeping files separate means a change to one does not invalidate the cache for all of them. That said, do not go to the other extreme with hundreds of tiny files. A sensible middle ground works best.
Image sprites
Sprites combine small images into one file. They still work, but the case for them is weaker. Inline SVG icons or separate small files are fine over HTTP/2.
Inlining CSS and scripts
Putting small files directly into the HTML saved requests. Server push can do a similar job while still letting the browser cache the file. Keep inlining for truly critical, tiny amounts of CSS.
Do not rush to undo these optimisations if a large share of your visitors are on browsers that still use HTTP/1.1. Check your analytics first.
What HTTP/2 will not fix
HTTP/2 makes the delivery of files more efficient. It does not make the files themselves smaller or the server faster at building pages. Common causes of slow sites remain:
- Slow server response caused by heavy plugins, slow database queries or overloaded shared hosting.
- Large, uncompressed images.
- Too many third party scripts.
- Render blocking JavaScript.
For WordPress sites, our WordPress speed optimisation guide covers these in detail. Fix them first. HTTP/2 then adds a further gain on top.
Is it worth switching on?
For most sites already on HTTPS, yes. The risk is low because browsers fall back gracefully, and the work is often a configuration change or a CDN setting. Sites that load many files per page, such as online shops and content heavy blogs, tend to benefit most.
Plan it like any other change:
- Confirm your server or CDN supports HTTP/2.
- Make sure TLS is configured well.
- Switch it on in a test environment if you have one.
- Measure page load times before and after with the same test tool and location.
- Review sharding and concatenation once you see the results.
FAQ
Does HTTP/2 help SEO?
Google has said speed is a ranking factor, and HTTP/2 can make pages faster. But it is the speed that counts, not the protocol label. A slow site on HTTP/2 is still slow.
Do I need to change my website code?
No. HTTP/2 keeps the same methods, status codes and URLs as HTTP/1.1. Your pages and links work as before.
What about SPDY?
SPDY was Google’s experimental protocol that HTTP/2 grew out of. Chrome plans to drop SPDY support in 2016, so servers should move to HTTP/2.
Want a faster, safer site?
We review hosting, server settings and front end code together, so speed gains are real and measurable. See how we help businesses turn visitors into customers with sites that load quickly.
