🍱 Lunchbox Hands

seo

Core Web Vitals Explained: LCP, INP, and CLS for Developers

What LCP, INP, and CLS actually measure, the thresholds that matter, and the real causes behind each failure — written for developers, with concrete fixes.

Most Core Web Vitals guides are written for marketers and stop at “make your site faster.” This one is for the developer who just got a failing score and needs to know what specifically causes each metric to fail and where to look in their own stack.

There are three metrics. Google measures each at the 75th percentile of real users (field data), and the thresholds are:

MetricGoodNeeds improvementPoor
LCP (Largest Contentful Paint)≤ 2.5s2.5–4.0s> 4.0s
INP (Interaction to Next Paint)≤ 200ms200–500ms> 500ms
CLS (Cumulative Layout Shift)≤ 0.10.1–0.25> 0.25

INP replaced First Input Delay (FID) as a Core Web Vital in March 2024, so if you’re working from an older guide that mentions FID, it’s out of date.

Field data vs. lab data — read this first

This trips up almost everyone. There are two ways to measure these metrics:

  • Field data (CrUX): real Chrome users over the trailing 28 days. This is what Google actually uses for ranking. It only exists once your site has enough traffic.
  • Lab data (Lighthouse): a single simulated load on a throttled device. Useful for debugging, but it runs on an emulated slow phone, so it routinely reports LCP of 2.5–4s even for fast sites.

If a tool tells you a fast site has “poor” LCP, check whether it’s grading lab data against the field thresholds — that’s a common mistake. (Our SEO Analyzer labels lab estimates as informational precisely because of this.) When field data is available, trust it over the lab number.

LCP: what makes it slow

LCP is the moment the largest element in the viewport — usually a hero image, a heading, or a block of text — finishes rendering. Common causes, roughly in order of how often they’re the culprit:

  • Render-blocking resources. A synchronous CSS or font request in the <head> blocks the first paint. Self-host fonts, inline critical CSS, and load the rest async.
  • A slow or unoptimized LCP image. Serve it in WebP/AVIF, size it correctly, and preload it. Never lazy-load the LCP image.
  • Slow TTFB. If the server takes 600ms to respond, LCP can’t be fast. Cache at the edge.
  • Web fonts. If your LCP element is text in a custom font, a blocking font fetch delays it. font-display: swap plus self-hosting is the usual fix.

INP: what makes it laggy

INP measures how quickly the page responds to every interaction across the visit, not just the first. High INP almost always traces to JavaScript:

  • Long tasks on the main thread. A single 300ms task blocks every click during it. Break work into smaller chunks, defer non-critical JS, and yield to the main thread.
  • Heavy third-party scripts. Analytics, chat widgets, and tag managers are frequent offenders. Load them late and audit what you actually need.
  • Expensive hydration. On SPA and islands frameworks, hydrating a large component on load makes the page look ready but feel frozen. Hydrate on interaction or when idle, not eagerly.

CLS: what makes it jump

CLS is visual stability — content shifting after it’s already on screen. The causes are almost always missing dimensions:

  • Images without width/height (or aspect-ratio). The browser doesn’t reserve space, so everything below jumps when the image loads.
  • Web fonts loading late and reflowing text. size-adjust and matched fallback metrics help.
  • Injected content — ads, banners, embeds — pushing content down. Reserve the space up front.

Which one to fix first

Start with whichever metric is poor in your field data, then needs improvement. If you only have lab data, treat LCP and CLS as the actionable ones (lab INP is unreliable). In practice, the highest-leverage fixes for most sites are: optimize the LCP image, self-host fonts, and set dimensions on everything.

To see your scores without setting up CrUX dashboards, run the SEO Analyzer and click “Run performance test” — it queries PageSpeed Insights and prefers real field data when it exists. For the technical layer that often rides alongside performance work, the HTTP Header Analyzer checks caching and security headers.

For the full picture of everything else that affects rankings, see our complete on-page SEO checklist.