To start with, we’re going to explain some things to watch out for when following the typical suggestions, and debunk some common myths.
Bundling code is one of the top recommendations in many page speed articles. But while this was the case for many years, it’s a tip that isn’t as relevant as it used to be.
The thinking behind code bundling was that if your website has to deliver more files, it means longer loading times. That’s because, before 2015, we only had HTTP/1.1, which could only make one request to your website at a time.
But now we have HTTP/2, which supports something called “multiplexing.” This basically means your browser and server can request multiple files at the same time. And every modern web browser supports HTTP/2. So that this mean you shouldn’t bundle your files?
Let’s say you bundle some scripts into a 1MB file, 200KB for the FAQ page, 200KB for the contact page, 200KB for refund forms etc. Each new user will need to download this 1MB file to use your website, and they’ll need to download it again every time you make changes in that bundle.
Worse, the user could be downloading code that they’re not even using.
You can see from the above screenshot from the Chrome performance tools that over 70% of the code included in this bundle was never used. So this page has unnecessarily increased the TTI.
The solution? Code-splitting.
Code-splitting means that, instead of providing 600KB of irrelevant code, the browser only downloads what it needs. The browser has a lot less work to do, and the page loads faster.
Additionally, if you make changes to the homepage code, the browser only needs to refresh that code; it doesn’t need to refresh the code for other pages on the site as well.
If you want to know more about code-splitting, Google has a whole area dedicated to performance, which contains a whole section about code-splitting. So, before bundling up all your code, make sure there isn’t a better solution for you!
Server caching can be a great way of decreasing your server’s Time To First Byte (TTFB), which is basically a way of describing how quickly your server can provide the user with the initial code of the webpage. That explains why caching is a popular topic in page speed articles. But it’s not always appropriate to every website.
Full page caching takes a snapshot of the code of the page and serves this up to all your users, so your server doesn’t have to process the same product page every time a user visits it.
Unfortunately, server caching can sometimes be slower than processing the page each time. When you cache something on your server, your server converts the code into a new format that can be stored. This is called “serialisation”, and when the data is used again it must be “deserialized”. And with large/complex amounts of data, this process can become slow.
So it’s worth investigating how much data your website needs to load for each visitor before caching everything. Test which is best for your server setup.
Sometimes, there might be a single component that can be holding up the TTFB. These are called “expensive operations” or "bottlenecks", and these can be anything that runs slowly or causes a surge in resource requirements. They’re often caused by slow database queries or working with large amounts of data.
For instance, your website might display a widget which displays your top 10 popular products. You stock 5,000 products and process 100,000 orders a day.
Calculating how many times each product has been sold and taking the top 10 from that list will use a lot of computing power, especially when you have a lot of people using your website.
One solution to this particular problem would be to schedule the task of identifying your top 10 products once a day, when your site isn’t being used much, and caching the result somewhere that your website could use the next day. This would eliminate the expensive operation and reduce the load on the server.
There are plenty of tools to help identify expensive operations, such as New Relic, Clockwork, and Blackfire. For instance, the image below shows how New Relic integration with WordPress can identify plugins which are causing issues.
Each platform is different, and so there’ll be steps specific to that platform that can have an effect on your page speed. For instance, we use PHP on our website, so we adopted two specific optimisations to speed up our website:
PHP Versions - PHP 7 has vastly improved performance over PHP 5. And it’s possible that your website might already be completely compatible with PHP 7.
Opcache - Each time someone visits your website, the server loads up all the code, converts it into a format it can understand, then starts executing the code. Opcache is a PHP extension which loads your website code just once, and stores it until you tell it to refresh its memory. On large or busy websites this can dramatically help the initial TTFB!
This might seem obvious, but if you’re paying £25 a month for your web hosting, you’ll be getting a server that can provide £25 a month worth of traffic. If you’re paying for £250 a month, you’re going to be getting a lot more.
Web hosting is like insurance: you might find a company with a really low premium, but their product might be full of caveats and not quite what you wanted. You get what you paid for.
For example, here is a comparison of different hosting providers. The shorter the bar, the better.
- GoDaddy - Dark blue (£8/m shared hosting)
- DigitalOcean - Light blue (£15/m cloud hosting)
You can see the difference a few pounds can make, so it’s always worth spending the time looking into a hosting solution that suits you. If you need any recommendations, you can speak to us! We’ve plenty of experience with different hosting companies, so we might be able to offer some advice.
The further away your customers are from your server, the longer a page will take to load for them.
You can see here that the load time can fluctuate a lot depending on where you are in the world.
We often speak to our clients about the benefits of Cloudflare. Amongst offering enhanced security, firewall, free SSLs etc., Cloudflare also offer an unrivalled Content Delivery Network (CDN).
A CDN is a network of servers that allow web browsers to download a website from a nearby server rather than one in an entirely different country. CDNs have the potential to make a big difference to how quickly your website loads for visitors around the world. Cloudflare has some of the fastest connections available, which means they can download any webpage from any country, in a fraction of the time your computer can.
Server optimisations are perhaps the most powerful ways to increase your TTI, but there’s even more you can do! In the third and final part of this series, we’ll take a look at on-page optimisations and caching you can use to make your websites load even faster.