Core Web Vitals: What Actually Moves Rankings in 2026

Core Web Vitals get treated like a lever that directly overrides rankings, and that's exactly why "we improved our Lighthouse score and rankings didn't move" is such a common complaint. The more accurate framing, and the one Google's own documentation has been consistent about for years, is that Core Web Vitals function as part of page experience — closer to a tie-breaker among pages that are already relevant to a query than a mechanism that overrides relevance and content quality outright.

Get the specifics current, because a lot of SEO advice still floating around is measuring the wrong thing: the three Core Web Vitals are Largest Contentful Paint (LCP, loading speed), Cumulative Layout Shift (CLS, visual stability), and Interaction to Next Paint (INP, responsiveness). INP formally replaced First Input Delay (FID) as the third Core Web Vital in March 2024. A site still being optimized against FID today is being optimized against a metric that no longer factors into the actual signal.

The published thresholds for "good" are specific: LCP at or under 2.5 seconds, CLS at or under 0.1, and INP at or under 200 milliseconds — each assessed at the 75th percentile of real visits, not a best-case load. That percentile detail matters more than it looks: a site can feel fast in a quick personal check and still fail its actual Core Web Vitals, because the 75th percentile gets dragged down by real-world conditions — older devices, weaker connections, uncached loads — that a single fast test on good office WiFi never encounters.

That's the real difference between field data and lab data, and it's the distinction that determines whether a Lighthouse score of 95 means anything for rankings. Lighthouse and PageSpeed Insights lab scores run one simulated load under controlled conditions. The Core Web Vitals that actually factor into search come from field data in the Chrome User Experience Report — real visits, real devices, aggregated over a rolling period. A page can score perfectly in a lab test and still fail its real-world Core Web Vitals if actual visitors are disproportionately on slower connections or older hardware the lab test never simulates.

Where Core Web Vitals do move outcomes, even without single-handedly moving rankings, is crawl budget and indexation, and conversion. A slow site consumes more of a crawler's allotted time per page, which matters most on larger sites where not every page gets recrawled promptly — a genuinely different mechanism than "faster page ranks higher," and one that shows up as slower indexation of new or updated content instead. Independent of any ranking effect at all, Core Web Vitals correlate directly with bounce rate and conversion rate — a slow or visually unstable page loses real visitors regardless of what position it holds in search results.

The honest verdict fits the bigger picture: Core Web Vitals are the Technical layer in a three-layer system — Technical, Topical, Trust — and fixing them removes a ceiling rather than raises a floor. A technically broken site caps what strong content and real trust signals can achieve on top of it, but a technically flawless page with thin or generic content still won't outrank a slightly slower page that actually answers the query better. Technical fixes also tend to show results fastest of the three layers, often visible in Search Console within weeks, which is exactly why it's the layer to fix first — not the layer expected to do all the work by itself.

It's also why Core Web Vitals get budgeted like a hard requirement during a build rather than measured after launch and patched later — a page that's fast by design doesn't need a performance sprint bolted on six months in. Auditing an existing site starts the same way: with real field data from actual visits, not a single lab score run once from a fast connection.