INP (Interaction to Next Paint) Explained

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).

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.

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.