How to Optimize Interaction to Next Paint (INP) for Web Apps

Why Did Google Replace First Input Delay (FID) With INP?

First Input Delay (FID) was an incomplete metric. It tracked only the delay before the browser began processing the very first interaction on a page—usually while initial bundles loaded. FID completely ignored the time taken to run your event handler callbacks, and it ignored the time taken for the browser to render the updated frame.

Worse, FID ignored every subsequent interaction. A user could load an e-commerce page, encounter no delays on the first tap, and then suffer 800ms freezes on every filter checkbox or accordion click. FID marked that session as fast.

Interaction to Next Paint (INP) fixes this blind spot. INP samples every click, tap, and keypress across the entire lifecycle of the visit. The single worst latency (or 98th percentile on pages with hundreds of interactions) becomes the page's INP score. If any tap freezes the UI for half a second, the page fails Core Web Vitals.

What Are the Three Phases of Every User Interaction?

When a visitor taps a button on your web page, the browser does not jump straight from input to pixels. Every interaction travels through three distinct stages:

1. Input Delay: The duration between the hardware event (finger touching screen, mouse click) and the moment the browser's main thread is free to fire your registered event listener.
2. Processing Duration: The wall-clock execution time of your JavaScript callbacks (such as onClick, keydown, or input validation handlers).
3. Presentation Delay: The time required for the browser engine to recalculate styles, recalculate layout (reflow), repaint layers, and composite the final pixels onto the screen.

Total INP equals the sum of these three phases. Optimizing INP requires discovering which specific phase consumes the bulk of your latency budget.

Phase Breakdown: Diagnosing Where Latency Hides

Use the Chrome DevTools Performance panel or the web-vitals JavaScript library to inspect the breakdown of slow interactions in real user sessions.

How to Yield to the Main Thread: Code Implementation

The single most effective technique for reducing processing duration and input delay is cooperative scheduling. When JavaScript runs a single task lasting longer than 50 milliseconds, the browser cannot accept new inputs or draw frame updates.

Modern browsers provide the scheduler.yield() API. When processing large data lists or updating multiple UI widgets, yield execution back to the browser engine so it can paint pending visual feedback:

// Yield helper with fallback for older browsers
async function yieldToMain() {
  if ('scheduler' in window && 'yield' in window.scheduler) {
    return await window.scheduler.yield();
  }
  return new Promise(resolve => {
    setTimeout(resolve, 0);
  });
}

// Handling a heavy filter action without locking the UI
async function handleFilterChange(items) {
  // 1. Immediately provide visual feedback (e.g., loading spinner or active state)
  showPendingIndicator();
  await yieldToMain(); // Allows browser to render visual feedback immediately

  const results = [];
  for (let i = 0; i < items.length; i++) {
    results.push(computeMatch(items[i]));

    // Yield every 50 items to keep main thread responsive to clicks
    if (i % 50 === 0) {
      await yieldToMain();
    }
  }

  renderResults(results);
  hidePendingIndicator();
}

Checklist: What to Audit When INP Exceeds 200ms

When an audit flags poor interaction latency on your client or e-commerce site, work through these diagnostic steps:

• Audit third-party script volume: Tag managers firing multiple tracking pixels simultaneously on click events create immediate input delay bottlenecks.
• Eliminate layout thrashing: Never read layout properties (like offsetHeight or getBoundingClientRect) immediately after writing DOM styles in the same event loop tick.
• Decouple analytics dispatch from UI feedback: Use navigator.sendBeacon() or fetch({ keepalive: true }) for tracking so analytics calls never hold up the visual next paint.
• Trim DOM node depth: Excessive DOM trees (over 1,500 elements) drastically increase presentation delay because recalculate style and composite operations scale with tree size.

Common Traps: What Does Not Fix INP

Teams unfamiliar with INP often implement fixes that solve server latency but leave interaction responsiveness untouched:

First, upgrading your hosting server or enabling edge caching improves Time to First Byte (TTFB), but does nothing for INP. INP is entirely a client-side execution metric running on the user's local CPU and GPU.

Second, wrapping code in requestAnimationFrame() does not shorten processing time. In fact, running heavy calculations inside requestAnimationFrame delays the upcoming frame paint directly, worsening presentation delay. Reserve requestAnimationFrame strictly for visual paint preparation, not heavy business logic.

Need your web platform audited for Core Web Vitals and frontend speed? Review our custom web development services, study our clinic platform build in the Coimbatore Dental Foundation case study, check our engineering presence across Tamil Nadu location hubs, or talk to Epiqu about performance optimization.