A client running an online cosmetics store called us in a mild panic. He had run his site through PageSpeed Insights, seen a red 34 on mobile, and concluded that whoever built the site had cheated him. We opened the report together. Most of the weight came from four tracking scripts, two of which were left over from a campaign a year earlier and were no longer used by anyone. Removing them took twenty minutes. The score jumped to 71 and the average load time of a product page fell from 4.8 to 2.1 seconds.
The story is typical. PageSpeed Insights is free and open to anyone, which is exactly why it causes panic. People see a number, react to the number, and miss what the tool is actually telling them. This article explains how to read the report, which metrics affect Google rankings, and what is worth fixing first.
What PageSpeed Insights measures
PageSpeed Insights is a Google tool that analyses a single page and returns a score from 0 to 100, separately for mobile and desktop. The part most people miss: the report contains two different types of data, and they are not interchangeable.
The first type is lab data. Google loads the page in a controlled environment, with a simulated mobile connection and a throttled processor, and measures what happens. That is where the coloured score comes from. It is a diagnostic tool, not a verdict on your business.
The second type is field data, coming from the Chrome User Experience Report. These are real measurements from actual visitors to your site over the past 28 days. If your site has enough traffic, this section appears at the top of the report and matters far more than the score below it. Google uses field data for ranking, not lab data.
Why the score changes every time you run it
Run PageSpeed Insights three times in a row and you will probably get three different numbers. A swing of 5 to 10 points is normal and comes down to Google's server load, caching and the momentary state of your hosting. So do not chase a specific figure. Watch the trend across several measurements and focus on the concrete recommendations in the report.
Core Web Vitals: the three metrics Google counts
Google reduces user experience to three measurable indicators. They are called Core Web Vitals and have been part of the ranking algorithm since 2021.
LCP (Largest Contentful Paint) measures when the largest visible element appears on screen, usually the main image or the heading. A good result is under 2.5 seconds. This is the metric that best answers the question "when does the visitor see that the page has loaded".
INP (Interaction to Next Paint) measures how quickly the page responds when a user taps a button, opens a menu or fills a field. It replaced the older FID metric in March 2024 and is stricter than it was. A good result is under 200 milliseconds.
CLS (Cumulative Layout Shift) measures how much elements jump around during loading. Anyone who has tapped a button and hit an ad instead, because the page shifted at the last moment, knows why this metric exists. A good result is under 0.1.
How to read the thresholds
| Metric | Good | Needs improvement | Poor | Most common cause |
|---|---|---|---|---|
| LCP | up to 2.5 s | 2.5 to 4 s | over 4 s | heavy images, slow server |
| INP | up to 200 ms | 200 to 500 ms | over 500 ms | excess JavaScript, heavy plugins |
| CLS | up to 0.1 | 0.1 to 0.25 | over 0.25 | missing image dimensions, fonts |
Google evaluates the 75th percentile of real visits. So if three quarters of your visitors have an LCP under 2.5 seconds, the page passes, even if the rest are on a slower connection.
Which problems are worth fixing first
The PageSpeed Insights report lists dozens of recommendations and most of them save a few tenths of a second. The value is in prioritising. Here is what, in our experience, delivers the biggest effect for the least effort.
Images
This is cause number one for slow sites. The typical case: a photo uploaded straight from a phone, 4000 by 3000 pixels, 6 megabytes, displayed in a container 400 pixels wide. The browser downloads all 6 megabytes to show something that needs under 100 kilobytes.
Three actions solve almost everything. Resize images to their actual display dimensions before uploading. Convert them to WebP or AVIF, which saves between 25 and 50 percent compared to JPEG at the same visual quality. Enable lazy loading for everything below the fold, so images at the bottom of the page are fetched only when the visitor reaches them.
Third-party scripts
Every tracking pixel, chat widget, review tool and cookie banner adds weight. Take an inventory: open the Network tab in developer tools and see exactly what loads. There is almost always at least one script nobody uses any more.
The remaining scripts can be deferred. The chat widget is not needed in the first second of loading, nor is the heatmap analytics tool. The defer and async attributes, plus delayed initialisation after first interaction, cut INP noticeably.
Hosting and server time
The TTFB metric (Time to First Byte) shows how long it takes before the server responds at all. If it is over 800 milliseconds, no amount of image optimisation will save you. The causes are usually three: an overloaded shared host, no server-level caching, or a database that has not been cleaned in years.
A server located close to your audience gives a tangible advantage. If you are not sure what you have, start with our comparison of hosting options.
Fonts
Custom fonts look good and quietly ruin CLS. While the browser waits for the font to download, text is either invisible or shown in a fallback and then jumps. The fix is font-display: swap, preloading the primary font, and limiting yourself to two font families with no more than three weights in total.
PageSpeed Insights versus real experience
Here comes the most common misunderstanding. A score of 100 does not mean a fast site, and a score of 60 does not mean a slow one. The tool measures technical execution, not perceived speed.
We have seen sites scoring 95 that feel sluggish because the main image appears last. And sites scoring 62 that feel instant because the critical content comes first in the loading order and everything else follows.
What score is good enough
For most businesses the sensible target looks like this: all three Core Web Vitals in green on field data, a mobile score above 70, and LCP under 2.5 seconds. Climbing from 85 to 98 usually costs more hours than it returns in value, and those hours are better spent on content or on advertising.
Online stores with heavy traffic are the exception. There every tenth of a second has a measurable price, because it multiplies by the number of visitors in the checkout flow.
How to monitor speed continuously
A one-off check is a snapshot. Speed degrades gradually, usually after a new plugin, a new campaign with tracking, or an event gallery upload.
Google Search Console has a dedicated Core Web Vitals report showing your pages grouped by issue, based on real visits. It is more useful than a single PageSpeed Insights run because it covers the whole site rather than one page. Setup details are in our article on Google Search Console.
For more precise monitoring, tools like WebPageTest work well, letting you test from a specific geographic location and at a specific connection speed. Test from the region your customers are actually in, on a mobile 4G profile, rather than from a data centre on fibre.
How often to check
Once a month is enough for an informational site. For an online store, and especially after every theme change or new feature, the check should be part of the process. If you maintain your site yourself, add it to your monthly list alongside regular maintenance.
Frequently asked questions
Does site speed affect Google rankings?
Yes, but less powerfully than often claimed. Core Web Vitals are a confirmed ranking factor, but content relevance weighs much more. Speed becomes decisive when two pages are comparably good on content: then the faster one wins. The indirect effect is even larger, because slow sites lose visitors before loading finishes and that shows up in behavioural signals.
What PageSpeed Insights score is good?
Above 90 counts as excellent, 50 to 89 as average, below 50 as poor. Practically, aim for above 70 on mobile with all three Core Web Vitals in green. The mobile score is always lower than desktop because Google simulates a weaker processor and a slower connection.
Why is my mobile score so much lower than desktop?
Because of the test conditions. Google simulates a mid-range device on a 4G connection. The desktop test uses a fast connection and a powerful processor. A gap of 20 to 30 points between the two is entirely normal. Since the majority of traffic now comes from phones, the mobile score is the one that matters.
Can I fix speed with a plugin?
Partly. A caching plugin such as LiteSpeed Cache or WP Rocket solves a large share of WordPress problems and often delivers the fastest improvement for the least work. But a plugin cannot compensate for a bloated theme, weak hosting or fifty unoptimised images. Sometimes adding more optimisation plugins makes things worse, because they compete with each other.
How long does speed optimisation take?
For a typical corporate site the main improvements take one to two working days: images, caching, script cleanup. An online store with thousands of products needs more, usually three to five days, because product images are processed in batches and checks are done per template. If the problem lies in the theme or the architecture itself, the conversation is about a rebuild, not optimisation.
In short
PageSpeed Insights is a diagnosis, not a verdict. Read it top down: field data first, then the specific recommendations, the score last. Images, third-party scripts and server response time cover the majority of real problems and can be solved without rewriting the site.
If you have run the test, seen red and are unsure which of the items above applies to you, send us your site address through the contact form. We do a free review and come back with a concrete priority list, plus a quote within 24 hours if you need one. And if you are planning a new site, speed is built into how we approach web development from day one.
