Core Web Vitals Explained: LCP, INP and CLS

Core Web Vitals are three metrics Google uses to measure how a page feels to real users: LCP (loading), INP (responsiveness), and CLS (visual stability). The “good” targets are LCP under 2.5s, INP under 200ms, and CLS under 0.1, measured at the 75th percentile of real visits. They’re a genuine ranking signal — one of many — and, more importantly, they’re a direct proxy for user experience. Here’s what each measures and how to fix it.

The three metrics

LCP — Largest Contentful Paint (loading)

LCP marks the moment the largest visible element — usually a hero image, heading, or main text block — finishes rendering. It answers: “How long until the user sees the main content?”

• Good: under 2.5 seconds
• Needs improvement: 2.5–4.0 seconds
• Poor: over 4.0 seconds

INP — Interaction to Next Paint (responsiveness)

INP measures how quickly the page visually responds when a user interacts — a tap, click, or key press. It looks across all interactions in a visit and reports a representative worst case. It replaced First Input Delay in 2024 and is stricter, because it captures ongoing responsiveness, not just the first tap.

• Good: under 200 milliseconds
• Needs improvement: 200–500 milliseconds
• Poor: over 500 milliseconds

CLS — Cumulative Layout Shift (visual stability)

CLS quantifies unexpected movement — content jumping as images load or ads inject, causing you to misclick. It’s a unitless score, not a time.

• Good: under 0.1
• Needs improvement: 0.1–0.25
• Poor: over 0.25

Metric	Measures	Good threshold
LCP	Loading	< 2.5 s
INP	Responsiveness	< 200 ms
CLS	Visual stability	< 0.1

These thresholds and definitions come straight from Google’s web.dev Core Web Vitals guidance.

Common causes and fixes

Fixing LCP

Slow LCP usually traces to the network or render path:

• Optimize the hero image. Compress it, serve modern formats (WebP/AVIF), and size it correctly. An oversized hero is the classic LCP killer.
• Serve real HTML fast. Server-side rendering or static generation paints content without waiting on a JavaScript bundle. This is one reason our web development is static-first.
• Preload critical resources and cut render-blocking CSS/JS.
• Use a CDN so bytes travel a short distance.

Fixing INP

Poor INP means the main thread is busy when the user interacts:

• Break up long JavaScript tasks so the browser can respond between chunks.
• Reduce the amount of JavaScript shipped — less to parse and execute means a freer main thread.
• Defer non-essential work until after interaction.

Sites that ship minimal JavaScript tend to have excellent INP almost for free.

Fixing CLS

Layout shift comes from content whose space isn’t reserved:

• Set width and height (or aspect-ratio) on images and video so the browser reserves space before they load.
• Reserve space for ads and embeds instead of letting them push content down.
• Avoid inserting content above existing content after load.
• Preload fonts to reduce shifts from late font swaps.

Why speed matters for SEO and crawl

Core Web Vitals are part of Google’s page experience signals. But relevance still dominates ranking, so treat vitals as a tiebreaker and a UX win, not a magic lever. Overstating their ranking weight is a common mistake — good vitals help, but they won’t rescue thin or irrelevant content.

The bigger, often-missed benefit is crawl efficiency. Fast, lightweight pages are cheaper to fetch, which matters for every crawler — including AI crawlers, many of which don’t run JavaScript and simply grab your HTML. A page that renders its content immediately is a page every bot can read. That connection runs through our take on AI SEO vs traditional SEO.

Measure with field data, not just lab scores

One trap: optimizing for a Lighthouse lab score while real users suffer. Prioritize field data — real-user measurements from the Chrome User Experience Report, surfaced in PageSpeed Insights and Search Console. Lab tools like Lighthouse are for diagnosis; field data is the scoreboard, reported at the 75th percentile so you’re serving most visitors well, not just your fast test machine.

The bottom line

• LCP = loading, target under 2.5s. Fix the hero and the render path.
• INP = responsiveness, target under 200ms. Ship less JavaScript.
• CLS = stability, target under 0.1. Reserve space for everything.
• They’re a real but secondary ranking factor — and a real user-experience and crawl win.

Want to know where your Core Web Vitals stand with real users, and exactly what’s dragging them down? Get an AI visibility audit — performance is part of how we assess whether engines and users can actually use your site.