INP measures the latency of every discrete user interaction — clicks, taps, and key presses — and reports the worst-case response time observed during the session. It replaced First Input Delay (FID) as a Core Web Vital in March 2024.
Where FID only captured the delay before the browser began processing the first input, INP covers the full duration from input to the next paint for every interaction throughout the page's lifetime. A high INP means the page feels sluggish or unresponsive even after it has fully loaded.
How Witnes captures it
Witnes uses a PerformanceObserver listening for event entries with
buffered: true. For each interaction, the observer records the time from when the
input was received to when the browser committed the next frame. The maximum observed value across
all interactions in the session is reported as INP.
For SPA navigations, Witnes resets the INP accumulator on each route change so that the reported value reflects only the interactions that occurred on the current page.
What good looks like
Witnes uses the same thresholds as Google Web Vitals:
| INP | Rating |
|---|---|
| ≤ 200 ms | Good |
| 201 – 500 ms | Needs Improvement |
| > 500 ms | Poor |
The 200 ms threshold is based on research showing that users perceive responses under 200 ms as instantaneous. Responses between 200–500 ms feel slightly delayed but still acceptable. Anything above 500 ms is noticeably slow and erodes trust in the interface.
INP in other scores
INP is recorded per page load and surfaced in session detail views. It is not currently used in the Sentiment Score calculation.