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

Interaction to Next Paint is the Core Web Vital that splits hardest along device lines. According to the 2025 Web Almanac, 97 percent of desktop sites have a good INP, but only 77 percent of mobile sites do. If your INP is failing, it is almost certainly failing on mobile, and almost certainly because JavaScript is blocking the main thread while the browser is trying to respond to a tap.

What follows is how to find the slow interactions and fix them, in priority order, with the mobile case called out where it differs.

What INP actually measures

INP measures how quickly your page responds to a user interaction, from the moment someone clicks, taps, or presses a key to the moment the browser paints the next frame showing the result. It reports close to the worst interaction across a whole visit, so one janky button can sink the score for the entire page.

The thresholds, in Google's own wording:

An INP below or at 200 milliseconds means a page has good responsiveness. An INP above 200 milliseconds and below or at 500 milliseconds means a page's responsiveness needs improvement. An INP above 500 milliseconds means a page has poor responsiveness.

Those are assessed at the 75th percentile of page loads, segmented across mobile and desktop. That segmentation is the part people miss. Mobile and desktop are graded separately, so a comfortable desktop score does nothing to rescue a failing mobile one.

INP replaced First Input Delay as a Core Web Vital in March 2024. Unlike FID, it measures the full interaction rather than just the initial delay, which is why so many sites that passed FID comfortably now fail INP.

Why your INP is over 200ms on mobile specifically

The mobile gap is not a measurement quirk. It compounds:

• Slower CPUs. The same JavaScript that parses and executes in 40ms on a laptop can take 200ms or more on a mid-range Android handset. Long tasks that are invisible on desktop become blocking on mobile.
• The same payload, less headroom. Most sites ship one bundle to every device. Desktop absorbs it; mobile does not.
• Touch interactions surface it. Taps tend to hit menus, filters, accordions, and add-to-cart buttons, which are precisely the handlers that do the most work.

The practical consequence: test on a throttled mobile profile, or you will not reproduce the problem at all. In Chrome DevTools, set CPU throttling to 4x or 6x slowdown before you record. An interaction that feels instant unthrottled is where most people wrongly conclude their INP is fine.

The three subparts of an interaction

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

• Input delay: the time before your event handlers start running, usually because the main thread is busy with other JavaScript.
• Processing duration: how long your event handler callbacks take to run.
• Presentation delay: the time after the callbacks finish until the browser actually presents the frame, driven largely by DOM size and layout work.

One caveat worth knowing before you start: CrUX does not report these subparts, so there is no field breakdown waiting for you in Search Console, and no reliable published figure for how much each phase typically contributes. You have to measure your own. Two ways to do it:

• In the lab: Chrome DevTools has a dedicated INP breakdown insight in the Performance panel that splits the longest interaction into the three phases.
• In the field: version 4 and later of the web-vitals library reports INP phase breakdowns from real visitors, which is the only way to know which phase is slow for the devices your actual audience uses.

Do this before you optimise anything. Fixing processing duration when your problem is presentation delay is a wasted afternoon.

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 cannot measure INP on their own because they do not simulate real interactions, which is also why a green PageSpeed score can sit on top of a site that feels slow.

Then reproduce it: open Chrome DevTools, apply CPU throttling, record a Performance trace, and interact with the page the way a visitor would. 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. Update the UI first, then do the bookkeeping.

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, and rarely the part of the page anyone remembers adding. 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 at all.

Step 4: Reduce presentation delay

Presentation delay is the phase people forget. It is not enough to make your handler fast if the page then takes 150ms to repaint:

• 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.
• Avoid layout thrash. Batch DOM reads and writes so you are not forcing repeated reflows inside an interaction.

INP on WordPress

WordPress sites are over-represented among INP failures, and the cause is usually additive rather than a single culprit. A typical stack runs a page builder, a slider, a cookie banner, a chat widget, an analytics tag, and a handful of plugins that each enqueue their own jQuery-dependent script on every page, whether the page uses it or not.

What actually helps, in order:

1. Audit what each plugin enqueues. Use the Network panel to list scripts by size, then check which ones load on pages that never use them. Conditionally dequeue the rest.
2. Stop shipping jQuery-dependent bundles to pages that do not need them. This is frequently the biggest single win on a builder-based site.
3. Defer the cookie banner and chat widget until after first interaction rather than on page load. Both are notorious for occupying the main thread at exactly the moment a visitor first taps something.
4. Be sceptical of caching plugins as an INP fix. Caching helps LCP and TTFB. INP is a main-thread problem, and a cached HTML document still ships the same JavaScript. The full picture is in fixing Core Web Vitals on WordPress.

The same logic applies to Shopify, where the theme's app embeds play the role plugins do on WordPress. See why Shopify stores fail Core Web Vitals.

The priority order

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

1. Measure on a throttled mobile profile. Otherwise you are optimising a problem you cannot see.
2. Break any task over 50ms. The biggest and most common win.
3. Audit and defer third-party scripts. Usually the largest source of input delay.
4. Apply content-visibility to long, off-screen pages. For heavy pages carrying more markup than they need.

Most sites pass after the first three. If yours does not, the problem is usually a single handler doing far too much work, and a field trace with the web-vitals library will point straight at it.

If you would rather have this traced and fixed rather than diagnosed by hand, that is exactly what the performance fix service does. And if you are not sure whether INP is even your worst problem, the 2.5 second LCP threshold is worth checking first, since LCP is the metric more sites actually fail.