How to Fix INP (Interaction to Next Paint) in 2026

Around 43 percent of websites still fail Interaction to Next Paint, making it the most commonly failed Core Web Vital. The fix is almost always the same: stop JavaScript from blocking the main thread while the browser is trying to respond to a tap or click. This guide shows you how to find the slow interactions and fix them, in priority order.

What INP actually measures

INP measures how quickly your page responds to a user interaction, from the moment they click, tap, or press a key to the moment the browser paints the next frame showing the result. It reports the worst interaction (near the 99th percentile) across a whole visit, so one janky button can sink the score for the entire page.

The threshold is simple: a good INP is under 200 milliseconds for at least 75 percent of visits. Between 200ms and 500ms needs improvement; above 500ms is poor. INP replaced First Input Delay as a Core Web Vital in March 2024, and unlike FID it measures the full interaction, not just the initial delay, which is why so many sites that passed FID now fail INP.

The three parts of an interaction

Every interaction breaks into three phases, and knowing which one is slow tells you what to fix:

• Input delay (~18% of INP): time before your event handler can even start, usually because the main thread is busy running other JavaScript.
• Processing time (~40%): how long your event handler itself takes to run.
• Presentation delay (~42%): how long the browser takes to render the resulting frame, driven largely by DOM size and layout work.

Presentation delay is the largest slice for most sites and the one people forget about. It is not enough to make your handler fast if the page then takes 150ms to repaint.

Step 1: Diagnose with real field data first

Before changing any code, confirm the problem in Google Search Console's Core Web Vitals report, which uses real Chrome user data (CrUX). Lab tools like Lighthouse cannot measure INP properly because they do not simulate real interactions. Work from field data so you fix the interactions real visitors actually struggle with, not the ones you imagine.

Then reproduce it: open Chrome DevTools, record a Performance trace, and interact with the page. Look for long tasks (the red-flagged blocks over 50ms) that line up with your clicks.

Step 2: Break up long tasks

The single highest-impact fix is breaking long JavaScript tasks into smaller pieces so the browser can respond to input between them. Any task over 50ms blocks the main thread and delays every interaction that lands during it.

Two techniques:

• Yield to the main thread. Use await scheduler.yield() (or a setTimeout fallback) to break a long function into chunks, letting the browser handle pending interactions in the gaps.
• Defer non-urgent work. Move analytics, logging, and anything not needed for the visible response out of the interaction's critical path.

Step 3: Get third-party scripts off the main thread

Third-party scripts (tag managers, chat widgets, A/B testing tools, ad scripts) are a leading cause of high input delay because they run long tasks on the main thread at unpredictable times. Audit what you load, remove what you do not need, and load the rest with async or defer. For the heaviest offenders, consider a web worker so they never touch the main thread.

Step 4: Reduce presentation delay

Since presentation delay is often the biggest slice, shrink the work the browser does to paint:

• Cut DOM size. Large DOM trees take longer to lay out and paint. Fewer nodes means faster frames.
• Use content-visibility: auto on off-screen sections so the browser skips rendering them until needed, which lowers rendering time and improves INP.
• Avoid layout thrash. Batch DOM reads and writes so you are not forcing repeated reflows inside an interaction.

The priority order

If you only do three things, do these, in this order:

1. Break any task over 50ms (biggest, most common win).
2. Audit and defer third-party scripts.
3. Apply content-visibility to long, off-screen pages.

Most sites that fail INP pass after the first two. The rest is squeezing out the presentation delay on heavy pages.