If you did everything you could, yet your website still seems slow — you may have hit one of the boundaries of HTTP. HTTP stands for HyperText Transfer Protocol — with hypertext being a text formatting system that is used for writing the webpages.
But the thing is, internet had evolved much since the 1999 — last time the HTTP was revised. We now rely much more on graphic information instead of plain text, transfer audios and videos on the regular basis. Even hypertext itself changed, with HTML (HyperText Markup Language) becoming a powerful tool that allows to create complex applications, instead of simple webpages. Yet HTTP is still stuck in the 90s and inefficient for the modern internet. So inefficient, that a lot of time web-designers and optimizers have to work against HTTP, instead of with it.
Issues with HTTP 1.1
There are many parts of HTTP protocol that had required an update for a long time, but the main issue with HTTP 1.1 is overhead. Simply put, the data gets sent in packages, with browser having to specifically request each bit from the server. And that’s bad, because it greatly increases the amount of packages that has to be sent and processed by both client and server, which takes a lot of time. And time is money — here literally, because studies have shown that people prefer to use the websites that load as fast as possible.
The road to HTTP 2.0
There have been attempts to solve the issues and push past HTTP 1.1 since the early 00s, but those solutions have never gained enough support. That is, until in 2009 two Google engineers have presented a new version of the protocol called SPDY. It did not attempt to replace HTTP — even Google doesn’t have enough weight to do it alone — but instead it worked around the existing standard to alleviate some problems.
For example, it:
- Implemented multiple concurrent requests on the single connection.
- Allowed browsers to prioritize assets
- Compressed and reduced redundant parts of HTTP
- Implemented server push, which allowed to reduce browser-to-server connections to the minimum.
Simply put, SPDY was great for what it tried to be. And it definitely caught on — pretty much every modern browser supports SPDY. But this was still a hacky arrangement and not a proper upgrade. That’s why not a lot of major websites switched to it, especially ones that work with sensitive information.
But with the success of SPDY, the talks of updating the HTTP protocol had started again, this time — with Google at the helm. Not everyone was happy, there was a lot of criticism — mostly because of the mandatory TLS encryption — but at the end of the day SPDY became the base for the new HTTP 2.0, also known as HTTP/2.
How do I implement HTTP/2
Simple answer? You don’t. Your hosting company does it and then offers you to transfer. But what you can do instead, is make sure you are ready to take advantage of everything HTTP/2 offers.
HTTP/2 is backwards compatible with HTTP 1.1, so even if your users do not have browsers that support the new standard, they will still enjoy some of the advantages it brings.
Get yourself an SSL-certificate
Seriously, this is #1 thing you should do. Even if you do not plan to move to HTTP/2, having an SSL certificate (and thus, making sure your users connect through the HTTPS) is mandatory these days. In less than a month Google is planning to start marking all HTTPS-less websites as unsafe in Chrome and other Chromium-based browsers. This is ~70% of the Internet users who are going to see a bright red screen instead of your website.
Having an SSL/TLS certificate is mandatory for all HTTP/2 server-to-browser connections. You can theoretically use server-to-server HTTP/2 connections without the encryption, but the usecase for this is limited.
Check your sprites
Sprites used to be all the rage in HTTP 1.1 days — gathering a ton of small images in the single spritesheet allowed to drastically reduce the amount of requests, although it did require more processing power and some really clever coding. Well, no more.
With the ability of HTTP/2 to send multiple files over the single TCP connections, you can use as many small images as you want without having to worry about queuing them. Of course, using spritesheets might still offer some benefits — primarily, in terms of the image size — but they are no longer required.
Move the images out of the CSS
When working with HTTP 1.1, the best solution used to be to inline the most common images of your website into the CSS, using the URIs. Basically, having a much larger stylesheet was still preferable to having a crap ton of HTTP-requests.
Well, thanks to multiplexing and other wonderful new abilities of HTTP/2, this is no longer the case. HTTP-requests are now cheap, and the practice of using inline images in the CSS is a hindrance, instead of a lifehack.
Deconcatenate CSS and JavaScript
One of the most extreme optimization techniques requires you to have a single CSS and JavaScript for the whole website. Once again, because HTTP-requests are evil and it is much more preferable to push a 10-15 Mb of data on your user at once than have them request each and every asset specifically.
Well, once again — HTTP-requests are cheap in HTTP/2. So sending all this code and CSS only to the pages where it belongs will speed up your website even more! It will also solve some issues with caching (i.e. allow you to purge the cache on the per case basis),
Remove domain sharding
To reduce the server’s workload, some web-optimizers prefer to push resources of the website to the different domains. For example, website johnsmithrox.com will have an image shard i.johnsmithrox.com and maybe even an audio shard a.johnsmithrox.com, in order to real with the HTTP-requests for the media and thus alleviate the load on the main host.
Guess what? Yep, HTTP-requests are cheap nowadays. So into the trash domain sharding goes, especially since it can create a lot of slowdowns on its own. Alternatively, you can enable smart domain sharding, that implements sharding only for your HTTP 1.1 users. But considering the rate at which the HTTP/2 gets adopted, this sounds like unneeded work.
TL;DR
HTTP/2 is great, and although you will have to wait until it is enabled at your hosting company, you can prepare for it. To do this:
- Get an SSL/TLS certificate
- Check whether you still need spritesheets
- Move the media out of CSS
- Organize CSS and JavaScript instead of lumping it together
- Remove domain sharding or implement the smart sharding technique
After that is done — you can switch whenever you want. But if you want to check Use Google Analytics in order to see what browsers your clients are using and whether or not they keep up with the updates.
As of now, latest versions of Chrome, Opera, and other Chromium-based browsers support HTTP/2, as well as the latest versions of Mozilla Firefox and Microsoft’s Edge/Internet Explorer. We are still waiting for Apple Safari (both MacOS and iOS) and the default Android browser.