Originally HTTP/2 started out from the SPDY protocol, and is now standardized as HTTP version 2. Already around 70% of users on the internet use browsers that support it and major web servers either already have support for it or are in the process of developing one. That said it seems like a very good time to educate ourselves and start making tests on how we can improve user performance by providing faster page loads.

What HTTP/2 is NOT:

• replacement for HTTP/1.x
• Silver bullet – some superior technology that just transfers bytes faster

What HTTP/2 is:

• Another transport layer for HTTP/1.x with pros and cons
• Basically the same protocol as SPDY with the same benefits

Switching to HTTP/2 or SPDY

Before we decide to implement HTTP/2, we need to identify how much of our code base is optimized for HTTP/1.x. There are four types of optimizations that are most commonly used in practice:

1. Domain sharding. Putting files on different domains to increase parallelism in file transfer. Content domain networks (CDNs) are a good example for that. But it doesn’t help – and can hurt – performance under HTTP/2. You can use HTTP/2-savvy domain sharding to shard only for HTTP/1.x users until the protocol becomes more widely used.

   

2. Image sprites. Image sprites are agglomerations of images that download in a single file; separate code then retrieves images as they’re needed. The advantages of images sprites are less under HTTP/2, though you may still find them useful.

   

3. Concatenating code files. I have done this on many websites (most recently on sofortkredit.org) and most caching plugins provide this functionality ‘out of the box’. Similar to image sprites, code chunks that would normally be maintained and transferred as separate files are combined into one. The browser then finds and runs the needed code within the concatenated file as needed. This reduces the number of files being transferred as HTTP/1.x has a limit of 6 at a time.

   

4. Inlining files. I bet you have seen the Optimize CSS Delivery warning when running a website trough PageSpeed Insights. However such optimizations (CSS code, JavaScript code, and even images are inserted directly into the HTML file) will be less and less relevant with HTTP/2. This optimization essentially means fewer file transfers, at the expense of a bloated HTML file for initial downloading – but with HTTP/2’s MultiPlexing this becomes almost irrelevant.

   

Every project has specific server setup and use and needs to be considered separately

For further study I recommend you read this overview by litespeed and this extensive article from NGINX to get to know HTTP/2 better and make the decision for yourselves as there are several factors you need to consider. If you need help with this decision let me know at anton@ruzhekov.com.

Here you can find a test whether your browser supports HTTP/2 and what the speed difference with HTTP/1.x is.

If you are interested to see which browsers already support HTTP/2 – 70% of users (as of 12.2015), mainly because of IE, surprise surprise. You can see an up-to-date graphic on caniuse.com.

Interesting talk from NGINX core engineer Valentin Bartenev

Want to know more about how to make HTTP/2 comparison tests or you are unsure if it is the right technology to enable on your project – ask me in the comment section below!