Core Web Vitals are three field metrics: Largest Contentful Paint for loading, Interaction to Next Paint for responsiveness, and Cumulative Layout Shift for visual stability. INP fully replaced First Input Delay in March 2024, so any guide still listing FID is out of date.
The detail most coverage skips is how you are graded. Google uses the Chrome User Experience Report at the 75th percentile across a rolling 28 day window. That means the score reflects the experience of a user having a worse than average time, not the comfortable middle, and it updates slowly.
Field Data and Lab Data Are Not the Same Thing
This distinction resolves most confusion about why scores disagree between tools.
Lab data comes from a simulated test under controlled conditions. Lighthouse produces it. It is repeatable, immediate, and useful for diagnosing why something is slow.
Field data comes from real Chrome users on real devices and connections. CrUX produces it, Search Console reports it, and it is what determines the ranking relevant score.
It is entirely possible to score 100 in Lighthouse and fail Core Web Vitals, because your real users are on slower phones and worse connections than the simulation assumes. When the two disagree, field data is the one that counts and lab data is the one that tells you why.
INP Is the Hardest to Pass and the Most Poorly Understood
Reported figures put around 43 percent of websites still failing the 200 millisecond INP threshold in 2026, making it the metric most sites fail.
INP measures the delay between a user interacting and the browser painting a response. Unlike its predecessor, which only measured the first interaction, INP considers interactions throughout the page lifetime and reports close to the worst one.
The cause is almost always JavaScript occupying the main thread. When a user taps and the main thread is busy executing a script, the browser cannot respond until it finishes.
What actually fixes it: breaking long tasks into smaller chunks so the browser can interrupt them, deferring work that does not need to happen during interaction, and reducing third party script weight. That last one is frequently the largest contributor and the least examined.
Third Party Scripts Are the Common Cause Nobody Audits
Tag manager, advertising pixels, chat widget, heatmap tool, A/B testing, review embed, cookie consent, captcha, session recording. Each was approved individually and each seemed reasonable.
Together they can dominate main thread activity, and a periodic audit of third party scripts is frequently more productive than advanced framework optimisation. The uncomfortable part is that removing them requires arguing with whoever owns each one.
The measurement worth taking to that argument is the main thread time attributable to each script, which Chrome DevTools reports directly. A chat widget costing 400 milliseconds of blocking time on mobile is a specific, arguable number rather than a general complaint about page weight.
LCP Is Usually an Image Problem
Largest Contentful Paint targets under 2.5 seconds and measures when the largest visible element renders. That element is typically a hero image, a featured image, or a large heading.
The usual causes are unoptimised images, slow server response, and render blocking resources in the head.
Image handling connects directly to the on page fundamentals covered in the on page SEO guide, where explicit dimensions serve both layout stability and accessibility.
Images first because it is the cheapest fix with the widest effect. Modern formats, appropriate dimensions rather than serving a 4000 pixel wide file into a 800 pixel container, and preloading the LCP image specifically so the browser does not discover it late.
Lazy loading is worth a caution. Applying it to the LCP image itself delays exactly the thing being measured, and that mistake is common on templates where lazy loading was applied globally.
CLS Is the Cheapest to Fix
Cumulative Layout Shift targets under 0.1 and measures elements moving during load. It is the most immediately frustrating metric for users, since it causes mistaken clicks, and it is usually the least expensive to resolve.
Explicit width and height attributes on every image and video, so the browser reserves space before the asset arrives. Reserved space for ad slots and embeds. Font loading strategies that avoid a visible swap. Avoiding content injected above existing content after render, which is what cookie banners and promotional bars frequently do.
If you are starting somewhere, start here. The fixes are mechanical, they rarely require architectural change, and the user experience improvement is immediately visible.
Mobile Is What Gets Ranked
Reported pass rates put desktop origins around 56 percent and mobile around 48 percent, a gap that has narrowed from wider figures in earlier years but persists.
The mobile specific dimension of this is covered in the mobile SEO guide. Phones run slower processors on worse connections, which is why the gap exists. Google indexes mobile first, which is why the mobile number is the one that matters.
Check the two separately in Search Console rather than reading a blended figure. A site passing on desktop and failing on mobile is failing, and reporting an average conceals it.
Test More Than the Homepage
The common trap is running PageSpeed Insights on a homepage, getting an acceptable score, and concluding the site is healthy.
Category pages, product pages, forms, blog articles, and paid landing pages behave completely differently because they load different assets and run different scripts. Search Console groups URLs by similarity precisely because the unit that fails is usually a template rather than a page.
Audit one representative URL per template, and fix at template level since that is where the problem lives.
Fixes Take 28 Days to Show Up
Because CrUX is a rolling 28 day average, a deployed fix does not appear immediately in the data Google scores you on. The improvement enters the window gradually.
The practical consequence is patience. Teams frequently ship a fix, check the field data a week later, see little movement, and revert or add further changes on top. Wait for the window to turn over before judging whether a change worked.
Lab data updates immediately, which makes it the right tool for confirming a fix did what you intended before the field data catches up.
How Much Does This Actually Move Rankings
My position, and I think the evidence supports it: Core Web Vitals function as a tie breaker rather than a primary factor. Where two pages are comparable on content and authority, the faster one wins. Where they are not comparable, speed does not close the gap.
Independent tracking has found pages in top positions show measurably higher pass rates than pages ranking lower, which is consistent with a tie breaker effect and also consistent with better resourced sites doing more things well generally.
The practical read: a site failing thresholds should fix them, because the ceiling is real. A site passing all three should stop optimising and spend the time on content, per the prioritisation in the technical audit guide. Chasing sub 150 millisecond INP when you already pass at 180 is not where remaining value is.
The Indexing Side Effect
Heavy JavaScript affects more than user experience metrics. Where rendering is deferred, content can be indexed late or incompletely, which is the situation covered in the rendering guide.
Reducing JavaScript weight improves INP and improves indexing reliability at the same time, which makes it a better investment than the CWV number alone suggests.
Which Tools for Which Job
Search Console Core Web Vitals report for field data on your actual indexed URLs, grouped by template. This is the closest thing to what Google scores.
PageSpeed Insights for a single URL, combining CrUX field data where sufficient traffic exists with a lab run for diagnosis.
Chrome DevTools performance panel for deep debugging, where you can see which specific script or resource is blocking.
The Search Console guide covers reading the report properly, including why the grouping matters more than individual URLs.
Where Speed Meets Everything Else
Performance work also affects whether AI crawlers successfully fetch and parse your pages, since timeouts and heavy rendering produce failures there too. The crawlers guide covers that dimension.
The NotionCue AI Crawler Audit checks what crawlers actually receive, which catches cases where a page renders acceptably for users and fails for automated fetching.
Start your free NotionCue trial and check your heaviest templates. Pages that are slow for users are frequently incomplete for crawlers, and the second problem is invisible in any performance tool.
Before optimising anything, open Search Console, filter Core Web Vitals to mobile, and look at which URL groups fail. That grouping tells you which template to fix, which is a different and much shorter list than which pages are slow.
Common Questions
Why does PageSpeed Insights disagree with Search Console?
PageSpeed shows a single URL and includes lab data. Search Console shows field data grouped across similar URLs. They measure different things and both are correct for what they measure.
Does a perfect score guarantee better rankings?
No. Core Web Vitals are one input among many and they behave as a tie breaker. A perfect score on thin content does not outrank a slower page with better content.
What if my site has too little traffic for field data?
CrUX requires sufficient traffic to report. Below that threshold you will see lab data only, which means using Lighthouse as a proxy and accepting that you cannot verify the field experience directly.