A user clicks a filter, and for half a second nothing happens. The button looks pressed, but the list doesn’t change, the spinner doesn’t appear, the page just sits there. Then everything updates at once. That gap between the tap and the visible response is what Interaction to Next Paint measures, and it is the Core Web Vital most likely to be failing quietly on a site that otherwise loads fast.
INP records the latency of interactions across the whole page lifetime and reports a single value that represents overall responsiveness. Good INP sits at or below 200 milliseconds. Anything above 500 milliseconds is poor, and a page in that range feels broken to users even when nothing is actually wrong. The metric replaced First Input Delay as a Core Web Vital on March 12, 2024, and that change matters more than it sounds, because the two metrics fail for different reasons and reward different fixes.
What INP Actually Measures #
FID measured only the first interaction on a page, and only the input delay portion of it. A site could pass FID with a fast first click and still frustrate users on every interaction after that. INP closes that gap by tracking clicks, taps, and key presses across the entire visit, then reporting the worst interaction (for pages with fewer than 50 interactions) or roughly the worst 2 percent (for pages with more). Scrolling and continuous gestures do not count.
Each interaction’s latency breaks into three phases, and knowing which one dominates is the whole diagnostic exercise:
- Input delay is the time between the user action and the event handlers starting. It exists when the main thread is busy with other work and cannot pick up the interaction yet.
- Processing time is how long the event handlers themselves run.
- Presentation delay is the gap between handlers finishing and the browser painting the next frame.
The thresholds apply at the 75th percentile, the same statistical basis as LCP and CLS. That percentile is why lab and field scores diverge so often: a developer on a fast machine sees a good number, while the slowest quarter of real users, often on mid-range phones, sees something much worse.
Why It Is Harder to Fix Than FID #
The old fix for FID was straightforward. First interactions usually happened early, while the main thread was busy parsing initial JavaScript, so lightening that initial load fixed the score. INP does not respond to that single lever, because the slow interaction can happen anywhere: a dropdown that triggers an expensive UI update, a search box that filters on every keystroke, a modal that loads content on open, a filter change that re-renders a product grid. Each of those is a separate failure mode, and a page can load fast, pass its first interaction, and still fail INP on the third click.
The mental shift is from “ship lighter JavaScript” to “keep every handler fast for the life of the page.” That is a discipline rather than a one-time fix, which is why INP tends to regress release after release when no one owns it.
The Recurring Causes #
Across most sites where INP gets diagnosed, the causes cluster into a handful of patterns.
Long-running event handlers are the first. A click handler that runs synchronous logic for 300 to 500 milliseconds blocks the next paint for exactly that long, whether it is processing data, manipulating the DOM, or forcing a framework to re-render many components at once.
Third-party scripts hogging the main thread come next. Analytics, ad tags, A/B testing tools, and support widgets all execute JavaScript on the main thread, and an interaction that trips their code can add hundreds of milliseconds the team never wrote.
Large rendering work after input is a third. The user clicks a filter, the framework re-renders 500 list items, and INP counts the full time until the result appears on screen.
Layout thrashing is quieter. A handler that reads a layout property, writes a style, then reads another property forces the browser to recalculate layout on each read, stretching the interaction across many frames. Synchronous third-party calls close out the list: a handler that makes a synchronous request or calls a heavy library function blocks until it returns, and the page appears frozen for the duration.
How to Diagnose It #
Diagnosis means finding which interactions are slow and which of the three phases is responsible, and that requires interaction-level data rather than a single score.
The Web Vitals JavaScript library is the practical starting point. It reports INP with attribution: the event type, the target element, and how long each phase took. Piping that to an analytics endpoint turns a failing aggregate score into a list of specific culprits.
The Chrome DevTools Performance panel is next. Recording a session while reproducing the slow interaction shows exactly which handlers ran, how long each took, and what blocked rendering, with poorly scoring interactions flagged in the overlay.
For ongoing visibility, real-user monitoring services such as SpeedCurve, Cloudflare Browser Insights, and New Relic capture INP from the field with per-page and per-interaction attribution. Because the metric is judged at the 75th percentile, field data is the ground truth; lab numbers routinely look better than what a quarter of users actually feel.
For deeper analysis, the Long Animation Frames API exposes detail about frames that ran longer than 50 milliseconds, including which scripts executed and what held up rendering. It maps directly onto the three phases, which makes it useful for deciding where to spend effort.
Fixing Each Phase #
Once attribution points to a phase, the remedies differ.
For input delay, the goal is a free main thread when input arrives. Break long tasks into chunks of 50 milliseconds or less and yield between them, either with scheduler.yield() where available or an awaited timeout, so the browser can service new input mid-task. Move heavy computation such as data processing or image work into Web Workers, and audit third-party scripts for main-thread time that can be deferred, replaced, or removed.
For processing time, make handlers do less synchronous work. A handler should update state and let the framework re-render asynchronously rather than rendering inline. Cache repeated computations, and use efficient logic in hot paths, since a filter looping over 10,000 items on every keystroke becomes noticeable fast. In component frameworks, the highest-value moves are memoizing genuinely expensive renders, virtualizing long lists so only the visible rows render, and debouncing search-as-you-type so a 300 millisecond delay collapses a hundred keystroke handlers into a handful.
For presentation delay, avoid layout thrashing by reading all layout properties before writing any styles, so the browser batches the writes. Prefer animating transform and opacity, which skip layout, over width, height, or position, which do not. Split large synchronous re-renders into smaller updates that spread across frames, and apply CSS contain so the browser can skip recalculating unaffected regions of the page.
Mobile deserves its own note. The same handler that runs in 80 milliseconds on a desktop can take 250 on a mid-range Android, and battery-saver modes throttle it further. Since the 75th percentile mobile experience often reflects hardware two or three years old, test on real or throttled lower-end devices rather than the developer’s high-end phone. Good mobile INP usually implies good desktop INP; the reverse is not reliable.
FAQ #
Is INP a ranking factor?
Yes. As a Core Web Vital it feeds Google’s page experience signals, and pages that fail at the 75th percentile can lose the small ranking and visibility benefit that passing pages get. It is one signal among many, not a decisive one, but a quiet regression can go unnoticed for weeks while affected pages drift.
Why does my lab score pass while field data fails?
Automated tests interact with a page in narrow, predictable ways and usually run on fast hardware. Real users click, type, and open modals in combinations tests never replicate, and a quarter of them are on slower devices. Field data at the 75th percentile is the number that matters.
What is a common INP mistake?
Carrying over FID-era thinking and optimizing only the first interaction. INP measures all of them, so a fast initial load with a slow filter handler still fails. Ignoring third-party scripts is the second common miss, since much of the delay comes from code the team did not write.
Do frameworks fix INP for me?
They help but do not decide it. React 18 concurrent rendering and Vue 3 async mechanisms can interrupt long renders to service input, and lighter frameworks reduce baseline overhead. Even so, a poorly written app in any framework has worse INP than a well-written one; debouncing, virtualization, and async work carry more weight than the framework label.
INP is the metric users feel directly, and diagnosing it is mostly a matter of finding the slow interaction and identifying which of the three phases owns the delay before reaching for a fix. Teams that keep it stable treat responsiveness as a product feature, with per-interaction budgets, regression checks in CI, and field alerts, the same way they already watch error rates. When that ownership is missing, the pattern repeats: a new feature regresses the score, the regression sits unnoticed, and the pages that felt slow start to look slow in the rankings too.