Core Web Vitals became a ranking signal in 2021. Since then, Google has refined how they're measured, expanded the data sources they pull from, and quietly shifted which thresholds trigger ranking boosts. Five years in, many teams are still optimizing for the wrong things — chasing metric names without understanding the ranking mechanics behind them.
Core Web Vitals are a set of field-measured user experience metrics that Google uses as a ranking signal. The key word is field-measured: these aren't lab scores from Lighthouse. They come from real Chrome users in the Chrome User Experience Report (CrUX), aggregated at the URL and origin level over a rolling 28-day window.
This distinction has major practical consequences. A page can score 95 on Lighthouse and still fail CWV thresholds if real users on slow connections or low-end Android devices experience poor loading. Conversely, a page can have mediocre Lighthouse scores and still pass CWV if the overwhelming majority of your actual users are on fast connections and modern hardware.
Core Web Vitals are not the only page experience signal Google uses, and they're not a replacement for content quality. Google has consistently said that great content with poor CWV scores can still outrank thin content with perfect scores. But in competitive SERPs — where topical authority and backlink profiles are roughly equivalent between competitors — CWV becomes a meaningful differentiator.
The three signals that constitute Core Web Vitals are LCP (Largest Contentful Paint), INP (Interaction to Next Paint), and CLS (Cumulative Layout Shift). Each measures a distinct dimension of the user experience: loading, interactivity, and visual stability.
The most significant 2026 update was the full deprecation of FID (First Input Delay) in favor of INP, which was completed in March 2024 but whose ranking weight was incrementally increased through 2025 and into 2026. Many sites that had acceptable FID scores are discovering that INP surfaces entirely different performance issues — particularly in JavaScript-heavy single-page applications.
Google also updated the CrUX data collection methodology to weight mobile data more heavily in origin-level scoring. If your site has a strong desktop experience but poor mobile performance, your overall CWV score is now more likely to reflect the mobile reality. This is significant: many enterprise sites have heavily optimized desktop experiences while neglecting the performance characteristics that matter on mid-range Android devices in markets outside North America and Western Europe.
Additionally, the "good" threshold for LCP tightened slightly. Pages that were previously in the "needs improvement" band with LCP scores between 2.5–3.5 seconds now have a narrower path to the "good" designation. If your LCP is sitting at 2.6–3.0 seconds, you're closer to the edge than before.
Largest Contentful Paint measures when the largest visible element in the viewport finishes rendering. For most marketing sites and blogs, this is a hero image or a large heading. For e-commerce pages, it's frequently a product image. For news sites, it's often a featured image or article heading.
LCP is the CWV metric with the strongest demonstrated correlation to ranking outcomes in competitive testing. The target threshold is under 2.5 seconds at the 75th percentile of real user experiences. That "75th percentile" qualifier is important: you're not optimizing for your average user, but for the user at the 75th percentile of slowness among all your visitors.
The most impactful LCP improvements, in order of typical ROI:
<link rel="preload"> and ensure no render-blocking scripts sit between the HTML parser and the image request.srcset, and avoid loading a 2400px desktop image on a 390px mobile viewport.Interaction to Next Paint replaced FID as the interactivity CWV in 2024. Where FID only measured the delay before the browser could start handling your first interaction, INP measures the full responsiveness of every interaction across the page's lifetime — clicks, taps, and keyboard inputs. The target is under 200ms.
INP is the metric where single-page applications most frequently fail. The core problem is long tasks: JavaScript tasks that run for more than 50ms on the main thread, blocking the browser from responding to user input. Modern React, Vue, and Angular apps routinely produce long tasks from component hydration, route transitions, and complex state updates.
The most effective INP fixes are:
scheduler.yield() or setTimeout(fn, 0) to yield control back to the browser during heavy processing. React's concurrent features, including startTransition, are designed specifically to prevent state updates from blocking input handling.async/defer or defer them until after the user's first interaction.Cumulative Layout Shift measures how much page content moves unexpectedly during the page's lifespan. A CLS score above 0.1 means users are experiencing visible layout instability — buttons that jump away as they're about to click, text that reflows when an ad loads, images that push content down when they render.
CLS might be the most underrated metric from a conversion standpoint. Unlike LCP and INP, which users consciously perceive as "slow," CLS creates frustration that users often attribute to the site being "buggy" or "unreliable." They click the wrong thing, they lose their place in a form, and they leave — frequently without understanding why.
The three most common CLS sources are: images and media without explicit width/height attributes, dynamically injected content above existing content (ads, cookie banners, notification bars), and late-loading web fonts that cause text reflow. All three are straightforward to fix. Add explicit dimensions to every media element. Reserve space for dynamic content with min-height on containers. Use font-display: optional or font-display: swap with size-adjusted fallbacks to eliminate font reflow.
If you're prioritizing CWV work, here's the order that delivers the most ranking impact per hour of engineering time:
Before investing in any of these, establish your current baseline using CrUX data in Google Search Console's Core Web Vitals report. Lab data from Lighthouse is useful for debugging but should never be the final word on whether your CWV is "fixed" — only real field data confirms that real users are experiencing improvement.