What INP actually measures
INP tracks every click, tap, and keyboard interaction during a page visit and reports something close to the slowest one (technically, the worst typical interaction after accounting for outliers) — meaning one badly-timed janky interaction can move the whole page's score, not just an average.
Google's published thresholds: under 200ms is "good," 200–500ms "needs improvement," over 500ms is "poor." Unlike LCP, INP can only be measured on real user interactions, so it doesn't appear in a lab test the same way — it needs field data (Chrome User Experience Report or your own real-user monitoring).
What usually causes a bad score
The most common cause is JavaScript blocking the main thread at the exact moment someone interacts — a large script still parsing, an event handler doing expensive work synchronously, or a third-party script (ads, analytics, chat widgets) hogging the thread.
Heavy, unoptimized React/framework re-renders are a frequent culprit on modern sites: an interaction that triggers a re-render of a large component tree can blow well past 200ms even though the actual visual change is tiny.
How to actually improve it
Break up long JavaScript tasks (anything blocking the main thread for 50ms+) using techniques like scheduler.yield() or breaking work into smaller chunks, so the browser gets a chance to respond to input between them.
Audit third-party scripts first — they're often the highest-leverage fix, since removing or deferring a single bloated ad or analytics script can fix an INP problem faster than optimizing your own code. Use Chrome DevTools' Performance panel or the web-vitals JS library to find the specific slow interaction rather than guessing.