Core Web Vitals in 2026: Passing INP

Core Web Vitals has three thresholds. Most sites pass two of them. The one that fails is almost always Interaction to Next Paint, and the reason is that INP measures something the previous metric did not.

The three metrics

• LCP — Largest Contentful Paint, under 2.5 seconds. How long until the main content appears.
• INP — Interaction to Next Paint, under 200 milliseconds. How long the page takes to visually respond to a user interaction.
• CLS — Cumulative Layout Shift, under 0.1. How much the layout jumps around while loading.

Why INP is harder than FID was

First Input Delay measured only the delay before the browser began processing the first interaction. It was easy to pass because it ignored how long the processing took and ignored every interaction after the first.

INP measures the full path from interaction to the next visual update, across all interactions, and reports roughly the worst one. A page that felt sluggish but passed FID will often fail INP — the metric caught up with the experience.

What causes INP failures

Long tasks on the main thread. JavaScript blocking for more than 50ms delays every interaction queued behind it. Tag managers loading a dozen third-party scripts are the usual source.

Heavy event handlers. Click handlers doing substantial synchronous work before updating the display.

Large DOM trees. Style and layout recalculation costs scale with node count. Page-builder sites frequently ship 4,000+ nodes where 800 would do.

Third-party scripts. Chat widgets, heatmap tools, consent managers and analytics all compete for the same main thread. On many sites the single biggest INP win is auditing which of these still earns its cost.

Lab scores mislead

Lighthouse simulates one page load on a synthetic device. Google ranks on CrUX field data — a 28-day rolling window of what real users on real devices actually experienced.

These disagree constantly. A site can score 95 in Lighthouse and fail INP in the field, because real users have older devices, worse connections, and interact with things the synthetic test never touches. Optimise against field data or you are optimising against a number nobody is measuring you on.

Fixes that work, in order

1. Audit third-party scripts. List everything the tag manager loads and remove what nobody uses. This is usually the largest single win and it costs nothing.
2. Defer non-critical JavaScript. Anything not needed for first interaction should not block it.
3. Break up long tasks. Yield to the main thread between chunks of work so queued interactions can be handled.
4. Reduce DOM size. On page-builder sites this often means rebuilding templates rather than tuning them.
5. Debounce expensive handlers. Particularly on scroll, resize and input.

For LCP and CLS

LCP: serve the hero image in a modern format at the right size, preload it, and eliminate render-blocking CSS and fonts. Do not lazy-load the LCP element — a surprisingly common own goal.

CLS: set explicit width and height on every image and iframe, reserve space for ads and embeds, and load fonts with font-display: swap plus a metric-compatible fallback.

How much does it matter?

Core Web Vitals is a real but modest ranking factor. It will not lift a weak page above a strong one. Where it matters most is as a tiebreaker between comparable pages, and — more importantly — in conversion. A site that responds in 100ms converts better than one that responds in 500ms, regardless of what Google does with the number.