Core Web Vitals — why your PageSpeed score measures something else

Most services sold as website optimisation come down to one goal: a green score above 90 in the popular audit tools. Business owners chase the perfect rating, believing it will translate into higher search rankings. Yet from Google's point of view, page loading speed is not a single number from 0 to 100. The score you see in most testers is a lab rating and nothing more. To understand what actually affects a site's visibility, you have to separate the simulation from the hard metrics the algorithm uses — the Core Web Vitals.

Lighthouse score vs Core Web Vitals

When you run a Core Web Vitals test or any speed test in the browser, the Lighthouse engine is doing the work underneath. It is worth looking at what its final rating consists of. In Lighthouse 13, which made no changes to the scoring model, the weights according to the official documentation are:

• First Contentful Paint (FCP): 10%
• Speed Index: 10%
• Largest Contentful Paint (LCP): 25%
• Total Blocking Time (TBT): 30%
• Cumulative Layout Shift (CLS): 25%

The largest weight in the lab score — a full 30% — goes to TBT. The problem is that TBT is not a Core Web Vitals metric, and the ranking algorithm does not use it. Meanwhile Interaction to Next Paint, which is a full ranking metric, does not appear in the Lighthouse score at all.

The reason for that absence is mundane and worth remembering, because it explains the rest of this article: nobody clicks in a lab. Lighthouse loads the page and measures what happens on its own. INP measures the response to a user's action, and with no user there is nothing to measure. TBT is the lab approximation of the same problem — it checks how long the browser's main thread was busy and would not have been able to respond if someone had clicked.

The other two items on the list are worth knowing by name, because they appear in every report. First Contentful Paint is the moment anything appears on screen — the first text or the first image. Speed Index describes how quickly the visible area of the page fills up. Both are sensible measures of the "something is happening" impression, both are lab metrics, and neither is a Core Web Vital.

The practical consequence: whoever invests in reaching 90 points optimises for a metric excluded from ranking and does not measure the one that is in it. That does not make the Lighthouse score useless — it is a good diagnostic tool, and we will show shortly when it can be the only one you have. It only means it is not the assessment the search engine performs.

Three metrics and three thresholds

The search engine does not rate a site with a weighted lab average; it measures website speed through specific user experiences. According to web.dev, a page meets the Core Web Vitals standard when it stays within three thresholds:

• Largest Contentful Paint (LCP): ≤ 2.5 s — the render time of the largest text block or image visible without scrolling.
• Interaction to Next Paint (INP): ≤ 200 ms — the metric that replaced FID in March 2024. The browser observes all interactions during a visit and reports a single value close to the worst of them — not a sum and not an average. On pages with many interactions, individual outliers are discarded, so that one accidental stall does not decide the rating.
• Cumulative Layout Shift (CLS): ≤ 0.1 — visual stability. It catches unexpected layout shifts, for example when text "jumps" away from your finger because a banner has loaded.

The thresholds do not apply to a single test. To pass, a page has to hold these values at the 75th percentile of visits — at least 75 out of 100 real visits must fall below the threshold. And one clarification that is easy to trip over: the percentile is calculated separately for mobile devices and separately for desktops. A site can pass on desktop and fail on phones, and that is a typical situation, not an exception.

Lab vs field

The gap between a high score after installing a speed plugin and the absence of any real effect comes from how the data is collected. Lighthouse is a lab environment. It simulates one load from one test server, applying predefined bandwidth limits — which makes results repeatable, but detached from reality.

For its assessment, Google uses the Chrome User Experience Report (CrUX) — a collection of anonymous data from real Chrome users. CrUX includes harsh conditions: five-year-old phones, momentary signal loss on public transport, crowded Wi-Fi networks, slow connections. In the field, what matters is not how the page loads for a developer on fibre, but how it behaves for your customers.

It is also worth knowing how this data is calculated, because it determines the timeline of any fix. According to the CrUX API documentation, CrUX provides a 28-day rolling average, updated daily at around 04:00 UTC, and the dataset runs about two days behind the current date, because it waits for complete data and for processing.

The practical effect is that a fix deployed on Monday will not show in the report on Tuesday, and when it does start to show, it will be diluted by three weeks of old measurements. The full picture after a change is visible only after roughly four weeks. Anyone judging a deployment after three days is mostly judging noise. Counting those two days of delay and assuming the same traffic every day: a week after the deployment, visits made after the fix are 18% of the data in the report, half after 16 days, and all of it only after 30.

Hence a practical conclusion for conversations with your contractor: a screenshot of a green score is not proof that anything improved. It is proof that in one simulated load the page behaved well. Proof is field data collected for several weeks after the change — if you have any at all.

Why your site may have no field data

This is the part missing from most guides, and for a smaller business it is the most important one.

For an address to be included in CrUX, it has to meet two conditions: be publicly accessible and sufficiently popular. The Chrome documentation states the second condition plainly: a page is sufficiently popular if it has a minimum number of visitors, and "the exact number is not disclosed" — it was chosen so that the sample makes statistical sense. Addresses and domains that do not cross the threshold are not in the CrUX dataset.

There is no middle ground. You do not get worse data or qualified data — you get none. A company website with a few hundred visits a month usually does not exist in CrUX, and opening PageSpeed Insights for such an address will show only the lab section, with no real-user data section.

What follows in practice:

• You cannot check whether your site "passes" Core Web Vitals if it has no field data. You can only estimate from the lab.
• The lab score then becomes the only tool you have — and then it is worth using, remembering what it is. That is an argument for Lighthouse, not against it.
• Your own real-user measurement is possible and requires no permission from Google: Core Web Vitals data can be collected from your own visitors' browsers. It is a standard feature a contractor switches on once. Do not confuse it with uptime monitoring: that tells you whether something has just broken, this tells you how the site performs for users over recent weeks; we describe the difference under website monitoring.
• Do not draw conclusions from missing data. No field section in PageSpeed does not mean the site is slow or that Google is penalising it. It means traffic is too low for Google to have anything to average.

Where LCP time really goes

Suppose LCP comes out too long. The question is: what to pay for to shorten it. The web.dev documentation breaks that time into four phases and gives the share each should have.

• Time to First Byte — about 40%. The time from clicking a link to the first byte of the response. That is the server: where it sits, how loaded it is, whether the response is cached.
• Resource load delay — under 10%. From the first byte to the moment the browser starts downloading the largest element.
• Resource load duration — about 40%. Loading that element itself. On a company website it is almost always a photo.
• Element render delay — under 10%. From the element being downloaded to it appearing on screen.

Eighty percent of the budget is the server and one image. Those are two decisions, neither of them a programming decision: the first is a purchasing one (where you buy hosting and what it costs), the second an editorial one (which photo goes at the top of the page and at what size). A plugin labelled "optimisation" touches neither.

You do not have to guess which element is meant. Audit tools name it directly — the report contains an item identifying the element treated as the largest. On a company website it is usually the header photo, less often a text block with a large heading. And here comes the first surprise: the LCP element often turns out to be something nobody planned — the background of the hero section, or an image that fills half the screen on a phone even though it is a side decoration on desktop.

The two "delay" phases are meant to be the remainder. If one of them has grown, it is a diagnostic signal, not a reason to buy a more powerful server — something is blocking the download from starting or the rendering. That is when it makes sense to reach for Lighthouse, because this is exactly the type of problem a lab shows well.

What really affects TTFB when choosing a server is covered separately in our article on hosting and domains.

INP: three phases, and why it is not FID

INP is the youngest of the three metrics and the most often misdescribed — usually as "the successor to FID", which suggests a minor rename. It is not a minor change.

FID measured the delay of the first interaction: how much time passed before the browser started handling the first click. It did not measure how long the handling itself took, or when the user saw the result. A page could therefore pass FID and at the same time respond terribly — all it took was a fast first click, with every one after it dragging a second behind.

INP measures the whole path, in three phases:

• Input delay — from the click to the start of handling. What FID used to measure.
• Processing duration — how long the code responsible for the response runs.
• Presentation delay — from the code finishing to the change being visible on screen.

Only the sum of these three segments describes what a user calls "the page froze". For a site owner the conclusion is concrete: INP gets worse because of what you add — tracking scripts, chat widgets, plugins that run their share of code on every click. It rarely gets worse because of the template itself.

That is why INP and the number of installed add-ons are in practice the same conversation as updates and everything that has been added to a site.

CLS — the cheapest to fix

CLS is the only one of the three metrics that can usually be fixed without spending money on infrastructure, because its causes are countable and repeatable:

• Images without declared dimensions. The browser does not know how much space to reserve, so it reserves none and pushes everything down when the photo arrives.
• Content inserted above existing content — consent banners, promotional bars, messages loaded after the page starts.
• Fonts swapped after loading. Text appears in a fallback font and then switches to the intended one with a different width, and the whole paragraph jumps.

The threshold itself can be misleading, because 0.1 is not a unit of time or distance. It is the product of two fractions: how much of the screen the moving element covers in its old and new positions combined, and how far it moved, measured against the longer side of the screen. What counts is the worst burst of shifts — ones that follow each other less than a second apart, within a window of up to 5 seconds — not the total for the whole visit. Take the example from Google's documentation: an element filling half of a phone screen moves down by a quarter of the screen's height, so together with its old position it covers 75% of the screen, and that single shift scores 0.75 × 0.25 ≈ 0.19 — almost twice the entire threshold (web.dev, "Cumulative Layout Shift (CLS)"). Worth remembering: on a phone it is enough for half the screen to move down by a fifth of its height (0.7 × 0.2 = 0.14) to exceed 0.1 in a single move. A single consent banner sliding in above the content can do that on its own.

Each of these three has a standard fix on the contractor's side, and it is work measured in hours, not weeks. If the work is commissioned as part of an ongoing website maintenance service, it is worth recording it as a separate task with a before-and-after measurement rather than as part of "routine fixes". If your performance budget is limited, CLS is where the ratio of effect to cost is best — and it is also the metric users feel most sharply, because it shows up as a click on the wrong button.

What a good score buys, and what it does not

Here we have to say something the optimisation industry won't. Google puts it surprisingly cautiously in its documentation for site owners.

First: "There is no single signal" — there is no single "page experience" indicator that the algorithm plugs into a formula. Ranking systems look at many signals, and Core Web Vitals are one of them.

Second, and more important: "Google Search always seeks to show the most relevant content, even if the page experience is sub-par". Relevance wins. A slow page that answers the question will beat a fast, empty one. Only when there are many valuable answers — and for most commercial queries there are — does good experience start to tip the balance.

Third, plainly: good Core Web Vitals results "doesn't guarantee that your pages will rank at the top".

What this means for the spending decision:

• Performance will not replace content. If a page does not answer customers' questions, speeding it up means it fails to answer them faster.
• Performance breaks ties. In a competitive niche where a dozen pages say the same thing, it is one of the differentiating factors.
• Performance makes sense beyond ranking. A page that sits on a white screen for three seconds loses some visitors before Google gets to assess anything. That is an argument in itself and does not need the algorithm to back it.

The order in which to spend money

Putting the above together, here is the order worth acting on:

1. Check whether you have field data at all. Open PageSpeed Insights for your address. If there is a real-user data section, you are working with facts. If not, you are working with the lab, and it is worth switching on your own measurement.
2. Start with CLS. The cheapest, the fastest, the most noticeable for users.
3. Then the images at the top of the page. About 40% of the LCP budget is downloading the largest element. The right size and format can be worth more than a change of hosting.
4. Then the server. If TTFB takes clearly more than 40% of the time, it is a conversation about where the site is hosted — and then changing hosting really does help. How to move to a new server without losing anything in search is covered under website migration.
5. Finally, count what you add. INP gets worse because of scripts. Every chat, pixel and plugin has its cost, paid on every user click.
6. Measure after the change, not before. Field data needs several weeks to show an effect. A screenshot from deployment day is not a measurement.

If you are wondering how much of this should be a fixed item in the budget and how much a one-off expense, that is a separate conversation about website maintenance costs and about what to watch on an ongoing basis.

How to read an optimisation proposal

Since the points score is not what the search engine assesses, a line such as "we will get the site to 90+ in PageSpeed" is a promise about a simulation, not about the state of the site for your customers. That does not make the proposal dishonest — it means it measures success in a unit that is not the unit of ranking.

Below are the four lines that appear most often in proposals, and what to ask about each.

A good performance proposal has three features. It starts with a baseline measurement, not with a list of tasks — without one, the effect cannot be demonstrated later. It names the metric it targets instead of talking about "speeding the site up". And it separates what will change immediately from what you will only see in field data after several weeks.

If your site has no field data, tell the contractor at the start. The honest response is a proposal to switch on your own measurement before work begins — not an assurance that "it will be faster anyway".