This post is a high level summarization of the research done for a production web application to leverage the benefits of HTTP/2.

1. Quick history
2. What problems does HTTP/2 solve?
3. When to switch?
4. How to switch?
5. What to do to get the benefits of HTTP/2?
6. Checklist

Quick history:

HTTP/1.1 - the underlying communication protocol of the web has been here since 1997 and is commonly used.

Once we crossed the millennium, web applications were expected to do more fancier stuff than ever and we needed more images and javascript at the client side to do that.

HTTP/1.1 couldn't perform a very good job as time passed by, as -

1. it is still capable of retrieving only one resource per request
2. in a modern browser, the max number of connections that could be made to a domain over HTTP/1.1 protocol is 6. In older browsers it's two.

So what did people do? they tried to send as much as assets possible with every response that goes back. And to work around the domain number limitation, developers used domain sharding.

Then Google engineers started to ponder on this problem and SPDY protocol was developed. Later, long story short, SPDY features are adapted to HTTP/2 and HTTP/2 is here - modern and more efficient - fitting the needs of today.

What problems does HTTP/2 solve?

1. HTTP/2 has multiplexing capability. Once a TCP connection is made to the server, all further requests pass through the same connection. Basically, requests are cheap.

2. HTTP/2 comes with compressed and reduced headers. Reduced overhead. More lighter and faster request/responses.

3. Support for assets prioritization. Servers used to send back only what the browsers requested and in the order that the browsers requested. But now things are moving to an arena where servers could be programmed to know better and it could send back resources in a way, that the browser can start doing its job asap.

4. Server push - As the name suggests, if you configure you server as needed, server will push necessary files that will be required by the browser without waiting for the browser to request them explicitly.
   Example - If you request index.html, server could push styles.css and allScripts.js without waiting for the browser to request them additionally.

When to switch?

Switching to HTTP/2 is a decision to made after analysing the browser version data of your user base. The HTTP/1.1 to HTTP/2 protocol conversion happens automatically and its backward compatible. So there is nothing pretty much to be done to switch it other than ensuring your server supports it.

Still, a developer should know something in this regard -

Two scenarios :

a) Simple protocol switching and no optimisations made in the web app.

Say your server is upgraded to HTTP/2. Web app is untouched. An user named A, uses the app from a latest version chrome. Since both client and server supports HTTP/2, the protocol is automatically switched to HTTP/2. The user A gets a slightly better experience because of the requests being faster once a connection to server is made.

Now an user B, using a browser that doesn't support HTTP/2, say, Opera Mini, uses the site. Since the browser doesn't support HTTP/2 protocol, the connections to the server stays HTTP/1.1. He doesn't get any performance gain but the usual user experience that the site has been giving is delivered.

As of writing this, the browser support statistics is as below

b) Protocol switch with optimization made to the web app

Tricky business. Optimizations to the web app mainly involves -

a) removing any optimisations that were in place for HTTP/1.1
b) building newer optimisations for HTTP/2.2

Let's familiarize what optimizations where usually done for HTTP/1.1

1. Embedding smaller images into a sprite and sending it
2. Embedding data uris in css files
3. Concatenating mode css and js than what the page needs in to the returning html file.
4. anything a developer did to improve payload management

So, obviously, the removal would be to

1. removing sprites. Retrieving only what the current page needs.
2. removing data uris and retrieving images as needed
3. Modularizing app into multiple smaller bundles which sends only what is needed by the current page. Downloading more smaller files is cheaper and efficient now.

Now let's check how this affects the users A and B

User A -> HTTP/2 browser + HTTP/2 server = faster loading, nicer experience. Say when it took 4 seconds to make the page interactive before, now it improved to be 2.5 seconds.

User B -> HTTP/1.1 browser + HTTP/2 server -> falls back to HTTP/1.1 protocol = slower experience than before. Reason - Lost all optimizations for HTTP/1.1. If it was 4 seconds for him before, now it could be more than 5.

So, basically, such app optimization has to be done when you are sure, your users are not hurt. So analysing user browser version is a good idea here.

And, optimizations for HTTP/2 would be to

1. Create individual assets
2. Organize the app and therefore the build process and bundles so that there are more smaller bundle downloads and server push can be tried out.
3. If your site loads a lot of images, enabling HTTP/2 to the serving server is a good idea.

Common server support for HTTP/2

AWS ALB - Yes (though no server push support as of now)
Nginx - Yes
Cloudflare - Yes

So, how do I turn on the HTTP/2 protocol?

Prerequisite: Launch site with a secure connection

It's a two person game. The protocol gets automatically switched if the browser the app is running on and the server you are connecting to supports HTTP/2.

So, most browsers has done its part and you might need to check and upgrade your server.

Head over to one of your favourite site > dev tools > network tab > right click and enable the protocol tab and see which protocol version is being used. I picked a sample from facebook and they use HTTP/2.

How to reap more benefits?

Sever push seems very promising. If you web app can be split into logical pieces of html, css and js, you could make your server to push anticipated files for a webpage even when the browser doesn't ask for it.
But there is a catch. This idea seems simple, but if you are using a complex web framework like next, it would be tricky and sometimes not a good idea to override the optimizations that the framework and split files as you like. I am yet to try it out and will update once I have some results. Simpler apps which has a server with server push support could try it easily.

Support of server push

AWS ALB - No
Nginx - Yes
Cloudflare - Yes

Assets Prioritization also seems promising but it seems it would be hard for a web developer to tweak the trivias on deciding how much bites of which asset is being send back to the browser first. It seems it would be great to use a service that works solely for that and Cloudflare seems to be a very good option.

Checklist before switching

1. Launch site with a secure connection
2. Ensure your hosting supports HTTP/2
3. Check your user browser version statistics
4. Prepare for HTTP/2 in development/build process
5. Roll out HTTP/2 optimization