Core Web Vitals Pillar Guide schedule 20 min read

Core Web Vitals: The Complete Guide
(LCP, INP, CLS)

Core Web Vitals are Google's user-experience ranking signals. Getting them right directly affects your position in search results — and your users' experience. This guide covers what each metric measures, how to diagnose problems, and the fixes that actually move the needle.

update Updated August 2025 · By David Kim | Web Performance Lead
Core Web Vitals Cover
Definition

Core Web Vitals are three user-experience metrics that Google uses as ranking signals: Largest Contentful Paint (LCP), which measures loading speed; Interaction to Next Paint (INP), which measures interactivity; and Cumulative Layout Shift (CLS), which measures visual stability. Google collects these from real users via Chrome and publishes the data in the Chrome User Experience Report (CrUX).

Why Core Web Vitals Matter for SEO

Core Web Vitals became a confirmed Google ranking signal in May 2021, when the Page Experience update rolled out. Since then, Google has continued to increase their weight in ranking algorithms and has retired the older Page Experience signals in favor of CWV-centric measurement.

In March 2024, Google replaced First Input Delay (FID) with Interaction to Next Paint (INP) as the interactivity metric — a significant change that caught many teams off guard. Sites that had optimized for FID discovered their INP scores were substantially worse, because INP measures the full cost of all interactions, not just the first one.

The direct ranking impact of Core Web Vitals is real but nuanced. Google has confirmed it is a tiebreaker signal, not a dominant factor — a page with poor CWV but excellent content will generally outrank a page with perfect CWV and poor content. But in competitive SERPs where content quality is similar across competitors, CWV becomes the differentiator.

The Three Core Web Vitals at a Glance

LCP
Largest Contentful Paint
Loading
Good: ≤ 2.5s
INP
Interaction to Next Paint
Interactivity
Good: ≤ 200ms
CLS
Cumulative Layout Shift
Visual Stability
Good: ≤ 0.1

Largest Contentful Paint (LCP)

LCP measures how long it takes for the largest visible element in the viewport to finish loading. The "largest element" is typically a hero image, a large text block, or a video poster frame. LCP represents the moment when the page's main content feels loaded to the user.

What Causes Poor LCP

  • Slow server response times (TTFB). If the server takes more than 600ms to respond, LCP will almost certainly be poor regardless of other optimizations. Use a CDN, optimize server-side rendering, and consider edge caching.
  • Render-blocking resources. CSS and JavaScript in the <head> that block the browser from painting the page. Use defer or async for non-critical scripts; inline critical CSS.
  • Slow-loading images. The LCP element is most commonly an image. If it's not preloaded, not properly sized, or served without modern formats like WebP/AVIF, it will be slow.
  • Client-side rendering. If the LCP element is rendered by JavaScript, the browser can't paint it until the JS has downloaded, parsed, and executed. Server-side rendering or static generation dramatically improves LCP for JS-heavy pages.

How to Fix LCP

  • Add <link rel="preload" as="image"> for the LCP image so the browser fetches it as early as possible.
  • Ensure the LCP image has explicit width and height attributes and uses modern formats (WebP or AVIF).
  • Move critical images out of JavaScript and into static HTML so they're discoverable by the browser's preload scanner.
  • Target Time to First Byte (TTFB) < 600ms. Use a CDN with edge caching for static assets and server-rendered HTML.
  • Remove or defer render-blocking CSS and JavaScript that aren't needed for the initial view.
speed Real-World Audit Log: INP & LCP Remediation

Case Study: Fixing Main-Thread Bottlenecks Reduced INP from 480ms to 95ms

By breaking up long tasks (> 50ms) using scheduler.yield() and preloading hero WebP images, an enterprise e-commerce platform improved its 75th percentile INP score from Poor to Good across 45,000 mobile page views.

Mobile Pageviews
45,000
Original INP
480 ms
Post-Fix INP
95 ms

Interaction to Next Paint (INP)

INP measures the responsiveness of a page to user interactions — clicks, taps, and keyboard input. It captures the longest interaction delay observed during an entire page visit (excluding outliers), not just the first interaction. A good INP score is 200ms or less.

INP replaced FID (First Input Delay) as a Core Web Vital in March 2024. The change was significant: FID only measured the delay before the browser started processing an interaction. INP measures the full time from interaction to the next paint update — including the time spent executing event handlers and the time to render the response.

What Causes Poor INP

  • Long tasks on the main thread. Any JavaScript that blocks the main thread for more than 50ms is a long task. Long tasks prevent the browser from responding to user input. Common causes: large JavaScript bundles, synchronous third-party scripts, and complex event handlers.
  • Heavy event handlers. Handlers that trigger large DOM updates, complex layout recalculations, or synchronous network requests will delay the next paint.
  • Third-party scripts. Analytics, chat widgets, and advertising scripts frequently run on the main thread and cause INP regressions.
  • Inefficient React/Vue/Angular components. Framework re-renders triggered by state changes can produce expensive updates. Memoization, virtualization, and careful state management are the main mitigations.

How to Fix INP

  • Profile interactions with Chrome DevTools → Performance tab. Identify long tasks during interaction sequences.
  • Break long tasks using scheduler.yield() or setTimeout(fn, 0) to give the browser time to paint between chunks of work.
  • Move expensive computation off the main thread using Web Workers.
  • Defer non-critical third-party scripts until after the page is interactive. Load them with async and consider loading behind a user interaction (e.g., the chat widget only when the chat button is clicked).
  • Use requestAnimationFrame for visual updates to ensure they're batched correctly with the browser's rendering pipeline.

Cumulative Layout Shift (CLS)

CLS measures visual stability — how much page content unexpectedly moves as the page loads. It's scored as a cumulative measure of all layout shifts that occur throughout a session, weighted by the size and distance of each shift. A CLS score of 0.1 or less is considered good.

Layout shifts are frustrating to users because they cause mis-clicks: you're about to tap a button, content shifts, and you tap the wrong thing. Google considers this a direct measure of user experience quality.

What Causes Poor CLS

  • Images without explicit dimensions. If an image tag doesn't have width and height attributes, the browser doesn't know how much space to reserve. When the image loads, everything below it shifts.
  • Dynamically injected ads and embeds. Ad slots that load after the initial render push content down. Reserving space with min-height prevents the shift.
  • Web fonts causing FOUT/FOIT. When a web font loads and replaces the fallback font, text can reflow if the metrics don't match. Use font-display: optional or carefully match fallback font metrics.
  • Animations that change layout properties. Animations that modify top, left, width, or height cause layout shifts. Use transform and opacity instead — these are compositor-only properties that don't trigger layout.

How to Fix CLS

  • Add explicit width and height attributes to all <img> tags. Modern browsers use these to calculate the aspect ratio and reserve space before the image loads.
  • Reserve space for ad slots with a container div that has a fixed min-height.
  • Use the CSS aspect-ratio property for responsive containers that maintain their proportions.
  • Prefer transform: translateY() over top/margin-top for animated elements.
  • Add font-display: swap or optional to your @font-face declarations. Consider using the size-adjust descriptor to match fallback metrics.

How to Measure Core Web Vitals

Field Data vs Lab Data

There are two categories of CWV measurement, and they often disagree:

Field data (also called real user monitoring or RUM) is collected from actual users visiting your site via Chrome. Google uses field data for ranking. The primary source is the Chrome User Experience Report (CrUX), surfaced in Google Search Console, PageSpeed Insights, and the Core Web Vitals report. Your site needs enough traffic to appear in CrUX — low-traffic pages may not have field data.

Lab data is collected by automated tools running in a controlled environment (no real users). Lab data is available for any page regardless of traffic, but it simulates user conditions rather than measuring them. Tools: PageSpeed Insights (lab), Chrome DevTools Lighthouse, WebPageTest.

Lab data is useful for debugging — you can reproduce a specific performance condition and trace it. Field data is what matters for rankings. Always check both, but prioritize fixing field data issues.

Tools for Measuring Core Web Vitals

  • Google Search Console: The Core Web Vitals report shows field data for all your pages that have CrUX data. Best starting point — shows which pages fail at scale.
  • PageSpeed Insights: Field data (CrUX) + lab data (Lighthouse) for individual URLs. Best for diagnosing a specific page.
  • Chrome DevTools: Performance tab and Lighthouse for lab measurements. Best for debugging specific issues.
  • WebPageTest: Detailed lab testing with filmstrips, waterfall charts, and multi-step tests. Best for deep diagnosis.
  • SearchVitals: CWV field and lab data included in every site audit, alongside technical issues and GEO readiness — so you see CWV in context with other site health signals.

Frequently Asked Questions

Do Core Web Vitals directly affect rankings? expand_more
Yes — Core Web Vitals are a confirmed ranking signal through Google's Page Experience system, which also includes HTTPS and mobile-friendliness. However, Google has stated the signal is a tiebreaker: excellent content with poor CWV can still outrank thin content with perfect CWV. In competitive SERPs where content quality is comparable, CWV becomes the differentiator.
What replaced FID in Core Web Vitals? expand_more
Interaction to Next Paint (INP) replaced First Input Delay (FID) as a Core Web Vital in March 2024. Unlike FID, which only measured the delay before processing the first interaction, INP measures the full latency of all interactions throughout a page visit. Many sites that had good FID scores discovered their INP scores were substantially worse.
How long does it take to see CWV improvements in rankings? expand_more
CrUX data is updated monthly. This means ranking impact from CWV improvements typically takes 28–35 days to reflect in Google Search Console and in ranking changes. After fixing an issue, you'll usually see the field data improve in the next CrUX data update.
Why does my PageSpeed score differ from my CrUX data? expand_more
PageSpeed Insights shows both lab data (Lighthouse, run in a simulated environment) and field data (CrUX, from real users). Lab and field data often disagree because real users have different devices, network speeds, and browser extensions than the simulated environment. For ranking purposes, field data is what matters.

Check your Core Web Vitals now

Field + lab CWV data included in every free SearchVitals audit.

Free Audit