Core Web Vitals have been part of Google’s ranking signals for a while now, but there’s still a lot of confusion about what they measure, how much weight they actually carry, and which fixes genuinely move them. Every year a fresh wave of “Core Web Vitals checklists” circulates that mix real fixes with cargo-cult advice that does very little. Here’s where things actually stand.
The three metrics, briefly
Largest Contentful Paint (LCP) measures how long it takes for the largest visible element — usually a hero image, banner or block of text — to render. Google’s threshold for “good” is 2.5 seconds or less.
Interaction to Next Paint (INP) measures responsiveness: how long the page takes to visibly respond after someone clicks, taps or types. This replaced First Input Delay as an official Core Web Vital, and it’s a stricter, more representative measure of real interaction sluggishness. The target is 200 milliseconds or less.
Cumulative Layout Shift (CLS) measures visual stability — how much content unexpectedly jumps around as a page loads. The target is a score of 0.1 or less.
How much this actually affects rankings
Core Web Vitals are one of many ranking signals, and Google has been fairly consistent that content relevance and quality outweigh page experience signals in most cases. A page with brilliant, exactly-relevant content and mediocre Core Web Vitals will usually still beat a fast, technically pristine page with thin or generic content.
Where Core Web Vitals genuinely matter is at the margins: when two pages are otherwise closely matched on relevance and authority, the faster, more stable one has a real edge. They also matter enormously for conversion rate, bounce rate and general user trust, independent of any ranking effect — which is usually reason enough to fix them.
What actually moves LCP
- Compress and correctly size hero images — serving a 4000px-wide image into an 800px container is still one of the most common causes of a slow LCP.
- Use modern formats (WebP or AVIF) rather than uncompressed JPEG or PNG for anything large.
- Preload the specific hero image or font rather than letting the browser discover it deep in the render chain.
- Reduce or defer render-blocking CSS and JavaScript that delays the main content from painting.
- Choose hosting and a CDN that keeps Time to First Byte low — no amount of front-end optimisation fixes a slow server response.
What actually moves INP
This is the metric most sites genuinely struggle with, because it’s about JavaScript execution, not asset size. Long-running scripts that block the main thread — heavy third-party widgets, poorly optimised tracking pixels, bloated page builders that output excessive DOM nodes — are the usual culprits.
- Audit and remove third-party scripts that aren’t earning their keep; every chat widget, tracking pixel and marketing tag adds real, measurable interaction cost.
- Break up long JavaScript tasks so the browser’s main thread isn’t blocked for hundreds of milliseconds at a time.
- Avoid excessive DOM complexity — page builder plugins that output deeply nested wrapper divs for every element make every interaction more expensive to process.
- Load non-critical JavaScript after the page is interactive, not before.
What actually moves CLS
- Always set explicit width and height attributes (or aspect-ratio in CSS) on images and embeds, so the browser reserves space before the asset loads.
- Reserve space for ads, embeds and dynamically injected content rather than letting them push the layout down once they load.
- Be careful with web fonts — a fallback font that renders at a different size to the final web font causes a visible reflow once the real font loads (use
font-display: optionalor matched fallback metrics to avoid it). - Avoid inserting new content above existing content after the initial load, which is the single most common cause of a poor CLS score.
What to stop worrying about
Chasing a perfect 100 in Lighthouse’s lab-based score is not the same thing as good real-world Core Web Vitals — Google’s ranking signal is based on real user field data (CrUX), not synthetic lab tests, and the two can diverge significantly. Equally, endlessly tweaking server response headers or minor caching rules rarely moves the needle if the real bottleneck is a 3MB unoptimised hero image or a bloated third-party script.
The bottom line
Core Web Vitals are a real, if secondary, ranking factor — and a genuinely important conversion factor regardless of rankings. Fix the handful of things that actually matter (image sizing, third-party script bloat, and reserved layout space) rather than chasing a perfect lab score, and both the metrics and the site’s real-world performance tend to improve together.