Google doesn’t just care about what’s on your website anymore — it cares about how your website feels to use. Core Web Vitals are a set of specific metrics that Google uses to evaluate the real-world user experience of your pages. They measure loading performance, interactivity, and visual stability, and they directly influence your search rankings. If your site fails Google’s Core Web Vitals assessment, you’re leaving both rankings and revenue on the table.

This guide breaks down each Core Web Vital metric, explains what Google considers a passing score, and gives you concrete steps to fix the issues dragging your site down. If you’ve already been working on improving page speed for better SEO rankings, Core Web Vitals are the framework that ties all those efforts together.

What Are Core Web Vitals?

Core Web Vitals are three specific metrics that Google has identified as essential to a good user experience on the web. They’re part of Google’s broader “page experience” ranking signals, and they measure aspects of your site that real users actually notice and care about. As of 2024, the three Core Web Vitals are:

  • Largest Contentful Paint (LCP): Measures loading performance — how quickly the main content of a page becomes visible.
  • Interaction to Next Paint (INP): Measures interactivity and responsiveness — how quickly the page responds when users click, tap, or type. (INP replaced First Input Delay in March 2024.)
  • Cumulative Layout Shift (CLS): Measures visual stability — how much the page layout shifts unexpectedly as it loads.

Each metric has specific thresholds that determine whether your page passes (“Good”), needs improvement, or fails (“Poor”). Google evaluates these metrics using real-world data from Chrome users (the Chrome User Experience Report, or CrUX data), which means your scores reflect actual visitor experiences — not just lab simulations.

Largest Contentful Paint (LCP): Making Content Appear Fast

LCP measures when the largest piece of content in the viewport — typically a hero image, featured video, or large text block — finishes rendering. It’s the metric that most closely corresponds to a user’s perception of “this page is loaded.”

What’s a Passing LCP Score?

  • Good: 2.5 seconds or less
  • Needs Improvement: 2.5 to 4.0 seconds
  • Poor: More than 4.0 seconds

Common Causes of Poor LCP

Slow LCP usually comes from one or more of these issues: slow server response times (high Time to First Byte), render-blocking JavaScript and CSS, slow resource load times for images and fonts, and client-side rendering that delays content visibility. The LCP element itself matters too — if your largest content element is a massive unoptimized image, that’s your bottleneck.

How to Fix LCP Issues

Start by identifying your LCP element using PageSpeed Insights or Chrome DevTools. Once you know what’s slow, apply these fixes:

  • Optimize your server response time. Upgrade hosting if needed, implement server-side caching, and use a CDN to serve content from locations closer to your users. Aim for a Time to First Byte (TTFB) under 800 milliseconds.
  • Optimize images aggressively. Use modern formats (WebP or AVIF), implement responsive images with srcset, properly size images for their display dimensions, and apply lazy loading to below-the-fold images. For your LCP image specifically, preload it with <link rel="preload"> and do NOT lazy-load it. Check out our detailed guide on image optimization for web performance for more techniques.
  • Eliminate render-blocking resources. Defer non-critical JavaScript with the defer or async attribute. Inline critical CSS and load the rest asynchronously. Remove any unused CSS and JavaScript from your pages.
  • Preload critical resources. Use <link rel="preload"> for fonts, hero images, and any critical above-the-fold assets so the browser fetches them earlier in the loading process.
  • Avoid client-side rendering for critical content. If you’re using a JavaScript framework, implement server-side rendering (SSR) or static site generation (SSG) so the main content doesn’t depend on JavaScript execution to appear.

Interaction to Next Paint (INP): Responsive to Every Click

INP replaced First Input Delay (FID) as a Core Web Vital in March 2024, and it’s a much more comprehensive metric. While FID only measured the delay of the first interaction, INP measures the responsiveness of all interactions throughout the entire page lifecycle and reports the worst one (with some outlier filtering). This means your page needs to be responsive not just on first load, but continuously as users interact with it.

What’s a Passing INP Score?

  • Good: 200 milliseconds or less
  • Needs Improvement: 200 to 500 milliseconds
  • Poor: More than 500 milliseconds

Common Causes of Poor INP

INP problems typically stem from JavaScript that blocks the main thread. Long-running scripts, heavy third-party code (analytics, chat widgets, ad scripts), complex DOM manipulations, and inefficient event handlers all contribute to sluggish interactivity. The more JavaScript your page executes, the more opportunities there are for interactions to be delayed.

How to Fix INP Issues

  • Break up long tasks. Any JavaScript task running longer than 50 milliseconds can block the main thread. Use requestAnimationFrame, setTimeout, or the newer scheduler.yield() to break large tasks into smaller chunks, giving the browser opportunities to process user input between them.
  • Reduce JavaScript bundle size. Audit your JavaScript with tools like Chrome DevTools Coverage panel. Remove unused code, split large bundles with code splitting, and lazy-load non-critical scripts. Every kilobyte of JavaScript that doesn’t need to execute is JavaScript that can’t block your interactions.
  • Minimize third-party script impact. Third-party scripts are often the biggest INP offenders. Load them asynchronously, defer their execution, or use a tag manager with delayed loading. Consider whether each third-party script is truly necessary — every one you remove improves responsiveness.
  • Optimize event handlers. Keep event handler code lean and fast. Avoid layout thrashing (reading then writing DOM properties in a loop), debounce handlers for frequent events like scrolling and resizing, and use CSS for animations instead of JavaScript wherever possible.
  • Reduce DOM size. Pages with very large DOM trees (over 1,500 elements) are inherently slower to interact with because every DOM manipulation requires more processing. Simplify your HTML structure, remove unnecessary wrapper elements, and use virtualization for long lists.

Cumulative Layout Shift (CLS): Keeping Things Visually Stable

CLS measures unexpected layout shifts — those annoying moments when you’re about to click a button and the page suddenly moves, causing you to click something else entirely. It’s calculated by multiplying the impact fraction (how much of the viewport shifted) by the distance fraction (how far it moved). CLS captures all unexpected shifts throughout the page’s life and reports the largest burst of shifts within a short window.

What’s a Passing CLS Score?

  • Good: 0.1 or less
  • Needs Improvement: 0.1 to 0.25
  • Poor: More than 0.25

Common Causes of Poor CLS

Layout shifts happen when elements load without reserved space. The most common culprits are images and videos without defined dimensions, dynamically injected content (ads, banners, cookie notices), web fonts causing text reflow (FOIT/FOUT), and content inserted above existing content by JavaScript. If your understanding of technical SEO fundamentals is solid, you’ll recognize many of these as issues that affect both user experience and crawlability.

How to Fix CLS Issues

  • Always include width and height attributes on images and videos. This allows the browser to reserve the correct amount of space before the resource loads. Use CSS aspect-ratio for responsive layouts where fixed dimensions aren’t practical.
  • Reserve space for dynamic content. If you have ad slots, banner areas, or dynamically loaded widgets, define their dimensions in CSS with min-height so the page layout doesn’t jump when they load. Use skeleton screens or placeholder elements for content that loads asynchronously.
  • Handle web fonts carefully. Use font-display: swap with a closely matched fallback font to minimize visible text reflow. Better yet, use font-display: optional for non-critical fonts — this prevents layout shift entirely by falling back to the system font if the custom font doesn’t load quickly enough. Preload your key fonts to speed up their availability.
  • Never insert content above existing content. Unless it’s in response to a user interaction (like clicking a “show more” button), don’t inject content above what the user is currently viewing. This includes top banners, notification bars, and dynamically expanded sections.
  • Use CSS contain and content-visibility. The CSS contain property limits the impact of layout changes within an element, preventing them from causing shifts in the rest of the page. The content-visibility: auto property can improve rendering performance for off-screen content while maintaining correct layout.

How to Measure Your Core Web Vitals

Google provides multiple tools for measuring Core Web Vitals, each serving a slightly different purpose:

  • Google Search Console: The Core Web Vitals report shows how your pages perform based on real-world CrUX data. This is the definitive source for understanding whether Google considers your pages as passing.
  • PageSpeed Insights: Provides both field data (real-user metrics from CrUX) and lab data (simulated tests). Use this for page-by-page analysis and specific optimization recommendations.
  • Chrome DevTools: The Performance panel lets you simulate and debug Core Web Vitals issues in real time. Essential for identifying specific elements causing problems.
  • Lighthouse: Runs lab-based audits and provides detailed recommendations. Good for development and testing, but remember that lab scores may differ from real-world field data.
  • Web Vitals Chrome Extension: Displays Core Web Vitals in real time as you browse your site. Great for quick spot-checking during development and QA.

For the most accurate picture, always prioritize field data from Google Search Console over lab data. Field data reflects actual user experiences across different devices, network speeds, and conditions that lab tests can’t fully replicate.

A Prioritized Action Plan for Passing

If your site is currently failing Core Web Vitals, here’s a prioritized approach to tackle it efficiently:

  • Week 1 — Audit and identify: Run every key page through PageSpeed Insights. Document which pages fail which metrics. Identify the LCP element, the worst interactions for INP, and the biggest layout shift sources for CLS on each failing page.
  • Week 2 — Quick fixes: Add image dimensions, preload LCP images, defer non-critical JavaScript, and reserve space for ads and dynamic content. These changes alone can move many pages from “Needs Improvement” to “Good.”
  • Week 3 — Infrastructure improvements: Implement a CDN if you haven’t already, optimize your hosting and server-side caching, and audit/remove unnecessary third-party scripts. Consider switching to a faster WordPress theme if your current one has structural performance issues. Our guide on how to fix a slow website covers these infrastructure improvements in detail.
  • Week 4 — Advanced optimization: Implement font optimization strategies, set up code splitting and lazy loading for JavaScript, optimize CSS delivery, and address any remaining INP issues with main thread optimization.
  • Ongoing: Monitor your Search Console Core Web Vitals report weekly. New issues can emerge from content updates, plugin changes, or third-party script updates. Set up alerts for any pages that regress.

Frequently Asked Questions

How much do Core Web Vitals actually affect rankings?

Core Web Vitals are a confirmed ranking factor, but they’re one of many signals. Google has described page experience as a “tiebreaker” — when two pages have similar content relevance, the one with better Core Web Vitals will rank higher. That said, fixing Core Web Vitals often improves user engagement metrics (lower bounce rate, higher conversions) which can have indirect ranking benefits far beyond the direct signal.

Do I need to pass on both mobile and desktop?

Google evaluates mobile and desktop separately. Since Google primarily uses mobile-first indexing, mobile scores are generally more important for rankings. However, you should aim to pass on both, especially if you have significant desktop traffic. Many issues that affect mobile (like large images and heavy JavaScript) also impact desktop, so fixes tend to improve both.

What replaced First Input Delay (FID)?

Interaction to Next Paint (INP) replaced FID as a Core Web Vital in March 2024. INP is a more comprehensive metric because it measures all interactions throughout a page’s lifecycle, not just the first one. Most sites that passed FID easily may find INP more challenging because it captures responsiveness issues that occur after initial page load.

How long does it take for improvements to reflect in Search Console?

CrUX data in Search Console is based on a rolling 28-day average of real user metrics. After making improvements, you’ll typically start seeing changes in your Search Console report within 2–4 weeks. Be patient — the data needs enough user visits after your changes to replace the older metrics in the rolling window.

Get Your Site Performing at Its Best

Core Web Vitals aren’t just a box to check for Google — they represent genuine improvements to how your visitors experience your site. Faster loading, responsive interactions, and stable layouts make your site more pleasant to use, which translates to more engagement, more trust, and more conversions. If your site is struggling with Core Web Vitals and you want expert help diagnosing and fixing the issues, book a free performance audit with our team. We’ll pinpoint exactly what’s holding your site back and create a roadmap to get you passing with flying colors.