Core Web Vitals score.
The composite Core Web Vitals score is a single pass / needs-improvement / poor bucket assigned to a URL when the 75th percentile of real-user field data falls inside the good band for all three metrics. The Search Console Core Web Vitals report renders the bucket; the Page Experience signal reads the bucket as a tiebreaker inside the integrated core ranking systems.
Core Web Vitals score is the rendered output of our natural SEO services handing off the diagnostic layer to the engineering team. The number is small. The discipline behind reading it is the work.
All three metrics in good, at the 75th percentile of field data.
The composite Core Web Vitals score is not an average. It is an AND condition across the three measured Vitals: the 75th percentile of Largest Contentful Paint must land at or under 2.5 seconds, the 75th percentile of Interaction to Next Paint at or under 200 milliseconds, the 75th percentile of Cumulative Layout Shift at or under 0.1. One metric in needs-improvement drops the URL out of the passing bucket regardless of how well the other two perform.
The 75th percentile reads against the Chrome User Experience Report. CrUX aggregates real-user measurements from Chrome installations that opt in to anonymous telemetry. The aggregation runs on a 28-day rolling window. A URL with insufficient traffic to clear the sampling floor sits as unevaluated until field volume reaches the threshold, which is one of the reasons new pages and low-traffic deep pages frequently show no score at all.
The bucket is per-URL when CrUX has enough data, and falls back to origin-level aggregation when the URL volume is insufficient. The origin fallback is why a homepage on a high-traffic site can carry one score while individual deep pages on the same site inherit the origin number rather than a per-page measurement.
The score Google ranks against is the field number, not the Lighthouse lab score.
PageSpeed Insights and the Lighthouse panel surface both field and lab data on the same screen. The two columns frequently disagree. The lab column simulates a fixed device profile and a constrained network throttle; the field column reads CrUX. Page Experience reads CrUX. Search Console reads CrUX. Lab is a diagnostic surface for what the field is likely to measure; it is not the surface Google ranks against.
The web-vitals JavaScript library, maintained by the Chrome team, exposes the canonical client-side measurement model. Real User Monitoring data captured through the library matches the CrUX measurement model and gives the engineering team a pre-CrUX read on metric movement. Programs that watch only Lighthouse ship green lab scores against red field data and miss the ranking signal entirely.
Lighthouse remains useful for the per-page diagnostic: which subsystem is responsible for the slow Largest Contentful Paint, which third-party tag is blocking the main thread, which image is reflowing the layout. The lab read is a microscope on a single load; the field read is the population the ranking signal acts on.
Surfaces field and lab data on the same page. Field column reads CrUX URL data when available; falls back to origin-level.
Search Central →Canonical client-side measurement maintained by the Chrome team. Matches the CrUX measurement model for RUM capture.
Search Central →The full Page Experience signal layer, including the ranking-weight notes and the measurement-surface map.
The two responsiveness and visual-stability metrics inside the composite score.
How the Core Web Vitals diagnostic integrates into the broader organic SEO program.
What operators ask about the Core Web Vitals score before the engineering work starts.
- 01.What counts as a passing Core Web Vitals score?
- A passing composite score requires the 75th percentile of real-user sessions to land in the good band for all three metrics. Largest Contentful Paint at 2.5 seconds or under, Interaction to Next Paint at 200 milliseconds or under, Cumulative Layout Shift at 0.1 or under. One metric in needs-improvement drops the page out of the passing bucket inside Search Console's Core Web Vitals report.
- 02.Why is the 75th percentile the cutoff and not the median?
- Field data carries a long tail. A median measurement hides the experience of the slowest quarter of sessions, which is precisely the segment Google wants the metric to surface. The 75th percentile forces the site to clear the bar for three quarters of real-user traffic, not for the easy half. Pages can hit a green Lighthouse score on a clean lab profile and still fail the 75th-percentile threshold in CrUX because the field tail is heavier than the lab simulation.
- 03.Where does the score show up in Search Console?
- The Search Console Core Web Vitals report groups URLs into good, needs-improvement, and poor buckets per metric, on mobile and desktop separately. The report runs on a 28-day rolling CrUX window. URLs without enough Chrome User Experience Report traffic to clear the sampling floor surface as unevaluated rather than as a numeric score.
- 04.Does the score feed into ranking directly?
- The score feeds the Page Experience signal, which the integrated core ranking systems read as a tiebreaker between pages of comparable content quality. A strong score does not redeem a thin content layer, and a passing score on a substantive page protects the page when a competitor of comparable content quality ships needs-improvement Vitals. The dependency runs through content quality first, Page Experience second.
If you want the Core Web Vitals score handled as a load-bearing technical layer rather than a Lighthouse number, see how we work.
Two-week diagnostic. The Core Web Vitals work sits inside the broader technical foundation, alongside rendering parity, crawl budget, and the schema architecture that carries the entity signal.