Interaction to Next Paint measures how quickly a page responds visibly when someone interacts with it: a tap, a click, a keypress. It replaced First Input Delay, and it is stricter, because it measures the whole interaction rather than just the initial delay.
That change caught many sites out. Pages that passed FID comfortably frequently fail INP, because the old metric ignored how long the response actually took to appear.
What INP actually measures
- The delay before processing begins, which is what FID measured.
- How long the event handler takes to run.
- How long until the resulting visual update is painted.
- It reports roughly the worst interaction on the page, not an average, so one slow interaction can fail the page.
The practical implication is that heavy JavaScript hurts INP even where the page loads quickly. Load speed and responsiveness are different problems.
The usual causes
Long JavaScript tasks
The dominant cause. Tasks that occupy the main thread block it from responding to input. Anything over 50ms is a long task, and analytics, tag managers and third-party scripts routinely produce them.
- Break long tasks into smaller pieces so the browser can respond between them.
- Defer work that does not need to happen immediately.
- Audit third-party scripts, which are frequently the largest contributors and the easiest to remove.
Too much third-party script
Chat widgets, heatmaps, A/B testing tools, multiple analytics packages and marketing tags all compete for the same thread. Each is individually defensible and collectively they are usually the problem.
Heavy event handlers
Handlers doing substantial work synchronously on click, such as recalculating a cart or filtering a large list, delay the visible response.
Large DOM
Pages with very many elements are slower to update, because any change requires more work. Category pages with hundreds of products are the common ecommerce case.
No immediate visual feedback
Sometimes the work is genuinely slow and the fix is to acknowledge the interaction immediately: a pressed state, a spinner, a disabled button. Painting something quickly is what the metric measures.
Where to look
- Field data first, since INP depends on real interactions and lab tools cannot simulate them well.
- Identify which interactions are slow, not just that the page is.
- Profile the main thread during those interactions.
- Audit the third-party script inventory and remove what is not earning its place.
- Test on a mid-range mobile device rather than a development machine.
Frequently asked questions
What is a good INP?
Under 200 milliseconds at the 75th percentile. Above 500ms is poor.
We passed FID but fail INP. Why?
FID measured only the delay before processing started. INP measures the full interaction through to the visual update, so slow handlers that FID ignored now count.
Can I fix INP without removing features?
Often yes, by deferring work and breaking long tasks up. But third-party scripts have a real cost, and some sites do have to choose between a tool and responsiveness.
Does INP matter on content sites?
Less than on interactive ones, since there are fewer interactions to measure. Sites with menus, filters and forms are affected far more.
Consulting CTA
If your pages load quickly but respond slowly, book an SEO consultation for a review of script load and interaction handling.