Interaction to next paint: how to cut input lag and keep interfaces responsive

Responsive interfaces are no longer a nice-to-have performance detail. They are a visible product quality signal, a conversion factor, and now a search-relevant benchmark through Core Web Vitals. Since March 12, 2024, Interaction to Next Paint, or INP, has officially replaced FID as Google’s responsiveness metric, with a good threshold defined as 200 ms or less at the 75th percentile. For teams building modern websites and web apps, that change makes input lag a design, engineering, and business concern all at once.

The reason INP matters is simple: it measures what users actually feel. Instead of stopping at the moment the browser begins handling an interaction, INP tracks the full path from a click, tap, or keypress to the next visual update. That makes it a far more practical proxy for responsiveness. If an interface looks frozen after a user acts, INP captures that delay, and if you want to cut input lag in a meaningful way, you need to optimize the entire interaction lifecycle.

Why INP is the metric that changes how teams think about responsiveness

INP measures the latency of an interaction from the user action through to the next painted frame that reflects the result. In practical terms, that means it includes input delay, event processing, and presentation delay. This is a major shift from older thinking around FID, which focused only on the initial delay before event handling began. A page can have short handler startup times and still feel sluggish if rendering takes too long afterward.

Google’s current thresholds are clear. A good INP is 200 ms or below, needs improvement is above 200 ms and up to 500 ms, and poor is anything above 500 ms. Those thresholds are evaluated at the 75th percentile, which matters because user experience varies widely by device capability, CPU speed, thermal conditions, and background tab pressure. A site that feels fine on a high-end development machine can still fail badly for users on weaker phones.

That percentile-based framing is critical for product teams and agencies. It moves performance away from anecdotal testing and toward population-level experience. If your PageSpeed Insights report shows weak field performance, that is not contradicted by one smooth local run. It means enough real users are hitting slow interactions that responsiveness has become a measurable business risk.

The three phases of INP: input delay, processing, and presentation

One of the most useful ways to optimize INP is to treat it as three separate problems. The first is input delay, which is the time between the interaction and the moment your event callback can start. The second is processing time, which covers the actual work inside your handlers and any related JavaScript. The third is presentation delay, which is the time after the code finishes until the browser can render and paint the updated frame.

This mental model is more than a teaching device. It is reflected in current Google guidance and in Chrome DevTools’ newer diagnostics, including INP-by-phase overlays introduced in 2025. Instead of treating responsiveness as a vague complaint, teams can see where time is being lost. If the problem is input delay, the main thread is likely busy before the handler can even run. If the issue is processing, your callbacks or associated tasks are too heavy. If the bottleneck is presentation, the rendering pipeline is doing too much work.

That distinction changes the fixes you choose. A slow click does not always mean “too much JavaScript in the handler.” Sometimes the handler is short, but the DOM mutation triggers expensive style recalculation and layout. In other cases, a long-running task elsewhere on the page blocks the interaction from starting at all. Breaking INP into phases helps performance work become precise instead of reactive.

The biggest cause of bad INP: long tasks blocking the main thread

The most common practical cause of poor INP is main-thread contention. When JavaScript monopolizes the main thread, the browser cannot promptly run input handlers, recalculate styles, perform layout, or paint the next frame. Google’s guidance on long tasks describes the core problem succinctly: the browser is not able to show a response until the entire function is finished running, which creates a slow and unresponsive UI.

This is why long tasks are so damaging to perceived speed. A user taps a button expecting feedback, but a script is already busy parsing data, rendering a huge component tree, or running synchronous business logic. The interaction waits in line. Even if the eventual result is correct, the delay feels broken because the interface fails to acknowledge the user in time.

For many teams, this is the highest-leverage place to start. Before chasing micro-optimizations, look for large chunks of uninterrupted work on the main thread. If a click triggers validation, filtering, sorting, DOM updates, analytics hooks, and UI transitions in one monolithic execution block, you likely have an INP problem waiting to happen. Long tasks are not just a performance smell; they are often the direct source of input lag.

How to cut input lag by splitting work and using scheduler.yield

A key modern fix is to break long work into smaller tasks and let the browser breathe between them. Chrome’s guidance around scheduler.yield is especially relevant here because it allows your code to yield control so the browser can run pending high-priority work before your JavaScript resumes. In practice, that means clicks, taps, keypresses, and rendering have a chance to run sooner instead of waiting behind a long execution block.

This makes scheduler.yield one of the most effective 2025-era tools for improving responsiveness in real applications. If you are processing a large array, hydrating a complex view, or running non-urgent post-interaction work, you can insert yield points so that the browser remains responsive while the overall task still completes. It is a cooperative scheduling strategy, not a magic shortcut, but it directly addresses the root issue of main-thread starvation.

If scheduler.yield is unavailable, chunking work with task boundaries still helps. A fallback such as setTimeout(..., 0) can break up a large task, but it is not ideal because repeated nested timeouts eventually incur a minimum delay of around 5 ms. That means it remains a fallback rather than the preferred mechanism. The larger principle still holds: smaller tasks give the browser more opportunities to respond, paint, and keep the interface feeling alive.

Keep event handlers lean and move non-urgent work off the critical path

Not every line of code triggered by an interaction belongs on the immediate response path. One of the most effective ways to improve INP is to keep handlers focused on the smallest amount of work needed to update the UI. If a user clicks “Add to cart,” the critical path is usually visual confirmation and state change, not a cascade of synchronous logging, recommendation recalculation, or secondary DOM work.

This is where teams often conflate business completeness with interaction responsiveness. From the user’s perspective, the interface should acknowledge intent quickly. Once that happens, supporting tasks can often be deferred, scheduled, or performed asynchronously. MDN’s framing is useful here: asynchronous operations such as network fetches or file reads usually do not hurt INP in the same way synchronous main-thread work does, because the browser can continue painting while those operations are handled elsewhere.

That distinction should influence architecture. When a handler performs heavy synchronous computation before updating the UI, it directly increases interaction latency. When the same flow updates the UI first and lets asynchronous work continue independently, the interface feels far faster. Product teams that prioritize immediate feedback, then defer secondary work, usually see gains in both responsiveness and perceived polish.

Rendering is part of responsiveness, not a separate concern

Many INP issues survive even after JavaScript handlers are shortened because the problem sits in rendering. INP includes presentation delay, so the clock keeps running until the browser can paint the updated frame. If your interaction triggers expensive style recalculation, complex layout, or heavy paint work, users still experience lag even though the event callback itself may have been brief.

Large DOMs are a recurring culprit. The more elements the browser must consider during style and layout work, the harder it becomes to produce a fast next frame. Layout thrashing can make things worse when code repeatedly reads layout information and writes DOM changes in an interleaved pattern, forcing the browser to recalculate more than necessary. In these cases, your responsiveness issue is not just about scripting cost; it is about the total rendering burden created by the interaction.

One concrete optimization worth investigating is content-visibility. Google explicitly highlights it as a useful way to reduce rendering work, especially when large sections of the page do not need immediate processing. By limiting how much of the page must be rendered at once, you can reduce the cost of presenting the next frame and improve INP. For performance-focused design systems, this kind of rendering containment can be just as important as JavaScript optimization.

Align visual updates with the browser using requestAnimationFrame

For animation-driven interactions and visual state changes, requestAnimationFrame remains the right scheduling primitive. It queues a callback for the next repaint, aligning visual updates with the browser’s rendering pipeline instead of competing against it. That matters because painting responsive UI is not just about finishing JavaScript quickly; it is about making sure DOM writes happen at the right moment to support a smooth next frame.

In practice, this means using requestAnimationFrame for UI work that should appear in sync with rendering, such as transitions, drag feedback, animation steps, or interaction-driven visual state changes. When visual updates are coordinated with the browser, you reduce the chances of jank caused by poorly timed DOM mutations. The browser gets a cleaner opportunity to process, layout, and paint the change.

This does not mean every interaction fix is an animation problem. Rather, it reinforces a broader principle: responsiveness depends on cooperating with the browser’s scheduling model. If your code fights the event loop and rendering pipeline, users feel lag. If your code yields appropriately, batches work intelligently, and schedules visual updates where the browser expects them, the interface feels immediate and composed.

Measure INP in the field and in the lab to find the real bottleneck

Good INP work starts with measurement, but no single tool tells the whole story. PageSpeed Insights combines field data from the Chrome User Experience Report with Lighthouse-based lab analysis. Those two views answer different questions. Field data shows what real users are experiencing across devices and conditions, while lab traces help you reproduce and diagnose specific interaction problems in a controlled environment.

That distinction is especially important because INP is percentile-based. CrUX and PSI can reveal that users at the 75th percentile are seeing much worse responsiveness than your local setup suggests. As of October 20, 2025, PageSpeed Insights uses Lighthouse 13 and exposes INP field data under INTERACTION_TO_NEXT_PAINT. For teams building performance dashboards or integrating PSI API responses into reporting, reading the correct field metric matters.

For deeper diagnosis, Chrome DevTools has become significantly more useful. The 2025 updates added better INP analysis in the Insights sidebar, including phase-level overlays directly on the performance timeline. That makes it far easier to see whether a bad interaction is dominated by input delay, processing time, or presentation delay. When you can map user-visible lag to a specific phase, you can prioritize the fix with far more confidence.

Production monitoring and a practical checklist for responsive interfaces

Lab debugging is essential, but mature teams also instrument INP in production. Google’s web-vitals package includes an attribution build for INP that adds a small size over, about 1.5 KB brotli compared with the standard build, in exchange for richer debugging context. That tradeoff is often worthwhile when you need to identify which pages, interactions, or components are driving poor responsiveness in the real world.

There is one nuance worth remembering: INP is not reported if the user never interacts with the page. That makes interpretation important. A page with low traffic but high interaction intensity may reveal more responsiveness risk than a lightly engaged landing page. Product teams should pair INP metrics with usage patterns so they understand not just whether the page loads, but whether it remains responsive once users start doing meaningful work.

A practical checklist emerges from current Google, Chrome, and MDN guidance. Keep event handlers small. Split long tasks. Use scheduler.yield where possible, and fallback chunking where necessary. Reduce DOM and rendering cost, including investigating content-visibility. Align visual updates with requestAnimationFrame. Then verify gains with CrUX field data, PageSpeed Insights, and DevTools phase analysis. That sequence turns performance advice into an actionable operating model.

Responsiveness is now one of the clearest indicators of web quality because it sits at the intersection of engineering discipline and user trust. The industry data still shows that Core Web Vitals remain a broad challenge, and the shift from FID to INP underscores why. It is not enough for a page to start handling input quickly; it must visibly respond quickly. That difference is exactly where many modern interfaces succeed or fail.

For teams that build performance-focused digital experiences, the opportunity is straightforward. Treat INP as a system problem, not a single metric. Diagnose whether delays come from blocked input, heavy processing, or expensive presentation. Then shape the interaction path accordingly: smaller tasks, cooperative yielding, lean handlers, lighter rendering, and disciplined measurement. That is how you cut input lag in practice and keep interfaces responsive at the standard users now expect.