Building websites for speed
Tue 15th Aug 2017
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?
- Analyse performance on slower devices or browsers
- Check for accessibility or symantic markup
- Do any real usability testing
- Check that what you’re building actually works on mobile devices
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:
- Inline load your CSS. Doing so will make your speed score jump up, as you remove a major render blocking asset on your site. In the case of PBR, we were loading in 7 different stylesheets (I know, I know – it was a time when it was ‘sensible’ to put different things such as media queries in their own stylesheet), but with a bit of PHP magic we were able to load them all in to a single stringe, minifying them on the fly, and load them all into our header. See below for the potential pitfalls of this approach.
- Optimise your imagery. If you have a static site, then the Page Speed Insights tool will let you download optimised images for the page you just tested, and you can simply upload them over your existing ones (take a backup first!). If you regularly update your site imagery, you might want to consider something like Kracken, which allows you to manually, or automatically via an API, optimise your images.
- Load your JavaScript asynchronously. This is the easiest thing to do, as it’s native browser support to load included script files simultaneously.. but it can also cause you major headaches, as JavaScript-based functionality that previously just worked now breaks, possibly impacting your entire site. The thing that causes this is exactly what you’re trying to stop in the first place – most sites, by default, will assume that libraries such as JQuery have loaded by the time their scripts try to run, because JQuery has been included and will load in its entireity before anything tries to use it. This is render-blocking behaviour, which you stop by loading in JQuery asyncerhronously…but by doing so, your page will hit – and try to run – your scripts before JQuery has loaded, and you’ll be in trouble. See below for how to fix this.
- Enable caching on your content. You might want to wait until your site is basically finished before you do this, because it can cause testing nightmares when you want a client to see a small change to a CSS file you’ve just committed…but you’ll see a massive Page Speed increase simply by allowing proper caching for your site assets. We’ll talk more about this in another post, but you’ll find plenty of examples on Google in the meantime.
- If you can, minify your HTML. This isn’t always easy, and indeed we’ve not bothered with it on any of our sites recently, yet we’ve still managed to get 100/100 on our most recent project…but if you’re struggling for higher scores, it definitely does help.
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.
All you have to do is load them in order of their dependencies. So, anything that relies on JQuery gets wrapped around a native JavaScript function that checks for the presence of JQuery. Then you wrap any dependencies on library 2 around a check for that…and so on, until all of our libraries and functions are loaded.
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.
Good luck!
Need some WordPress help?
We’ve been working with WordPress for a long time, and we know how to make it sing.