Google’s PageSpeed Insights tool is a quick and easy way of checking site performance on desktop and mobile. It provides you with suggestions on what to improve and this can help you to figure out if there are any quick wins to be had. It can also help to troubleshoot performance and give clues as to where you may have a problem. It gives sites a performance score between 0-100 with 0-50 considered ‘slow’, 50-90 considered ‘average’ and a score of above 90 considered ‘fast’.
How I got this WordPress site to a mobile & desktop score of 100
I decided recently to start blogging again with a new focus on sharing web development tips, tricks & experiences. As part of that change, I decided to update everything mainly because I didn’t want to be talking about web development and not practicing what I was preaching. The shoemaker’s children go barefoot and all that…
One of the top things on my to-do list was to make sure this blog achieved a PageSpeed score of 100 on both mobile and desktop partially because I just wanted a fast site and partially to demonstrate that I know how to optimise sites for performance and can just point lazily to this site as proof.
I’ll try to give a summary of the changes I’ve made and what it takes to get that coveted green circle with three digits inside…
I started by ditching the old theme which was no longer maintained by the author and wasn’t very ‘Gutenberg’ friendly (Gutenberg is the new WordPress Editor, introduced in version 5.0). I had thought about hacking the old theme apart myself and just keeping what I need but ain’t nobody got time for that… when I’m blogging I just want to post content and not have to worry about updating things and compatibility with plugins. I prefer to stick with a tried and tested theme from a reputable author. Speed / performance out of the box is very important too. The old one was fine from that perspective but it was just awkward to work with due to the new WordPress editor so I ended up going with the GeneratePress theme.
I then opted for web safe fonts instead of any sort of custom font or Google fonts mainly to adhere to the “Don’t use crap you don’t need” policy. Custom fonts can be nice and may be important for brands but I’m not a brand and I don’t need custom fonts on my personal blog. By using web safe fonts, you’re instantly saving one network request / file download / extra unnecessary bit of code and it’s that mentality (if applied to everything) which will get you well on your way towards a score of 100. In real world projects, you’ll have a much tougher battle on your hands with designers and marketing people trying to convince them that the company font should be dropped in favour of defaults. It may be a losing battle, but these are the sort of conversations that need to happen to get people thinking about performance and how pretty things may look interesting or appealing but if they result in a 10% slower load time do you still want them? Do you *need* them?
Can’t live with plugins, can’t live without them. Many people will tell you that plugins are the cause of all your performance issues and that’s because it’s true most of the time. When you install a plugin you don’t really know or care about what’s happening behind the scenes – you just care about the feature and the end result the plugin will give you. Some plugins will run scans in the background or save lots of junk to your database which may serve some purpose for the plugin to operate but may also (and probably more likely) be complete overkill for whatever it is you’re trying to achieve.
Worse still, over time plugins will evolve, WordPress will evolve and as you deactivate and delete plugins there may still be crap left over that’s just sitting in your database permanently. As a rule of thumb, the fewer plugins you install and activate, the faster and more efficient your site will be.
I currently have 10 plugins activated on this blog and even that would be considered excessive by some people. Most of the plugins I use though are performance & security related. The only plugin that falls under the “I possibly don’t need that” category is “Code Syntax Block” which makes code look prettier / readable in posts.
# Pretty Code See, this code looks pretty. If I didn't use the Code Syntax Block plugin it would look ugly.
I don’t *need* it, but when pasting code it just looks much better if it’s formatted properly. I could manually import scripts and styling to do this myself but using a ready made plugin made more sense and saved a lot of time. So that’s how I justify keeping it. Rolling my own solution is something I’ll add to my list of rainy day projects that will realistically never be complete.
You can have the most optimised WordPress site on the planet using no plugins and a bare bones theme but if it’s hosted on a crappy server somewhere along with hundreds or thousands of other sites for $1/month, you can’t expect top notch performance. I don’t necessarily agree with the “you get what you pay for” mentality when it comes to hosting but if you’re on the cheapest shared hosting package you can find and there are various options available to upgrade to higher spec’d plans, including a ‘recommended’ plan, that’s a clue that you’re probably skimping on something you really shouldn’t be skimping on. It’s like paying for a 1mb broadband connection and then wondering why you can’t stream a live sporting event in HD.
If you’re after a PageSpeed score of 100, the server must have decent response times and you also need to be aware that the database can often be on a separate server to the site files. So you could have fast response times from one but not the other or vice versa. This is also where caching can help to minimise database requests and move as much as possible to static files, which are much quicker to download and therefore better from a performance perspective.
This blog runs on a VPS from Digital Ocean. The server isn’t particularly well optimised or doing anything fancy, it’s just reliable and reasonably well spec’d. It costs $15/month to run (I run several sites on it, not just this blog) so that’s why I say you don’t always get what you pay for – because many hosts will happily charge you $15/month and stuff you on to an overloaded shared server with far greater restrictions. You do need some technical knowledge to set up and manage a VPS but it’s perhaps less intimidating than you imagine, especially with Digital Ocean tutorials.
Server caching, browser caching, database caching… cache the whole damn lot. If you’re confident your site is well optimised and your server isn’t the bottleneck holding back your PageSpeed score, caching may just be the magic wand that transforms an average PageSpeed score in to a near-perfect one.
I use Cloudflare on this site for a few reasons. One of them is the fact they make enabling https easy, even on shared hosts… another is security benefits and the third is caching. They have a bunch of settings that you can toggle on and off to enable various types of caching. If you don’t know much about it, my advice would be to turn everything on and then check to see if your site is broken. If it is broken, start turning things off until it’s no longer broken.
Cloudflare by itself isn’t enough though. It’s better than nothing, but you ideally also want to install a WordPress caching plugin so that you reduce the strain on your server and its memory usage associated with database requests. I use WP Fastest Cache on this blog along with Autoptimize. Combined with Cloudflare, there’s nothing you’ll see on this site that isn’t cached and that’s a large reason why the site has PageSpeed score of 100 on both mobile and desktop.
With caching in place you just basically download a single html file that’s readily available. It’s why different pages and posts should seem quite fast to load. Because blog posts rarely change over time, they’re a perfect example of something that should be cached. Most caching plugins will also have an option to refresh the cached version of a post if / when it has been updated so there is never a danger of forgetting to update cached content.
GTmetrix and Pingdom
As useful a tool as PageSpeed is, it’s still only a test from a single source. Some people think it’s weighted more heavily towards server speed and TTFB (time to first byte or time until the browser receives it’s first byte from the server). However, if your site is consistently getting high scores and A+ ratings across GTmetrix, Pingdom and PageSpeed then you probably haven’t just fluked a fast site, you’ve more than likely earned it.
Right now, this site has an annoying 99% YSlow score. It’s annoying because of that last 1%. I know why it’s not 100% and it’s because of a CloudFlare related cookie strategy which I can’t control. I could get a 100% score but the effort involved wouldn’t be worth it and I’d be doing it purely to achieve the perfect score – there’d no actual difference in performance. Another rainy day project for me perhaps…
On Pingdom, this site scores a 92. Again, I know why this is the case and it’s because Pingdom only recognise Gzip as a compression method. They don’t recognise Brotli (developed by Google) which is superior in the eyes of many so as a result any site using Brotli instead of Gzip gets cheated out of a fair score. Pingdom for example gives this site an ‘F’ rating in compression.
Despite that great injustice, I’d still recommend using Pingdom in the hope you may find some recommendations to improve performance. You can never have enough suggestions. You just need to be aware that because you get an ‘F’ rating in something, doesn’t necessarily mean you’ve done something wrong. Sometimes the marking system is wrong and if you confirm it and figure out why it’s wrong, then at least you can sleep soundly at night.