What is Interaction to Next Paint (INP), and how do you fix a slow score?
Interaction to Next Paint measures how fast your site responds to taps and clicks. What a good INP score is, why it gets slow, and how to fix it.
On this page8 sections
Short answer
Interaction to Next Paint (INP) measures how long your page takes to visibly respond after someone clicks, taps or presses a key. A good score is 200 milliseconds or less; above 500 milliseconds is poor. Slow INP almost always comes from too much JavaScript running on the main thread, and the fix is to do less work, or break it up so the browser can paint first.
You tap a menu button and nothing happens. You tap again. Then the menu opens and closes, because both taps landed. That half-second of nothing is what Interaction to Next Paint measures, and it's one of the three Core Web Vitals Google uses to describe page experience.
This guide explains what INP is in plain terms, how it's measured, what makes it slow, and what to fix first. Some of it gets technical; we've kept the code to one example.
What is Interaction to Next Paint?
Interaction to Next Paint is a responsiveness metric. According to web.dev, it observes the latency of every click, tap and keyboard interaction during a visit and reports a single value that represents how responsive the page was overall. Hovering, scrolling and zooming don't count.
The "next paint" part is the key idea. INP doesn't stop the clock when your code starts running. It stops when the browser actually shows the visitor something new on screen: the menu opening, the checkbox ticking, the spinner appearing. That's what a person experiences as "it responded."
INP thresholds
| INP score | Rating |
|---|---|
| 200 ms or less | Good |
| Over 200 ms, up to 500 ms | Needs improvement |
| Over 500 ms | Poor |
To pass, a page needs a good score at the 75th percentile of real visits, measured separately for mobile and desktop. In other words, three out of four visits should be at 200 milliseconds or better.
How the score is chosen
For most pages, INP is the slowest interaction during the visit. On pages with lots of interactions, the measurement ignores one of the highest values for every 50 interactions, so a single freak delay doesn't define the page.
INP replaced FID in March 2024
INP became a Core Web Vital on March 12, 2024, replacing First Input Delay (FID). The change mattered. FID only measured the delay before the browser started handling the first interaction. INP measures every interaction, all the way to the next paint. Plenty of sites that passed FID easily fail INP, because the slow part was always the work after the click, not the wait before it.
Does INP affect rankings?
Somewhat, and it's worth keeping in perspective. Google says Core Web Vitals are used by its ranking systems, and its guidance asks for an INP under 200 milliseconds. It also says "Google Search always seeks to show the most relevant content, even if the page experience is sub-par."
So a great INP won't rescue a page that doesn't answer the search. But a slow, frustrating page loses visitors whether Google notices or not. People who tap "Get a quote" and wait often don't wait twice. That's the stronger reason to fix it.
How to check your INP score
- PageSpeed Insights. Enter a URL and look at the field data at the top. That's real-user data from the Chrome UX Report (CrUX), if your page gets enough traffic to have it.
- Search Console. The Core Web Vitals report groups your URLs into good, needs improvement and poor, for mobile and desktop.
- Real user monitoring. For sites with less traffic, or to see which specific interactions are slow, a real-user monitoring tool or Google's open-source
web-vitalsJavaScript library can report INP from your own visitors, including which element was clicked. - Chrome DevTools. The Performance panel lets you record an interaction and see exactly what ran on the main thread.
A standard lab test of page load can't measure INP, because nobody is clicking anything. Use lab tools to find heavy JavaScript, then confirm with field data.
The three phases of an interaction
Every interaction has three parts, and each one has different causes and fixes.
- Input delay. The time between the tap and your event handlers starting. If the browser's main thread is busy with something else, the tap waits in line.
- Processing duration. The time your event handlers take to run.
- Presentation delay. The time from the end of your code to the browser painting the next frame: recalculating styles, laying out the page and drawing it.
Common causes of a slow INP and how to fix them
Input delay: the main thread is busy
The usual culprit is long tasks. A long task is any piece of work that holds the main thread for more than 50 milliseconds. While it runs, taps and clicks wait.
Common sources on business websites:
- Analytics, ad, heatmap and chat scripts all loading and running at once
- Tag managers with years of accumulated tags nobody has reviewed
- Large JavaScript bundles parsing and executing during page load
- Sliders, animations and pop-ups that run code on a timer
Fixes: remove scripts you don't use, delay non-essential third-party scripts until after the page is interactive, and break big chunks of work into smaller tasks. Auditing a tag manager is often the fastest win on a marketing site.
Processing duration: your event code does too much
When someone clicks, the code that responds often does everything at once: update the screen, send analytics, save state, recalculate a list. The visitor only needs the first thing to happen right away.
The fix is to do the visible update first, then yield to the main thread so the browser can paint, then run the rest. Here's the pattern, based on the approach in web.dev's INP optimization guide:
function yieldToMain() {
if (globalThis.scheduler?.yield) {
return scheduler.yield();
}
return new Promise((resolve) => setTimeout(resolve, 0));
}
filterButton.addEventListener('click', async () => {
showLoadingState(); // visible feedback first
await yieldToMain(); // let the browser paint
applyFilters(); // heavy work afterwards
sendAnalyticsEvent(); // non-urgent work last
});scheduler.yield() is a newer browser API built for this; Chrome added it in version 129. Not every browser supports it, which is why the example falls back to setTimeout.
Also watch for layout thrashing: reading a size or position from the page right after changing styles, in the same task, forces the browser to recalculate layout immediately. Batch your reads and writes.
Presentation delay: the page is expensive to draw
Big, deeply nested pages take longer to re-render after every change. Web.dev notes that large DOMs require more rendering work, both on load and during interactions.
Fixes:
- Keep the page's HTML lean. Page builders that wrap every element in several layers of containers are a frequent cause.
- Use the CSS
content-visibilityproperty to skip rendering long off-screen sections until they're needed. - Avoid rendering large chunks of HTML with JavaScript in response to a click when the server could have sent it.
- Be careful with animations and effects that trigger layout on every frame.
Where small business sites usually go wrong
In our experience, slow INP on a marketing site rarely comes from the site's own code. It usually comes from:
- Third-party scripts. Chat widgets, review widgets, booking embeds and tracking pixels, often several doing similar jobs.
- Heavy themes and page builders. Lots of JavaScript and a very large DOM on every page, whether the page needs it or not.
- Mobile menus and accordions that run expensive code when opened.
- Cookie consent banners that block the main thread while they set themselves up.
Checking these four areas first is usually the quickest route to a better score, often without touching the design.
What we'd do
- Check Search Console's Core Web Vitals report to see which page groups fail INP on mobile.
- Open the worst template in PageSpeed Insights and note the field INP.
- Record the slowest interactions in Chrome DevTools, usually the mobile menu, forms and filters.
- Audit third-party scripts and remove or delay anything non-essential.
- Fix the specific handlers that do too much, using the yield pattern above.
- Re-check field data after a few weeks. The Chrome UX Report is a 28-day rolling average, so improvements take time to show.
If your INP problems come from the theme or builder itself, that's a foundation problem rather than a tuning one. Our post on when a redesign makes sense covers that call. And if you'd rather have a site that's fast by default, performance is part of how our web design team builds every site, not a fix bolted on afterwards.
