This is Part 2 of the guide to Google PageSpeed Insights, and perhaps the more interesting part for many of you. In the previous part of the guide, we covered the lab data that Google PageSpeed Insights displays.
In this part, you will learn how to actually improve those scores and lab metrics that PSI shows you. We will go over whether and how to fix the recommendations that PageSpeed displays. In general, we will explain these recommendations in simple terms and clarify how to interpret them, especially for non-technical WordPress site owners.
Update: In October 2025, Google released Lighthouse 13, which consolidated and renamed some of the audits in the report. The scores and metrics have not changed, but you may notice different names for some of the recommendations. This guide is still relevant because the underlying principles are the same.
Opportunities for Improvement – Google PageSpeed Insights
Before we look at these opportunities for improvement, you should understand that they do not directly affect the score you receive. However, addressing and fixing these recommendations will improve the lab metrics we discussed in Part 1 of the guide, and those are what affect your score.
Remember! The ultimate goal is not to improve the score itself, but to improve the user experience that comes from faster site loading and displaying the main content to the visitor as quickly as possible.
Let’s get straight to it. I will try to cover each recommendation. Throughout this guide, I may use the term PSI, which is short for PageSpeed Insights, for convenience 🙂
1. Avoid Multiple Page Redirects
You will see this recommendation if the URL you entered in PSI performs at least two redirects. Make sure you always test the correct version of your URL. If it is an HTTPS address, test that version. If your site uses www, test the URL with www, not without it.
In practice, it is important that the incorrect version of the URL redirects to the correct, primary address. If a user enters the wrong URL in the address bar for whatever reason, they should be redirected to the correct one.
However, since redirects take time, you should make sure that as many links on your site as possible use the primary URL so there are no unnecessary delays.
For example, if I test the Savvy Blog URL with the HTTP protocol and WWW, I will get this recommendation. That is because two redirects occur in this scenario – from HTTP to HTTPS and from WWW to the non-WWW address.
Can and should you fix this?
Of course. If your domain does not perform a special redirect to another domain, the fix is very easy – simply test the page with the correct URL.
You may find additional relevant information in the post about how to migrate a WordPress site to HTTPS.
2. Reduce Server Response Time
This recommendation can indicate several things, but essentially it means your server is responding slowly. This metric is also known as TTFB – Time to First Byte.
The faster your server responds, the sooner the page becomes available to the visitor. Many parameters affect server response time. For WordPress sites specifically, the main causes are:
- No caching is in place, or it is configured incorrectly.
- A low-quality hosting provider (check out the hosting I recommend – I promise you will see better results).
- Plugins that cause issues and slow down server response time.
- A bloated database.
- And more…
If you are using a cache plugin and still see this recommendation, try running PSI again in case the first test hit a page that was not yet cached. If you do not have server-level caching (check with your hosting provider), you should definitely install a cache plugin such as WP-Rocket or Total Cache.
Can and should you fix this?
Yes. A slow server response can be the primary source of long load times and usually indicates deeper issues.
Read the extended post about the impact of TTFB on website speed and the ways to improve this metric.
3. Properly Size Images
This recommendation indicates that the images on the page received from the server are larger than the size at which they are actually displayed on your site. For example, if a product image in your store is displayed at 400×400 but the actual image size is 700×700, the browser has to do extra work to resize it. On top of that, your site weighs more due to unnecessary data.
This situation can occur if you upload images that are too large to the media library, or if your theme (or a specific plugin) has not defined image sizes tailored for the different locations where images appear.
Can and should you fix this?
Absolutely. Make sure you upload images at exactly the right size to the media library, and make sure your theme uses the correct image sizes.
For more information and how to define new image sizes in your theme, check out the post on image sizes in WordPress.
4. Efficiently Encode Images
You will see this recommendation if the images on the page weigh too much. Heavy images are one of the main reasons for slow pages.
This recommendation is very important, except in cases where it flags only a few bytes. Pay attention to the number indicating how many bytes you can save. This is especially true if you have already optimized your images and still see this recommendation.
Pay attention to the number of bytes you can save and act accordingly. There is a high chance you will see this recommendation if you have not properly optimized your site’s images.
Note that PSI will flag all images on the page, even those coming from an external script. For example, if you display images directly from Instagram using a plugin, those images will likely appear in the list of images that need attention.
In that case, you cannot optimize them because you have no control over them – only Instagram does. So you either remove that plugin from your site, reduce the number of displayed images, or accept that they will negatively impact your site’s performance and you will always get recommendations about them in PageSpeed Insights.
So can you address this?
Yes. Whether you optimize images using a plugin or manually, this is an easy win and fairly simple to implement.
5. Serve Images in Next-Gen Formats
The most common image formats on websites are JPG and PNG. However, Google introduced a new format called WebP that is more efficient and delivers lighter images, which means faster load times.
Should you convert your images to WebP?
If the savings are significant, you should definitely do it, especially if your site is image-heavy. Several plugins can help you with this, such as Imagify or LiteSpeed Cache.
It is worth noting that today all modern browsers support the WebP format, so there is no longer a compatibility issue. Beyond WebP, there is also the AVIF format, which provides even better compression at high quality. AVIF is also supported today by all major browsers (Chrome, Firefox, Safari, Edge).
If you are not sure how to convert images to WebP or AVIF, plugins such as Imagify, ShortPixel, or LiteSpeed Cache can handle the conversion automatically. Just make sure your images are optimized and served at the correct size – that will have the biggest impact…
6. Defer Off-Screen Images
This recommendation tells you to use LazyLoad for loading images. LazyLoad, or “lazy loading”, is a technique where images are loaded only when the user scrolls the page and needs to see them.
It should be obvious that if the user does not intend to scroll down and see those images, loading them would be a waste of resources.
Can you fix this?
Yes, and it is highly recommended. This will help improve the initial content rendering on the page because fewer images are loaded upfront.
It is important to note that starting from WordPress 5.5, the system automatically adds the loading="lazy" attribute to images in post content. This means that if you are using a recent version of WordPress, you likely already have basic Lazy Loading without needing an additional plugin.
However, plugins like LiteSpeed Cache and WP-Rocket provide more advanced Lazy Loading capabilities, including Lazy Loading for videos and iframes. That said, Lazy Loading does not always work properly with certain themes and plugins, and in some cases it can cause unwanted delays in image loading.
7. Enable Text Compression
Compression, whether through gzip or brotli, is a way to reduce file sizes as they travel from the server to the browser.
Can you fix this recommendation?
If the files are served from your server, you should absolutely fix this. Smaller files mean faster load times. File compression is a critical feature, and most cache plugins will automatically add the relevant rules to your htaccess file to enable compression.
Most servers support this option. If yours does not, switch to a different hosting provider, and fast.
Note that you cannot control third-party files that are not served from your server, but in most cases those will arrive compressed as well. If not, it is worth reconsidering whether you need those files at all.
8. Minify Resources – HTML, JS, CSS
Minification is the process of reducing file size by removing whitespace and comments from HTML, CSS, and JavaScript files using various techniques. This reduces file weight and theoretically makes downloading these files faster.
In practice, the data savings from minification are often negligible and unlikely to have a noticeable impact on your site’s load time. Check the potential savings for these files after minification. If the savings are not significant, do not worry about it.
As with minification, you cannot control third-party files that are not hosted on your server.
How to address this recommendation?
The solution is simple, and many plugins can handle minification for you, especially cache plugins. So why not do it? Just be aware that in some cases, minification can break functionality on your site.
9. Preconnect to Required Origins
One of the issues with third-party assets is that every domain the browser needs to reach requires an additional DNS connection, and that connection takes time (albeit small). To address this, you can use dns-prefetch or preconnect, which I wrote about in detail, to have the browser initiate a connection to that domain earlier, so it does not get delayed when the asset is actually needed.
How to address this?
You can solve this relatively easily using the cache plugins I mentioned in the previous section, or through code. It is important to note that this is a band-aid of sorts – the real solution is to use as few third-party assets as possible.
Here is an example of using preconnect for early loading of Google Fonts:
<link href='https://fonts.gstatic.com' rel='preconnect' crossorigin>
<link href="https://fonts.googleapis.com/css?family=Assistant:300,400,700,800" rel="stylesheet">Coffee break 🙂 Now you should know that the next three recommendations I will present are aimed at combating the negative effects of overly complex page construction.
10. Eliminate Render-Blocking Resources
The process of displaying a web page in the browser is called “rendering.” For your site to feel fast to visitors, this needs to happen as quickly as possible so the content appears on screen without delay.
CSS and JavaScript files slow down the rendering process because when the browser encounters requests for these files, it stops working, processes the requested file, and only then continues. That pause blocks the rendering and is called Render Blocking.
To avoid this situation, you can load these files in a non-blocking way using techniques called “defer” and “async.” We will not go into detail about these in this post. If you want to learn more, check out the post on deferring JavaScript, and perhaps even before that, the post on creating Critical CSS and fixing render-blocking resources.
Should you fix this recommendation?
Definitely. If you do not want to do it manually, most cache plugins will handle it for you. They allow you to apply defer and async to render-blocking files and even generate the Critical CSS for the above-the-fold portion of the page.
Make sure to test your site after applying these techniques, as they can break functionality on your site.
11. Remove Unused CSS
Almost every WordPress site owner will see this recommendation. It is one of the more complex recommendations to fix and requires working with code and understanding CSS.
In short, the appearance and layout of elements on screen are controlled by CSS. Your theme will typically load at least one CSS file, and almost every plugin that is not related to the WordPress admin dashboard will load a CSS file as well.
Themes and plugins on WordPress sites try to cater to as many users as possible, since everyone uses different display options and settings. As a result, a lot of CSS data gets loaded even though it is not necessarily needed.
Should you fix this?
To begin with, the chance of fully fixing this recommendation and making it disappear is close to zero, and even that is only possible if you develop the theme yourself and control every file that gets loaded. Beyond that, the impact of unused CSS on site performance is not that significant, so I would suggest you address other recommendations and leave this one aside.
If you insist on trying, one way to check which CSS is unused on a specific page is through Chrome Developer Tools under the Coverage tab. Additionally, plugins like WP-Rocket now offer a feature called “Remove Unused CSS” that automatically removes unused CSS on each page. LiteSpeed Cache also offers a similar feature called “Unique CSS (UCSS).”
Diagnostics
Whether you noticed or not, the report that PageSpeed Insights provides is divided into two sections. Opportunities, which we covered so far, and Diagnostics, which we will discuss now.
12. Ensure Text Remains Visible During Webfont Load
This recommendation is relevant to the fonts loaded on your site. You are likely using a web font, whether you load it through Google Fonts, TypeKit, or via @font-face.
Since it takes time for these fonts to load, there is a period during which no text is displayed on screen for the visitor. This creates the feeling that the site is loading slower.
There are several ways to address this recommendation. The main one is to display a basic system font during that time – one that does not require loading since it already exists on the visitor’s device. This ensures the visitor sees text on screen as quickly as possible, and the font swaps to the web font once it loads.
Fixing this issue is done using the font-display property, which I discussed in the post about the font-display property.
Should you fix this?
That is up to you, since there is a user experience impact when fonts swap after text is already visible. In general, if you insist on removing this recommendation, use font-display: fallback for every font you load.
The next two diagnostics, called “Minimize Main-Thread Work” and “Reduce JavaScript Execution Time,” are related to the impact that JavaScript has on a specific page.
You need to know a bit about JavaScript to understand the next two recommendations I will present. But before we discuss those, let’s say a few words about the negative impact of JavaScript.
Appendix – The Negative Impact of JavaScript on Site Performance
Unlike HTML and CSS, which are the building blocks of a web page, JavaScript in most cases is not an essential component. JS is typically used to add interactive elements such as sliders, carousels, animations, video players, and so on.
If a lot of JavaScript is loaded on a specific page, it will slow that page down in most cases because:
- The browser has to download the JavaScript file.
- Parse the JavaScript (so the browser can read it).
- Execute the JavaScript in the browser.
Depending on the code itself and its purpose, the third step I mentioned will require significant time (in terms of site loading). Beyond that, the negative impact of JS grows exponentially on mobile devices because they have less processing power.
If you are not the one who wrote the JavaScript code, the only way to deal with its negative impact is to remove that code entirely.
Now that I have gotten that off my chest, let’s continue with the diagnostics that PageSpeed shows us…
13. Minimize Main-Thread Work
You will not find a better explanation of this recommendation than the one written by Addy Osmani (formerly Head of Developer Experience for Chrome at Google): JavaScript Start-up Optimization.
In a few words (that we may have already mentioned a few paragraphs ago), JavaScript has a high cost and it affects your site’s performance. You need to understand that the more JS is loaded, the longer it takes the browser to parse and execute it, and therefore the longer it takes before visitors can interact with your site.
Can you fix this?
Yes, by removing as much JavaScript as possible from your site. That means removing plugins and disabling interactive features in your theme or the Page Builder you are using.
14. Reduce JavaScript Execution Time
This recommendation indicates that JavaScript execution on your site takes a long time (relatively). You may see this recommendation in the mobile report but not in the desktop report, because the processing power of computers and laptops is much greater than that of mobile devices.
Should you address this?
Yes. You should remove as much non-essential JavaScript from your site as possible, similar to what I mentioned in the previous section. Check whether there are JavaScript files that are not needed and find a way to remove them. Unfortunately, explaining how to do this is beyond the scope of this guide…
Removing and disabling the loading of JavaScript files is an excellent way to improve the “Time to Interactive” metric we discussed in Part 1 of this guide.
15. Serve Static Assets With an Efficient Cache Policy
Browser caching significantly improves performance for visitors who visit your site more than once. This cache allows files to be stored in the browser’s memory, leading to better performance on return visits.
Most servers support this option by default, but you can definitely fine-tune these settings. For example, to store files longer in the cache, to define which files are cached, and so on.
Should you fix this recommendation?
If the files flagged are served from your domain, you should fix this. Like the text compression we mentioned earlier, an efficient cache policy is a fundamental technique in site optimization, and most cache plugins will handle it for you.
As with other recommendations in this guide, you can only apply this technique to files served from your server, not to third-party files served from an external domain.
If you want to do this yourself without a plugin, check out the post on how to improve WordPress loading time. It is the most viewed post on this blog, and you will find many settings and optimizations there that are not necessarily mentioned in this post – ones that PageSpeed Insights does not flag.
16. Avoid Enormous Network Payloads
This recommendation mainly refers to the overall size of the page. Page size is determined by all the individual files (assets) your site uses – images, CSS files, JS files, fonts, and so on.
Should you address this recommendation?
PageSpeed will show this recommendation if the total page size exceeds the recommended threshold (about 5MB). That said, try to aim for as low a size as possible – 1.5MB or less is a realistic target for most sites. This will have a significant impact on load speed, especially on mobile.
17. Avoid Excessive DOM Size
This recommendation is definitely aimed at developers. The DOM (Document Object Model) is the structure of a page created from the code that renders it.
In simple terms, every element you add to a page is another node. The more elements on the page, the more complex the DOM becomes, and the longer it takes the browser to download the page and build that DOM.
Using premium themes and plugins, and especially Page Builders, increases the number of DOM nodes, adds complexity, and contributes to a larger, more complex page.
Should you address this?
If you have the option, try to avoid building overly complex pages, and in general, avoid using Page Builders. This recommendation is an indicator of the overall complexity of the page. If you remove elements and simplify the page, it will affect this metric.
However, if you have done everything you can and still see this recommendation in PSI, you will not be able to fix it without a developer’s help. And even a developer’s intervention will not help if you are using a Page Builder.
Here is a post I wrote that goes into more detail about the Avoid Excessive DOM Size recommendation – check it out!
18. Use Video Formats for Animated Content
This post by Jeremy Wagner covers this topic in detail. GIF files, especially large ones, are not efficient for displaying animations on your site. Consider whether they are truly necessary, and if not, display video or static images instead.
Should you address this?
If you want to improve your site’s load time, using GIF animations is not the right approach. If possible, get a professional developer to convert them to CSS, SVG, or even video if needed.
These are much more efficient methods, performance-wise, for displaying animations on your site. There are also free online services that allow you to convert GIF to video quickly and easily.
19. Minimize Critical Request Depth
This is another very technical recommendation related to the JS and CSS recommendations we mentioned throughout the guide. The above-the-fold portion of the page – the part users see first – is affected by those files.
You need to make sure the above-the-fold portion of the page renders as quickly as possible for the visitor. To do that, you should prioritize the files that are truly needed for the critical part of the page and defer files that are not needed using the techniques we discussed earlier: async & defer.
Should you address this?
For average WordPress site owners, the best way to address this is to implement the recommendations related to render-blocking requests that we discussed throughout the guide. Another option is to add the relevant CSS for the above-the-fold portion of the page as inline CSS in the page’s head.
If you are not a developer and you did not build the site and theme you are using, you will likely find it difficult to fix this recommendation. Keeping your pages, content, and structure simple can help…
Core Web Vitals and PageSpeed Insights
It is important to note that since the original guide was written, Google introduced Core Web Vitals as part of its ranking formula. The three current metrics are:
- LCP (Largest Contentful Paint) – Measures how long it takes to display the largest element in the above-the-fold portion of the page. The recommended threshold is 2.5 seconds or less.
- INP (Interaction to Next Paint) – This metric replaced FID (First Input Delay) in March 2024 and measures the responsiveness of the page across all interactions. The recommended threshold is 200 milliseconds or less.
- CLS (Cumulative Layout Shift) – Measures the visual stability of the page. The recommended threshold is 0.1 or less.
These metrics affect your Google ranking and appear in the Field Data section of PageSpeed Insights. If you see those metrics in green, you are in good shape.
FAQs
Common questions about Google PageSpeed Insights:
Final Words on Google PageSpeed Insights
The average, non-technical WordPress site owner can definitely benefit from the report that PageSpeed Insights provides. However, it presents an oversimplified score through a number and a color, and the recommendations it shows are too technical for most users.
So you should use the data and recommendations from this tool alongside other performance testing tools to get the full picture of your site’s real-world performance.
Either way, I hope this guide shed some light on the report that PageSpeed provides. If you found it helpful, I would really appreciate it if you share this post or link to it – it takes many hours to write a post of this scope, and your feedback is what encourages me to keep writing…
