No one ever wants a slow website, but as the web has progressed, site speed has become an ever-increasing concern for website owners; certainly in no small part to Google’s continued messaging that site performance can and does impact your search engine listings.
A glance at our support desk confirms this on an almost daily basis, clients routinely ask what they can do to increase their scores. More often than not the scores they’re referring to are the numbers provided by the Google PageSpeed Insights tool. Go ahead and pop your domain name in there now – how does your site perform?
While there are a number of site speed testing tools out there, it’s understandable why website owners turn Google’s; after all, it’s more than likely that the data generated here is what Google’ search engine brain understands about your website speed.
With all that in mind, over a series of posts I’m going to go over the PageSpeed tool, looking at the information it provides, understanding what it all means, and crucially how you can get your site to score better.
Let’s test a site
First of all, go ahead and test your site if you haven’t done so already. Pop your domain name in the field at the top of the page and press analyze. Your report should come back pretty quickly, typically no more than thirty seconds. We recommend you run the test a few times, three at least.
You’ll note that the report comes back a little differently each time. The Internet is a fluid and fascinating thing – network lag, processing hiccups, goblins in the gears – whatever the reason we think looking at the average is better than a one-off micro-slice in time.
You should now have a baseline score for your website, from zero through to one hundred. Think of 100 as Usain Bolt, and 0 as lying on your back and giving up at the notion of a brisk workout. 100 is fast, 0 is slow.
Mobile vs desktop speeds
The first thing you’ll want to take note of is that the PageSpeed tool returns two numbers, and it’s easy to mistake the data. PageSpeed tests your site on a simulated mobile/cellphone connection and also a simulated desktop machine. As standard the data provided and shown to you is the mobile score. If you glance at the top left of the page you can see which you’re currently looking at, and also switching seamlessly between the two.
It’s worth noting that your mobile score is always likely to be less than your desktop score. In testing your site for mobile, Google uses a simulated connection of what they think the real world looks like. At the time of writing that’s using a “mid-tier device (Moto G4)” on a connection speed of 1.6mbps.
Google employs throttling to test how your site would work on such a device and mobile connection. They write, “These exact figures are used as Lighthouse’s throttling default and represent roughly the bottom 25% of 4G connections and top 25% of 3G connections (In Lighthouse it is sometimes called “Slow 4G” used to be labelled as “Fast 3G”). This preset is identical to the WebPageTest’s “Mobile 3G – Fast” and, due to a lower latency, slightly faster for some pages than the WebPageTest “4G” preset.”
If you hit the tab for desktop you should see a much faster score. It’s important to understand the two scores. Clients often get in touch with us about a “slow” score and don’t understand that the first score they’re given is that of a mid-range mobile device on (what I personally think) is a slow mobile connection these days.
With your numbers in hand, scroll down the screen. Next up, Google breaks down how they’ve generated that score for you. There are six core points that make up your speed scoring. They’re a little hard to understand, so here’s what each of them means
First contentful paint – FCP represents the time take to show something to the user in their browser. This could be anything, a text or a simple image, anything is fine. FCP represents the user receiving some form of positive feedback that the site they’ve accessed is there and working. A fast FCP is important in engaging the person trying to use your site. If something doesn’t at least appear to be loading, they’ll likely leave.
Speed index – Once things start to load in the browser, exactly how fast do they start to load? Google generates a visual image of the various elements of your site loading (a block of text here, an image there) and then calculates how fast the progression of loading is.
Largest contentful paint – Google tries to estimate when the majority of your website’s content has loaded and is visible to the user. Google’s current recommendation is that your LCP should be achieved within 2.5 seconds.
Time to interactive – TTI is a measurement of when can the user start using your site. When can they click links, use menu navigation and so forth. Exactly how long does it take for your site to be fully interactive?
Total blocking time – This one is a little more complex to understand. Google define it as, “TBT measures the total amount of time that a page is blocked from responding to user input, such as mouse clicks, screen taps, or keyboard presses”. In essence, as your page loads, a number of moments occur that prevent the user from using your site. How long is that period in total?
Cumulative layout shift – Google’s own description of this one makes complete sense, “Have you ever been reading an article online when something suddenly changes on the page? Without warning, the text moves, and you’ve lost your place. Or even worse: you’re about to tap a link or a button, but in the instant before your finger lands—BOOM—the link moves, and you end up clicking something else”.
CLS measures any of these jarring loading experiences for your site. If the page loads only to suddenly be re-arranged or shifted, it will be noted here.
Taken together, these six components make up your overall site speed score. For those parts of your sites Google deems ok you will see the score in green. If Google thinks you have an issue with one of these components it will show in red. This can help track down parts of your site that might be dragging things down.
Again though, test a few times to be sure. It’s very common to see your site score one way, only for the issue to be fixed again a few minutes later. This can be down to the hosting server or Google’s test tool itself. Always look at the average, never a one off test.
Opportunities to improve website speed
You should now have a baseline score for how fast your website currently runs on both mobile and desktop devices.
You should also have started studying the next section in the PageSpeed output – opportunities. In this post, I will go through each of the most common items the report is likely to show you, and what we can do to work on those.
Reduce initial server response time
The reason for these performance posts usually isn’t your web hosting account – if you’re hosted with us anyway! Speed issues almost always stem from the way the site is constructed. That said, there are times we can lend a direct hand and this error message is one of them.
The server response time reflects how quickly your web hosting account is responding to user requests. This can be affected by your site’s code, but if you’re seeing this message there might be some potential for us to help.
Again, just like I wrote about in my first post, test your account several times and take the average. This is one of the data points that can appear then vanish then next test around. If you’re seeing this consistently we might be able to assist.
Eliminate render-blocking resources
Remember your FCP score? This message relates directly to that. If you’re seeing this, Google has detected one or more resources on your site that are causing it to slow down in the very early stages.
Google will show you a list of resources that are contributing to this problem with a time in milliseconds of how much delay each is adding. If you use plugins on your site, you’ll probably recognize a few names here – do you really need them?
Ensure text remains visible during webfont load
You might see this if your site uses special fonts. While your website font files are downloading to the user’s browser, any text using those fonts can be hidden by the browser. This can lead to an ugly flash of invisible text effect when the font finally loads in.
You can display text immediately by setting the
font-display CSS property to
swap. This will cause the text to be displayed in a system font until the custom font is ready to be swapped in.
Reduce the impact of third-party code
If you see this alert you will also be able to click to open a section that shows a breakdown of third party code running on your site. “Third party” essentially means code pulled from other places that runs on your site. Ad software and analytics software feature prominently here.
This one can be tricky to resolve beyond either removing the third party code or looking to replace it; this is often not possible for many websites.
Serve static assets with an efficient cache policy
This warning refers to how assets are cached. For a really deep dive into the world of caching, see here. We set the cache TTL to 30 days on our WordPress platform. Lighthouse recommends it be set to 365 days, hence the error.
Minifying code makes it far smaller to send to the client at the expense of readability. White space within code, which makes the layout readable for humans, is removed. Variable names are shortened; your browser doesn’t care whether a variable is called
veryUsefulVariable, and sending just
x is quicker.
There are a number of plugins that will do this for you, and one of the most popular and simplest to use is Autoptimize. Simply install this plugin, activate it, go into the Settings, Autoptimize and turn on the options.
Enable text compression
Avoid enormous network payloads
You’ll likely find this warning while reviewing the mobile tab, only to see it disappear on the desktop test. I just ran this test on one of my own sites and received a warning of:
Avoid enormous network payloads -Total size was 3,599 KiB
This essentially means, “hey, please try to not send mobile users huge amounts of data.” In the case of my own site, the home page clocks in at 3.6MB which Google considers fairly hefty for mobile access. Me personally? The site in question is image-driven and I know my users are happy with the experience I offer, so I choose not to change this too much.
This point is worth keeping in mind – these are suggestions by Google, not deal breakers in and of themselves. You need to think about each suggestion logically. Not only can you change your setup, but also should you? Again in my case, I know that Google is tracking how users interact with my site and that it offers a valuable resource, it just happens to require big images by its nature.
Avoid multiple page redirects
If you’re seeing this error your then site is misconfigured in some fashion. Definitely reach out to our support team – this is absolutely one we can advise on as your WordPress host.
Minimize main-thread work
Improving WordPress performance with images
You might see a range of opportunity notes for the images on your site. For example:
- Properly size images
- Efficiently encode images
- Serve static assets with an efficient cache policy
- Serve images in next-gen formats
- Defer offscreen images
But before we deal with those, lets start from the ground up…
It’s best to start on the right foot, which means addressing image performance right from day one, as you upload them. If you’re able to, we always recommend optimising your images before you upload them to your web hosting account. You can make real speed improvements here, not least save storage on your account.
I love the ImageOptim tool for this. This is a desktop tool that lets you drag and drop your images into one by one, or in big batches. You set the level of optimisation/compression you’re comfortable with and it does the rest.
There are also tools you can install on the server side of things, if you’d rather things happen auto-magically with minimal effort; Imsanity is one such plugin that works really well, I wrote about that in a previous article here.
CDNs, compression and caching
The three Cs! Let’s take a look at each one in turn.
Using the services of a Content Delivery Network (CDN) on your website can make material improvements in your site loading speed.
First up, what exactly is a CDN? Well, it’s usually a global network of servers that work with your hosting server to fan your content out across the world. When you publish new images, they’re fed into the CDN and pushed to various points around the world. When a user in Australia accesses your site, the images will load from the local CDN server, not your hosting server – the result of which is usually a faster experience.
Many hosts offer a CDN as standard, we do not, by design. There are many options out there from free (like WordPress’ own Photon network, or the very popular CloudFlare) to paid, each offering slightly different solutions for users. We think it’s better to leave our WordPress platform open ended in this respect and let you choose what CDN you want to use, if of course it makes sense for your website.
If you do need pointing in the right direction, we recommend using the KeyCDN service, which is reasonably priced and simple to get going on your WordPress Hosting account with us. Here’s a brief tutorial that shows how to get KeyCDN working on your WordPress hosting:
How to fix PageSpeed Insight image opportunities
Back to my last post, you’ve probably got some questions about several image-related warnings and recommendations. Here are the most common, what they mean, and what you can do.
Properly size images
This can be a tricky one to address. The error essentially means your website is sending images to the client that are incorrectly sized. For example, they’re sending a huge image when the client is using a mobile device.
Typically your designer or developer can fix this for you. If you’re using WordPress a new theme might be in order (remember to regenerate your images once you change themes).
Advanced tip: this one isn’t for the feint of heart, but one additional WordPress fix is to inspect the source code of your rendered site and see what image sizes are being sent to the browser. From there you can then change the media thumbnail sizes in the WordPress settings to match, regenerating your images based off of that. This should mean that your site serves properly sized images.
Efficiently encode images
When scanning your page, Google collects all the JPEG or BMP images on the page, sets each image’s compression level to 85, and then compares the original version with the compressed version.
If the potential savings are 4KiB or greater, Google flags the image as optimizable; if you’re seeing this you need to re-save your JPEGs with a compression level of 85 or better.
Serve static assets with an efficient cache policy
On this one, we slightly disagree with Google’s policy, and you might too. As standard we use a 30 day cache TTL for the WordPress platform. This means that when your hosting account sends data such as images to a web browser, it also says it’s ok to cache and keep using those for 30 days.
This particular error though will appear for anything less than a cache policy of 365 days. We think that’s a tad extreme. This means if your website sends an image file to the user, it wouldn’t matter what you update on your site, they might load the locally cached version for a full year!
Defer offscreen images
This warning means you aren’t correctly using the ‘lazy load’ facility on your site. ‘Lazy loading’ is the act of holding off on sending images to a users browser if the image is not currently on the screen. Images are sent out to the browser as the user scrolls down the page, rather than all at once.
These days ‘lazy loading’ is a standard part of WordPress so modern sites should already be utilizing this feature. That said, if you do see this error, it is possible that you have an older site and your images have not been updated retroactively.
Drop us an email so we can look at this for you; images with certain pre-existing attributes might not have auto updated to lazy loading, or your theme might be over writing this entirely.
Serve images in next-gen formats
It’s likely you use JPG or PNG (or even GIF!) image files on your website. If you’re seeing this particular warning, one file format you’re not using is WebP. This format was developed in-house at Google.
We love WebP, it’s a huge step forward in reducing image size. There is of course one huge drawback: WebP is not supported by older versions of the Safari web browser in particular. That means users of older Apple devices might not see an image served in this format.
But wait, all is not lost! Many websites use some nifty code to serve images in a variety of formats, sending WebP images to capable devices where possible. If you use WordPress on your website there are plugins that you can drop in that take care of this automatically with no further effort on your part.
If you use our WordPress Hosting plan, things are a little more complex. most plugins that offer WebP support rely on the Apache webserver, where we instead use Nginx for the very best performance. We’ve developed our own internal tooling to take care of this for you. If you’re looking to squeeze every last ounce of performance out of your website, drop us an email, we can enable the auto serving of WebP images on demand for your site.
WordPress themes – the real culprit of slow sites
The fact of the matter is that themes often contribute the most to your website’s overall performance. No amount of fine tuning the back end hosting, leveraging caching and optimizing images will ever overturn the poor loading of a bloated WordPress theme.
Many themes focus on design and aesthetics first, performance is a secondary issue; naturally, theme designers want to wow you with the look and feel of their work first and foremost. All those fancy fonts, features and effects come at a performance cost.
And that might be fine for your site. It’s at this point we caution our clients that a perfect Google speed scoring isn’t the be all and end all. It really depends on your site, your industry, your users and your competition. Remember that the speed of your site is only one factor among many in Google’s ranking algorithm. For your own site, a slightly less than perfect speed score might be just fine, if the user experience works well. For others, only the fastest possible site might do.
With all that in mind then you might ask: what’s the fastest theme out there? It’s a tricky question, as we can’t easily access a huge number of paid premium themes. What we can do though, is audit the most popular free WordPress themes and stack them up in terms of how they perform.
For the purposes of our test, we took a simple WordPress test site, one with a variety of posts, pages and images. From there we created a local installation of the Google PageSpeed testing setup and started to test the most popular themes in the WordPress repository. We created a tool to cycle through and install the top 250 themes, before running the speed testing tool three times, taking the average of the trio of tests.
And after that, we have a huge list of data…
What are the fastest free WordPress themes?
Testing your own site
If you use our WordPress hosting platform you can begin measuring your site’s current theme against this list above right away. Each account comes with a staging area that lets you spin up a copy of your site in a few short minutes. You can then test away on your staging site to your heart’s content.
In 2021 we also hope to open up our own site testing tool to users in general – performing the same ‘top 250’ test against your own site.
Next up in our series on performance – and something that will be huge in 2021 – Core Web Vitals: what they mean and what you need to do to prepare.
Hi, my name is Stuart and I’m the business development director at 34SP.com. If you want to pick my brains, suggest an edit, or talk more in depth about website performance issues feel free to drop me a line at firstname.lastname@example.org.
Looking for more in depth guides? Here are some more we offer: