We’ve been focusing on improving the page speed scoring of the sites we produce for a while now (see here – why is Google’s page speed important? – for why we think it’s an important metric). From experience, a typical site – launched without much in the way of consideration towards page speed – will score somewhere between 60 and 70 for mobile and desktop, and it will only really be possible to get it above the baseline 85 – where Google makes things ‘green’ and rates your efforts as ‘good’ with a bit of luck and the ability to take a hatchet to your site’s source code.

It is possible to get 100/100, however…even when using a CMS such as WordPress – at the time of writing, our own site – a WordPress-hosted, responsive website – scores 100/100 for both mobile and desktop. We’ve several other client sites that also either score 100/100, or are in the high nineties (we find Google Page Speed Insights very susceptible to factors we don’t always control, such as hosting speed and server-level caching), and all of these sites are built using WordPress, too.

For clarity, there is no guaranteed way to get a high – or perfect – insights score, but by following the rules below, which we do for every project we undertake, you’ll find you end up with a high score without any retrospective effort at all.

Firstly, lets look at the key things that we seek to eliminate when building for speed:

1. Inline all CSS. This can take some work, especially if you’re using a framework such a Bootstrap, because there are hard limits on how much CSS you can put into your HTML source before it makes the file too big to be downloaded in a single visit. You’ll also have to think about how you do this within your development workflow. See our post on how we inline our CSS – How to dynamically inline your css.
2. Optimise your images. For static sites, you can do this manually, indeed you can even download optimised images right from the Google Page Speed Insights report. For more dynamic sites, you’ll want to look at integrating a third party service such as Kracken than can do this for you.
3. Remove your ‘render blocking’ assets. These are external files which slow your page load by needing to be loaded before the page completes, such as external style sheets (a problem removed if you inline your CSS as above) and JS libraries such as JQuery. For script files, you can load them asynchronously, though this will come with its own headaches as your site tries to use functionality before the necessary scripts have loaded in.
4. Cache ALL OF THE THINGS. Yes, it can make it harder for your client to see changes, but it will also make your site faster and Google’s Insights report love you just a little bit more. We do this via simple .htaccess rules, but this is dependent on both access to that file, and some (fairly standard) server config to allow caching in Apache.
5. Minify where you can. It’s relatively straight forward to minify your JS and CSS, but if you might find the insights report also asking you to do the same for your HTML. It’s not something we come across often, but when you’re scrambling around for that last point or two, it will give you the boost you need, especially if your HTML source is lengthy.
6. Minimise as much as possible. Do you really need to animate that? Are you doing something ‘the lazy way’ in JQuery when native JavaScript, or even clever CSS, would do the same? When it came to optimising our old website, simply removing a few animations and re-writing our menu removed absolutely zero engagement or functionality, but gained us 20 precious points as we were able to completely remove the JQuery library from our site as a render-blocking resource.

Those are the key things to look out for. The next thing to consider is when you do all of this planning and thinking, because we typically see it done as a ‘post live’ activity – the site’s now finished, the content is in, how can we make it as fast as possible?

If you’re leaving it that late, then it’s likely too late. breezing to a score of 100 requires that you plan ahead, starting from the very earliest stages of your site’s development. For example:

1. You might use bootstrap and JQuery because they’re quicker to develop in, but you’ll also find them harder to optimise for speed. Could an extra few days of development to code from scratch make all the difference? (answer – yes, absolutely…and it’s beneficial not just for page speed!)
2. Having page elements that bob in and out of the page on initial load look modern and great and stuff, but they also require up-front loading of a load of scripting and styling. Do you really need them, or are they just for the sake of glitz and sparkle or, even worse, to design around the problem of poor content and user journey planning?
3. How can you break up your site into logical chunks and progressive feature loading that means you deliver a seamless experience to your users quickly, and add the rest behind the scenes…all without them noticing or caring?

The later you start to think about these kind of things, the harder it is to implement what’s required to actually implement them – such questions and answers impact everything right from your initial design concepts. Importantly, this is not about simplifying or restricting design – you can have the most graphical, animated and scripted site in the world and still score 100 – this is about thinking about how all of your site assets and functionality can be delivered to your visitors in the most optimal way.

So on your next project, before you commit a single crayon to paper, sit back and think about what causes your page insights scores to go down, and how you might change the process of what you’re about to do to work around those challenges.

Back to the blog listing