HTTP/2 is the latest version of HTTP.

It’s the first major upgrade to the HTTP protocol in over 15 years. Websites have changed dramatically in the interim, with the number of external image, CSS, and JavaScript assets growing by the year. HTTP/1.1 wasn’t designed for this kind of complexity.

HTTP/2 began its life as Google’s SPDY protocol, which they designed to address many of the performance problems inherent in HTTP/1.1. The core benefits of SPDY have made their way into HTTP/2, improved by the global Internet community, and formalized into an Internet Standard.

HTTP/2 is optimized for the modern website, improving performance without complicated hacks like domain sharding and file concatenation.

Benefits of HTTP/2 explained

HTTP/2 introduces several new features, and they’re all designed to improve page load times for your website visitors without any changes to your existing codebase..

Multiplexing

HTTP/1.1 is sort of like buying a single item at a grocery store, taking it back home, going back to the store for the next item you need, and repeating until your pantry is fully stocked. Multiplexing gives you a shopping cart so you can pick up everything you need in one trip.

Multiplexing is perhaps the most significant benefit of HTTP/2. HTTP/1.1 requires each request to use its own TCP connection. Multiplexing, in contrast, allows a browser to include multiple requests in a single TCP connection.

Server Push

HTTP/2 Server Push lets our edge network send web assets back to your browser before it even knows it needs them. This speeds up page load times by eliminating unnecessary round trips. For example, when a browser requests an HTML page, you can “push” all of the CSS stylesheets, image resources, and other assets inside of that web page. After the browser parses the HTML and finds all those assets, they’ll already be loaded into the local browser cache. This avoids extra requests back to the server.

Stream Priority

Stream priority is a mechanism for browsers to specify which assets they would like to receive first. For example, an HTTP/2-aware browser can use stream priority to load the HTML for a page first, followed by CSS, then JavaScript, and finally image assets. This order allows the browser to render the page as quickly as possible.

You can think of stream priority as an optimization on top of multiplexing. Multiplexing lets you send several requests in a single TCP connection, and stream priority lets you define the order of the responses. While multiplexing eliminates much of the TCP overhead, it does nothing to optimize transfer times from the server to the browser. This is what stream priority is for.

Header Compression

Modern websites rely on a lot of external assets: images, CSS, JavaScript, and fonts, just to name a few. Each time a browser requests one of these assets, it includes an HTTP header with the request. When the server sends the asset back to the browser, it also includes an HTTP response header. That’s a lot of overhead for the typical web page.

HTTP/2 forces all HTTP headers to be sent in a compressed format, reducing the amount of information that needs to be exchanged between browser and server. HTTP/1.1 does not provide any form of header compression.