Technology

How to Optimize Interaction to Next Paint Without Chasing the Wrong Signal

A practical, evidence-based guide to diagnosing slow interactions, reducing main-thread work, and interpreting INP alongside—not instead of—broader search and user-experience signals.

Editorial note: This source-backed explainer was prepared with AI assistance, reviewed under the newsroom workflow, and approved for publication. It is not individualized professional advice or a report of a new event.

Interaction to Next Paint (INP) is Google’s Core Web Vital for responsiveness. It asks a practical question: after a person clicks, taps, or presses a key, how long does the browser take to present the next frame that reflects the interaction? A low value means the page is generally able to acknowledge user input quickly and consistently during the visit, rather than merely responding well to the first input. 1

Google recommends aiming for an INP of 200 milliseconds or less at the 75th percentile of page loads, with results segmented by mobile and desktop. Values above 200 ms and up to 500 ms need improvement; values above 500 ms are considered poor. These thresholds are a way to evaluate responsiveness, not a promise that every interaction on every device will finish within exactly the same time. 1 2

What INP measures—and what it does not

An interaction is a logical user gesture made up of related events. A tap, for example, can involve multiple pointer and click events; a keyboard action can involve keydown, keypress, and keyup. INP considers the interaction’s slowest relevant event and the time until the next frame can be presented. That latency has three useful diagnostic parts: input delay, while other work prevents the event from starting; processing duration, while event callbacks run; and presentation delay, while the browser performs rendering work before showing the result. 1 2

INP observes clicks, touchscreen taps, and keyboard presses. It does not observe scrolling, hovering, or zooming, although a gesture that includes a measured click, tap, or key press can still contribute. A visit can also have no INP value when the user loads a page but never performs a qualifying interaction, uses only unmeasured gestures, or is a non-interacting bot. Consequently, an absent INP is not evidence that a page is perfectly responsive; it may simply mean that no eligible interaction was recorded. 1

Start with field evidence

Optimization should begin with real-user data whenever possible. A RUM implementation can associate a poor page-level INP with the interaction that caused it, including its type, timing, and whether it happened during startup or later. PageSpeed Insights and the Chrome User Experience Report can provide valuable field-level context, but aggregated data may not explain which component or callback needs attention. Reproduce representative journeys in a lab after field data identifies a problem. Test both during page load, when the main thread is often busy, and after load, when application features may schedule substantial work. 1 2

A useful investigation records the slow interaction, device class, route, browser context, and the three latency components. This avoids treating a single synthetic click as the whole experience. It also helps teams distinguish a global JavaScript problem from a feature-specific problem such as a menu, filter, editor, checkout control, or embedded widget.

Reduce input delay

Input delay often comes from work already occupying the main thread. Large script evaluation, parsing, compilation, timers, fetch handling, layout-triggering work, and earlier interactions can all postpone event callbacks. Reduce the amount of JavaScript shipped and executed before the page becomes interactive. Remove unused code, split bundles by route or feature, defer non-critical third-party scripts, and avoid initializing expensive widgets before they are needed. These changes are not mechanical score tricks: they reduce contention for the thread that must handle the next user gesture. 2

Prioritize the critical path. A page can appear painted while scripts are still loading and executing, so “the page looks ready” does not necessarily mean that it can respond promptly. Profile startup work on representative mobile hardware, not only on a fast development laptop. Use traces and long-task attribution to determine whether the delay comes from application code, a library, advertising, analytics, or a third-party frame.

Make event callbacks do less

The safest first change is to keep the interaction callback focused on the minimum work required for immediate visual feedback. Update the control state, render the essential result, and allow the browser to paint. Defer non-urgent work such as analytics, secondary calculations, persistence, spell checking, recommendation refreshes, or remote synchronization. When necessary, yield to a later task with an appropriate scheduling technique. The goal is not to scatter arbitrary timers throughout the code; it is to establish a deliberate boundary between work the user must see now and work that can follow. 2

This distinction matters because blindly splitting a long task can create overhead, preserve unnecessary work, or delay the feedback that should appear first. Do not split long tasks mechanically. Break work at meaningful points, especially immediately after the UI has been updated, and verify in a trace that the next frame actually arrives sooner. If a callback performs expensive computation, consider reducing the algorithmic cost, processing less data, virtualizing large lists, or moving suitable work away from the main thread. If DOM updates are expensive, reduce the number of nodes touched and avoid forced synchronous layout caused by interleaving reads and writes.

Reduce presentation delay and verify the result

After callbacks finish, style calculation, layout, paint, compositing, and rendering can still hold back the next frame. Keep the visual update small and predictable. Avoid invalidating large portions of the document for a local state change, and inspect whether animations or effects trigger expensive layout or paint. A responsive interaction does not require every downstream effect to finish before the first acknowledgement appears. It requires the user to see a credible response promptly, while secondary effects continue responsibly.

Measure again in the field after each meaningful release. The 75th-percentile target is important because responsiveness varies by device, network, browser, and user behavior. Compare distributions and interaction types rather than celebrating a single best-case trace. Also monitor errors and product outcomes: a fast button that fails to communicate a completed action is not a successful experience.

INP is important, but it is not the whole ranking story

Google’s Search documentation recommends good Core Web Vitals for user experience and Search success, but Google’s Search Central blog explicitly cautions that good Core Web Vitals statistics do not guarantee good rankings. Page experience involves more than INP, including other Core Web Vitals, mobile usability, security, accessibility, content quality, relevance, and broader search-system considerations. Treat INP as an engineering and user-experience signal, not as a ranking shortcut. 3 2

Editorial disclosure: This explainer is an original editorial synthesis of the official Google and web.dev documentation listed in the References. It is educational guidance, not a guarantee of search performance or a substitute for testing a specific site.