Interaction to Next Paint
Interaction to Next Paint measures how long a page takes to show a visual response after somebody clicks, taps or presses a key. It observes every interaction during the visit and reports close to the worst one, so a single badly handled click can define the score for the whole session.
Good
Under 200ms
Needs work
200ms to 500ms
Poor
Over 500ms
Why it matters
INP replaced First Input Delay as a Core Web Vital in March 2024, and it is a far harder test. First Input Delay only measured the delay before the handler started on the very first interaction. INP measures the full path from input to the next frame painted, across every interaction. That is what people experience as responsiveness: a button that highlights instantly feels solid, one that takes half a second feels broken, and they click again.
How it is measured
The browser records the time from the user input to the next frame that reflects a change, including the input delay, the handler processing and the rendering work that follows. Most pages report the 98th percentile of their interactions, which means the metric is deliberately sensitive to the worst cases rather than the average.
What makes it slow
Long tasks blocking the main thread
The main thread handles input, script execution, layout and painting, and it does one thing at a time. Any task over 50 milliseconds means an interaction arriving during it has to wait. A 400 millisecond hydration pass makes every click in that window feel dead.
Expensive event handlers
Work done synchronously inside a click handler happens before the browser can paint. Filtering a large list, writing to localStorage, or triggering a synchronous layout read all push the next frame further away.
Large DOM and heavy style recalculation
When a handler changes something that invalidates a large tree, the browser has to recalculate styles and lay out again before it can paint. On a page with several thousand elements this can dominate the measurement even though the handler itself was fast.
Third party scripts
Analytics, tag managers, chat widgets and A/B testing tools run on the same main thread as your own code. They are a frequent cause of long tasks that are invisible in your own source.
Hydration on framework pages
Server rendered pages look interactive before they are. If a visitor clicks during hydration, the interaction queues behind it, which is why INP is often worst in the first seconds of a visit.
How to improve it
Ordered roughly by return on effort. The quick wins are usually worth doing first even when the deeper problem is elsewhere.
Yield to the main thread inside long handlers
Quick winBreak work into chunks and let the browser paint between them, with scheduler.yield where available or a task split via setTimeout. Showing the visual response first and doing the work after is almost always the right order.
Give immediate visual feedback
Quick winApply the pressed state, the spinner or the optimistic update before the expensive work begins. INP measures time to the next paint, so painting something honest and early improves both the number and the experience.
Move heavy computation off the main thread
ModerateParsing, sorting, searching and image manipulation belong in a Web Worker. The main thread stays free to respond to input while the work happens elsewhere.
Reduce and defer JavaScript
ModerateCode split along routes and interactions so each page ships only what it needs. Load analytics and widgets after the page is interactive, or on first interaction rather than on load.
Virtualise long lists
InvolvedRendering a thousand rows means every interaction pays for a thousand rows of style and layout work. Rendering only the visible window keeps the tree small and the responses fast.
How Pulse reports this
A Pulse audit is a scripted page load, and nobody interacts with it, so there is no genuine INP to report. Rather than invent a number, Pulse marks the metric unavailable and reports Total Blocking Time instead, which measures how long the main thread was unable to respond during load. If Total Blocking Time is high, real INP almost certainly is too.
Common questions
What is a good INP score?
Under 200 milliseconds is good, 200 to 500 milliseconds needs improvement, and over 500 milliseconds is poor.
Why can a lab test not measure INP?
INP is the response time to real interactions. A scripted load performs none, so there is nothing to measure. Lab tools report Total Blocking Time as the closest proxy, and field data from real visitors is the only source of a true INP.
How is INP different from First Input Delay?
First Input Delay only measured the wait before the first handler began. INP measures the full duration from input to the next paint, for every interaction in the visit, and reports close to the worst. Pages that passed First Input Delay comfortably often fail INP.
Related metrics
Measure INP on your own page
An audit runs in a real Chromium browser and reports INP alongside every other metric, with the measured saving behind each recommendation.