HTTP/2 is the latest version of HTTP.
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..
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.
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.
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.
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.