What INP measures
INP counts discrete interactions: mouse clicks, touchscreen taps and key presses on physical or on-screen keyboards. Hovering, scrolling and zooming are not measured. Each interaction has three parts: input delay, while the browser waits for the main thread to free up; processing duration, while event handlers run; and presentation delay, until the next frame appears on screen.
The value reported for a visit is the slowest interaction observed, with a few outliers ignored on highly interactive pages. A single sluggish menu can therefore set the score for the whole page.
Thresholds and how it differs from FID
INP is good at 200 ms or less, needs improvement up to 500 ms and is poor above that, at the 75th percentile of real visits. Its predecessor, FID, only measured the input delay of the very first interaction, so a page could post a great FID and still respond slowly to every later click. INP looks at all interactions during the visit, which makes it far stricter.
Common causes of poor INP
- Long JavaScript tasks hogging the main thread when the user clicks.
- Third-party scripts: live chat, A/B testing tools, ad pixels, tag managers loaded with dozens of tags.
- Heavy event handlers, such as a filter that recalculates and re-renders an entire product grid.
- A very large DOM that slows down every rendering update.
- Late hydration of JavaScript frameworks on mobile devices.
How to improve responsiveness
Break up long tasks so the browser can respond between steps, defer non-essential scripts until after load, show immediate visual feedback (a pressed button state, a spinner) before expensive work, and trim the DOM. Google's web-vitals library, wired to your analytics, reports which element triggered the slow interaction for real visitors, so you fix the right component.