INP Optimization: Fix Interaction to Next Paint in 2026

The Short Answer: How to Fix INP in 2026

INP optimization is the work of cutting the latency between a user interaction and the next paint to under 200 milliseconds at the 75th percentile. The fastest path: identify slow interactions in real-user data, break their JavaScript work into chunks that yield to the main thread, and remove or defer the third-party scripts crowding your event loop.

Most sites that fail INP fail for the same five reasons—long JavaScript tasks, heavy third-party scripts, hydration overhead, oversized DOMs, and synchronous event handlers. Fix those and your INP score moves from "poor" to "good" inside 30 days.

What Is Interaction to Next Paint?

Interaction to Next Paint (INP) measures the full latency from a user input—click, tap, or key press—to the next frame painted to the screen. It captures input delay, processing time, and presentation delay as one number, then reports the worst (or near-worst at high traffic) interaction across the page lifecycle.

INP became a stable Core Web Vital on March 12, 2024, replacing First Input Delay (FID). Google made the swap because FID only measured the delay before the first interaction was processed—not the time to update the UI, and not subsequent interactions. INP gives a far more honest picture of how responsive a page feels.

The Three Phases of an Interaction

Adding all three together gives you a single interaction's latency. Page-level INP is then the worst interaction at typical traffic, or roughly the 98th percentile interaction at very high traffic. The Chrome User Experience Report (CrUX) aggregates this across all your visitors and reports it back to Search Console.

Does INP Affect SEO Rankings?

Yes—INP is a confirmed Google ranking signal as part of the page experience update. Google uses field data from CrUX to evaluate Core Web Vitals, and pages that pass all three metrics (LCP, INP, CLS) get a tiebreaker advantage in competitive search results. Our Core Web Vitals guide covers the broader ranking math.

The data backs the priority: according to HTTP Archive's Core Web Vitals Technology Report (April 2026), only about 64% of mobile origins pass INP—making it the hardest of the three Core Web Vitals to pass and the most common reason a site fails the overall threshold. LCP and CLS pass at 78% and 81% respectively.

The business case is sharper than the ranking case. RedBus reduced INP by 68% and saw a 7% increase in sales. The Economic Times improved INP by 61% and saw a 50% drop in bounce rate. Slow interactions cost conversions even when search rankings hold steady.

How to Measure INP in Real Users

Lab data alone won't catch INP problems—the metric is built around real user behavior across thousands of interactions. You need both lab tests for debugging specific issues and field data to verify production impact.

Field Data Tools (What Google Uses for Ranking)

Lab Tools (For Debugging Specific Interactions)

import { onINP } from 'web-vitals';

onINP((metric) => {
  // Send to your analytics endpoint
  navigator.sendBeacon('/api/vitals', JSON.stringify({
    name: metric.name,
    value: metric.value,
    rating: metric.rating, // 'good' | 'needs-improvement' | 'poor'
    id: metric.id,
    path: window.location.pathname,
  }));
});

Why Is My INP Score Bad? The Five Common Causes

INP problems almost always trace back to the same handful of patterns. Diagnose by recording a Chrome DevTools Performance trace while clicking your slowest button or form, then look for which of these is dominating your trace.

1. Long JavaScript Tasks Blocking the Main Thread

Any task longer than 50ms is a "long task" that blocks input handling. A click that fires while a 300ms task is running has at least 300ms of input delay before its handler even starts. Long tasks come from heavy parsing, render-blocking scripts, expensive component trees, and synchronous loops over large arrays.

2. Heavy Third-Party Scripts

Chat widgets, A/B testing tools, tag managers, ads, and analytics all run JavaScript on the main thread. The 2024 Web Almanac performance chapter found that third-party scripts account for an average of 38% of main-thread time on mobile pages—often the single largest INP contributor on otherwise-fast sites.

3. Hydration Overhead in SSR Frameworks

Next.js, Remix, and other SSR frameworks render HTML on the server, then "hydrate" with JavaScript on the client. Hydration is a long task by definition—if the user clicks during hydration, INP spikes. Sites with large component trees or excessive client components (use client) suffer here. Our Next.js performance guide walks through the Server Component split that fixes this.

4. Oversized DOM

Pages with more than 1,500 DOM nodes pay a tax on every layout, paint, and event handler. Long product listings without virtualization, deeply nested component trees, and SVG-heavy infographics are the usual culprits.

5. Synchronous Work Inside Event Handlers

Click handlers that run validation, format data, update state, and trigger re-renders all synchronously will blow past 200ms on mid-range phones. The fix is to yield to the main thread between expensive steps so the browser can paint a response (loading state, ripple, focus) before finishing the work.

How to Fix Slow INP: 8 Proven Strategies

These strategies move sites from "poor" to "good" INP in 30 days. Implement them in order—the early wins (yielding, third-party deferral) usually deliver 50-70% of the total improvement.

1. Yield to the Main Thread Inside Handlers

The single highest-leverage INP fix. After the first chunk of work in a click handler, yield to let the browser paint, then continue. The new scheduler.yield() API is the modern way; setTimeout(fn, 0) is the universal fallback.

async function handleClick() {
  // 1. Show immediate visual feedback
  setLoading(true);

  // 2. Yield so browser can paint the loading state
  await scheduler.yield?.() ?? new Promise(r => setTimeout(r, 0));

  // 3. Do the heavy work
  const validated = validateForm(formData);

  // 4. Yield again before the next chunk
  await scheduler.yield?.() ?? new Promise(r => setTimeout(r, 0));

  // 5. Submit
  await submitForm(validated);
  setLoading(false);
}

2. Defer or Remove Third-Party Scripts

Audit every third-party script with the Chrome DevTools Coverage tab. Anything not used on the current page should be deferred (load on interaction) or removed. Replace heavy chat widgets with lighter alternatives or facade patterns. Move analytics to defer attributes and load tag managers via Partytown to push them to a web worker.

3. Use React useTransition for Non-Urgent Updates

React 18+ ships useTransition and useDeferredValue specifically for INP. Wrap state updates that don't need to be synchronous (filtering a large list, expanding a panel, switching tabs) and React will keep the UI responsive while the update runs in the background.

import { useTransition, useState } from 'react';

function ProductFilter() {
  const [isPending, startTransition] = useTransition();
  const [filter, setFilter] = useState('');

  const handleChange = (e) => {
    // Urgent: update the input immediately
    setInputValue(e.target.value);
    // Non-urgent: filter the 5,000-item list in the background
    startTransition(() => {
      setFilter(e.target.value);
    });
  };

  return <input onChange={handleChange} />;
}

4. Debounce Expensive Event Handlers

Scroll, resize, and input events fire dozens of times per second. Wrap any expensive handler in a debounce or throttle so it runs at most every 100-200ms. For React, use a debounce hook or libraries like use-debounce.

5. Move Heavy Computation to Web Workers

Image processing, large-data parsing, encryption, and complex calculations belong in a web worker. The main thread stays free to handle clicks while the worker runs in parallel. Comlink makes the messaging boilerplate trivial.

6. Virtualize Long Lists

Lists of 100+ items render and re-render expensively. Use react-window, TanStack Virtual, or react-virtuoso to render only the rows currently in the viewport. DOM size drops, and every interaction speeds up.

7. Use CSS Containment and content-visibility

CSS containment (contain: layout paint) tells the browser an element's rendering is independent of the rest of the page, so style recalculations don't cascade. content-visibility: auto skips rendering entirely for off-screen sections—huge wins on long pages.

8. Avoid Layout Thrashing in Handlers

Reading layout properties (offsetWidth, getBoundingClientRect) and then writing to the DOM in the same handler triggers synchronous layout. Batch reads first, then writes. Even better: use ResizeObserver and IntersectionObserver instead of measuring during click handlers.

Framework-Specific INP Fixes

Next.js INP Optimization

WordPress INP Optimization

Shopify INP Optimization

How to Prioritize INP Fixes

Not every page needs the same treatment. Use this prioritization order to focus engineering time where it moves rankings and revenue.

For a broader Core Web Vitals roadmap that includes LCP and CLS alongside INP, work through our website speed optimization guide. INP fixes that come from cutting JavaScript and DOM also tend to improve LCP—the wins compound.

30-Day INP Action Plan

If INP is still failing after the 30-day plan, the issue is usually structural—a framework choice, a vendor script you can't remove, or a DOM that needs to be rebuilt. At that point a deeper technical SEO audit and refactor is the right next step.

Frequently Asked Questions