If you took the time to read the blog that this is a follow up to by Adam Grimley, then you’ll know of some of the technologies we think are the most promising. I took the technology that I think is most likely to improve user experience on a daily basis (even though there will be no actual difference to what the user sees), and explored it further, performed some experiments, and found some interesting results.

HTTP2

When was the last time you waited longer than a few seconds for a webpage to load before mashing the refresh button or cursing it for being a terrible site and swearing you’ll never use it again for as long as you live (I’m looking at you imgur). This isn’t just a user side problem either, companies legitimately notice a sharp decline in revenue when their site takes even a second longer than normal to load.

According to Google, mobile sites are 53% likely to be abandoned if they take longer than 3 seconds to load.

When you take into account that 56% of website traffic comes from mobile devices and that’s a statistic that isn’t gonna slow down any time soon, it becomes glaringly obvious that we need to keep up with the times, and have websites that load faster than my attention span (which admittedly, isn’t great).

HTTP2, for those who aren’t familiar with it, is a rewrite of HTTP1.1, which is what we most commonly use to send documents (e.g. images, stylesheets) through browsers. Its main features include:

The use of binary to transfer data, not text

The use of header compression to reduce overhead

Multiplexed to allow parallelism

Allows servers to proactively push to clients

Um, what?

You might have just read that list and thought, “I have no idea what that means”. That’s fine, so did I at first. I’m going to take some time to go into depth about what each of them actually mean and why they’re worth having in the first place. Take note of the last two, as they are the heavy hitters in how HTTP2 improves speed and why it is so beneficial to everyone.

If you don’t really care about the theory, you can click here to skip to my experience and results using HTTP2.

Binary transfer of data

Sending data via binary instead of just text might sound like a bit of a disadvantage. After all, it’s not like we can read it. However, binary makes it much easier to process, in turn speeding up your browsing experience. On top of that, binary makes things much more secure, it makes it much harder for someone to intercept your data.

Header Compression

If you take an average website, it has around 100 assets (images, stylesheets, scripts) to send to you. For each of these assets, a request is sent and the header contains all the information about the request itself. Add all of these headers up and the end up being a considerable size. Compressing them to as small as possible speeds up page load times considerably.

Multiplexed

This one sounds the most complicated, but honestly it’s probably the easiest to understand and also the one that provides the biggest improvement in load times. To best understand it you can imagine the page you’re trying to visit as a pool, when its full the web page is loaded. You fill the pool with a hose, the water being all the assets you need. Now imagine a HTTP2 enabled site as a separate pool, being filled with several hoses. Which one do you think will fill the quickest?

The difference is easy to see.

Basically, HTTP1 only allows for a few assets to be sent at a time, whereas HTTP2 allows many more to be sent at once, which cuts down on time waiting for the server to send 100 files 2 at a time.

Server Push

Imagine you wanted to build a shed for whatever reason and no idea where to start. You might purchase an instructional manual called “How to build a Shed” (It’s a working title). You would make your way through this book, taking note of what materials you might need, then you would go and get said materials. This is how surfing the web on HTTP1 works. You visit a web page, get the “manual” on what you’ll need to view the page correctly, then go and get them from the server.

This is how a typical HTTP1 enabled site works.

Now imagine instead of an instructional book, you bought a “Build your own shed” kit, complete with materials. This is how HTTP2 works. You open the manual, same as before, but this time, you have the materials, eliminating the need to go to the shop. It’s the same principal for websites. When you get the “manual” (desired web page), the server sends you the “materials” (stylesheets, scripts) at the same time, removing the need for back and forth trips from server to client.

This is how a typical HTTP2 with server push enabled site works.

___________________________________________________________________

My Experience

All these facts and statistics I’ve just thrown at you are all well and good, but how does it hold up in practice? Well I decided to take a website, convert it from HTTP1 to HTTP2 and then perform further optimisations to see just how many seconds of load time I could shave off.

So what website did I choose? Well I had to make sure I picked one that wasn’t currently making use of HTTP2 so I could properly show off its features. I ended up going with “gov.uk”. I ran some speed tests, then downloaded the site and began to make optimisations.