The short answer
Interaction to Next Paint is a Core Web Vital. It records how long each interaction takes to produce a visible response, from the click or tap until the browser paints the next frame, and your score reflects close to the slowest interaction in the visit. Aim for 200 milliseconds or less at the 75th percentile of real visits.
Nearly every INP problem is the main thread being too busy to respond. The fix is to find the specific slow interaction in field data, reproduce it in the DevTools Performance panel, then cut the work the browser has to do before it can paint.
- Good INP is 200ms or less. 200ms to 500ms needs improvement, above 500ms is poor.
- Field data tells you a page has an INP problem. The DevTools Performance panel tells you which interaction and why.
- Break up any task over 50ms and yield the main thread so the browser can respond and paint.
What Counts as a Good Score
Google puts every page into one of three bands, judged at the 75th percentile of visits. That percentile matters: roughly the worst quarter of your real interactions has to stay under the threshold, which is why a page that feels fine on your laptop can still fail in the field.
Good
≤ 200ms
The response feels instant. The browser paints a visible change almost as fast as the user acts.
Needs improvement
200 to 500ms
A noticeable lag. Common on pages running heavy, unchunked JavaScript on the main thread.
Poor
> 500ms
The page feels unresponsive. Users tap again, assume it is broken, or leave.
An Interaction Has Three Parts
Every interaction INP measures breaks into three stretches of time. Fixing INP means knowing which one is slow, because the remedy is different for each. The DevTools Performance panel labels all three when you record an interaction.
Input delay
The time from the moment someone interacts until your event handlers can start running. This is usually the main thread being busy with other work.
How to shorten it: Break up long tasks during load, and ship less JavaScript so the thread is free when the click arrives.
Processing duration
The time your event handlers take to run once they start. Heavy work inside a click or input handler lands here.
How to shorten it: Do only the work needed to update the screen now. Defer analytics, logging and other non-urgent work until after the next paint.
Presentation delay
The time the browser needs to recalculate layout and paint the next frame after your code finishes.
How to shorten it: Keep the DOM small, avoid large style and layout recalculations, and prefer CSS over JavaScript for visual changes.
Find the Slow Interaction Before You Change Code
INP only appears with real interactions, so you cannot see it from a standard page-load test. Diagnose in two stages: field data to find out that a problem exists and where, then the lab to find out why.
- Confirm it in the field. Open the Core Web Vitals report in Search Console, or run the page through PageSpeed Insights, which both read the Chrome User Experience Report. This tells you which page groups fail INP, on mobile and desktop separately.
- Reproduce it in the lab. Open the Chrome DevTools Performance panel, start recording, and perform the interaction that feels slow. The recording shows an interaction entry split into input delay, processing and presentation, so you can see exactly where the time went.
- Know the proxy, and its limit. Lighthouse does not measure INP, because it is a load-time lab tool and INP needs real input. Its Total Blocking Time score correlates with responsiveness and is a reasonable early signal, but the Performance panel is where you attribute an actual slow interaction.
For the metrics that precede this work, see measuring PageSpeed and Core Web Vitals, and the companion guides on Largest Contentful Paint and Cumulative Layout Shift.
Breaking Up Long Tasks
A long task is any single piece of work that holds the main thread for more than 50 milliseconds. While one runs, the browser cannot start handling a click or paint a response, so long tasks are the most common cause of poor INP. The fix is to split the work into smaller chunks and hand the main thread back between them.
The modern tool for this is scheduler.yield(). It pauses your task, lets the browser respond and paint, then resumes where you left off. It is not in every browser yet, so pair it with a setTimeout fallback.
// GOOD: yield the main thread between chunks of work
async function saveItems(items) {
for (const item of items) {
process(item);
await yieldToMain(); // let the browser respond and paint
}
}
// Use scheduler.yield() where available, fall back to setTimeout
function yieldToMain() {
if ("scheduler" in window && "yield" in window.scheduler) {
return window.scheduler.yield();
}
return new Promise((resolve) => setTimeout(resolve, 0));
}Two more wins come from the other parts of the interaction. In the event handler, run only what updates the screen now and push non-urgent work, such as analytics calls, to after the next paint. For presentation delay, keep the DOM shallow and avoid reading a layout property right after writing one, which forces the browser to recalculate layout synchronously. A related saving is to remove unused JavaScript so there is less to parse and run in the first place.
A Worked Example
Illustrative scenario
An online store fails INP on mobile. The Search Console Core Web Vitals report flags the product listing pages, with a 75th percentile INP around 420ms. Here is how the two-stage process turns that into a fix.
- Reproduce: on a throttled mobile profile in the DevTools Performance panel, the team records tapping a filter. The interaction entry shows most of the time in processing.
- Attribute: the filter handler re-sorts the entire product array and re-renders every card in one synchronous task, well over 50ms.
- Fix processing: the handler now updates only the filter state and the visible cards, and yields before the heavier re-sort so the UI responds immediately.
- Fix presentation: a forced synchronous layout, reading an element height inside the render loop, is moved out, so the browser paints in one pass.
- Confirm: field INP for those pages moves back under 200ms over the following weeks as new visits are recorded.
The lesson is that the fix followed the diagnosis. The team did not guess at the DOM or rewrite the whole page. They found the one slow interaction, saw which of the three parts was long, and changed only that.
An INP Readiness Checklist
No long tasks during interactions
No single main-thread task runs longer than 50ms while the user is clicking, tapping or typing.
Handlers do only urgent work
Event handlers update what the user needs to see now. Analytics, logging and heavy recomputation are deferred to after the next paint.
Work is chunked and yields
Long operations are split into chunks that yield the main thread with scheduler.yield(), with a setTimeout fallback.
Rendering stays cheap
The DOM is shallow, there are no forced synchronous layouts in render loops, and visual changes use CSS rather than JavaScript where possible.
Field data confirms it
The 75th percentile INP in the Chrome User Experience Report is under 200ms on both mobile and desktop, not just in a local test.
Did the Fix Move Anything?
Murkuz does not measure Core Web Vitals, you fix INP with the tools above. What Murkuz does is connect Google Search Console, Analytics 4 and Bing to Claude or ChatGPT, so once a fix is live you can ask whether the pages you touched held their rankings and clicks. Point Live_Traffic_Drops and Page_Search_To_Behaviour at those URLs and read the before and after. Reading your own data is unmetered.
Further reading
The primary sources on INP, starting with the Chrome team's own documentation. Each one was opened and read before it was listed here.
Official docsweb.dev
Interaction to Next Paint (INP)The canonical definition from the Chrome team. It sets the 200ms / 500ms thresholds, explains the three parts of an interaction, and shows why INP is measured at the 75th percentile of real visits.
Official docsweb.dev
Optimize Interaction to Next PaintThe step-by-step optimisation manual. Work through it in order: find the slow interactions in the field, reproduce them, then reduce input delay, processing time and presentation delay one at a time.
Official docsweb.dev
Optimize long tasksThe clearest explanation of why a single task over 50ms freezes the page, and the patterns for breaking work into chunks and yielding the main thread back to the browser.
Official docsMDN Web Docs
Scheduler: yield() methodThe reference for scheduler.yield(), the modern way to hand the main thread back mid-task and resume where you left off. Check the browser-support table before you rely on it without a fallback.
Official docsGoogle Search Central
Understanding Core Web Vitals and Google Search resultsGoogle's own statement of how Core Web Vitals, INP included, feed into ranking through the page experience signals, and the reminder that relevant content still comes first.
Frequently Asked Questions
What is Interaction to Next Paint (INP)?
INP is a Core Web Vital that measures how responsive a page feels. For each click, tap or key press during a visit, it records the time from the interaction until the browser paints the next frame that shows a visual response. Your page's INP is close to the slowest of those interactions across the whole visit, so it captures the responsiveness of the entire session rather than a single moment. On March 12, 2024, INP replaced First Input Delay (FID) as the Core Web Vital for responsiveness.
What is a good INP score?
An INP of 200 milliseconds or less is good. Between 200ms and 500ms needs improvement, and above 500ms is poor. Google assesses the score at the 75th percentile of page loads across mobile and desktop, which means roughly the worst quarter of your real visits has to stay under the threshold, not just the average.
Why did INP replace First Input Delay (FID)?
FID only looked at the very first interaction on a page, and only at the delay before the browser could start handling it. It said nothing about how long the work took or whether the screen actually updated. INP looks at interactions throughout the visit and measures the full path from the input to the next paint, so it reflects how the page feels to use rather than just how fast it accepts the first click.
How do I find what is causing poor INP?
Start with field data, because INP only shows up with real interactions. The Core Web Vitals report in Search Console and a tool like PageSpeed Insights tell you which page groups have an INP problem using data from the Chrome User Experience Report. Then reproduce it in the lab: open the Chrome DevTools Performance panel, record while you perform the slow interaction, and read the interaction entry to see whether the time went into input delay, processing or presentation. Lighthouse does not measure INP directly, since it is a load-time lab tool, but its Total Blocking Time score is a useful correlated proxy.
How do I fix main-thread blocking for better INP?
Most INP problems trace back to long tasks: any single task that holds the main thread for more than 50 milliseconds. Break that work into smaller chunks and yield the main thread back to the browser between them, so it can respond to the user's input and paint. Use scheduler.yield() where it is available, with setTimeout as a fallback. Also do less in the event handler itself: run only the work needed to update the screen now, and defer anything non-urgent until after the next paint.
Is INP a Google ranking factor?
Yes, as part of Google's page experience signals, which include the Core Web Vitals. Google is clear that it is a lighter signal than relevance and quality: a fast page will not outrank a genuinely more helpful one. INP is still worth fixing, because responsiveness affects whether people stay and act, and because it can act as a tiebreaker between pages that are otherwise close.
Does INP behave differently on mobile and desktop?
Yes. Mobile devices have slower processors, so main-thread work that feels instant on a laptop can push mobile interactions over the threshold. The Chrome User Experience Report measures mobile and desktop separately, and Search Console splits its Core Web Vitals report the same way, so check both. In practice mobile is where most INP failures appear and where the fixes matter most.