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:
| Metric | Good | Needs improvement | Poor |
|---|---|---|---|
| LCP (Largest Contentful Paint) | ≤ 2.5s | 2.5–4.0s | > 4.0s |
| INP (Interaction to Next Paint) | ≤ 200ms | 200–500ms | > 500ms |
| CLS (Cumulative Layout Shift) | ≤ 0.1 | 0.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
preloadit. 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: swapplus 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
yieldto 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(oraspect-ratio). The browser doesn’t reserve space, so everything below jumps when the image loads. - Web fonts loading late and reflowing text.
size-adjustand 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.