Whilst never a perfect measure of website speed, as good an indicator as any for how a site might perform is the Google Page Speed Insights tool (https://developers.google.com/speed/pagespeed/insights/). We must say right from the get-go that the results this tool gives are less than perfect – for example, it’s produced by Google, but it penalises the inclusion of Google Analytics; and whilst it gives a good indication of overall site load speed, this does not always correlate to a good user experience…indeed, following the recommendations of the insights tool can often lead to a worse experience if not implemented correctly.
Specifically, what does it not do?
For sure, it’s not the only thing you should be using to quality check your projects, but that’s not to say it should be ignored.
Firstly (and maybe most importantly), if you spend enough per month with Google, you’ll get access to an account manager, and they will suggest to you that a good page speed score will help your organic rankings. Previously conducted research suggests that page speed is just one of over 200 metrics used in google ranking, and accounts – at best – for less than 1.2% of the influence on your results positioning…but it does stand to reason that, all else being equal, the page that loads faster will perform better than the one that doesn’t, so it’s definitely worth paying attention to.
For us, it gives us a general indication that we’ve built something properly – something that focuses on delivering content before functionality, and ensures that the ‘above the fold’ content is presented in a styled format as quickly as possible to the user. Page Speed Insights focuses on image optimisation, the removal of render-blocking assets (those which must be downloaded entirely before the page can be rendered properly) and proper caching, effectively ensuring that your visitors download as little as possible, as quickly as possible, to start seeing your website in its intended state.
The problem here is that such fixes are hard to apply retrospectively, as they require fundamental changes to how your site uses – and loads – scripting and styles. That said, we’ve been able to remedy our own site, with very little noticeable difference and absolutely none to the every day user, some 4 years after it was originally built and launched…so nothing is impossible!
Here’s our top tips for getting a decent page speed score:
OK…so you’ve done the above, but you’ve hit a few problems. Firstly, you’ve inlined your CSS and whilst you’re now no longer getting a warning about your included stylesheet files being render blocking, you are getting warnings about your page not downloading in a single visit. This is because, with all your included inline styles, your page is now bigger than the 4kb a single HTTP request can handle…so it’s doing two (or more) trips to get your entire page, which takes time…which is slowing your page down. Hence, a lower page speed score.
The solution is both simple and potentially impossible – use less CSS. Now that sounds crazy, right…? But it’s probably not. Chances are, your CSS is only so big because you’re using a framework such as Bootstrap, and if so then you’re likely using only a fraction of the CSS selectors that are actually in the CSS files. Using a tool such as unusedcss.com will allow you to analyse your website and remove any selectors that are not used (notice – it’s a paid-for tool and will not be perfect…for example it can only identify the selectors it can see, so ones that only appear on your site under particular circumstances will not be found and thus marked as unused).
By doing this on our own site, we removed over 80% of the CSS that we were loading in every time simply because we’d used a framework stylesheet.
As a point of interest, we now write all of our CSS from scratch, and find not only does it make for incredibly light websites, but also generally takes less time to build, as we get to define exactly what we want our layouts to be, but also provides better cross-device and browser support.
The second problem we can help with is if you’re hitting problems with your scripting now that libraries are loading in asynchronously. The solution is actually very easy, if a little time consuming to work out and implement, depending on how many libraries you use and how they’re implemented on your site.
One thing to consider, however, is how much your site actually relies on scripting. If built properly, you’ll be loading in static versions of your content and layout, and then adding the scripted glitz afterwards…and if you do it properly properly, no one will notice as the scripting will have loaded before they ever come to try and use it.
For those sites that are entirely dependent on scripting, it should be known up-front that this could cause problems, and maybe you’ll find that a preloader screen is in order. Personally I think they’re rubbish, but if you’re building a tool rather than a traditional website, their usage will be more acceptable.
One thing to remember is that it migth just not be possible to implement all or indeed any of the things you need to on an existing website – as mentioned above, it’s much harder to implement retrospectively than when considered at the time of design and build. Hopefully you’ll get lucky, and like us get your site up above 90/100 even if it is old and tired.
Tue 15th Aug 2017
tel: 0161 762 1121