The web is now 25 years old and how your browser talks to the website, the HTTP protocol, hasn't changed much since back then. However, how we use the web has changed, and the limitations of HTTP/1 are starting to show. Loading web pages is slower than it needs to be and it doesn't use the network as efficiently as it could. That's because HTTP/1 effectively only allows one request to be on a single TCP connection at any one time.
Since modern web pages often need to make more than a hundred request to load JavaScript, CSS, and images, this is a big problem. Today, browsers use many connections per site to download all of these assets. However, they can't use too many because that would overload the network by making congestion worse, so they currently use between four and eight connections, guessing which request to send on each one - and sometimes getting it wrong.
The large number of requests on a modern web page also cause another problem: each request has a set of HTTP headers that has grown over time, thanks to things like cookies, and they can add up to a lot of data to send. On high latency mobile networks this has a significant impact on performance. All of this has made HTTP/1 slow and increasingly complex to use. Many sites try to address these problems by hacking around them, using techniques like CSS printing, in-lining, and concatenation. While they help, these hacks are a good indication that we can do a lot better.
So in 2012 work began on HTTP/2. This new protocol, based on the Speedy project, allows one connection to be used for all the communication between your web-browser and the website. It does this by splitting request and response messages into little chunks called “frames” and labeling them so they can be reassembled once they get to the recipient.
This is called multiplexing and allows the network to be used much more efficiently because many messages can be in flight at the same time, unlike in HTTP/1. Additionally, HTTP/2 allows headers to be compressed, which means that bandwidth isn't wasted repeating lots of redundant information. This makes it possible to load pages more quickly even if they need to make a large number of requests, as many do, because the requests take less time to get across the network. Other optimizations like server-push make it possible for a site to send responses to the browser before the browser needs them - again improving performance.
Early results indicate that just turning on HTTP/2 will often -but not always- give a five percent to fifteen percent performance improvement. With some tuning, it could be substantially more. It's important to know that the new protocol doesn't change things like HTTP methods. Headers or status codes the HTTP APIs use should look pretty much the same. And it can even be used on a hop-by-hop basis, so you don't have to update your whole infrastructure at the same time.
HTTP/2 is almost done. It should be supported by popular web browsers like Firefox, Internet Explorer, and Google Chrome soon. Akamai will support HTTP/2 as well, bringing the new protocol to a large portion of the Web.