If you’ve read through my first post on PageSpeed, you should now have a baseline score for how fast your website currently runs. If you haven’t, go and complete that stage first here. With your score in hand, you should now have a basic understanding of how fast Google perceives your site to be 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 from my last post? 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
Image related warnings
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
There are a lot of potential pitfalls with images on your site, so much so that images are the whole topic of my next post. Stay tuned!