Page speed is how quickly a page becomes visible and usable for the person opening it. It is not a single number: Google measures three separate aspects and calculates them from data collected in real users' browsers, not from a simulated test.
That difference between real and simulated data explains almost every argument about a site's speed: the coloured score PageSpeed Insights gives you and the assessment Google uses for ranking are two different things, produced by two different systems. Anyone who confuses them spends months optimising the wrong number, and it is one of the most expensive SEO myths.
The three metrics Google measures
They are called Core Web Vitals, and there are three. Largest Contentful Paint (LCP) measures how long it takes for the largest visible element at the top of the page to appear, usually an image or a block of text. Interaction to Next Paint (INP) measures the delay between the moment the user taps something and the moment the screen responds. Cumulative Layout Shift (CLS) measures how much the layout moves while the page finishes loading: the thing where you press one button and hit another because a banner has just opened.
| Metric | What it measures | Good | Needs improvement | Poor |
|---|---|---|---|---|
| LCP | Appearance of the main element | ≤ 2.5 s | 2.5 - 4 s | > 4 s |
| INP | Response to an interaction | ≤ 200 ms | 200 - 500 ms | > 500 ms |
| CLS | Unexpected layout shifts | ≤ 0.1 | 0.1 - 0.25 | > 0.25 |
Two details of the method change how any report should be read. First, the threshold is not applied to the average visit but to the 75th percentile. Google chose that value because it ensures three visits out of four meet the required level without a handful of outliers distorting the result, as would happen at the 95th percentile. Second, the window is 28 days. A fix made yesterday enters the report gradually, and it takes almost a month for the value to settle.
A fourth metric left the stage recently. INP replaced First Input Delay on 12 March 2024, and support for FID in Chrome tools ended on 9 September the same year. If you still find FID in a checklist or an agency report, you are reading a document at least two years old.
The PageSpeed Insights score is not the Core Web Vitals
When you open PageSpeed Insights you see two blocks. At the top, if the site has enough traffic, is the field data: the real data, collected from the Chrome browsers of users who visited that page in the last 28 days and aggregated in the Chrome UX Report. Below it is the 0 to 100 score, which comes from a simulation: Lighthouse loads the page once, with an empty cache, on a device and connection set up in advance.
The two blocks can tell opposite stories, and that is not a fault in the tools. Google has written down why lab and field data diverge: real users often arrive with some resources already cached, use the back button and trigger the bfcache that the test does not simulate, see personalised content or A/B test variants with different LCP elements, and scroll the page so that lazy-loaded images shift the layout at a moment no test reproduces. In the other direction, a 300 millisecond delay on a slow device does not affect the Total Blocking Time measured in the lab but does worsen the real INP.
The lab score is also unstable. In our experience it is normal for two consecutive runs on the same URL, minutes apart, to return very different scores. The number is not a property of the site; it is the result of a single measurement.
How much speed counts for rankings
Here it is better to quote Google word for word than to paraphrase. The page experience documentation says that "There is no single signal. Our core ranking systems look at a variety of signals that align with overall page experience", and a little further down that "Google Search always seeks to show the most relevant content, even if the page experience is sub-par". The same guide, in the part that deals with the Core Web Vitals, contains the sentence that settles the question: "Getting good results in reports like Search Console's Core Web Vitals report or third-party tools doesn't guarantee that your pages will rank at the top of Google Search results".
The right reading comes from another passage of the Google Search Central documentation: for many queries there is plenty of helpful content, and in those cases a good page experience can contribute to success. In practice, speed counts when you are already in the race. If your problem is that nobody links to you, that the site does not match search intent or that there is no demand for the brand, taking LCP from 3.1 to 2.4 seconds will not move anything. It is worth reading which ranking factors really matter and in what order to tackle them.
The state of the web, in numbers
The 2025 edition of the HTTP Archive Web Almanac, built on the global CrUX dataset, measures how many origins pass all three thresholds. The sample is neither British nor American: it is the set of sites covered by Chrome worldwide.
| "Good" rating | Mobile | Desktop |
|---|---|---|
| All three Core Web Vitals | 48% | 56% |
| LCP | 62% | 74% |
| INP | 77% | 97% |
| CLS | 81% | 72% |
Three things stand out. First, on mobile fewer than one site in two passes, so being below the threshold is not an anomaly but the condition of the majority. Second, the gap between desktop and mobile is concentrated in INP, 97% against 77%, because responsiveness depends on the work JavaScript puts on the phone's processor. Third, things are improving slowly but they are improving: from 36% in 2023 to 44% in 2024 and 48% in 2025 on mobile.
One figure overturns a common assumption: among the top thousand sites in the world by traffic, the share passing Core Web Vitals on mobile is 51%, and for INP it drops to 63% against 77% for the general population. The biggest sites are on average less responsive, because they are the ones loading the most third-party scripts.
In the UK the network is not the bottleneck
Many articles on speed assume that users browse in difficult conditions. The regulator's data says otherwise. Ofcom's Mobile Matters 2025 report, based on more than 120 million crowdsourced Opensignal data points collected between October 2024 and March 2025, found that 47% of 5G download speeds exceeded 100 Mbit/s. The median time to download a 10 MB file was about one second on 5G and about two seconds on 4G, and average response times on both 4G and 5G were under 25 ms.
With that capacity, a slow website is slow because of what has been piled on top of it: tracking scripts, chat widgets, ad pixels, fonts loaded from external domains, plugins nobody ever removed. Not because of bandwidth. That moves the problem from infrastructure to marketing decisions, which is better news, because marketing decisions can be changed in an afternoon.
137 "poor" URLs and a cookie banner
A case from our own projects, reported without the client's name because the figures are not public. An Italian B2B company with three sites in three languages opens Google Search Console and finds 137 pages flagged as "poor" on mobile Core Web Vitals, spread across two domains. The CEO's reaction is the usual one: he understands the problem may not affect SEO, but seeing that red number on the dashboard bothers him and he wants it fixed.
Looking at the pages, the only value outside the threshold was mobile INP; on desktop everything was fine. The cause: the requests all fired at once and, until they completed, the page counted as not loaded according to the tool's metrics. Browsing the same URLs in incognito with the Performance panel of Chrome DevTools open, the Core Web Vitals came out good.
A few months earlier, on the same group of sites, another LCP alert had been cleared with a ten-minute fix: the cookie policy banner covered almost the whole phone screen, Google identified it as the largest element on the page and measured how long it took to appear. Once the banner was made smaller in the CMP console, the warnings closed. No theme rewrite, no change of hosting.
The interesting part is what happened next. Over the same period the international domain was losing organic traffic despite months of work on content. The cause was not speed but the lack of brand demand and authority signals outside Italy: no awareness campaigns, no international link building, no mentions on non-Italian sources. There, Core Web Vitals were a finishing touch, not the lever. In industrial and manufacturing projects this mix-up of priorities is the most common of all.
When it is worth working on speed
This is the table we use to decide whether performance work goes into the plan or stays in the queue. The same criterion applies to all the other ways to improve a website's SEO. It assumes a site that is already indexed and gets at least some traffic.
| Situation | Priority | Reason |
|---|---|---|
| Field data "poor" on LCP or INP and significant traffic | High | You are losing conversions now, regardless of rankings |
| Ecommerce or quote form with real volumes | High | The effect on conversion rate can be measured within weeks |
| Competitors equivalent in content and authority | Medium | This is where page experience can be the tie-breaker |
| Low Lighthouse score but field data "good" | Low | You are looking at a simulation, not your users |
| New site or no authority in the target market | Low | The bottleneck is demand, not loading |
| Less than 28 days since the last fix | None | The report does not yet have enough data to tell you whether it worked |
The conversions row has a solid source behind it. The study Milliseconds Make Millions, carried out by Deloitte for Google on 37 European and US brands and more than 30 million sessions monitored over 30 days at the end of 2019, measured the effect of just a 0.1 second improvement: +8.4% conversion rate in retail, +10.1% in travel, +21.6% form submissions in lead generation, +9.2% average order value. The sample is European and American and covers the mobile sites of big brands: these are orders of magnitude, not a promise that transfers to any site. But the effect on conversions is more direct and faster than the effect on rankings, and in most cases it is the argument that justifies the budget.
Fixes in order of return
The order below follows what we see working on the company websites we look after, almost all on a CMS such as WordPress, not the order in which tools list them.
- Remove scripts nobody uses any more. Pixels from finished campaigns, chat widgets never switched on, heatmap tools installed for a test two years ago. This is the fix with the best result-to-time ratio and it needs no development.
- Size the LCP element. Find which element Google considers the largest on the page, then decide whether it really needs to be that one. A full-screen banner, a homepage slider, a background video: often the answer is to remove it, not optimise it.
- Serve images in the right format and size. Modern formats, real display dimensions, width and height attributes to reserve the space and prevent layout shifts. The practical detail is in the guide to image optimisation.
- Defer JavaScript that is not needed for the first render. This is the fix that moves INP, and also the one that can break something: do it on a staging environment.
- Cache and CDN. Useful and by now standard, but it acts on server response time, which is rarely the worst part of the problem on an average company website.
- Change hosting. It makes sense when TTFB stays above 800 milliseconds even with caching on. Before that point it is a cost that just moves the problem elsewhere.
None of these fixes should be judged before 28 days, because of the data collection window described above. That is why Core Web Vitals belong among the SEO KPIs you check once a month rather than once a day, alongside performance metrics such as click-through rate.
Which tool is for what
| Tool | Type of data | When to use it |
|---|---|---|
| Search Console, Core Web Vitals report | Field, aggregated by groups of similar URLs | Understand how many pages, and which, have a real problem |
| PageSpeed Insights, top block | Field, 28 days, 75th percentile | Check a single URL with real user data |
| PageSpeed Insights, 0-100 score | Lab, single run | Find what to optimise, not judge the state of the site |
| Chrome DevTools, Performance panel | Local, real browsing | Reproduce the problem and see which element causes it |
| Chrome UX Report | Field, monthly history | Compare against competitors and read the trend |
A mistake we often see during an SEO audit: judging a whole site by running Lighthouse on the homepage. The homepage is almost always the heaviest and least representative page, and the Search Console report works by groups of similar URLs precisely because the homepage is a case of its own. The same goes when you cross-check with Google Analytics: the session average hides the pages that are really struggling.
Where page speed sits in the rest of the work
Speed is one item in technical SEO, and technical SEO is the part of the work that makes a site readable, not the part that makes it authoritative. On a B2B project with a few hundred visits a month, moving LCP by half a second produces fewer measurable effects than a single well-written page on a query no competitor covers, and the same resources go further in on-page optimisation. On an ecommerce site with ten thousand sessions a day, the same half second turns into revenue.
If you are deciding where to start, the two entry points are SEO consulting, when the problem is visibility, and website development, when the problem is that the structure underneath cannot carry what has been built on top of it.
One last thing that is rarely said in the industry. Page speed is not a project you close; it is a budget that gets spent. Every department that adds a tag, every campaign that brings a new pixel, every supplier that asks to install its widget spends a little of the speed budget someone earned months earlier, and nobody keeps count. The companies that stay fast are not the ones that did the best optimisation: they are the ones where someone is allowed to say no to a script.
Page speed FAQs
The 0 to 100 score is not the assessment Google uses for ranking: it comes from a single simulated lab run. Above 90 is considered good, 50 to 89 needs improvement, below 50 is poor. What really counts is the top block of the tool, the field data collected from real users over the last 28 days. A site can score 62 and still pass all the Core Web Vitals.
Core Web Vitals are among the signals the ranking systems consider, but Google states in its own documentation that there is no single page experience signal and that Search shows the most relevant content even when page experience is sub-par. Speed becomes relevant when two pages are equivalent in content and authority.
Because the assessment is based on the 75th percentile of real visits over 28 days, not on your own browsing. If a quarter of users arrive on slow phones or congested connections, the value outside the threshold is theirs. The most common causes are an oversized LCP element, such as a full-screen cookie banner, and third-party scripts that tie up the device processor.
At least 28 days, because that is the field data collection window. In the first few days the report mixes experiences from before and after the fix, so a real improvement can look absent. The lab score changes immediately, which is why it is used to check that a change has had a technical effect.
Whichever is outside the threshold in the field data, not whichever the tool flags first. On the mobile web the most critical metric is LCP, with 62% of origins rated good according to the Web Almanac 2025, while CLS is the least problematic at 81%. If you fail more than one metric, LCP is almost always the place to start because it depends on a single, identifiable element.
