Core Web Vitals: what LCP, INP and CLS measure and how to fix them

Core Web Vitals are three metrics Google uses to score page experience: Largest Contentful Paint (loading), Interaction to Next Paint (responsiveness), and Cumulative Layout Shift (visual stability). A page passes only when at least 75% of real Chrome visits over the trailing 28 days hit the "good" threshold for each metric.

The three metrics and their thresholds

Google assesses each metric at the 75th percentile of field data — the experience of your slower-than-median users, not your fastest.

Metric	Measures	Good	Needs improvement	Poor
LCP (Largest Contentful Paint)	Loading — when the biggest visible element renders	≤ 2.5 s	2.5–4.0 s	> 4.0 s
INP (Interaction to Next Paint)	Responsiveness — lag from tap/click to the next frame	≤ 200 ms	200–500 ms	> 500 ms
CLS (Cumulative Layout Shift)	Visual stability — how much content jumps during load	≤ 0.1	0.1–0.25	> 0.25

INP replaced FID in March 2024

If you are working from an older checklist, correct it: INP replaced First Input Delay as a Core Web Vital on 12 March 2024, and FID is retired. FID only measured the delay before the first interaction was processed. INP looks across the whole session and reports the worst interaction latency users actually felt, which is a much harder — and more honest — bar to clear.

Field data is what ranks; lab data is for debugging

There are two kinds of measurement, and confusing them is the most common Core Web Vitals mistake.

Field data comes from the Chrome User Experience Report (CrUX) — anonymized measurements from real Chrome users. This is what Google's ranking systems use. You see it in the Search Console Core Web Vitals report, in PageSpeed Insights, and through the CrUX API.

Lab data comes from a synthetic test in a controlled environment (Lighthouse, the lab section of PageSpeed Insights, Chrome DevTools). It is repeatable and great for diagnosing a regression, but it cannot measure INP or full-session CLS, because those depend on how a real person interacts with the page. A perfect Lighthouse score does not mean you pass in the field.

A practical consequence: new pages, or low-traffic pages, may have no CrUX data at all. Google then falls back to origin-level data or simply has nothing to assess. Do not expect a fresh page to show field results immediately.

Does passing Core Web Vitals lift rankings?

Passing does not guarantee a ranking boost. Core Web Vitals is one input into page experience, and page experience acts as a tiebreaker among results that are comparably helpful. It will not rescue thin or off-intent content, and it will not out-rank a more relevant, more authoritative page. Treat it as table stakes: a fast, stable page that fails on substance still loses.

Core Web Vitals also sits inside a broader page-experience picture that has no single ranking signal. The other contributing aspects are HTTPS, mobile-friendly/responsive design, no intrusive interstitials, and reasonable ad density where the main content stays distinguishable from ads.

How to fix each metric

Improve LCP (loading)

The LCP element is usually the hero image or a large heading. Serve it fast and early.

• Render server-side (SSR or static generation) rather than client-only, so the largest element is in the initial HTML.
• Preload the hero image and mark it high priority; do not lazy-load the element that is your LCP.
• Compress and correctly size images; use modern formats.
• Cut render-blocking CSS and slow server responses — time to first byte feeds directly into LCP.

Improve INP (responsiveness)

INP is dominated by main-thread work. When JavaScript is busy, taps feel laggy.

• Break up long tasks so the browser can respond between them.
• Minimize hydration and client-side JavaScript. Server components (Next.js RSC/streaming) and partial hydration (Astro islands) ship less interactive code.
• Defer non-critical third-party scripts, which are a frequent INP culprit.

Improve CLS (visual stability)

Layout shift comes from content that loads without reserved space.

• Set explicit width/height or an aspect-ratio on every image, video, and embed.
• Reserve space for ads, banners, and late-loading widgets instead of injecting them above existing content.
• Preload web fonts and use font-display sensibly to avoid text reflow.

How Crawlinx helps

Crawlinx measures on a single fetch, so it cannot report your field CrUX percentiles — only real Chrome users produce those. What it does is surface the structural causes that push field metrics into the "poor" band, before you spend crawl on PageSpeed Insights:

• perf.slow_response — a slow server response inflates LCP for every page.
• perf.large_html — oversized HTML lengthens parse and main-thread work, hurting LCP and INP.
• images.missing_dimensions — images without width/height are a leading cause of layout shift.
• render.content_js_only and rendering.js_dependent — content that only appears after JavaScript runs delays LCP and loads the main thread.
• security.mixed_content — mixed content blocks HTTPS, one of the page-experience aspects that surrounds Core Web Vitals.

For actual field scores, pair a Crawlinx audit with the Search Console Core Web Vitals report and PageSpeed Insights.

Takeaway

Fix LCP, INP and CLS at their structural roots — server speed, main-thread JavaScript, and reserved layout space — then verify with the field data in Search Console, since only real-user CrUX percentiles decide whether you pass. Passing is a tiebreaker, not a shortcut past weak content.

Related reading: structured data and GEO/AEO for AI search.