Last year, the HTTP/2 protocol was finalized. Support has already been implemented in Firefox and Chrome. Work is underway to integrate the protocol into web servers like Apache. It’s expected that in 2015, adoption of HTTP/2 will grow. It’s likely that adoption will proceed slowly, but it’s in the interest of web designers and developers to know what to expect.
Although most of the work towards HTTP/2 will be carried out at a lower level of the stack than web designers need to worry about — within web servers and browsers — it will have an impact on how web pages are put together. In fact, web design and front-end development habits now viewed as best practices are likely to harm performance under HTTP/2.
A large proportion of what are considered performance best practices for front-end developers are actually techniques for getting around the limitations of HTTP/1.1. The earlier protocol was designed for a different web. A web page of today involves assets of many different types loaded from many different servers. For HTTP/1.1, that’s a problem, because each TCP connection will download assets one at a time, blocking further downloads until completion. So browsers open several TCP connections, each of which takes time and imposes a performance penalty, but there is a limit to how many simultaneous connections we can open to each server.
We try to work around these limitations with techniques like domain sharding, image sprites, resource inlining, and concatenation — all aimed at increasing the number of resources we can download concurrently by squeezing them down one TCP connection.
HTTP/2 will bring the gift of multiplexing: One TCP connection can request and download multiple resources concurrently. Under HTTP/2 there should never be any reason to open more than one request to a host. In fact, the HTTP/2 spec specifically warns against doing so.