So you have decided to switch to HTTP/2. Or maybe you are just intrigued and want to know how much work that would involve. Either way, you are at the right place.
You’ll be glad to hear that migrating to HTTP/2 is a relatively simple task. Once that you’ve made sure that you have covered all 7 steps from the following checklist, it’s mostly just a matter of flipping the switch.
Alright, let’s get started!
1. Check what browsers do your users use
HTTP/2 has been here with us for over a year now, which gave all major browsers enough time to support it. However, many people out there are still using outdated versions of browsers. Before you jump the gun and decide to switch to HTTP/2, you may want to check whether a significant part of your visitors use supporting versions of browsers and therefore will be able to benefit from the change.
The logic behind this step is quite simple: why bother with HTTP/2 if only few can actually enjoy its benefits?
Open your Google Analytics account and go to the Audience > Technology > Browser & OS report. By default, your primary selected dimension will be set to Browsers. Change the secondary dimension to Users > Browser version. As a result, you will see a table with the number of visitors of your website broken down by browser and version. Here you can check what versions of browsers currently support HTTP/2.
2. Measure your site speed
It’s always a good thing to keep track of your current loading speed. This will be especially useful to compare the performance once your website runs on HTTP/2, but also may be an important factor in making the decision about switching in the first place.
Why? Although in general switching to HTTP/2 is a good idea, in case your website already performs well both on mobile and desktop, it may be a good option (and less work) to stay on your current version of the HTTP protocol for now.
Once again, Google Analytics is the tool to go to. Open your account and view you are interested in and navigate to Behaviour > Site Speed > Overview. Here, you can see not only what’s your site’s average download time, but also what browsers are your content serving the fastest. Google Analytics will show you the culprits if you click on “Page Timings”, i.e. particular pages which have the longest loading times.
For our monitoring purposes, you will want to click the “Full Report” in the lower right corner and then click on “Secondary Dimension” and select “Device Category”. Increase the limit of the shown results to a maximum, and change the primary metric (which is Pageviews by default) to “Average Loading speed”. You can then export this report to whichever format you find most convenient, e.g. xslx.
3. Check the version of your server software
Now, here is the bit where you will need some answers from your techies. To be precise, what version of server is your website using? You will find some neat information about the way your site is hosted on www.netcraft.com, but to be able to tell whether your server is ready to run on HTTP/2, you will also need to know exactly which version of software you are using.
The full list of software supporting HTTP/2 is kept up-to-date on: https://github.com/http2/http2-spec/wiki/Implementations
4. Is your site secure?
This part is easy, but important: if your site is still not secured (i.e. doesn’t start with https), you probably should not be switching to HTTP/2 until your site owns a valid SSL certificate.
The reason is that most browsers will simply ignore the HTTP/2 version of your website if it is not secured.
Is your website optimised for HTTP/1.1?
Here comes the hard work.
If you are building a site from scratch, you are good to skip this step and enable HTTP/2 right away. For the rest of us, here are a few questions to address first:
5. Is your site using image spriting?
Image sprites are a technique designed to help your site’s speed performance on HTTP/1.1. Before HTTP/2 and SPDY, loading each image of a page individually was expensive time-wise, costing precious milliseconds of loading time. To save on time and network resources, one solution was to combine all the images from the page into one “super image”. Once downloaded, the browser would then cut out the relevant picture from the bigger image sprite using CSS.
With SPDY or HTTP/2 this technique is unnecessary, as these protocols are built to carry out many requests in parallel without blocking each other. Downloading one big image instead of many smaller images has no benefits anymore and can actually increase latency. This is because changing one particular image on your website means that the browser will have to download the whole new big image sprite instead of just the small one being changed.
6. Concatenated CSS and JS files
This is likely to be the most complex change to the way your website was coded, so in case you don’t have enough resources to address it, consider it at least to be something to keep in mind for future updates.
7. Domain sharding – switch to smart domain sharding for http1.1 only
Domain sharding is a technique where you try to parallelise downloading as many resources at the same time as possible through splitting your content on multiple domains. With HTTP/2, this tactic becomes redundant and possibly harmful.
The best solution is to implement smart domain sharding. This keeps the benefits of domain sharding for users who visit your website on HTTP/1.1 and ignores it for users on HTTP/2.
Aaand…that’s it! You are now ready to become one of the less than 10% of websites in the world supporting HTTP/2, which basically makes you a pioneer and a proper internet hero for making the Web faster, congrats!
Or in case you need further convincing or consultation on this topic, don’t hesitate and drop us a line here.