Google started development on what would become the basis of HTTP/2 as early as 2010. Known as SPDY, it was designed to work alongside the then-current HTTP/1.1 protocol by manipulating and optimizing traffic as it left the server. In 2015, SPDY was integrated into – and gradually replaced by – HTTP/2.
Like SPDY, HTTP/2 was designed to overcome many of the shortcomings of HTTP/1.1, particularly with how content is delivered over a network. Users see improvements in page load speed and responsiveness, while website administrators see lower resource usage. The result is a faster experience with no change to the existing functionality of the web.
HTTP/2 focuses on optimizing the flow of content between clients and servers. It’s fully backwards-compatible with HTTP/1.1, meaning websites will work the same with either protocol.
When a user connects to a server, their browser negotiates an HTTP session with the server. The type of session created will vary depending on the features supported by the browser and the server. If both parties support HTTP/2, the server uses the HTTP/2 protocol to shape and optimize traffic before it passes through the network to the user.
Once the browser and server agree to use HTTP/2, they can utilize features such as compression, multiplexing, and server push to optimize the connection. If either party doesn’t support HTTP/2, both the browser and server fall back to HTTP/1.1.
In order to maintain backwards-compatibility with HTTP/1.1, HTTP/2 maintains much of the functionality of HTTP/1.1. However, it does introduce some drastic changes including:
HTTP/2 also solves many of HTTP/1.1’s workarounds such as:
Although HTTP/2 is still fairly new, support for it continues to grow. Most major browsers support HTTP/2 including Microsoft Edge, Firefox, Chrome, Safari, and Chrome for Android. Many popular web servers include native support for HTTP/2 including the Apache HTTP Server, NGINX, and Tomcat. As software support for HTTP/2 increases, so will adoption across websites and web platforms.