Interaction to Next Paint, or INP, is the Core Web Vital that asks a simple question: when someone interacts with your page, how long until they see something happen? The definitive reference is Google’s own web.dev article on INP, which describes it as “the successor metric to First Input Delay (FID)”. This post covers the thresholds, what counts as an interaction, the three phases that make up the number, and where to look when it is poor. It also argues that INP is mostly a JavaScript problem, which changes who on your team should own it.
The INP thresholds
INP is scored in three bands. The figure that counts is the 75th percentile of page views, so a page passes only when at least three in four visits see a response at or under the threshold. A fast experience on your own laptop proves very little.
| Rating | INP at the 75th percentile | What it usually means |
|---|---|---|
| Good | 200 ms or less | Interactions feel immediate |
| Needs improvement | More than 200 ms, up to 500 ms | Noticeable lag on some devices or pages |
| Poor | More than 500 ms | Users see clicks that seem to do nothing |
The 75th percentile matters more than the threshold itself. Your slowest quarter of visits is often people on mid-range phones, with several tabs open, on pages heavy with third-party scripts. That is the audience INP is built to represent, and it is rarely the audience testing the site before launch.
First Input Delay vs Interaction to Next Paint
First Input Delay measured only the first interaction on a page, and only the wait before the browser began handling it. INP replaced it because that was a narrow view. A page could respond quickly to the first tap and then lag on every filter, menu and form field afterwards, and FID would still call it good.
INP looks at the interactions across the visit and measures the full path to the next frame, not just the opening delay. The interactions it counts are specific: clicking with a mouse, tapping on a touchscreen and pressing a key. Scrolling, hovering and zooming are not counted. If your page feels janky while scrolling, that is a real problem, but it is not the problem INP reports.
The three phases of an interaction
Every interaction INP measures splits into three phases. Knowing which phase is slow tells you what to fix, so it is worth separating them before touching any code.
Input delay is the time between the user’s action and the moment your event handlers start running. It is long when the main thread is already busy with something else, such as a script still parsing or a timer doing work in the background. The user’s tap simply waits in line.
Processing duration is the time your event handlers take to run. This is the phase developers usually think of first: a click handler that filters a large list, recalculates state across a component tree or writes to analytics before doing the visible work.
Presentation delay is the time from the handlers finishing to the browser painting the next frame. Large DOM updates, expensive layout and style recalculation all land here. A handler can be quick and the interaction still slow if it triggers a costly re-render.
How to measure interaction to next paint
Start with field data, because that is what the threshold applies to. The Core Web Vitals report in Search Console groups URLs by status, and real-user data from the Chrome UX Report sits behind it. If your page or origin has enough traffic, you will see an INP figure there. If a report is already showing failures, our guide to a failed Core Web Vitals assessment covers how to read it.
Field data tells you that something is slow, not what. For that you need to reproduce the interaction in the lab. Open the browser’s performance panel, throttle the CPU to approximate a slower phone, record, and perform the click or tap you suspect. The recording shows what ran on the main thread and how long each piece took, which maps directly onto the three phases above.
If you can, collect INP from your own users with a real-user monitoring script that also records which element was interacted with. Knowing that the slow interactions are the mobile menu or the add-to-basket button narrows the search far faster than a page-level score.
How to improve interaction to next paint
The received wisdom is that page speed is a hosting problem: buy a faster server, add a CDN, compress the images. Those help loading metrics. They do little for INP, which is decided after the page has loaded, on the user’s own device, by how much JavaScript competes for the main thread. That makes INP a front-end engineering problem first.
For a long input delay, reduce what runs in the background. Audit third-party scripts, defer anything not needed for the first interaction and break long tasks into smaller pieces so the browser can respond in between. For a long processing duration, do the visible update first and push non-urgent work, such as analytics calls, until after the next paint. For a long presentation delay, update less of the DOM per interaction and avoid layout thrashing.
Frameworks deserve particular scrutiny. Heavy client-side rendering and hydration can keep the main thread busy well after the page looks ready, which is when users start clicking. Our post on JavaScript SEO covers the rendering trade-offs from the search side; the same choices show up here as input delay.
How much INP matters for rankings
INP is part of Core Web Vitals, so it feeds into Google’s page experience signals. That does not make it a large ranking lever. As our post on page speed and SEO sets out, Google has described Core Web Vitals as a small factor, and relevance outweighs it. Fixing a poor INP score is unlikely to lift a page that does not answer its query.
The stronger case is the user. A button that seems not to respond gets tapped twice, a form that lags gets abandoned, and a menu that opens late makes a site feel broken. Those costs show up in conversions and return visits whether or not they show up in rankings.
One limitation to keep in mind: field data needs volume. Low-traffic pages may have no INP figure of their own, and Search Console may only report a grouped or origin-level value. In that case your lab recordings are an approximation of what real users see, not a measurement of it. Fix the slow interactions you can reproduce, then watch the field figure over the following weeks rather than expecting it to move the day you deploy.
Frequently asked questions
What is a good INP score?
200 milliseconds or less at the 75th percentile of page views. Above 500 milliseconds is rated poor.
Does scrolling count towards INP?
No. INP counts mouse clicks, taps on a touchscreen and key presses. Scrolling, hovering and zooming are not included.
What replaced First Input Delay?
Interaction to Next Paint. Google describes INP as the successor metric to First Input Delay.
Will a faster server fix a poor INP score?
Rarely. INP is mostly decided by JavaScript running on the user’s device after the page loads, so the fixes are usually front-end.
The takeaway Find which interactions are slow, split them into input delay, processing and presentation, and fix the JavaScript behind them. Do it for users first; rankings are a smaller reward.
