Your PageSpeed score is not your website’s speed.

Someone ran your site through PageSpeed Insights, screenshotted a red 47, and sent it to you with a note about how this is why you are not ranking. Now there is a quote in your inbox for a performance project.

Before you approve it, three things about that number are worth knowing, and all three come from Google's own documentation.

The score is a simulation of a visit that never happened

That 0 to 100 figure is lab data. A tool loads your page once, on a synthetic device, over a throttled connection, and grades what it saw. It is a useful development check and it catches regressions before they ship.

It is not what Google assesses. Core Web Vitals are measured from field data, meaning real visits by real people on their own phones and connections, and the assessment is taken at the 75th percentile across mobile and desktop. Google's guidance is blunt about the relationship: only field measurement can accurately capture the complete picture, and lab data is not a substitute for it.

Which means a site can score in the nineties and fail in the field, or score badly and pass. The two numbers are answering different questions, and only one of them is about your actual customers.

One of the three metrics cannot be tested in a lab at all

Core Web Vitals is three measurements. Largest Contentful Paint should happen within 2.5 seconds. Interaction to Next Paint should be 200 milliseconds or less. Cumulative Layout Shift should stay at 0.1 or below.

INP is the one that replaced First Input Delay, and it became stable in 2024, so any advice you are reading that still talks about FID predates the change. It measures how quickly the page responds when somebody interacts with it, which requires somebody to interact with it. A simulated load has no user, so lab tools cannot measure INP.

A third of the thing you are being sold cannot be seen by the tool in the screenshot.

What Google actually says about ranking

Core Web Vitals are used by Google's ranking systems; that part of the pitch is true. The rest of the documentation is where the sales argument falls apart.

Google states there is no single page experience signal, that its core ranking systems look at a variety of signals, and — the sentence worth pinning above the quote you were sent — that "Google Search always seeks to show the most relevant content, even if the page experience is sub-par". It also says outright that good results in Search Console's Core Web Vitals report or in third-party tools do not guarantee your pages will rank at the top.

The honest reading is that page experience is a tiebreaker. Where lots of comparable content exists, being the faster page can contribute. It does not promote a page that is not relevant, and it will not lift you past competitors who answer the question better. If you are not ranking, work out whether you are even indexed first, because that is a different problem with a different fix.

Who is missing from the real data

The field data comes from the Chrome User Experience Report, and its eligibility rules matter more than anyone mentions.

A page has to be publicly discoverable and sufficiently popular, defined as a minimum number of visitors that Google does not disclose. Pages under that bar are not in the dataset at all, which is why plenty of small business sites have an empty Core Web Vitals report and no way to fill it except more traffic.

The collection is also narrower than most people assume. It comes from Chrome on desktop and Android, including Custom Tabs and WebAPKs, and notably not from Chrome on iOS.

Sit with that one if your customers are iPhone users. The experience of a substantial share of your visitors is not represented in the dataset Google grades you on, which is an argument for testing on a real phone rather than trusting either the score or the report.

The one that quietly costs you money

Of the three, Cumulative Layout Shift is the one with an obvious line to revenue, and it is the one nobody prioritises because it does not sound like speed. It measures things moving after the page has already drawn, usually because an image or ad arrived late and shoved everything below it down the screen.

On a phone, that is the reason someone taps the wrong button on your booking form, lands somewhere they did not intend, and leaves. Nobody reports that as a complaint. It shows up as a form that underperforms for no visible reason.

Fix speed for that, not for the score. A site that responds quickly on a bad connection in a truck outside a customer's house is worth building; a green circle in a report is worth nothing on its own.

What to do instead of chasing 100

Open your own site on your own phone, on mobile data, away from the office wifi, and use it like a customer would: find the number, open the booking form, submit it. Most real performance problems announce themselves in that thirty seconds, and most of them are images nobody compressed and scripts nobody removed.

Then look at the field report in Search Console rather than the lab score, and if it is empty, accept that you do not have enough traffic to be measured and spend the money on the reason for that instead.

A performance retainer aimed at moving a lab score from 62 to 94 is a project with a visible deliverable and an invisible benefit, which is exactly why it is easy to sell. If someone has sent you one, book a strategy call and we will tell you whether it is worth doing, including when the answer is that your site is fine and the content is the constraint.