Core Web Vitals in 2026: INP is the one people still fail

The three metrics, and the thresholds that matter

Core Web Vitals are measured on real visits, at the 75th percentile — so passing means three quarters of your visits are good, not that your own laptop feels fine. That distinction is where most disagreements about site speed come from.

Why INP fails when LCP passes

FID measured only the delay before the browser began handling your first input. INP measures the whole thing — input delay, the processing your event handler does, and the time to paint the result — across every interaction in the session, and reports close to the worst one.

So a site can deliver content in 1.8 seconds and still feel broken: the user taps a menu, a 400KB JavaScript bundle is still hydrating, three analytics scripts are initialising, and the tap takes 600ms to do anything. On a flagship phone you would never notice. On the ₹15,000 Android handset most Indian users own, it is the experience.

The usual causes, in the order I find them

First, too much JavaScript. Large client bundles, whole UI libraries imported for one component, and heavy hydration of content that was never interactive. Second, third-party tags — chat widgets, tag managers, pixels, review embeds, each initialising on load and competing for the main thread. Third, expensive event handlers doing layout-thrashing work synchronously on tap. Fourth, long tasks that block the main thread for hundreds of milliseconds with nothing to break them up.

Notice that three of the four are things a marketing team adds after launch, one tag at a time, each individually harmless. That is why performance regresses quietly on sites that launched fast.

What actually fixes it

Ship less JavaScript. That is the whole answer, expressed four ways: render on the server what does not need interactivity, code-split so a page loads only its own logic, remove libraries used for one function, and avoid hydrating static content. On a modern framework most of this is a matter of not opting into client-side behaviour by default.

Then manage third parties like a budget rather than a wish list: load them after interaction where possible, remove anything nobody reads a report from, and put a hard cap on how many you allow. And break long tasks — yield to the main thread between chunks of work so the browser can paint a response while the rest continues.

CLS and LCP: still worth ten minutes

CLS is usually fixed by reserving space: explicit width and height on images and embeds, no content injected above existing content, and fonts loaded so that swapping does not reflow the page. Banners and consent widgets are a frequent cause, because they appear late and push everything down.

LCP is about the largest element — usually a hero image — so serve it in a modern format at the right size, do not lazy-load it, preload it if necessary, and make sure nothing blocking sits in front of it. Both of these are hygiene. INP is where the engineering is.

Why this matters commercially, not just for rankings

Core Web Vitals are a ranking signal, and a modest one — you will not outrank a better page by shaving 100ms. The commercial case is conversion: a site that responds instantly to a tap converts better than one that hesitates, and on Indian mobile traffic the difference is not subtle.

So treat performance as a conversion project with an SEO side effect, and give it a budget you defend. A page-weight and INP threshold that any new script must respect prevents the slow accumulation that turns a fast site into a mediocre one over two years.