Skip to content
EasyWebWeb design & development studio

INP: the Core Web Vital most sites still fail

8 min readPerformance

Interaction to Next Paint measures how long your site takes to visibly respond after someone taps or clicks. Google considers anything under 200 milliseconds good. It is the Core Web Vital most sites fail, because unlike loading metrics it cannot be fixed by better hosting — it is caused by JavaScript occupying the main thread.

A close-up of a clock face displayed on a computer screen
Photo by Xavier Cee on Unsplash

What does INP actually measure?

INP measures the delay between a user interacting with your page and the browser painting the result. It watches every tap, click and key press across the whole visit, then reports roughly the worst one. Not the average — close to the worst.

That distinction matters. A page can feel fine ninety-five times and be scored on the five times it stuttered. It replaced First Input Delay in March 2024 precisely because FID only measured the first interaction, which was almost always the easiest one.

Why do so many sites fail it?

Because INP is caused by JavaScript, and JavaScript is the one thing that has grown steadily for fifteen years. Faster hosting will not help you. A CDN will not help you. The main thread is single-threaded, and while it is busy running a script it cannot repaint the screen.

The usual culprits are depressingly consistent across sites:

  • Hydration on large pages

    A React or Vue site rebuilding its component tree in the browser while the visitor is already tapping things.

  • Third-party tags

    Analytics, chat widgets, consent banners and heat-mapping tools, each running their own handlers on every interaction.

  • Unthrottled event handlers

    Scroll, resize and input listeners doing real work on every single event rather than batching.

  • Layout thrashing

    Code that reads a geometric property like offsetWidth after changing the DOM, forcing the browser to recalculate layout synchronously.

How do you get INP under 200ms?

Start by finding out which interaction is actually slow, rather than optimising by intuition. Chrome DevTools' Performance panel records interactions and shows you the long task responsible. Field data in Search Console tells you whether real visitors experience it at all.

Then, in rough order of return:

  • Remove what you do not need

    The fastest script is the one you deleted. Most sites carry at least one tag nobody has looked at in two years.

  • Break up long tasks

    Anything over 50ms blocks interaction. Yield back to the browser with scheduler.yield() or setTimeout between chunks of work.

  • Defer non-critical work

    Analytics, banners and widgets rarely need to run before the page is interactive. Load them after.

  • Send less JavaScript

    Server Components and server-side rendering shift work off the browser entirely. This is the structural fix, and the only one that keeps paying.

A useful test: open your site on a five-year-old Android phone rather than your laptop. INP is measured on real devices, and most of them are slower than the machine you build on.

Does INP actually affect rankings?

It is a ranking signal, but a light one. Content relevance still dominates, and a fast page about nothing will not outrank a slow page that answers the question.

The larger effect in 2026 is indirect. AI Overviews and answer engines appear to filter slow pages out of citations, so poor Core Web Vitals can cost you visibility in the surfaces that are growing fastest — regardless of where you sit in the ten blue links.

Common questions

What is a good INP score?
Under 200 milliseconds is considered good by Google. Between 200 and 500 needs improvement, and above 500 is poor. Competitive sites in 2026 are targeting under 150ms.
Is INP the same as First Input Delay?
No. FID measured only the delay before the first interaction was processed, and most sites passed it easily. INP measures the full time until the screen updates, across every interaction in the visit, which is far harder to pass.
Can better hosting fix INP?
No. INP is decided by how long JavaScript occupies the browser's main thread on the visitor's device. Faster servers improve loading metrics like LCP, but they cannot make a script run faster on someone's phone.
How do I measure INP on my own site?
Google Search Console shows field data from real Chrome users, which is the version that counts for ranking. Chrome DevTools' Performance panel shows you which specific interaction is slow and which task caused it.