Core Web Vitals get treated two ways: either as a magic ranking lever that will fix flat traffic, or as a box-ticking exercise that doesn't matter much. Neither is accurate, and the confusion mostly comes from Google's own messaging shifting more than once since 2021. This article sorts out what the three Core Web Vitals metrics actually measure, how Google scores a page against them, where the evidence for a real business impact holds up, and where it doesn't. Core Web Vitals are three specific metrics: Largest Contentful Paint, Interaction to Next Paint, and Cumulative Layout Shift. Google's own definition on web.dev states each one measures a distinct aspect of user experience: LCP for loading, INP for interactivity, and CLS for visual stability. They don't evaluate content quality, keyword relevance, or anything a writer or strategist controls directly. They measure how a page feels to load and use. INP hasn't always been the interactivity metric. It replaced First Input Delay in March 2024, and the change wasn't cosmetic. FID only measured the delay before a browser started processing a single interaction; INP tracks responsiveness across every interaction during a visit, which makes it a stricter and often less forgiving number to hit, particularly on pages loaded with third-party scripts. Google doesn't grade a page once and move on. It classifies performance using real visitor data collected through the Chrome User Experience Report, and web.dev's own explanation of how the thresholds were set is specific about the method: a page passes a given metric only when at least 75% of real visits to that page meet the "good" threshold. That's the 75th percentile, not an average, which matters because an average can look fine while a meaningful slice of visitors, often the ones on older phones or slower connections, are having a genuinely poor experience the average hides. This is also why a Lighthouse score run once in a browser tab can look great while Search Console flags the same URL as "poor." Lighthouse produces lab data, generated under fixed, controlled conditions. Search Console and the CrUX report reflect field data, gathered from actual visits on actual devices and networks. The two numbers are answering different questions, and treating a good lab score as proof the field data will follow is one of the more common ways teams get blindsided. Here's where most articles either overstate or understate the case, and the honest answer sits in the middle. Google's own page experience documentation states there's no single page experience ranking signal; Core Web Vitals feed into a variety of signals that the core ranking systems weigh alongside everything else. That's a deliberately soft framing, and it followed a period where Google's messaging shifted from calling page experience a ranking "system" to clarifying it was a set of signals used by other systems, a distinction Google's Search Liaison had to walk back and re-explain in 2023 after it caused genuine confusion in the SEO industry. In practice, this means Core Web Vitals rarely decide a ranking outcome outright. Between two pages that are otherwise close in relevance and content depth, better field data can be the difference. Between a page with thin, generic content and better competitor content that happens to load a second slower, the content gap wins every time. Treating Core Web Vitals as a shortcut around weak content is a mistake; treating them as irrelevant in a genuinely close competitive field is a different mistake, and just as costly. Core Web Vitals get discussed as if they're a standalone discipline, and that framing causes most of the confusion around them. They're not separate from SEO, they're one input into it, sitting alongside content quality, crawlability, and the dozens of other factors covered in our breakdown of what SEO actually involves. Treating page speed work as disconnected from the rest of a site's technical health is how teams end up fixing LCP in isolation while a duplicate content problem or a crawl budget issue quietly caps the upside anyway. This is also why Core Web Vitals rarely show up as a standalone line item in a serious technical review. A proper technical SEO audit checks LCP, INP, and CLS as part of the same pass that covers indexability, internal linking, and structured data, because a page that loads fast but is missing a canonical tag, or one with excellent CLS but a thin content problem, is still going to underperform. Fixing performance metrics on their own, without that wider context, tends to produce a site that scores well in PageSpeed Insights and still doesn't move in search results, which is usually the moment a business concludes "Core Web Vitals don't work" when the actual issue was scope, not the metrics themselves. LCP is mostly a server and asset problem before it's a code problem. Slow server response times, render-blocking CSS and JavaScript loaded before the main content, and unoptimized hero images are the usual suspects, and they compound. Fixing one without the others often produces disappointing gains. INP is the hardest of the three to fix because it isn't about one moment, it's about every interaction across a visit. Long JavaScript tasks that block the browser's main thread are the primary cause, and the fix usually means breaking large scripts into smaller chunks and deferring anything that doesn't need to run immediately, which is genuinely developer work, not a plugin toggle. CLS is usually the most mechanically simple to fix and the easiest to overlook. Images and embeds without explicit width and height attributes, ads that inject into the layout after the surrounding content has already rendered, and web fonts that swap in and shift text are the common causes. None of these require deep architectural change, which is part of why CLS is often the first metric a site gets to "good." Page speed isn't only a user experience question. A slow server response time doesn't just cost human visitors, it throttles how much of a site Google is willing to crawl in a given session, a mechanic covered in more depth in our breakdown of why pages sometimes don't get indexed at all. A page can pass every content check and still sit in crawled longer than it should simply because the server it lives on is slow to respond. There's a related distinction worth keeping straight here too. A page can render perfectly and load fast for a human visitor while still being difficult for Googlebot to fully process, particularly when content depends on client-side JavaScript execution. That's a crawlability question rather than a Core Web Vitals one, and the two get confused often enough that we wrote a separate explainer on the actual difference between crawlability and indexability. The same mechanics that affect Googlebot's crawl efficiency affect the crawlers behind AI-generated search answers. A page that's slow to render or unstable to load is slower and more expensive for any crawler to process, human-facing search engine or otherwise. This is one of the areas where classic technical SEO and newer AI-search optimization genuinely overlap rather than compete, something we go into further in our guide to Google AI Mode optimization. There isn't yet a published, verifiable study isolating Core Web Vitals as a direct citation factor in AI Overviews or AI Mode specifically, so it's worth stating plainly rather than guessing: the connection is mechanical (faster, more stable pages are easier for any automated system to process) rather than a confirmed, documented ranking signal for AI answers the way LCP is documented for classic search. Chasing a perfect Lighthouse score in a lab environment while ignoring what Search Console's field data actually shows for real visitors. Fixing LCP by compressing one hero image while leaving render-blocking scripts untouched, then concluding "Core Web Vitals don't work." Assuming a fast desktop experience means a fast mobile one. Field data is measured and reported separately for each, and mobile scores are frequently worse. Treating Core Web Vitals work as a way to compensate for thin or generic content, when the ranking evidence points the other way: it's a tiebreaker among comparable content, not a substitute for it. Fixing CLS by removing ads or dynamic content entirely instead of reserving space for it, trading a real business need for a metric improvement that didn't need to cost that much. Search Console's Core Web Vitals report is the most direct starting point, since it groups URLs by status and shows exactly which metric is failing for which group of pages. PageSpeed Insights gives both the field data (when enough traffic exists for a URL to have CrUX data) and a lab-based Lighthouse score side by side, which makes the lab-versus-field gap visible on the same screen rather than something to reconcile across two separate tools. For a site without enough traffic to generate CrUX field data on individual pages, Google falls back to origin-level data covering the whole domain, which is less precise but still usable as a general health check.What the Three Metrics Actually Measure
How Google Actually Scores a Page
Is It Actually a Ranking Factor
Where This Sits Inside the Bigger SEO Picture
What Actually Moves Each Metric
Where This Connects to Crawling and Indexing
Does This Matter for AI Search Too
Common Mistakes
How to Check Where a Site Actually Stands
Frequently Asked Questions
What are the three Core Web Vitals?
Largest Contentful Paint (LCP), which measures loading speed, Interaction to Next Paint (INP), which measures responsiveness, and Cumulative Layout Shift (CLS), which measures visual stability.What is a good LCP score?
Under 2.5 seconds, measured at the 75th percentile of real visits to a page.What replaced First Input Delay?
Interaction to Next Paint replaced First Input Delay as the official responsiveness metric in March 2024. INP measures the full range of interactions during a visit rather than just the first one.Are Core Web Vitals a direct Google ranking factor?
They're one of several signals Google's ranking systems use, not a standalone ranking system, and Google has been explicit that there's no single page experience signal. They matter more as a tiebreaker between pages of similar content quality than as a factor that overrides relevance.Why does my Lighthouse score not match my Search Console Core Web Vitals report?
Lighthouse produces lab data collected under fixed test conditions. Search Console reflects field data from actual visitor sessions on real devices and networks, and the two frequently disagree, especially for sites with a wide range of visitor device quality.Does improving Core Web Vitals actually increase sales or conversions?
Documented case studies, including a controlled A/B test by Vodafone Italy, have shown measurable increases in sales, session duration, and ad revenue tied directly to Core Web Vitals improvements, independent of any change in rankings.What's the hardest Core Web Vitals metric to fix?
INP is usually the most technically demanding, since it requires identifying and breaking up long JavaScript tasks across the entire page, rather than a single fix like compressing an image.Do Core Web Vitals affect mobile and desktop the same way?
No. Google measures and reports them separately for mobile and desktop, and mobile scores are typically worse due to slower networks and less processing power, so both need to be checked independently.Can a page have good Core Web Vitals and still rank poorly?
Yes. Good technical performance doesn't compensate for weak content, poor relevance, or a lack of topical authority. Core Web Vitals affect the margin, not the baseline.Do Core Web Vitals matter for AI search visibility?
There's no confirmed, published ranking mechanism tying Core Web Vitals directly to AI Overviews or AI Mode citation. The plausible connection is that faster, more stable pages are easier for any automated crawler to process, which matters for accessibility to AI crawlers even without a documented scoring link.




