Interaction to Next Paint (INP) is the Core Web Vital for responsiveness. It observes the latency of clicks, taps and keyboard interactions throughout a visit and reports one of the slowest, measuring from the input to the next frame the browser paints. Good INP is 200 milliseconds or less and poor is above 500 milliseconds, at the 75th percentile. It replaced First Input Delay in March 2024.
What INP measures
Each interaction has three phases: input delay (waiting for the main thread to be free), processing duration (running the event handlers), and presentation delay (the browser recalculating layout and painting the update). INP covers all three, unlike First Input Delay, which only measured the first input delay.
For most pages INP is the worst interaction in the visit. On pages with many interactions, the metric skips the single highest per 50 interactions to discount outliers. Scrolling and hovering are not counted.
Why it can only be measured in the field
INP needs real interactions, so Lighthouse cannot report it from a page load. Field data from CrUX, or your own real-user monitoring with the web-vitals JavaScript library, is the source of truth. In the lab, Total Blocking Time is a useful proxy, and Chrome DevTools can record interactions to show which handlers are slow.
import { onINP } from "web-vitals/attribution";
onINP(({ value, attribution }) => {
// Send the value and the slow element to your analytics
sendToAnalytics({ inp: value, target: attribution.interactionTarget });
});Common causes and fixes
The fix is almost always less work on the main thread at the moment of interaction.
- Long tasks from third-party scripts: delay or remove chat, recording and tag-manager scripts
- Heavy hydration in JavaScript frameworks: reduce client components, split bundles
- Expensive event handlers: do the visible update first and defer the rest
- Large DOM sizes that make each re-render and layout slow
- Breaking up long tasks so the browser can paint between chunks
Example
A pricing toggle that lagged
Suppose a fictional observability SaaS, Tracewell, has a monthly/annual toggle on its pricing page that recalculates every plan, re-renders a large feature comparison table, and fires several analytics events in the same handler. On mid-range phones the toggle visibly hesitates.
Updating the visible prices first, then deferring the analytics calls and the table re-render to after the next paint, shortens the interaction without changing what the visitor sees.
Common mistakes
Relying on Lighthouse alone
Lighthouse cannot measure INP. A page with a perfect lab score can still fail INP in the field.
Adding scripts without a budget
Every new third-party tag adds main-thread work. Review tags regularly and remove ones nobody uses.
Questions
FID measured only the input delay of the first interaction. INP measures the full latency of interactions across the whole visit, so it captures more of the real experience.
Phones have slower CPUs, so the same JavaScript takes longer. Mobile and desktop are assessed separately.
Not on its own. SSR mostly helps loading. INP depends on how much JavaScript runs during and after hydration, so SSR helps only if it also means less client-side work.
