In short
FID measured only the first input delay. INP looks across interactions and reports a high percentile, so one heavy menu, form field, or script-triggered render can expose a real responsiveness problem.
Most INP problems come from too much JavaScript on the main thread, expensive event handlers, slow rendering after a state change, or third-party code loaded on pages where it does not earn its weight.
Where it bites
INP bites when a page appears loaded but does not feel ready. Users click, nothing happens, and the team blames the form copy while the browser is busy running scripts.
What to check
- Which interaction produces the longest delay in field data or a performance trace?
- Are long tasks, hydration, analytics, chat widgets, or embeds blocking the main thread?
- Can expensive work be split, deferred, cached, or removed from the page template?
Common questions
What is INP?
INP, or Interaction to Next Paint, measures how quickly a page visibly responds after user interactions such as clicks, taps, and keyboard input.
What is a good INP score?
Google considers an INP under 200 milliseconds good. Scores above 500 milliseconds are poor and usually point to heavy JavaScript or rendering work.
What should you check first for INP?
Start with the slowest real interactions, long main-thread tasks, third-party scripts, hydration cost, and event handlers tied to forms, menus, filters, and checkout steps.