Core Web Vitals in 2026: LCP, INP and CLS Thresholds and How to Fix Them

The Three Metrics and Their Thresholds

Core Web Vitals is now three metrics. INP replaced FID in March 2024 — if your dashboard still shows First Input Delay, it is out of date.

Metric                          Good      Needs work        Poor
LCP  Largest Contentful Paint   <= 2.5s   2.5s - 4.0s       > 4.0s
INP  Interaction to Next Paint  <= 200ms  200ms - 500ms     > 500ms
CLS  Cumulative Layout Shift    <= 0.1    0.1 - 0.25        > 0.25

To "pass", at least 75% of page loads must be in the good band, measured separately for mobile and desktop. That last part catches people out: a site can pass on desktop and fail on mobile, and mobile is what counts for the mobile index.

Field Data vs Lab Data — Know Which You Are Looking At

This is the most important practical distinction in performance work.

• Lab data (Lighthouse, PageSpeed Insights' "Analyse" run, DevTools) is a single simulated load on a throttled connection. Reproducible, useful for debugging, and not what Google uses for ranking.
• Field data (the Chrome User Experience Report, or CrUX) is real Chrome users over a rolling 28-day window. This is what Google uses.

Two consequences. First, a Lighthouse score of 100 does not mean you pass Core Web Vitals — real users on real devices and networks may still be in the poor band. Second, fixes take up to 28 days to fully appear in field data. Do not judge a change after two days.

Also note: Lighthouse cannot measure INP at all, because INP requires a real user interacting. Lab tools substitute Total Blocking Time as a proxy.

LCP: Largest Contentful Paint

When the largest above-the-fold element finishes rendering. Usually a hero image, a video poster, or a large text block.

LCP breaks into four sub-parts, and knowing which one dominates tells you what to fix:

1. Time to first byte — server and network.
2. Resource load delay — the gap between the document arriving and the browser starting to fetch the LCP resource.
3. Resource load duration — downloading it.
4. Element render delay — the gap between download finishing and paint.

Fixes, in rough order of impact:

• Preload the LCP image and set fetchpriority="high" on it. This attacks load delay, which is the largest slice on most sites.
• Never lazy-load the LCP element. loading="lazy" on a hero image is a self-inflicted LCP failure.
• Serve modern formats. AVIF or WebP at the correct display size, with srcset for density. This is usually the single biggest byte saving available.
• Inline critical CSS, defer the rest. A blocking stylesheet in <head> delays every paint.
• Self-host fonts, preload the WOFF2, and use font-display: swap so text-based LCP is not held hostage to a font download.
• Cache aggressively and put static assets behind a CDN.

INP: Interaction to Next Paint

INP measures the worst interaction latency across the whole page visit — click, tap, or key press to the next frame painted. It replaced FID because FID only measured the delay before the handler ran, which hid most real sluggishness.

INP has three phases:

• Input delay — the main thread was busy when the user acted.
• Processing time — your event handler running.
• Presentation delay — the browser recalculating style and layout and painting.

Fixes:

• Break up long tasks. Anything over 50 ms blocks input. Yield with await scheduler.yield() where supported, or setTimeout(fn, 0).
• Ship less JavaScript. Code-split by route; do not hydrate what is not interactive.
• Move heavy work off the main thread into a Web Worker.
• Debounce expensive handlers, especially on input and scroll.
• Defer non-critical third-party scripts. Analytics, chat widgets, ad loaders and A/B testing tools are the usual culprits — they compete for the same main thread your buttons need.
• Avoid layout thrashing — batch DOM reads, then writes.

CLS: Cumulative Layout Shift

The sum of unexpected layout shifts during the page's life, scored as impact fraction times distance fraction. It is the cheapest of the three to fix and the most annoying to users.

Fixes:

• Always set width and height on images and videos (or aspect-ratio in CSS) so the browser reserves the box before the file arrives.
• Reserve space for ads, embeds and iframes with a fixed min-height.
• Never insert content above existing content — cookie banners, promo bars and "you have 1 new message" strips are classic offenders. Overlay them or reserve their space.
• Use font-display: optional or match fallback metrics with size-adjust to avoid reflow when a webfont swaps in.
• Animate transform and opacity, never top, left, width or height.

Where to Actually Measure

1. Search Console → Core Web Vitals — your real field data, grouped into URL patterns. Start here.
2. PageSpeed Insights — shows CrUX field data and a Lighthouse lab run for the same URL, side by side.
3. The web-vitals JavaScript library — collect your own real-user metrics with attribution, so you know which element was the LCP and which handler blew the INP budget.
4. Chrome DevTools → Performance — for debugging a specific long task.

Compress and resize hero images with the Image Compressor and Image Resizer, strip stylesheet bloat with the CSS Minifier, and sanity-check your own connection with the Internet Speed Test.

Related: Next-Gen Image Compression Techniques and Image Formats Compared.