Complete Guide to Interaction to Next Paint (INP)

Interaction to Next Paint (INP) is the Core Web Vital that measures responsiveness. It captures how quickly your page responds to user interactions -- clicks, taps, and key presses -- by measuring the time from the user's input to when the browser paints the visual result. A good INP score is 200 milliseconds or less.

INP replaced First Input Delay (FID) as a Core Web Vital in March 2024, and it's a significantly more demanding metric. While FID only measured the delay before the first interaction's event handler ran, INP measures the complete latency of every interaction on the page and reports a value representing the worst-case experience. This means sites that passed FID with ease may fail INP, especially JavaScript-heavy single-page applications.

What is Interaction to Next Paint?

INP measures the latency of user interactions with the page. An "interaction" in INP's context is a discrete user action: a click, a tap on a touchscreen, or a physical key press on a keyboard. Hover and scroll are not measured.

For each interaction, INP measures the total time from the user's physical input (e.g., mouse button down) to when the browser paints the next frame that reflects the result of that interaction. This total time has three distinct phases:

1. Input delay: The time between the user's action and when the event handler starts executing. This delay occurs when the main thread is busy with other work (a long JavaScript task, for example) and can't respond to the input immediately.
2. Processing time: The time it takes to execute all event handlers associated with the interaction (mousedown, mouseup, click, keydown, keyup, etc.).
3. Presentation delay: The time from when the event handlers finish to when the browser actually paints the next frame. This includes style recalculation, layout, paint, and compositing.

INP does not simply report the worst single interaction. Instead, it uses an approximation of the 98th percentile: for pages with fewer than 50 interactions, the worst interaction is used; for pages with 50+ interactions, the algorithm ignores one interaction per 50, effectively reporting the near-worst experience while filtering out true outliers.

// Measure INP using the web-vitals library
import {onINP} from 'web-vitals';

onINP(({value, entries}) => {
  console.log('INP:', value, 'ms');

  // The interaction that determined INP
  const worstEntry = entries[entries.length - 1];
  console.log('INP event:', worstEntry.name);
  console.log('Input delay:', worstEntry.processingStart - worstEntry.startTime, 'ms');
  console.log('Processing time:', worstEntry.processingEnd - worstEntry.processingStart, 'ms');
  console.log('Presentation delay:', worstEntry.startTime + worstEntry.duration - worstEntry.processingEnd, 'ms');
});

INP thresholds

Google evaluates INP at the 75th percentile of page visits. 200ms may sound generous, but remember that INP includes input delay, processing, and rendering -- the entire pipeline from physical input to visual output. On a page with heavy JavaScript, 200ms can be surprisingly tight.

Why INP matters for SEO and UX

1. It measures what users actually feel. When a user taps a button and nothing happens for 400ms, the page feels broken. FID could report 20ms for that same interaction because it only measured the initial input delay, not the total time to visual feedback. INP captures the complete perception of sluggishness.

2. It's the Core Web Vital most sites fail. INP has the lowest pass rate of any Core Web Vital, and the December 2025 core update increased the weight of all user experience signals. Sites with poor INP are at a measurable ranking disadvantage, especially on mobile where slower processors and limited memory amplify JavaScript performance issues.

3. It affects conversion directly. Amazon's research found that every 100ms of latency costs 1% in sales. When users feel a page is sluggish, they abandon forms, skip product explorations, and leave for faster competitors. INP is the most direct proxy for this perceived sluggishness.

Common causes of poor INP

1. Long tasks blocking the main thread

The single most common cause of poor INP is JavaScript long tasks -- any task that runs on the main thread for more than 50ms. While a long task is running, the browser cannot respond to user input. If the user clicks a button while a 300ms analytics script is executing, their click sits in a queue for up to 300ms before the event handler even starts. This input delay alone can blow past the 200ms threshold.

2. Expensive event handlers

Event handlers that do too much synchronous work: computing large state transitions, manipulating thousands of DOM nodes, running complex algorithms, or triggering cascading re-renders in a framework like React. Each of these extends the processing time phase of INP.

3. Large DOM size and complex rendering

After event handlers complete, the browser must recalculate styles, layout, and paint the result. Pages with thousands of DOM nodes, deeply nested elements, or complex CSS selectors take longer to render. A DOM with 5,000+ nodes can add 100ms+ to the presentation delay phase alone.

4. Third-party scripts

Analytics, A/B testing, chat widgets, ad scripts, and social media embeds all compete for main thread time. They often run long tasks during page lifecycle, creating input delay whenever a user happens to interact while these scripts execute. The worst offenders are scripts that use synchronous XMLHttpRequest, run heavy DOM queries, or force layout recalculation.

Step-by-step INP optimization

// Detailed INP debugging with attribution
import {onINP} from 'web-vitals/attribution';

onINP(({value, attribution}) => {
  console.log('INP:', value, 'ms');
  console.log('Event type:', attribution.interactionType);
  console.log('Target:', attribution.interactionTarget);

  // Breakdown of the three phases
  console.log('Input delay:', attribution.inputDelay, 'ms');
  console.log('Processing time:', attribution.processingDuration, 'ms');
  console.log('Presentation delay:', attribution.presentationDelay, 'ms');

  // Long animation frames that overlapped
  console.log('Long animation frames:',
    attribution.longAnimationFrameEntries);
});

// Modern: scheduler.yield() - yields and re-queues at same priority
async function processItems(items) {
  for (let i = 0; i < items.length; i++) {
    processItem(items[i]);

    // Yield every 5 items to let browser handle input
    if (i % 5 === 4) {
      await scheduler.yield();
    }
  }
}

// Fallback: setTimeout(0) for browsers without scheduler.yield
function yieldToMain() {
  return new Promise(resolve => setTimeout(resolve, 0));
}

async function processItemsFallback(items) {
  for (let i = 0; i < items.length; i++) {
    processItem(items[i]);
    if (i % 5 === 4) {
      await yieldToMain();
    }
  }
}

// BAD: Everything in the handler blocks INP
button.addEventListener('click', () => {
  updateUI();           // Visual work
  sendAnalytics();      // Non-visual (50ms)
  syncToLocalStorage(); // Non-visual (30ms)
  logToConsole();       // Non-visual (10ms)
  // Total: all of these block presentation
});

// GOOD: Only visual work in the handler
button.addEventListener('click', () => {
  updateUI(); // Only the visual response

  // Defer non-visual work
  requestIdleCallback(() => {
    sendAnalytics();
    syncToLocalStorage();
    logToConsole();
  });
});

// Dynamic import for non-critical features
button.addEventListener('click', async () => {
  // Load the heavy module only when needed
  const {openModal} = await import('./modal.js');
  openModal();
});

// React: lazy load routes
const Dashboard = React.lazy(() => import('./Dashboard'));
const Settings = React.lazy(() => import('./Settings'));

// BAD: Layout thrashing - alternating reads and writes
elements.forEach(el => {
  const height = el.offsetHeight; // Read (forces layout)
  el.style.height = height + 10 + 'px'; // Write (invalidates layout)
  // Next iteration forces layout again!
});

// GOOD: Batch reads, then batch writes
const heights = elements.map(el => el.offsetHeight); // All reads
elements.forEach((el, i) => {
  el.style.height = heights[i] + 10 + 'px'; // All writes
});

Advanced INP optimization techniques

Scheduler API and prioritized tasks

The Scheduler API (scheduler.postTask()) lets you assign priority levels to tasks: user-blocking (highest), user-visible (default), and background (lowest). Visual updates after user interaction should be user-blocking; analytics and logging should be background. This ensures the browser processes input-responsive work first.

Offloading to Web Workers

Move computationally expensive work (data processing, sorting, filtering, encryption) to a Web Worker. Workers run on a separate thread and cannot block the main thread. The main thread can post a message to the worker, continue responding to user input, and receive the result asynchronously when the worker finishes.

// Main thread: offload heavy computation
const worker = new Worker('/sort-worker.js');

searchInput.addEventListener('input', (e) => {
  // Show loading indicator immediately (fast INP)
  showSpinner();

  // Offload expensive filtering to worker
  worker.postMessage({
    query: e.target.value,
    data: largeDataset,
  });
});

worker.addEventListener('message', (e) => {
  hideSpinner();
  renderResults(e.data.filtered);
});

React concurrent features for INP

React 18+ concurrent features are purpose-built for INP optimization. startTransition() marks state updates as non-urgent, letting React interrupt them if a higher-priority update (like user input) arrives. useDeferredValue() returns a deferred version of a value that updates at a lower priority, preventing expensive re-renders from blocking interaction responsiveness.

// React: startTransition for non-urgent updates
function SearchPage() {
  const [query, setQuery] = useState('');
  const [results, setResults] = useState([]);

  function handleInput(e) {
    // Urgent: update the input immediately
    setQuery(e.target.value);

    // Non-urgent: React can interrupt this
    startTransition(() => {
      setResults(filterLargeDataset(e.target.value));
    });
  }

  return (
    <>
      <input value={query} onChange={handleInput} />
      <ResultsList results={results} />
    </>
  );
}

Measuring INP: lab vs. field

INP is uniquely difficult to measure in lab environments because it depends on how users actually interact with the page. Lab tools simulate a page load but don't simulate real user click patterns, scroll behaviors, or interaction frequencies.

Field measurement is essential for INP. Use the web-vitals library to collect INP from real users and send it to your analytics platform. Segment by device type (mobile devices typically show 2-3x worse INP than desktop), browser, and page section.

Lab debugging workflow:

1. Open Chrome DevTools Performance panel
2. Start recording, then interact with the page as a user would
3. Stop recording and examine the flame chart
4. Look for long tasks on the main thread that coincide with your interactions
5. Identify the functions consuming the most time within those tasks
6. Use the "Interactions" track (Chrome 108+) to see INP measurements directly

Framework-specific INP fixes

React: Use startTransition and useDeferredValue for expensive state updates. Virtualize long lists with react-window or @tanstack/virtual. Memoize expensive computations with useMemo. Consider React Server Components to move rendering off the client entirely.

Next.js: Use the App Router with Server Components to minimize client-side JavaScript. For interactive components, use "use client" boundaries as narrowly as possible. The next/dynamic function with ssr: false can lazy-load heavy client components.

Vue: Use defineAsyncComponent for code splitting. Leverage v-memo directive to prevent unnecessary re-renders. For large lists, use virtual scrolling libraries. Vue 3's reactivity system is generally efficient, but computed properties that depend on large arrays can create expensive re-evaluations.

WordPress: The biggest INP challenge is third-party plugin JavaScript. Audit plugins with the Performance panel and defer non-critical scripts. Use the wp_enqueue_script with strategy => 'defer' (WordPress 6.3+). Consider Partytown to run third-party scripts in a Web Worker.

Frequently asked questions