HTTP2 is coming soon. It will bring big improvements to the web and make current performance optimizations obsolete... eventually.

Our bag of tricks isn't good enough

As you likely know, the HTTP 1.1 protocol involves opening one or more concurrent TCP connections to a server to request all the assets required by a HTML page. Each browser limits the number of concurrent requests. For example, Chrome only allows six simultaneous requests per host.

This limitation can slow down the time it takes to completely render a web page with lots of assets. Web developers invented some techniques (hacks) to speed things up... all of which have downsides:

These techniques are well-established and generally regarded as "best practices". Search engines will rank your site higher in results if you implement these techniques for example. This is a good thing; it's all to improve the user experience. Unfortunately even if you manage to reduce the number of HTTP requests to the bare minimum (and somehow maintain your sanity) HTTP 1.1 is STILL incredibly slow on mobile devices. Why? Latency.

TCP is really designed for long-lived connections, not creating lots of short-lived new ones. After hand-shaking, the protocol uses a slow-start process technique for network congestion mitigation. This isn't great when your application needs to fire up multiple connections in a just-in-time fashion.

Each new HTTP requests involve a DNS lookup, TCP handshake and TCP slow-start process. Each of these involves multiple network round trips, each one compounding the total latency. Since latency is especially bad on mobile networks, the net result is multiple HTTP requests results in a poor experience on mobile despite whatever optimizations you have in place.

HTTP2 fixes the latency problem

HTTP2 solves the latency problem by multiplexing requests over a single TCP connection. It has some extra optimizations like header compression and "server push" (where the server can preemptively send assets to the client) but the important part is the multiplexing. One long-lived TCP connection per web site is all you will need.


HTTP2 is available in some browsers right now. For Chrome, you need to go to chrome://flags/ and enable SPDY (which HTTP2 is based on). Firefox has it enabled by default for HTTPS sites only.

Here's an awesome demo site written in Go where you can try it for yourself.

HTTP2 will be coming to a web server near you very soon. It's probably going to be in nginx by the end of 2015 and will ship with Windows 10.

What this means for developers

For the most part, HTTP2 is very inter-operable and will just magically work as browsers and servers implement it. HTTP2 is enabled when a browser requests it from the server and the server upgrades the connection if it supports the protocol.

There was some debate about TLS and if it should be required for HTTP2 to work. The end result was that the protocol doesn't require TLS but browser vendors might do it anyway, just to promote the use of TLS in general (which is a very good thing).

Also, HTTP2 is binary. This was done for complexity and performance reasons. So you won't be able to telnet to a HTTP2-only endpoint and will need to rely on client software to do the de-serialization. This shouldn't be much of a problem for most people these days since we have things like curl.

I'm not clear exactly on how things like reverse proxies will need to change, if at all.

The most interesting thing is multiplexing basically renders all the best practices obsolete. Instead of trying to inefficiently bundle assets, you can just request only what your page needs individually, the old fashioned way, and not pay any latency penalty.

Of course not all browsers will support HTTP2 right away, so you should probably continue to use your bag of tricks until you know the majority of your users are on HTTP2.

More information

There's a lot to HTTP2 so definitely dig into it if you're curious. HTTP is probably the most successful application-layer protocol ever so it's wise to understand how it works.

[ Archive · Home ]