The HTTP/1.x protocol served faithfully for almost 20 years. It was replaced by HTTP/2, based on the SPDY protocol, developed in conjunction with Google. HTTP/2 is a major revision of the HTTP protocol that:

makes page loading and rendering faster;
speeds up the delivery via HTTPS;
makes utilization of available network capacity more efficient.

How HTTP/2 increases website load speed

Multiplexing allows multiple requests and response messages between the client and server to be in flight at the same time over a single https connection, instead of multiple connections, which improves page load times.
Header compression reduces the overhead bytes downloaded by the client, helping get the content to the viewer sooner. This is especially useful for mobile clients that are already constrained on bandwidth.
Stream priority, allows for quicker page rendering by enabling the client to control the order in which web assets are delivered, thereby optimizing user experience.

How HTTP/2 improves the performance of SSL

HTTP/2 was designed only for HTTPS (does not work with HTTP)
It works optimally with it, speeding up the work of the protocol. The reasons for choosing TLS-only mode are to take care of the user’s privacy, and early research has shown a high level of success with new protocols when using TLS.
Read why you need to go to https and how to do it correctly, read the article “A complete guide on how to migrate from HTTP to HTTPS the right way without traffic loss”.

How HTTP/2 makes network resources utilization more efficient

HTTP/2 enables a more efficient use of network resources and a reduced perception of latency by introducing header field compression and allowing multiple concurrent exchanges on the same connection. It also allows prioritization of requests, letting more important requests complete more quickly, further improving performance.

The technologies that HTTP/2 uses to significantly improve content delivery

HTTP/2 enables full request and response multiplexing, minimize protocol overhead via efficient compression of HTTP header fields. Plus, it supports request prioritization and server push.

Binary framing layer

At the core of all performance enhancements of HTTP/2 is the new binary framing layer, which dictates how the HTTP messages are encapsulated and transferred between the client and server. Therefore, the protocol is more efficient when parsing, more compact in transmission, prone to fewer errors.

Request and response multiplexing

In HTTP/1.x, browsers use multiple connections to the server to load a web page, and the number of such connections is limited. While HTTP/2 uses multiplexing, which allows the browser to use one TCP connection for all requests.
All files are loaded in parallel. Requests and responses are divided into frames with meta-data that associate requests and responses. So they do not overlap each other and do not cause confusion. In this case, the answers are obtained as they are ready, therefore, heavy requests will not block the processing and issuance of more simple objects.

Stream prioritization

Along with multiplexing, traffic prioritization appeared. Queries can be prioritized based on importance and dependency. So when loading a web page, the browser will, first of all, receive important data, CSS code, for example, and all the minor will be processed afterward.

HPACK compression format

The HTTP protocol is designed in such a way that when sending requests, headers that contain additional information are also transmitted. The server, in turn, also attaches headers to the responses. And given that web pages consist of many files, all headers can take up a decent amount. HTTP/2 has header compression, which significantly reduces the amount of supporting information so that the browser can send all requests at once.

Server Push

When using the HTTP/1.x protocol, the browser requests the page, the server sends HTML in response and waits until the browser processes it and requests all the necessary files: JavaScript, CSS, and photos. The new protocol has an interesting feature called Server Push. It allows the server to immediately, without waiting for the response of the web browser, to add the necessary files in its opinion to the cache for quick issuance.

Encryption

The HTTP/2 protocol does not require channel encryption. However, all modern browsers work with HTTP/2 only in conjunction with TLS, like Nginx. So the massive implementation of the protocol should contribute to the dissemination of encryption on the web.
If you are already using TLS, then you should use HTTP/2, which reveals the full potential of encryption. When creating an encrypted connection, only one TLS Handshake occurs, which greatly simplifies the entire process and reduces connection time.

Optimizations no longer needed with HTTP/2

The main optimization of HTTP/2 compared to HTTP/1.x is that multiple modifications and optimizations of the previous versions are no longer needed.
Examples of outdated HTTP/1.x optimizations:

refuse from the domain sharding. This way of distributing multiple files across different domains and CDNs is relevant for HTTP/1.x since it solves the problem of parallel connections. But in the case of the new protocol, this solution degrades performance and negates the prioritization of traffic.
refuse from sprites or modify them. Combining a multitude of small images into one large image can increase the page loading speed, but if the user opens the page with one small image, the whole sprite will be sent to him anyway. In the case of HTTP/2, such a solution would be less useful because of multiplexing.
embed images using DataURI. It can also be useful with HTTP/2, but will definitely be less effective than in the case of the previous version.
refuse to merge (concatenate) files. The method is similar to sprites – all the necessary files, CSS and JavaScript, are combined into one large one for transferring one stream over a single connection. So if a user has accessed the page with one small JS code, the entire merged file will be sent to him anyway. Another complication is that all merged files need to be unloaded from the cache at the same time, and one change in the code of any of them requires updating the entire set. So thanks to the multiplexing, this approach does not make sense with HTTP/2.

Closing

HTTP/2 protocol is more friendly to the network because competes less with other flows, and longer-lived connections, which in turn leads to better utilization of available network capacity and faster load speed.
If you’re not sure your store is using all benefits of HTTP/2 check it with Website Checker that will tell if it’s configured correctly.
In case you haven’t switched to HTTP/2 but would like to do this and increase your store performance, we will be happy to help you, just email us. To give you some extra motivation to move to HTTP/2: the next version (HTTP/3) is being developed already.

All AWS Cloud Hosting clients have HTTP/2 configured by default.

Why & How Upgrading to HTTP/2 Will Boost Your Online Business