On a web page, which user interactions does the Interaction to Next Paint (INP) metric measure, and which common ones does it ignore?
answer
- discrete inputs only
- click, tap, key press
- not scroll, not hover
- measured to the next paint
- one value per visit, worst-ish
basics
~20 sINP measures discrete interactions — clicks, taps and key presses — timing each from the user's input to the next frame painted after the page responds. Scrolling and hovering are excluded, and one value per page visit is reported.
solid answer
~40 sINP watches three kinds of discrete input: mouse clicks, touch taps, and key presses. For each one it measures from the moment the user acted to the moment the browser paints the next frame — so it captures the whole round trip the user perceives, not just how long a handler ran. Continuous gestures are deliberately left out: plain scrolling and hovering do not count, and neither does mouse movement, because the browser can often handle scrolling off the main thread and it would swamp the signal. A page visit produces many interactions but reports a single INP value, drawn from the slowest ones. Under the thresholds in force since 2024, an INP at or below 200 ms is good and above 500 ms is poor, judged at the 75th percentile of real visits.
go deeper
Be able to list the three qualifying inputs — click, tap, key press — say that timing runs to the next painted frame, and note that scrolling and hovering are excluded.
Explain that the events of one logical action are grouped into a single interaction, and that the reported value is one number per page visit rather than a per-click average.
Show that you use the exclusions when triaging: bad scroll feel is not an INP problem, and a page with almost no clicks will have thin INP coverage no matter how much traffic it gets.
Own the reporting consequence — read-heavy surfaces produce sparse INP data, so a responsiveness target for those pages needs a sampling and coverage plan before it can be enforced anywhere.
## What INP is trying to capture Responsiveness is not "how fast did my JavaScript run" — it is "how long after I acted did the screen change". Interaction to Next Paint (INP) is built around that user-visible definition. For every qualifying interaction, the browser times from the hardware input event through all of the event handlers that run, through the rendering work that follows, up to the moment the **next frame is presented**. That final paint is what the user reads as "the page responded". ## Which inputs qualify Three input types generate an INP-eligible interaction: - **Mouse clicks** — the `pointerdown` / `pointerup` / `click` sequence. - **Touch taps** — the touch equivalent of the same sequence. - **Key presses** — `keydown` / `keypress` / `keyup`, including typing in a field and pressing Enter or Space on a focused control. All the events belonging to one logical action are grouped together into a single interaction, so a click that fires `pointerdown`, `pointerup` and `click` handlers is measured once, end to end, and not three times. The Event Timing API exposes that grouping through an `interactionId` shared by the events of one interaction. ## Which inputs do not qualify - **Scrolling.** Plain scrolling is excluded by design. In modern browsers scroll is frequently handled on the compositor, so it does not reflect main-thread responsiveness, and it would dominate the sample count on any long page. - **Hovering and mouse movement.** No interaction is generated; there is no discrete commitment by the user. - **Continuous gestures** such as dragging or pinch-zoom are not measured as interactions in their own right, though the initial press that starts a drag is. A useful test: if the user made a discrete decision and expects the page to *do something*, it counts. If they are just moving over the page, it does not. ## One number per visit An active page visit produces dozens or hundreds of interactions, but INP reports a single value for that visit — essentially the worst interaction the user experienced, with a small allowance for outliers on very interaction-heavy pages. That is a deliberate choice: an average would hide the one 900 ms tap that made the user think the app was broken, and users remember the worst moment, not the mean. That single value is then aggregated across many visits before anyone judges the page. The published bands, in force since INP became a Core Web Vital in 2024, are **200 ms or less = good**, **200–500 ms = needs improvement**, **above 500 ms = poor**, evaluated at the **75th percentile** of visits. So "our INP is good" is a statement about three quarters of real sessions, not about one click on your laptop. ## Why an interaction can have no INP at all If a user loads a page and reads it without clicking, tapping or typing, that visit contributes no INP value. Pages that are mostly read rather than operated therefore have sparser INP data than LCP data, and field reports may show INP for a fraction of the visits. ## Where the time actually goes Because the measurement ends at a paint, three separate things can make an interaction slow: waiting for a busy main thread before any handler starts, the handlers themselves running long, and the rendering work needed to show the result. A handler that returns in two milliseconds can still sit inside a 500 ms interaction if the page had to re-render an enormous list before the next frame could be produced. ## Common mistakes The frequent junior error is to assume INP is about load performance, or that it measures only the first interaction — that was the behaviour of the older FID metric. Another is to assume that smooth scrolling proves good INP; scroll jank is a real problem, but it is not what this metric reports. ```js // Every event of one click shares an interactionId; INP measures the group once. new PerformanceObserver((list) => { for (const e of list.getEntries()) { if (e.interactionId) console.log(e.name, e.duration); } }).observe({ type: 'event', buffered: true, durationThreshold: 16 }); ```
- If a user loads the page and never clicks or types, what INP does that visit report?None. INP is only produced when a qualifying interaction happens, so a read-only visit contributes no value. That is why field reports often show INP coverage on fewer visits than LCP, and why a page with heavy content but light interaction may have thin INP data.
- A single click fires pointerdown, pointerup and click handlers. Does INP count that as one interaction or three?One. The browser groups the events of a logical action under a shared interactionId and measures the whole group from the initial input to the next paint. The individual handler durations matter for diagnosis, but the reported interaction latency covers all of them plus the rendering that follows.
- Why is scrolling deliberately excluded from INP?Because it is usually handled by the compositor rather than the main thread, so it does not reflect the responsiveness INP is measuring, and because scroll events are so numerous they would drown out real interactions in the sample. Scroll jank is still worth fixing — it is just measured elsewhere.
saying these in an interview costs you the question
- Says scrolling smoothness counts toward INP
- Thinks INP only measures the first interaction on a page
- Describes INP as a page-load metric like LCP
- Claims hovering a menu generates an INP interaction
- Says INP is the average latency of all interactions