The Future of Web: Gotta Go Fast
How HTTP2 can improve web browsing for me, you, and everyone.
Check our Kainos’ newest blog on web technologies, focusing on Web Bluetooth by Witomir Badowski here!
This is a follow up blog to “Where is the web going and how do we get there?” by Adam Grimley
The “future” of web isn’t so much a future, and more of a co-existing present that we neglect like a student procrastinating on their homework. Much like said student, most of us are waiting for someone to come up with an easy solution that we can easily copy and pass off as our own.
Well here in the Applied Innovation team at Kainos, we’re looking into ways of speeding up this transition from older technologies and methods into the “next-generation” of the web. In my research, I’ve noticed that the main purpose of new web technologies is all about speed.
We have grown impatient as a society. People want to spend the least amount of their very little free time waiting, queueing, or watching loading bars. And rightly so, it’s 2017, the web should be better.
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.
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?
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.
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.
___________________________________________________________________
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.
What if I told you that you could take 55% of the time off your daily commute to work just by taking a different road? You’d take the new road, right? Well that’s exactly how much time I was able to take off the gov.uk load time just by flipping the switch on HTTP2.
I managed to take the Gov.uk website from a 3.7 seconds load time to 1.6 seconds in less than 5 minutes. Of course, it wouldn’t be that quick to set up a production level server for a website like this, but you can see already that the benefits would definitely outweigh the costs.
Now these are already great results, but this is only using base HTTP2 without server push. After turning on server push, I managed to shave off another half a second. In the graph below you can see the “Time to Interactive” (which means the time taken for every element of the page to be accessible by the user) for each version of the website. The fourth version is the fully optimised version of the site including Server Push.
Not quite as impressive as the jump from HTTP1 to 2, but still half a second less that a user has to stare at a blank page. I’d say implementing server push isn’t quite a priority, but if you’re migrating your site from a HTTP1 server to a HTTP2 server, you may as well do it while you’re working on it.
This sounded a bit too good to be true to me, so I decided that I needed to do it again, make sure that it wasn’t just a fluke. So I a found a website that was more intensive on the browser than the gov.uk homepage, a website that takes a whopping 9.7 seconds to fully load on 3G network speeds, the National Crime Agency homepage. So I ran my tests again, optimised the site as best I could, and again, the results proved that HTTP2 is worth the hype.
This time, the load time on my local copy went from 8.7 seconds to 6.8 seconds. Again, that’s a 1.9 second decrease in load time. With further optimisations, including implementing server push, another second comes off, bringing the total load time to 5.9 seconds. Much better than what we started with, but to take any more time off, the website would require a major rework.
In conclusion, HTTP2 is something we should all be embracing, not just sitting around waiting for it to slowly become the norm. Most of the decrease in load time seen in my tests came from flipping the switch on HTTP2. On top of that, it’s important that I stress good web development practice. A lot of the optimisations I made to these websites were simple image changes, inlining some styles, and loading images and stylesheets “lazily”.
It may not necessarily be the fanciest of changes or something that revolutionises the user’s experience, but performance is just as importance as interface, accessibility, or any other factor you might consider when designing any new website and HTTP2 seems to me to be the thing you can implement today that will give the biggest jump in performance, and in turn, increasing revenue.
