I spent the last few weeks investigating HTTP/2, the successor of HTTP1.1 and I’d like to share my findings and thoughts in this article.

Let’s start by saying: if the question you have in mind at this point is “Can I really use it today, not only for experiments but also in production?”
My answer would be: “YES, you can!”

Where is it supported?

First of all, I’d like to show you the browsers implementation status for this protocol:

As you can see from the screenshot taken from caniuse.com it’s definitely well supported on the latest versions of the major browsers – with some caveats obviously.

If you are not convinced yet, check this website with one of the browsers that currently supports HTTP/2. See how fast it loads!

I’d suggest installing the HTTP/2 indicator Chrome extension. Using this, you can discover how many web apps or online services are using this protocol:

HTTP/2 is a binary protocol with a multiplexing requests method implemented. That means all the browser requests will be handled asynchronously.

This massive change will drastically increase the performance of your application. At the moment a browser can download a maximum of 5 resources per domain simultaneously. With HTTP/2, however, we will be able to request all the resources and render them when the browser finishes downloading them. Check this demo made with Go for a proper comparison between the 2 protocols. To understand how the 2 protocols differ, you can also check the Network panel in the Chrome Dev Tools or Firefox Dev Tools.

So what are the pros and cons of HTTP/2?

The Good

HTTP/2 only has a few rules that must be met in order to implement it.

  • It only works with the HTTPS protocol (therefore you need a valid SSL certificate).
  • It’s backward compatible. If a browser or a device where your application is running doesn’t support HTTP2 it will fall back to HTTP1.1.
  • It comes with great performance improvements out-of-the-box.
  • It doesn’t require you to do anything on the client side, only the server side for a basic implementation.
  • A few new interesting features will speed up the load time of your web project in a way that is not even imaginable with HTTP1.1 implementation.

HTTP/2 is bringing a substantial change to the internet ecosystem.

One of my favourite features is the server PUSH. Here, a server can pass a link header that specifies what the browser should download first. It does this before starting to parse the entirety of the HTML document. Using this, we can ensure the browser downloads several resources like images, CSS or even Javascript files before the engine recognise them inside the DOM. This provides a better user experience to our web apps and/or games.

The Bad

There is still plenty of work to do in order for this protocol to be great. A few specs are still on-going (read the next paragraph: the ugly). It will probably take a while before we’ll see a lot of services moving to this new protocol.

Apart from the high level overview of the downsides, let’s look what will change on the technical side.

Considering that HTTP/2 is not restricted on the amount of requests a browser is doing in order to download resources, a few techniques for optimising our websites will need to be reviewed.

Delivering the entire application inside a unique Javascript file won’t have any benefit with HTTP/2. We can move our logic, downloading only what we need, when we need it.

Knowing that downloading large files won’t be a problem we could use sprites instead of several small images to handle the icons of our website.
Tools like Grunt, Gulp or Webpack will probably need to review their strategies or update their plugins in order to provide real value to this new project pipeline.

The Ugly

Google Chrome protocol implementation!

Chrome is my favourite browser and I use it extensively. In particular, I use it when I need to debug a specific script, or I need to gather metrics from a specific behaviour of a web app.

At the moment it’s the only browser that requires HTTP/2 server negotiation via ALPN (Application-Layer Protocol Negotiation). This is basically an extension allowing the application layer to negotiate which protocol will be used within the TLS (Transport Layer Security) connection.

Considering that OpenSSL only integrates ALPN from version 1.0.2, we won’t be able to enable HTTP/2 protocol support for Chrome (from build 51 and above) if we don’t configure our server correctly.

For instance, on Linux OS, only Ubuntu from version 16.04 has that OpenSSL version installed by default. For all the other major Linux version you will need to either install the newer version manually, or you’ll need to wait for the next major OS release.

I’d suggest carefully reading the article that describes this “issue” on ngnix blog before you start to configure your server for Chrome.

Wrap up

HTTP/2 is not perfect and probably not as well supported as it should be. However it could definitely improve your web project performance – drastically in certain cases.

A lot of “big players” are already using HTTP/2 protocols in production (Instagram, Twitter or Facebook for instance) and the results are remarkable.

Why not catch up with the future today?

HTTP/2: the good, the bad and the ugly

| Modern Web| 3,536 views | 0 Comments
About The Author
- Solutions Architect at @dazn_de, Google Developer Expert (#GDE) and London JavaScript Community Manager @london_JS

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>