INP — Interaction to Next Paint — measures how fast a page reacts when a user clicks or taps something. Under 200 milliseconds is good; over 500 milliseconds is poor, per Google's thresholds.
INP is one of the three Core Web Vitals — see What Are Core Web Vitals? for how it fits alongside LCP and CLS.
Why INP is easy to miss and hard to ignore
Think of the form that takes a second to register your tap, the menu that hesitates before opening, the button you have to press twice because nothing happened the first time. These interactions don't feel broken to the developer who built them on a fast machine — they feel broken to the person using a three-year-old phone on a mid-range mobile connection. INP is the metric that catches this gap between how a site feels to build and how it feels to actually use.
What actually drives a bad INP score
Heavy JavaScript execution on the main thread. When a script runs synchronously in response to a click — validating a form, updating multiple parts of the page, fetching and processing data — it blocks the browser from responding to anything else until it finishes, including painting the visual feedback that tells the user their tap registered.
Too much happening at once. A single interaction that triggers a cascade of updates (re-rendering large parts of a page, running multiple analytics scripts, loading additional content) adds up even when no individual piece is slow on its own.
Third-party scripts. Chat widgets, analytics trackers, and ad scripts often run on the main thread and can meaningfully worsen INP, especially when several are loaded on the same page competing for the same processing time.
What to actually do about it
Break up large JavaScript tasks so the browser can respond to interactions between them instead of finishing one long block of work first. Defer non-essential third-party scripts until after the page is interactive. Test on a genuinely mid-range device, not just a development machine — INP problems are often invisible until you test the way a real customer actually experiences the site.
A page that responds instantly to every tap feels trustworthy in a way that's hard to articulate but easy to notice the absence of — INP is the metric that quantifies that feeling.
Frequently asked questions
What's a good INP score?
Under 200 milliseconds is good. Between 200 and 500 milliseconds needs improvement. Over 500 milliseconds is poor, per Google's thresholds.
Why does INP feel invisible when I test my own site?
Because it's usually tested on a fast development machine. Interactions that feel instant there can take 500ms+ on a mid-range phone over a slower connection — see [What Are Core Web Vitals?](/blog/what-are-core-web-vitals) for how INP fits alongside LCP and CLS.
What causes a bad INP score?
Heavy JavaScript execution blocking the browser's main thread when a user interacts — large scripts, inefficient event handlers, or too much work happening synchronously in response to a click or tap.
Yash
Founder & Principal Consultant, Ynexgen
Yash leads Ynexgen, helping small and mid-sized businesses turn technology into a stronger foundation for growth — 7+ years across Salesforce CRM, websites, and AI adoption.
