Monitoring Interaction to Next Paint
Field INP plus lab Total Blocking Time for every URL.
Interaction to Next Paint, or INP, measures how quickly a page responds when someone taps, clicks or types. It became a Core Web Vital in March 2024, replacing First Input Delay. INP is harder to monitor than LCP or CLS, because it depends entirely on real people interacting with the page.
What INP measures
For each interaction on a page, the browser measures the time from the input to the next frame being painted. That includes:
- Input delay. Waiting for the main thread to be free.
- Processing time. Running your event handlers.
- Presentation delay. Recalculating layout and painting the update.
INP reports roughly the slowest interaction on the page visit, ignoring a few outliers on pages with many interactions. Google's thresholds are 200 ms or less for good, and over 500 ms for poor, at the 75th percentile.
Why lab tests cannot measure INP
A standard Lighthouse test loads the page and stops. Nobody clicks anything. So there is no INP value in lab data.
The closest lab signal is Total Blocking Time: how long the main thread was blocked by long tasks during load. A page with high TBT usually has a busy main thread, which makes slow interactions likely. TBT is not a replacement for INP, but when TBT jumps after a release, INP often follows in field data a week or two later.
Sources of INP data
Chrome UX Report. Field INP at the 75th percentile for pages and origins with enough traffic, over a rolling 28 days. This is what Vitals Clock uses, along with the history API for weekly trends.
Your own real user monitoring. A script on your site that records INP for every visit. More detail, including which element was clicked, but it needs setup and a separate tool.
A monitoring setup for INP
- Track field INP for your key URLs and your whole origin, weekly.
- Track lab TBT daily as an early signal.
- Alert when field INP crosses 200 ms, and when TBT rises sharply against its median.
- When you get a TBT alert, check what shipped. When INP crosses the threshold, look at the interactions on that page.
Common causes of poor INP
Long JavaScript tasks. Anything that holds the main thread for over 50 ms delays the next interaction. Break work into smaller pieces and yield to the browser between them.
Heavy third-party scripts. Tag managers, analytics, chat widgets, A/B testing tools and ad scripts all compete for the main thread. Audit them regularly and remove what you do not use.
Expensive event handlers. A click that triggers a large re-render or a synchronous network call blocks the paint. Give visual feedback first, then do the heavy work.
Large DOM. Thousands of elements make style and layout recalculation slow. Paginate or virtualize long lists.
Hydration on load. Frameworks that hydrate the whole page at once can make early interactions slow. Partial or deferred hydration helps.
Input handlers on scroll and typing. Debounce search-as-you-type and avoid layout reads in scroll handlers.
Why INP regresses quietly
INP problems often arrive with features: a new filter panel, a richer product configurator, another analytics tool. Each adds a little main-thread work. Because field data lags, you may not notice for weeks. Monitoring TBT daily and field INP weekly closes most of that gap.
Questions
My page has no field INP. What now?
The page may not have enough Chrome traffic. Check origin-level INP instead, and use TBT as your daily signal.
Is mobile INP usually worse?
Yes. Mobile CPUs are slower, so the same JavaScript takes longer to run.