Interaction to Next Paint (INP)
Interaction to Next Paint (INP) measures how quickly a page responds when people click, tap or type. For each interaction, it measures the time from the input until the browser paints the next frame showing the result, such as a menu opening or a checkbox becoming ticked. A page’s INP is close to its slowest interaction during the visit (outliers are ignored on pages with many interactions).
INP is one of the three Core Web Vitals. It replaced First Input Delay (FID) in March 2024. FID only measured the delay before the first interaction started being handled; INP covers all interactions and the full time until something visibly changes.
Why it matters
When a page does not react to a tap, people assume it is broken. They tap again, which can trigger the action twice, or they leave. Slow interactions are common on JavaScript-heavy sites and on mid-range phones, where the CPU is much slower than a developer’s laptop.
Where the data comes from
INP needs real people interacting with the page, so it is a field-only metric. We read it from the Chrome UX Report (CrUX) through PageSpeed Insights: data from real Chrome users who opted in, over the last 28 days.
CrUX only publishes data for pages and origins with enough traffic. If your site has too few visits, we show “no field data” for INP. That is not an error. When a single URL lacks data, PageSpeed Insights may use data for the whole origin instead. See the field data guide for details.
Without field data, use Total Blocking Time from the lab test as a proxy. Pages with high TBT usually have poor INP too.
What we check
We use Google’s rating of the 75th percentile (p75) of real-user INP:
| Result | INP |
|---|---|
| Good | 200 ms or less |
| Needs attention | over 200 ms, up to 500 ms |
| Poor | over 500 ms |
What makes interactions slow
Each interaction has three parts. Any of them can be the problem:
- Input delay: the main thread is busy with other work (a long task, often a third-party script) when the visitor taps, so the event handler cannot start yet.
- Processing time: the event handlers themselves take too long.
- Presentation delay: after the handlers finish, the browser needs a long time to recalculate styles, lay out and paint, often because the update touches a very large DOM.
How to fix
Give visual feedback first, do heavy work after. Update the UI right away, then yield to the browser so it can paint before you continue:
button.addEventListener('click', async () => {
button.classList.add('is-loading'); // visible change first
await new Promise((resolve) => setTimeout(resolve, 0)); // let the browser paint
await saveForm(); // heavy or slow work after
});
In browsers that support it, scheduler.yield() is a better way to yield. Feature-detect it and fall
back to setTimeout.
Break up long tasks. Long-running JavaScript blocks every interaction that arrives while it runs. Split work into smaller chunks, and move pure computation to a Web Worker.
Cut third-party and startup JavaScript. Analytics, tag managers, chat widgets and A/B testing scripts often run long tasks exactly when people start interacting. Remove what you do not need and load the rest later.
Keep the DOM small. Very large pages make every style and layout recalculation slower. Paginate
or virtualize long lists, and avoid rendering hidden content you do not need yet. The CSS
content-visibility: auto property lets the browser skip rendering work for off-screen sections.
Avoid expensive re-renders. In component frameworks, an input that re-renders a large part of the page on every keystroke is a common INP problem. Debounce expensive updates and keep state changes local to the component that needs them.
Finding slow interactions
Because INP depends on what real people do, measure it on real visits. The open-source web-vitals
JavaScript library reports INP with attribution: which element was interacted with and how the time
split between input delay, processing and presentation. In Chrome DevTools, the Performance panel
shows INP for the interactions you perform yourself, and CPU throttling helps simulate slower phones.