How to Fix INP: Interaction to Next Paint Optimization Guide

The answer is probably INP

Interaction to Next Paint officially became a Core Web Vital in March 2024, replacing First Input Delay (FID). Unlike its predecessor, INP doesn't just measure how your page feels when it first loads. It tracks responsiveness throughout the entire user session, exposing problems that FID conveniently missed. Understanding Core Web Vitals INP is essential for maintaining search rankings.

This guide covers what INP measures, why so many sites suddenly failed after the switch, and practical approaches to fix responsiveness issues in JavaScript-heavy applications. You'll learn INP optimization techniques that can help you fix INP score issues.

Prerequisites

Before working on INP improvements, you should have:

• Basic familiarity with Chrome DevTools Performance panel
• Understanding of JavaScript's event loop and main thread blocking
• Access to PageSpeed Insights or Google Search Console for your site
• Knowledge of your site's JavaScript framework (React, Vue, Next.js, etc.)

If your site has real user traffic, you'll also need access to Chrome UX Report (CrUX) data through PageSpeed Insights or Search Console to see actual field measurements.

What INP Actually Measures

INP captures the full latency of user interactions from the moment someone clicks, taps, or uses their keyboard until the browser paints the next visual frame. This includes everything that happens between input and visible response.

The thresholds are straightforward:

• Good: ≤ 200ms
• Needs Improvement: 200–500ms
• Poor: > 500ms

To pass Core Web Vitals for responsiveness, you need most real-user interactions under 200ms at the 75th percentile. That 200ms window sounds generous until you realize how quickly JavaScript frameworks can burn through it.

Why This Metric Exists

Google introduced INP because FID created a false sense of security. About 93% of sites had good FID scores on mobile. That number dropped to roughly 65% when measured by INP.

The gap exists because FID only measured input delay for the first interaction, mostly telling you whether your page was ready when it initially loaded. INP catches the sluggishness that happens during actual use: when hydration kicks in, when heavy event handlers run, when React re-renders entire component trees.

How INP Differs from FID

Understanding INP vs FID is crucial for grasping why scores changed. The differences explain why your previously "fast" site might now show responsiveness problems:

• Scope: FID measured first interaction only; INP measures all interactions throughout page session
• Measurement: FID measured input delay only; INP measures full interaction latency
• Threshold: FID was 100ms; INP is 200ms
• What it catches: FID caught startup responsiveness; INP catches entire session responsiveness

FID measured only how long the browser waited before it could start processing your first click. INP measures input delay plus processing time plus the time it takes to paint the result. It does this for every qualifying interaction during your visit, then reports approximately the worst one.

The calculation includes some outlier suppression. For pages with many interactions, Google ignores one highest-latency interaction for every 50 interactions to prevent random hiccups from dominating the score.

The Three Phases of INP

Every interaction breaks down into three phases, and problems in any phase hurt your score:

Phase 1: Input Delay

This is time spent waiting for event handlers to start. The user clicked, but the browser can't begin processing yet because the main thread is busy with something else. Learning to reduce input delay is key to INP optimization.

Common causes:

• Long tasks running during page startup or framework hydration
• Script evaluation blocking the main thread
• Heavy synchronous work from third-party scripts

Phase 2: Processing Time

This is time spent actually executing your event handlers. The browser started processing the click, but your code takes a while to finish. JavaScript performance optimization is critical here.

Common causes:

• Large synchronous event handlers doing too much work
• Expensive state updates triggering calculations
• Inefficient framework render paths

Phase 3: Presentation Delay

This is time the browser needs to render the visual result. Your code finished, but painting the update takes longer than expected.

Common causes:

• Large DOM trees (more than 1,400 elements gets problematic)
• Complex CSS requiring heavy style recalculation
• Heavy component re-renders updating large portions of the page

Our experience shows that most INP failures come from phases 1 and 2, particularly when JavaScript frameworks queue up work that blocks the main thread right when users try to interact.

Which Sites Struggle Most

The INP shift hit certain types of sites particularly hard:

Single-page applications with heavy client-side JavaScript often fail because hydration and route transitions block the main thread during exactly the moments users want to interact. React hydration performance is a common culprit.

E-commerce sites with complex product interfaces, filtering systems, and dynamic cart updates frequently exceed the 200ms threshold when users click through options.

Legacy frontends carrying years of accumulated JavaScript without performance auditing tend to have main thread blocking code scattered throughout.

Sites heavy on third-party scripts like analytics, ads, chat widgets, and tracking pixels often see input delays spike because those scripts compete for main thread time.

Practical Improvement Approaches

Improving INP requires addressing whichever phase is causing the most delay. Start by profiling actual interactions in DevTools to identify your specific bottlenecks. These strategies will help improve website responsiveness.

1. Break Up Long Tasks

Long tasks JavaScript (over 50ms) block the main thread and inflate input delay. Break them into smaller chunks using scheduler.yield() (available in Chrome 125 ) or setTimeout. Using scheduler.yield JavaScript is the modern approach:

// Instead of processing everything at once
async function processLargeDataset(items) {
  for (const item of items) {
    processItem(item);
    
    // Yield to the main thread periodically
    if (shouldYield()) {
      await scheduler.yield();
    }
  }
}

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

2. Defer Non-Critical Work

Use requestIdleCallback for work that doesn't need to happen immediately:

// Schedule non-urgent updates for idle time
function scheduleAnalyticsUpdate(data) {
  if ('requestIdleCallback' in window) {
    requestIdleCallback(() => {
      sendAnalytics(data);
    }, { timeout: 2000 });
  } else {
    setTimeout(() => sendAnalytics(data), 100);
  }
}

3. Debounce and Throttle Event Handlers

For interactions that fire rapidly (scroll, resize, input changes), limit how often your handlers execute:

function debounce(func, wait) {
  let timeout;
  return function executedFunction(...args) {
    clearTimeout(timeout);
    timeout = setTimeout(() => func.apply(this, args), wait);
  };
}

// Apply to search input
const searchInput = document.getElementById('search');
searchInput.addEventListener('input', debounce((e) => {
  performSearch(e.target.value);
}, 300));

4. Reduce DOM Size and Complexity

Large DOMs slow down both processing and presentation phases. Working with teams has taught us that DOM cleanup often delivers the most noticeable INP improvements:

• Virtualize long lists instead of rendering all items
• Remove hidden elements from the DOM rather than using display: none
• Simplify nested structures where possible
• Lazy-load content sections as users scroll

5. Address Framework-Specific Issues

React, Vue, and other frameworks have their own INP considerations:

React: Use useMemo and useCallback to prevent unnecessary re-renders. Consider React.lazy for code splitting and startTransition for non-urgent state updates.

Vue: Leverage computed properties properly and avoid reactive dependencies that trigger cascading updates.

Next.js/Nuxt: Both frameworks released INP-focused updates in 2024. Upgrade to recent versions and follow their hydration guidance to reduce startup blocking.

Common Mistakes to Avoid

Relying only on lab testing. INP can appear fine in DevTools but fail in the field because real users interact at unpredictable moments when the main thread might be busy. Always check field data from CrUX.

Ignoring third-party scripts. That chat widget or analytics library might be responsible for significant main thread blocking. Audit third-party impact using the Chrome DevTools performance panel.

Assuming fast initial load means fast interactions. This was exactly why FID gave misleading results. A site can load quickly but become sluggish once JavaScript frameworks start doing work.

Over-optimizing for rare interactions. Focus on the interactions users perform most often. INP reports approximately the worst interaction, but fixing your most common interaction paths will improve overall user experience more effectively.

Deferring too aggressively. Moving all work to idle callbacks can make the UI feel unresponsive in a different way. Find the balance between immediate feedback and background processing.

Measuring and Verifying INP

PageSpeed Insights

PageSpeed Insights INP data shows both lab and field measurements. The field data comes from the Chrome UX Report and reflects the previous 28 days of real user measurements. This is what Google actually uses for Core Web Vitals scoring.

Note that field data requires sufficient traffic. If your page doesn't have enough visits, you'll only see lab measurements, which may not reflect real-world INP.

Chrome DevTools

The Performance panel lets you record interactions and see exactly where time goes:

• Open DevTools and go to the Performance tab
• Click Record
• Perform the interaction you want to measure
• Stop recording
• Look for "Interaction" entries in the timeline

This shows you the breakdown between input delay, processing, and presentation for specific interactions.

Google Search Console

Search Console expanded INP reporting in late 2024. Check the Core Web Vitals report to see which URL groups have INP issues and track improvements over time.

Web Vitals JavaScript Library

For custom monitoring, Google's web vitals library captures INP in the field:

import { onINP } from 'web-vitals';

onINP((metric) => {
  console.log('INP:', metric.value);
  // Send to your analytics
});

Important Measurement Caveats

INP may be absent for page views where users don't perform any qualifying interactions. This can complicate analysis for pages where users primarily read content without clicking.

The Event Timing API that powers INP measurement can generate entries even when there are no actual event listeners. When building custom monitoring, filter for meaningful interactions rather than raw event timing data.

Conclusion

INP raised the bar for web responsiveness by measuring what FID ignored: how sites behave throughout actual use, not just at first click. The roughly 28% of sites that passed FID but failed INP represent real user frustration that was previously invisible to Core Web Vitals.

Fixing INP typically means breaking up long JavaScript tasks, managing framework hydration carefully, keeping DOM sizes reasonable, and auditing third-party script impact. The specific approach depends on your stack and where your particular bottlenecks live.

We've found that INP improvements often require JavaScript profiling expertise and sometimes architectural changes, particularly for legacy applications with accumulated performance debt. If your site is struggling with INP scores and you're not sure where to start, we can help you identify the specific bottlenecks and build a prioritized plan for improvement.