Core Web Vitals in Search Console: what the report actually measures

A site can score 100 in PageSpeed Insights and sit in the red in Search Console at the same time, and both numbers are correct. They are measuring different things: one simulates a load on a machine in a data centre, the other reports what happened to real people on real phones over the last 28 days. Only the second one counts for the assessment, and mistaking one for the other is how teams spend a quarter optimizing a score that was never the score being graded.

What are Core Web Vitals in Google Search Console?

Three thresholds measured on real visits: 2.5 seconds for LCP, 200 milliseconds for INP and 0.1 for CLS, at the 75th percentile. On a new site they are rarely the problem; on a mid-authority site they are a margin; on a consolidated one, where content already ties, they can break the tie. No weighting is published.

Quick answer

• Field data decides, lab data debugs. Search Console reports field; PageSpeed lab is a tool.
• The threshold is the 75th percentile of your real visitors, not your laptop on office wifi.
• The window is a rolling 28 days, so a fix takes weeks to show.
• It is a confirmed signal and a small one. It breaks ties; it does not rescue a page.

The distinction that invalidates half the measurements

There are two ways to measure this and they do not agree, by design.

Lab data. What a tool produces by simulating a load: Lighthouse, and the lab section of PageSpeed Insights. It is reproducible and it points at the specific resource behaving badly, which makes it the right tool for debugging.

Field data. What Google collects from real Chrome users and aggregates in the CrUX report, over a rolling 28-day window. This is what feeds the Search Console report and what counts for the assessment.

The gap matters because the assessment happens at the 75th percentile of your real visitors. Three out of four visits have to meet the threshold, which means your own experience testing the site on fibre with a good laptop is irrelevant. A site can score 100 in Lighthouse and fail in the field because its visitors arrive on mid-range phones over mobile data.

There is a case where the report simply says nothing: a site with little traffic may not have enough field data to be assessed. No amount of work manufactures that data, and the correct response is to fix the obvious problems with lab tools and stop refreshing the report.

Reading the report without drawing the wrong conclusion

Search Console groups URLs rather than listing them individually, and that grouping is the part people misread.

URLs are bucketed by similarity, not one by one. A group is flagged because the URLs in it behave alike, so fixing one template fixes the whole group. That is good news: the work is usually template-level rather than page-level.

The status changes slowly. With a rolling 28-day window, a deployment today starts appearing in the data over the following weeks and reaches its full effect a month later. Validating a fix in Search Console and watching for an immediate change is a guaranteed way to conclude the fix did not work.

Mobile and desktop are separate reports and frequently disagree. Mobile is where the failures concentrate and where the visitors are.

The three metrics, and where they break

LCP: the most fixable one

Largest Contentful Paint measures when the biggest element finishes rendering, which on most pages is the hero image or a headline. It is the metric that yields the most improvement for the least work.

The usual culprits are an uncompressed hero image, a font that blocks rendering, and a server that takes too long to send the first byte. On a small site, compressing images is often the entire project.

Worth knowing before the work is scoped: this is the metric a business owner can act on without a developer, which is unusual in technical SEO and part of why it belongs first. What the rest of that ordering looks like for a business with no marketing team is in the basic SEO checklist.

INP: the one that replaced FID

Interaction to Next Paint measures how quickly the page responds when someone taps or clicks, across the whole visit rather than only the first interaction. It replaced First Input Delay in March 2024 and it is stricter, because it no longer ignores everything after the first tap.

Failures here are almost always JavaScript: scripts loading features the page does not use, tag managers stacking third-party tags, and page builders shipping their entire library on every page.

CLS: the one your own site can cause on purpose

Cumulative Layout Shift measures how much the layout jumps while loading. It is the most irritating to a reader and often the cheapest to fix, because the fix is declaring dimensions.

An image without width and height leaves the browser no room reserved, so the page jumps when it arrives. This site hit exactly that: a portrait image of 900x1252 was being served with dimensions that were not its own, which is why the generator now reads dimensions from the file rather than accepting what somebody typed.

How much it is actually worth

This is where the topic gets oversold, in both directions.

It is a confirmed ranking signal, so the people saying it does nothing are wrong. It is also a small one, so the people selling a quarter of engineering work on the promise of position gains are selling something they cannot deliver. It breaks ties between comparable pages; it does not lift a page that answers the query worse than the ones above it.

The honest reason to do the work is the other one. A page that renders in one second and does not jump converts better than the same page at four seconds, regardless of where either sits in the results, and that effect does not depend on any algorithm.

When not to prioritize this

When the site is not indexed properly. Speed on a page Google has not stored is worth nothing, and the diagnosis for that comes first, as covered in why is my page not indexed.

When there is no field data. Below a certain traffic level there is no assessment to improve, and the report will keep saying so no matter what gets deployed.

When the content does not answer the query. A fast page that is the wrong answer stays the wrong answer, and no amount of engineering changes that. Confirming which of your pages are in that position is a reading exercise rather than a technical one, and the sources for it are in keyword research without paid tools.

What Google says, and the percentage the industry invented

Searching this topic on 12 August 2026, one figure kept appearing: that Core Web Vitals account for roughly 10 to 15 % of ranking signals, attributed to "industry research". Google publishes no weighting for any signal, and that figure has no traceable source.

What the documentation does say is worth quoting in full, because the three sentences qualify each other:

"Core Web Vitals are used by our ranking systems." A direct confirmation, which rules out the opposite position that they count for nothing.

"There is no single signal. Our core ranking systems look at a variety of signals that align with overall page experience." So there is no named page experience system to pass or fail.

And the one that sets priority: "getting good results in reports like Search Console's Core Web Vitals report doesn't guarantee that your pages will rank at the top." Google adds that Search always seeks to show the most relevant content, even if the page experience is sub-par.

Together those say something different from either version in circulation. They are not decorative and they are not a lever. They are a threshold worth crossing, and once crossed there is no additional reward for going lower.

Where the numbers come from, and which report to open

The distinction that decides how to read any of this is field data versus lab data. Field data comes from real visits over a rolling window and is what Google evaluates; lab data comes from a simulation and responds instantly. They answer different questions and get confused constantly.

The report itself lives inside Search Console, and setting the property up is covered in how to set up Search Console. If pages are missing from the report entirely, the problem is upstream and belongs in why is my page not indexed.

Where this sits in the order of technical work is in basic SEO checklist, and what the whole discipline looks like from the top, in what is SEO. For a business serving customers at an address, none of it outranks the profile work in local SEO for small business and Google Business Profile.

An empty report is not a clean report

The sentence that decides how this report should be read is in Google's own help page for it, and almost none of the guides that own this query leads with it: "If a URL group does not have a minimum amount of reporting data for both LCP and CLS, the URL is omitted from the report." Checked on 13 August 2026.

That is not a footnote. The report is built from field data, which is collected from real visits, so a page nobody visits produces no row. A small site can open this report, see nothing at all, and read it as a pass. What it actually says is that there were not enough visitors to judge, which is a different fact with a different next step: measuring in the lab, on the templates, rather than waiting for a verdict that will not arrive.

The two states look identical on screen and that is the whole trap. "No problems found" and "could not measure" render the same way, and only one of them means the work is done. A report that cannot tell you which one you are looking at is a report that has to be read alongside your own traffic numbers.

Mistakes that repeat

• Optimizing the Lighthouse score. It is lab data and it is not what gets graded.
• Testing on your own laptop. The threshold is the 75th percentile of real visits.
• Expecting the report to move in days. The window rolls over 28 days.
• Fixing URLs one at a time. The report groups by template; so should the work.
• Ignoring the mobile report. That is where both the failures and the visitors are.
• Selling it as a ranking strategy. It is confirmed, it is small, and it breaks ties.

Data and transparency

That URL groups without a minimum amount of reporting data for LCP and CLS are omitted from the report, that the data is field data gathered from real visits, and that the window is 28 days, come from Google's own help page for the report, opened on 13 August 2026. That few of the top third-party guides for this query lead with the omission rule is an own observation from the same day and is recorded as a gap, not as a source.

That Core Web Vitals are used by Google's ranking systems, that there is no single page experience signal, and that good results in those reports do not guarantee top rankings because Search prioritises relevance, comes from Google's public page experience documentation, checked on 12 August 2026. Google publishes no weighting, so the 10 to 15 % figure in circulation is named here as an unsourced number rather than repeated as fact.

The thresholds for LCP (2.5 s), INP (200 ms) and CLS (0.1), the assessment at the 75th percentile, the rolling 28-day window of the CrUX report, the replacement of First Input Delay by Interaction to Next Paint in March 2024, and the fact that Core Web Vitals are a confirmed ranking signal, all come from Google's public documentation, current as of August 2026. The 900x1252 image being declared with dimensions that were not its own is from this site, where it was corrected by reading dimensions from the file rather than writing them by hand. No correlation figures between speed and rankings appear here, and no "every 100 milliseconds costs X percent of conversions" claim: the studies those come from were run under conditions that do not transfer to an arbitrary site. Verified as of August 2026.

Primary sources, opened on 13 August 2026: the Core Web Vitals report in Search Console.

What this changes

The reason this topic attracts so much wasted effort is that it produces a number, and a number invites a target.

A score is satisfying in a way that "answer the query better than the other ten results" never is, so budget flows toward the thing that can be graded. Worth asking before approving that work: if the site hit all three thresholds tomorrow, what would change for the business? On a site whose pages answer their queries well, the answer is a small tiebreaker and a better experience. On a site whose pages do not, the answer is nothing at all, faster.

Frequently asked questions