Interaction to Next Paint (INP) measures how quickly a page responds when someone clicks, taps or presses a key. Specifically, it tracks the time from the interaction until the browser shows the next visual update, like a menu opening or a button changing state. It's one of Google's three Core Web Vitals.
For businesses, INP captures a frustration that older speed metrics missed: pages that look loaded but feel stuck. If "Add to cart" or a product filter takes a beat too long to respond, people tap again, give up or start to doubt the site.
What is Interaction to Next Paint?
web.dev's INP guide says the metric "assesses a page's overall responsiveness to user interactions" by observing clicks, taps and keyboard interactions throughout a visit. Hovering, scrolling and zooming aren't measured on their own.
INP reports roughly the slowest interaction on the page. To avoid punishing busy pages for one random hiccup, it ignores one highest interaction for every 50 interactions. Google then looks at the 75th percentile across page views, split by mobile and desktop.
The thresholds are:
- Good: 200 milliseconds or less
- Needs improvement: more than 200 milliseconds, up to 500 milliseconds
- Poor: more than 500 milliseconds
As of March 12, 2024, INP is officially a Core Web Vital, replacing First Input Delay (FID). If you still see advice built around FID, it's out of date.
Why INP matters
It measures the whole visit. FID only measured the delay before the browser started handling the first interaction. INP looks at clicks, taps and key presses across the visit, and includes the time to process each one and paint the result. That gives a much fuller picture of how a page feels to use.
It's part of Google's page experience signals. Google's page experience documentation says "Core Web Vitals are used by our ranking systems," while noting that good scores alone don't guarantee top placement.
It matters most on the pages that convert. Pages with lots of interactivity, like ecommerce filters, booking forms, quote calculators and checkout steps, give INP more to measure. These are often the pages closest to a sale, so slow responses there can affect your conversion rate.
How INP works
Three phases of every interaction
web.dev breaks each interaction into three parts:
- Input delay: the wait before the page's event handlers can start running, often because the main thread is busy with other JavaScript.
- Processing duration: the time the event handlers take to run.
- Presentation delay: the time from when the handlers finish until the next frame appears on screen.
Any of the three can be the bottleneck. A button's own code can be fast and still feel slow if another script is occupying the main thread when the user taps.
Why JavaScript is usually involved
Browsers handle most page work on a single main thread. While a long task is running, the browser can't respond to input until it finishes. web.dev's guide to optimizing INP recommends breaking work into smaller tasks and yielding to the main thread, noting that "yielding indiscriminately is better than not yielding at all."
Rendering approach and hydration
Sites that render on the server and then hydrate with JavaScript can show content quickly but stay unresponsive while scripts run. web.dev's rendering guide warns that hydration "can have a significant negative impact on TBT and INP, even if it improves FCP." Our server-side rendering entry covers the trade-offs.
Single-page apps
In October 2026, Chrome added experimental soft-navigation metrics to the Chrome UX Report, including an INP variant that accounts for in-app navigations on single-page apps. Google says stable Core Web Vitals scores are unchanged while these are evaluated.
How to improve INP
- Find slow interactions in the field. Search Console's Core Web Vitals report flags groups of URLs with poor INP. Real-user monitoring tools can show which specific interactions are slow.
- Audit third-party scripts. Remove tags you no longer use, and delay non-essential ones like chat widgets until after the page is usable.
- Break up long tasks. Split heavy JavaScript into smaller chunks and yield to the main thread between them.
- Give instant feedback. Update the interface first, such as showing a loading state, then do the heavier work.
- Avoid layout thrashing. web.dev warns against updating styles and then immediately reading layout values in the same task, which forces extra work.
- Keep the DOM lean. web.dev notes that a large DOM can delay the next frame after an interaction.
Common mistakes and misconceptions
"A lab test will catch INP problems." INP depends on real interactions. A standard Lighthouse page-load test doesn't include them, so it can't report your site's INP. Field data is the source of truth.
"INP is just FID with a new name." FID measured only the input delay of the first interaction. INP covers interactions across the visit and all three phases of each one.
"Our page loads fast, so INP is fine." Loading and responsiveness are different. A page can have a good Largest Contentful Paint and still respond slowly to taps.
"Only developers need to care." Marketing teams often add the scripts that compete for the main thread: tag managers, pixels, heatmaps and chat tools. A periodic tag audit is a shared job.
INP vs. First Input Delay
FID measured how long the browser waited before it could begin processing the first interaction on a page. INP measures the full time from interaction to visual response, across interactions throughout the visit, and reports one of the slowest. INP is the stricter and more complete measure, which is why Google made the switch.
How Butter approaches INP
At Butter, we look at Core Web Vitals as part of technical health, alongside crawlability and indexing, rather than as a standalone vanity score. We start with field data from Search Console, because that is what reflects your real visitors, then use lab tools to find the cause.
On our GEO+SEO plan, technical SEO fixes and unlimited on-page optimization give us room to address issues like heavy scripts on key templates. The Butter Analytics dashboard connects to Google Search Console and Google Analytics, so you can see whether changes hold up over time. On the GEO plan, we include performance issues in our monthly on-page recommendations. Better responsiveness improves the experience for every visitor and can help in search, but we never promise rankings from speed work alone. See our SEO services page for details.
Frequently asked questions
What is a good INP score?
Google considers an INP of 200 milliseconds or less good, more than 200 and up to 500 milliseconds needs improvement, and more than 500 milliseconds poor, measured at the 75th percentile of page views on mobile and desktop.
When did INP replace FID?
INP officially replaced First Input Delay as a Core Web Vital on March 12, 2024. Google's three Core Web Vitals are now Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift.
What causes poor INP?
Usually, JavaScript is keeping the browser's main thread busy, so it can't respond to input quickly. Heavy third-party scripts, slow event handlers, layout thrashing and very large pages can all contribute.
Can I measure INP in Lighthouse?
A standard Lighthouse page-load test doesn't include real interactions, so it can't report your site's INP. Use field data from Search Console, PageSpeed Insights or real-user monitoring, and use Chrome DevTools to reproduce and debug slow interactions.