Short answer: Interaction to Next Paint (INP) measures how quickly a page responds when someone clicks, taps or presses a key. It reports the slowest interaction of the visit, ignoring outliers. A good INP is 200 milliseconds or less, and over 500 is poor.
What INP counts
Only three kinds of interaction count: clicking with a mouse, tapping a touchscreen and pressing a key. Hovering, zooming and scrolling don’t, although a gesture that includes a click or tap does. Clicks inside embedded iframes count too, such as pressing play on an embedded video.
The final value is the longest interaction of the visit. On pages with many interactions, one of the highest is left out for every 50, so a single hiccup doesn’t decide the result. The page’s INP is calculated when the visitor leaves it. INP replaced First Input Delay, which only measured the input delay of the first interaction.
The three parts of an interaction
Every interaction INP measures runs from the input until the browser paints the next frame, in three parts.
| Part | What it covers | What makes it long |
|---|---|---|
| Input delay | From the click, tap or key press until the event handlers start | Long tasks on the main thread, such as scripts loading |
| Processing duration | The time all the event handlers take to run | Heavy work inside those handlers |
| Presentation delay | From the end of the handlers until the next frame appears | Rendering work, which grows with a large DOM |
From web.dev, “Interaction to Next Paint (INP)” and “Optimize Interaction to Next Paint”, read November 3, 2026.
How to fix slow interactions
- Find your slow interactions in field data, because lab tools usually load the page without clicking anything.
- Reproduce a slow interaction in the lab and see which of the three parts takes longest.
- Cut long tasks on the main thread, especially from scripts that run while the page loads.
- Do as little work as possible inside event handlers.
- Yield to the main thread often, for example with setTimeout, so other work can run in between.
- Update what the visitor sees first, then yield before the rest of the work.
- Keep the DOM small, and use content-visibility to render off-screen content later.
To find your field data, see our guides to Core Web Vitals and PageSpeed Insights.
INP on our own pages
A standard lab test can’t give you INP, because it loads the page without clicking anything. web.dev calls Total Blocking Time a reasonable proxy for INP, but not a substitute, so that’s what we looked at. We measured it on November 3: two readings per page, on four pages, from PageSpeed Insights for mobile.
The results moved a lot between runs. Our SEO services page stayed at 20 to 38 milliseconds, while our robots.txt guide went from 306 to 1,391, with 7 and 17 long tasks.
In the slow run, the four longest tasks came from marketing tags: two from the Google tag, of 504 and 312 milliseconds, and two from the Meta pixel, of 325 and 268. While a task like that runs, a click has to wait: that is the input delay web.dev describes.
Before you call your INP fixed
- You know your INP from field data.
- Long tasks don’t block the main thread while the page loads.
- Event handlers do the visible work first.
- Long work yields to the main thread.
- The DOM stays small.
- Off-screen content renders later.
RememberINP is about the slowest response of the visit, not the average. Find the interactions that take longest, see which part slows them down, and fix that part first.
If clicks on your site feel slow, see what our web design service covers.
Quick answers about INP
What is a good INP?
web.dev rates 200 milliseconds or less as good, more than 500 as poor, and anything between as needing improvement. The target is for real visits at the 75th percentile, on mobile and on desktop.
Does scrolling count toward INP?
No. INP only observes clicks, taps and key presses. Scrolling, zooming and hovering aren’t measured, although some of those gestures include a tap or click that INP does count.
Why doesn’t PageSpeed Insights show my INP?
INP needs real interactions, so it only shows up in field data from real visitors, when there’s enough of it. The lab test loads the page without clicking anything, and its Total Blocking Time is only a proxy.
What did INP replace?
First Input Delay. FID only measured the input delay of the first interaction on a page. INP looks at every click, tap and key press of the visit, from the input until the next frame is painted.
Can a big DOM slow down INP?
Yes. web.dev notes that rendering work tends to grow with the size of the DOM, which lengthens the wait before the next frame. Keeping the DOM small and rendering off-screen content later both help.
Sources
Read on November 3, 2026. web.dev: Interaction to Next Paint (INP) and Optimize Interaction to Next Paint. Our own case: Total Blocking Time and long tasks on four of our pages, measured with PageSpeed Insights on November 3, 2026.