We mentioned caching in our article about server optimisations, but this time we’ll be looking at browser caching.
Caching is a useful tool for reducing your Time To Interactive (TTI), but while many page speed articles paint it as a simple fix, poor implementation of browser caching could actually slow down your website.
Implementing a browser cache tells a user’s Internet browser to save files it finds on your website so that, when the user returns to your site, the browser doesn’t have to ask your server to load up all those files again; it already has them saved on the user’s computer.
This dramatically increases your TTI because there’s less of your page to load from the server, but there is a downside; if you make changes to your website and don’t clear the cache, users won’t see the changes you’ve made because their browser will load the old version of the page it has saved.
So is browser caching bad?
Cache busting makes sure that your users won’t see old versions of your website. It works by adding a query string to the name of any file you change, which prompts the browser to ask for the new version rather than loading the old one.
For instance, if this was the path for your original file:
You could add a query string like this:
If you use a dynamic language such as PHP, you can handle these query strings using the modified time of the file, like this:
https://mywebsite.com/images/logo.jpg?v=<?php echo mtime(‘images/logo.jpg’); ?>
One other thing to note is that browser caching won’t affect the initial page speed; the benefit is only seen when the user comes back to the page again. That means that browser caching won’t affect the load time reported by speed testing tools, although they might recognise that you’ve enabled caching when making their recommendations.
Speaking of speed testing tools, don’t worry about warnings about the length of caching headers for things like Google Analytics. These aren’t hosted by you, so you have no control over their headers.
So what’s the solution? Code splitting.
Preloading is basically a way of telling the browser “this resource is high priority and should be processed asap".
Twitter and Tinder have boasted that they decreased their TTI by approx 35% by simply implementing preloading, so it’s definitely worth looking at. You can view a full detailed explanation about it in the Google Performance Guides, but a brief example of how to do this is below.
Simply define the paths to the resources you need to preload as follows:
<link rel="preload" as="script" href="navigation.js">
<link rel="preload" as="style" href="critical.css">
If you’re using cache busting techniques, don’t forget that browsers see exact URLs, so you’ll need to include any query strings.
Don’t start preloading everything or nothing will get any faster. And make sure you’re testing to make sure the resources you’re preloading are being used within the first 3 seconds; if you do not do this, Chrome will throw a warning at you and can potentially ignore your preloading directives if it thinks you’re abusing them.
You might have seen other page speed articles encouraging you to inline your critical or above-the-fold CSS. But this is difficult to do efficiently, and probably falls out of your budget.
The benefit of embedding the critical CSS within the '<head>' of the page is that the user doesn’t need to wait for another HTTP request to fetch the CSS before they can see the content they want.
But the biggest problem you might face is that your site will have different above-the-fold content on each page, which means the critical CSS for each page will be different too. And WordPress, Drupal, Magento, etc. just don’t offer the necessary functionality out of the box, so embedding all this CSS would need a lot of bespoke work.
Unfortunately, this means that some websites go in the opposite direction and embedding their entire stylesheets into the head of the page. But this is a terribly cheap way to increase your page score at the detriment of the overall performance, potentially doubling the size of your pages!
There is an alternative: rather than embedding your entire stylesheet to account for every page on your site, you could embed critical CSS just on your high impact pages. This could deliver the speed benefits to the pages that are used most without slowing down your entire site.
We’ve reached the end of our series. Although we’ve tried to offer as much advice as possible, your website isn’t the same as every other site on the Internet; you’ll be facing your own unique page speed challenges. So, if you would like any support or recommendations for your website, please get in touch with one of our team!