HTTP/2 vs HTTP/1 – performance comparison?

Rahul Nanwani

This article about HTTP2 vs HTTP1 was originally published on ImageKit’s Medium blog as “Still not using HTTP/2?

The relatively new HTTP/2 protocol speeds up page load significantly and is widely supported by all major browsers and servers. You should be using it right now.

Before moving further, take a look at ImageKit.io’s demo page, to understand the performance boost because of HTTP/2.

Disadvantages of HTTP/1.1

Previously, HTTP/1.1 was the major version of HTTP network protocol used by the World Wide Web, implemented across clients and servers. That worked well for 15 years. But as modern day applications and websites evolved and the amount of data to be loaded on a single page increased, the shortcomings of HTTP/1.1, became more prominent.

One open request per connection

HTTP/1.1 practically allows only one outstanding request per TCP connection (though HTTP pipelining allows more than one outstanding request, it still doesn’t solve the problem completely). The browsers, to circumvent this limit, implement multiple parallel TCP connections to every domain(the number of parallel connections varied per browser). But this head-of-line blocking nature of HTTP/1.1 is a major bottleneck for faster loading applications.

Duplication of data

The other problem with HTTP/1.1 is the duplication of data across requests (cookies and other headers). Too many requests means too much redundant data, which would impact performance.

This led to the development of techniques like image sprites (combining multiple image requests into a single one) and domain-sharding (splitting the requests for resources over multiple domains to increase the number of possible parallel TCP connections).

Advantages of HTTP/2

HTTP/2 was built over Google’s SPDY protocol with the above shortcomings of HTTP/1.1 in mind. The main advantages of HTTP/2 over HTTP/1.1 as pulled from their Github page are –

Multiplexed, instead of ordered

Allows using same TCP connection for multiple parallel requests

Header compression using HPACK

Compressed headers, reduced data redundancy

Server Push

Instead of waiting for the client to request for assets like JS and CSS, the server can “push” the resources it believes would be required by the client. Avoids the round trip.

HTTP/2 in action

While the basic advantages are mentioned above, let’s get a real-world example of the difference between HTTP/1.1 and HTTP/2 performance.

The demo page from ImageKit that was given earlier in this post consists of an image split up into 100 smaller images. The image is loaded over both HTTP/1.1 and HTTP/2 side-by-side to show the difference in the loading performance because of multiplexing and header compression of HTTP/2.

Here is the difference in loading assets over HTTP/1.1 vs HTTP/2

HTTP/2 is the clear winner. Once the first few assets start loading over HTTP/2, the following assets are loaded very quickly. This is not the case with HTTP/1.1, where the image assets keep loading for a longer time one after the other (typical to pipelining in HTTP/1.1) to complete the full image.

Some more proof of the performance difference

Open up the debugger in Chrome and reload the demo page on ImageKit. Sort the images in the “Network” tab by “Waterfall”. Here is what you will see.

Images over HTTP/2 start loading in parallel, at nearly the same time and finish loading in nearly the same time. On the other hand, here is what we get for images loaded over HTTP/1.1

The images are loaded in batches of 6 (parallel connections established by the browser). And hence the entire set of 100 images takes more time to complete loading.

How to check if you are using HTTP/2?

Open Chrome’s developer tools and head over to the Network tab. Right-click on the “Name” or any other heading of the item list and make sure you have selected “Protocol” in the list that opens up.

Now reload the page and check the value of Protocol for the items being loaded on the page. If HTTP/2 is working for a particular request, the value of Protocol will be “h2”. Otherwise, the value will be “http/1.1”. This can be observed in the Network tab screenshots that have been shared above.

What browsers support HTTP/2?

Almost, all the browsers support HTTP/2 — Chrome, Firefox, Opera, Safari (for specific OS versions) and even IE. A complete list of browsers supporting HTTP/2 can be found here.

Note: HTTP/2 is implemented only over TLS. Thus it is all the more important now to move your resources to HTTPS if you haven’t done so already. Note that HTTPS is necessary for the particular resource and not the entire page or website.

How should I move to HTTP/2?

The HTTP working group maintains a comprehensive list of implementations of HTTP/2 on different servers. You can upgrade your server, if one is available, to support HTTP/2. For resources that are being loaded from a CDN or a 3rd-party provider, you would need to get in touch with them to upgrade to HTTP/2 if needed.

Also note that while most of your users would be able to use HTTP/2, a few of them might still be accessing your application from older browsers. Thus the performance optimisations done for HTTP/1.1 would still be important and worth keeping.

ImageKit provides HTTPS-ready CDN that supports HTTP/2 automatically for image delivery without any extra configuration. This ensures that the optimised and transformed images on your website load even faster with ImageKit.

Please share your comments on the impact you saw in your page load performance when you upgraded your application to use HTTP/2 and any other learnings one should take away from your migration experience.

If you liked reading this post, please like and share it.