Core Web Vitals: What Changed with INP, and How to Pass

Core Web Vitals are the subset of performance metrics Google uses as a ranking signal, and they are measured on real users, not a lab machine. The biggest recent change was the retirement of First Input Delay in favour of Interaction to Next Paint (INP), a stricter measure of responsiveness. Here is what to target and where the wins actually are.

The three thresholds

• Largest Contentful Paint (LCP): under 2.5s — how fast the main content appears.
• Interaction to Next Paint (INP): under 200ms — how responsive the page feels to input.
• Cumulative Layout Shift (CLS): under 0.1 — how much the layout jumps as it loads.

LCP: it is almost always the hero image

For most sites the LCP element is a large image or heading above the fold. Serve the image in a modern format, size it correctly, and let it load early rather than behind a waterfall of scripts.

• Use next/image with the priority prop on the hero so it is not lazy-loaded.
• Preconnect to any origin the LCP asset loads from.
• Avoid rendering the hero only after client-side hydration — server-render it.

One detail that catches people out: LCP measures when the element renders, not when it finishes loading in some abstract sense — and the element it picks can change between visits. A page whose hero is sometimes a heading and sometimes an image (because the image is slow) will show a bimodal LCP, which looks like noise until you realise the metric is measuring two different things.

INP: keep the main thread free

INP punishes long JavaScript tasks that block the browser from responding. Ship less JavaScript, split what remains, and defer anything not needed for the first interaction. In React, watch for expensive work running synchronously inside event handlers.

INP replaced First Input Delay for a specific reason. FID measured only the delay before an event handler began, so a page could score well while doing something slow enough afterwards to feel broken. INP measures the whole interaction — input, processing, and the paint that follows — across the entire visit, and reports close to the worst one. It is a much harder metric to game, which is precisely the point.

In practice the common causes are hydration on a large React tree, expensive synchronous work inside an event handler, and third-party script competing for the main thread. Splitting long tasks and moving work off the critical path helps more than micro-optimising any single handler.

CLS: reserve the space

• Always set width and height (or an aspect ratio) on images and embeds.
• Use font-display: swap and preload key fonts to avoid text reflow.
• Never insert banners or ads above existing content after load.

Lab numbers are not the numbers that rank

Lighthouse gives you a lab estimate from one simulated device. The assessment Google actually uses comes from the Chrome User Experience Report — field data from real Chrome visitors, evaluated at the 75th percentile over a 28-day window. A green lab score and a failing field assessment are entirely compatible, which is why chasing the Lighthouse number alone can feel like running in place.

ShipReady does not measure Core Web Vitals, and no scanner that fetches your pages from a server can: the metric is defined by what happens on your visitors' devices. What it does check is the passive hygiene that feeds them — images served without width and height, the most common source of layout shift; render-blocking scripts; text served uncompressed; static assets with no cache headers; and redirect chains that delay the first byte. Fix those, then read the field data in Search Console.