INP Optimization 2026: How to Fix Interaction to Next Paint on Mobile (with Case Study)

Guide Core Web Vitals · 11 min read · Updated May 2026

Interaction to Next Paint replaced First Input Delay as a Core Web Vital on the 12th of March 2024, and two years later it is still the metric the most teams struggle with. INP measures the worst interaction across the entire session, not the first one. That single change in definition exposed a class of latency problems that FID had been quietly hiding: heavy event handlers, long JavaScript tasks triggered by the third click, expensive React or Vue re-renders, web workers that block the main thread by accident. This guide explains where INP comes from, why mobile is much harder than desktop, the twelve patterns that produce most of the bad scores, and the concrete code changes that moved one of our production sites from 480 milliseconds to 120 milliseconds at the 75th percentile.

What INP measures, in exact terms

Every time a user interacts with the page (click, tap, key press), the browser records the latency between the input event and the next visual update on the screen. The latency includes the time to run the event handler, the time to process any styling and layout work that follows, and the time the browser needs to paint the next frame. INP is the highest of those latencies recorded during the session, ignoring a few outliers and applying small smoothing rules. Google’s threshold is 200 milliseconds or less for the 75th percentile of page visits; above 500 milliseconds the site fails INP outright.

The definition is intentionally pessimistic. FID rewarded sites where the first click was fast and the tenth was slow. INP punishes sites where the tenth click is slow. The change matters because real users notice the worst interaction, not the first one. A login form that responds in 30 milliseconds but a “load more” button that takes 700 milliseconds gets reported as a 700 millisecond experience under INP, which is what the user actually felt.

Why mobile is harder than desktop

The mobile INP score is almost always worse than desktop on the same site. The reason is structural: a mid-range Android phone in 2026 still has a CPU four to six times slower than a typical laptop, a memory bandwidth two to three times lower, and a cell network with jitter that randomly stretches small JavaScript tasks. The same React tree that renders in 80 milliseconds on a laptop can take 350 milliseconds on a phone, which is enough to push a single click past the INP threshold.

The implication for optimisation is that mobile is the only target that matters. Google indexes the mobile experience for ranking under mobile-first indexing, the field data in CrUX is dominated by mobile traffic on most consumer sites, and the worst-case interactions almost always come from low-end Android devices. Profile on a throttled CPU (4x slowdown is the default Chrome DevTools preset and is roughly representative of a 2022 mid-range Android in 2026), and treat desktop performance as a free side effect of the mobile work.

The biggest INP killers in 2026

After working through dozens of INP audits, the same patterns keep appearing. In rough order of frequency:

1. Heavy event handlers. A click handler that does synchronous work for 300 milliseconds will produce a 300 millisecond INP regardless of how fast the rest of the page is. The most common offenders are analytics events that fire synchronously, JSON deserialisation, large React state updates that touch dozens of components, and CSV exports that block the main thread.
2. Third-party scripts firing during interaction. Tag managers, A/B testing libraries, session-recording tools and ads frameworks routinely fire long tasks in response to user actions. The site is fast until the user clicks; the click triggers the third-party code path, which freezes the main thread for hundreds of milliseconds.
3. Synchronous layout thrashing. Reading the layout property (offsetHeight, getBoundingClientRect) inside a loop that also writes to the DOM forces the browser to recompute layout on every iteration, which compounds quickly. A loop over 200 items can easily produce a 200 millisecond pause.
4. Large DOM trees. A page with 5000 DOM nodes has a base cost on every interaction because the browser must walk part of the tree to determine what changed. Sites that lazy-render entire panels instead of just the visible part are usually fine; sites that render everything upfront pay the tax forever.
5. Web fonts swap that triggers layout shift mid-interaction. A font that loads after the click and causes a reflow contributes to INP because the paint following the click is delayed by the reflow. font-display: swap mitigates the visual jank but not the INP cost; size-adjust in the font face is the modern fix.
6. Long-running setTimeout callbacks. Any task scheduled by the application that runs for longer than 50 milliseconds is reported as a long task by the browser. If it happens to overlap with an interaction, the interaction inherits the delay.
7. Synchronous fetch or XHR in a handler. Awaiting a network request inside an event handler blocks the next paint. Always treat the handler as a synchronous critical path and defer the network round-trip with optimistic UI or with a loading state painted immediately.
8. Hydration of large server-rendered components. React 18, Vue 3 and SvelteKit ship partial hydration techniques that solve most of this, but a site that hydrates a 200-component tree on first interaction still pays the cost. Move to islands architecture or selective hydration where possible.

Profiling INP with DevTools

The Chrome DevTools Performance panel is the most precise INP profiler available in 2026. The “Interactions” track shows every input event during the recording with its INP score in milliseconds. Long tasks that overlap an interaction are highlighted in red. The basic workflow is:

1. Open DevTools, switch to the Performance tab, and enable CPU throttling at 4x (the default).
2. Set network throttling to Fast 3G or Slow 4G for a realistic mobile baseline.
3. Click record, perform the interactions you want to profile (use the slowest perceived ones), stop record.
4. In the Interactions track, sort by INP descending. The top three interactions usually expose the offending long task in the Main track right below.
5. Zoom into the first red long task. The flame chart names the function that was running. That is your optimisation target.

For field data, install the Chrome User Experience Report Loop API or use our Core Web Vitals INP probe against the URL. CrUX gives you the 75th percentile across real Chrome users in the past 28 days, which is the number Google uses for ranking. Lab data is precise but a single sample; field data is noisy but representative.

Strategies that actually work in production

The single most effective change is to break long event handlers into smaller pieces with scheduler.yield() or setTimeout(fn, 0). The pattern is:

async function handleClick() {
  await heavyTask1();
  await scheduler.yield(); // returns to the browser for input checks
  await heavyTask2();
  await scheduler.yield();
  await heavyTask3();
}

Each scheduler.yield() lets the browser process pending input and paint the next frame. The total work is unchanged, but the worst latency drops from the sum of all tasks to the longest individual task.

The second most effective change is to move CPU-bound work off the main thread via Web Workers. Anything that does not touch the DOM is a candidate: JSON parsing, search filtering, encryption, image processing, data validation. The work happens in a worker thread, the main thread stays free, INP stays under 100 milliseconds even on cheap phones.

Third, delay third-party scripts until idle with requestIdleCallback or with a Partytown-style worker proxy. The site loads with only first-party scripts, the trackers come in after the first user interaction has been processed, INP improves dramatically because the worst-case interaction no longer triggers an analytics script.

Fourth, use CSS containment (contain: layout style) on independent components so a change in one component does not force layout recomputation across the rest of the page. This is a one-liner per component and the benefit is invisible in lab tests but compounds in the field.

Fifth, preload critical interactivity assets with <link rel="preload" as="script"> for the scripts you know will run on the first interaction. The interaction handler is already in memory when the user clicks, removing the parse+compile cost from the critical path.

Case study — 480 ms to 120 ms

The numbers below come from a production e-commerce site we audited in early 2026. The mobile INP was 480 milliseconds at the 75th percentile, well above the 500 millisecond fail threshold. After three weeks of focused work, the score dropped to 120 milliseconds, comfortably under the 200 millisecond “good” threshold. The same site also saw a 12 percent increase in mobile-to-cart conversion in the following month, which suggests the perceived responsiveness translates into business.

The three changes that delivered the gap, in order of impact:

• Moved the “add to cart” event from synchronous to optimistic UI. Previously, clicking the button triggered a synchronous fetch to /api/cart/add and waited for the response before updating the UI. After: the UI updates immediately (item appears in the cart drawer), the fetch happens in the background, and the UI rolls back on error. INP impact: -180 milliseconds on the worst case.
• Deferred the tag manager until after the first interaction. The site used Google Tag Manager loaded synchronously in the head. After: GTM loads with defer and is wrapped in a requestIdleCallback so it does not compete with the first user click. INP impact: -130 milliseconds.
• Moved product-list filtering to a Web Worker. The filter logic was a synchronous loop over 1200 products with full re-render on every keystroke. After: the worker handles the filter, posts the result back, the main thread re-renders only the visible 20 items. INP impact: -50 milliseconds on the filter interaction.

12-point INP optimisation checklist

Use this list during every front-end audit. Each item maps to a known INP killer and a known fix.

1. Profile mobile under 4x CPU throttling first; ignore the desktop number until mobile is green.
2. Break event handlers longer than 50 milliseconds with scheduler.yield().
3. Move CPU-bound, DOM-free work to Web Workers.
4. Defer third-party scripts until requestIdleCallback or after first interaction.
5. Replace synchronous fetch in handlers with optimistic UI plus background reconciliation.
6. Apply contain: layout style on independent components.
7. Preload critical interactivity scripts with <link rel="preload" as="script">.
8. Avoid synchronous layout reads inside loops that also write to the DOM.
9. Configure web fonts with font-display: swap and size-adjust to prevent reflow during interaction.
10. Replace synchronous JSON deserialisation of large payloads with streaming or worker-based parsing.
11. Audit DOM size; if over 1500 nodes on first load, lazy-render the off-screen sections.
12. Re-measure after each change with CrUX field data; a single Lighthouse run is not enough.

FAQ

Related tools and resources