Core Web Vitals fixes: LCP, CLS, and INP in plain English

What each metric measures, the thresholds Google uses, and the fixes that actually move the numbers on real sites.

Updated October 13, 202611 min readFor: Developers shipping marketing sites and web apps

The three metrics

MetricMeasuresGoodPoor
LCP (Largest Contentful Paint)When the main content appears≤ 2.5 s> 4 s
INP (Interaction to Next Paint)How quickly the page responds to clicks, taps, and keys≤ 200 ms> 500 ms
CLS (Cumulative Layout Shift)How much the layout jumps around≤ 0.1> 0.25

Google evaluates each metric at the 75th percentile of real visits, on mobile and desktop separately.

Fixing LCP

First find the LCP element: usually a hero image, a large heading, or a video poster. LCP time breaks down into four parts, and each has its own fix:

  1. Server response (TTFB). Cache HTML at the edge, use a CDN, and avoid slow database calls on landing pages.
  2. Resource load delay. The browser should discover the hero image immediately. Use a real <img> (not a CSS background), add fetchpriority="high", and never lazy-load it.
  3. Resource load time. Serve WebP or AVIF, size it for the viewport with srcset and sizes, and keep hero images under ~150 KB.
  4. Render delay. Render-blocking CSS and JavaScript, web fonts, and client-side rendering hold the paint back. Inline critical CSS, defer scripts, and server-render above-the-fold content.

Fixing CLS

  • Give every image, video, and iframe width and height attributes, or a CSS aspect-ratio, so the browser reserves space.
  • Reserve space for ads, embeds, and cookie banners instead of pushing content down.
  • Never insert content above existing content unless the user asked for it.
  • Reduce font swap shifts with a matched fallback (size-adjust) or font-display: optional.
  • Animate with transform and opacity, not top, left, width, or height.

Fixing INP

INP is about the main thread. When a user taps, the browser must finish whatever JavaScript is running, run your event handler, and paint. Long tasks anywhere in that chain make the page feel stuck.

  • Break up long tasks. Split work into chunks and yield to the browser between them (await scheduler.yield() where supported, or a setTimeout fallback).
  • Do less on interaction. Update the UI first, then do analytics, network calls, and heavy computation afterwards.
  • Cut JavaScript. Remove unused libraries, code-split routes, and avoid hydrating parts of the page that never change.
  • Tame third parties. Chat widgets, tag managers, and A/B testing scripts are frequent INP culprits. Load them late or on demand.
  • Avoid huge re-renders. Typing in one input should not re-render a 5,000-row table. Memoize, virtualize long lists, and debounce expensive handlers.

Measure the right way

  • While building: measure on the live tab, throttled to a mid-range phone.
  • Before launch: run Lighthouse or PageSpeed Insights on staging or the preview URL.
  • After launch: watch field data in Search Console's Core Web Vitals report and in PageSpeed Insights once you have enough traffic.

Questions

What are good Core Web Vitals scores?

LCP at or under 2.5 seconds, INP at or under 200 milliseconds, and CLS at or under 0.1, measured at the 75th percentile of real page loads. Poor is LCP over 4 seconds, INP over 500 ms, or CLS over 0.25.

What happened to First Input Delay (FID)?

INP replaced FID as a Core Web Vital in March 2024. INP measures the delay of all interactions on the page, not just the first, so it is much harder to game.

Why do my Lighthouse and Search Console numbers differ?

Lighthouse is a lab test on one simulated device. Search Console uses field data from real Chrome users over the last 28 days. Google ranks with field data, so treat lab scores as a debugging tool.

Do Core Web Vitals affect rankings?

They are part of Google's page experience signals, but relevance matters far more. Their bigger impact is on users: slow, jumpy pages lose visitors and conversions.

Tools for this guide