HTTP/2 is a new protocol for communicating over the web. Its predecessor, HTTP/1.1, dates back to 1999 and is long overdue for retirement.
HTTP/2 is also here, now. There are already a number of server implementations, and it is fully supported in Chrome, Firefox and Opera (with support in IE11 on Windows 10). It’s worth noting that while the HTTP/2 spec doesn’t require encryption, current browser implementations only support it over TLS.
Why do we need HTTP/2? How does it differ from HTTP/1.1? And what will it mean for web performance?
We’ll take a more detailed look over the coming weeks, but for now, here’s a brief overview of some of the key features of the new protocol and their likely impact on performance.
In HTTP/1.1 the number of resources a browser can download in parallel is limited by the number of connections per hostname (typically six or more, depending on the browser). One way to increase this limit is domain sharding – splitting resources over more domains in order to increase the total number of connections. However, multiple connections mean multiple TCP slow starts (where the amount of data transmitted is ramped up gradually to avoid sending more than the network can deal with). Adding more domains also adds more DNS lookups, which limits the benefits of sharding.
In HTTP/2, requests and responses are multiplexed over a single TCP connection, enabling more resources to be downloaded in parallel. This could make domain sharding at best redundant and at worst harmful (thanks to the overhead of the extra DNS lookups).
HTTP/2 allows resources to be sent from server to client without the client requesting them, eliminating the delay caused by the time it takes for the browser to discover and then request those resources. For example, most pages depend on at least one CSS file. Server push means the file can be sent to the client before the client asks for it.
This will mean it’s no longer necessary to inline critical CSS in order to improve performance. This is good news for two reasons. One is that it allows developers to write cleaner code – separating style from content. The other is that a separate CSS file can be given a longer cache lifetime than the HTML.
On pages with large numbers of objects, header size can add significantly to page weight and therefore load time. In HTTP/2, headers are compressed, reducing their impact on performance.
Taken together, header compression, multiplexing and server push all mean that with HTTP/2 the performance cost of having multiple objects on a page is greatly reduced. This calls into question the benefits of techniques such as spriting and concatenating text files. Indeed, we might well be better off splitting files up for more granular control over caching.
Overall, the signs are that HTTP/2 is going to make the web faster, which is great news for all of us. However, we could find ourselves having to undo a lot of the work we’ve done to get around the limitations of HTTP/1.1 – performance best practices that have suddenly become worst practices (also see http://www.slideshare.net/AndyDavies/are-todays-good-practices-tomorrows-performance-antipatterns-28286548). We’ll be looking at these in more detail very soon, so watch this space…