INP: What Is Interaction to Next Paint | Blog SEO Ighenatt

On March 12, 2024, approximately 600,000 websites that had previously passed all Core Web Vitals began failing one of them. Not because they had gotten worse — Google replaced FID with INP, a far stricter standard for interactivity. The transition exposed something field data had been signaling for months: many sites load fast but respond slowly.

INP (Interaction to Next Paint) measures how quickly a page responds visually to what users do. Not just to the first action, as FID did, but to every click, tap, and key press throughout the entire session. A user filling out a form, filtering search results, or navigating a dropdown generates dozens of interactions. INP reports the worst of them.

The threshold is concrete: 200ms or less for a good rating. Within that window, the browser must receive the input, execute all event handlers, perform any necessary DOM recalculations, and paint the next frame on screen. On many JavaScript-heavy sites, that cycle extends to 800ms or more.

How INP Works: The Three Phases of an Interaction

To optimize INP you need to understand exactly what it measures. Every interaction recorded by the browser is split into three phases:

1. Input Delay

The time between when the user clicks or presses and when the browser can begin executing the event handlers for that event. If the main thread is busy with another task — an in-flight request processing data, a timer running code, script parsing — the event waits in the queue. That queue time is the input delay.

High input delay usually points to long tasks blocking the main thread. The standard reference is that no task should take longer than 50ms on the main thread to guarantee immediate responsiveness.

2. Processing Duration

The time it takes to run all event callback code associated with that interaction. If a button click fires three handlers that update React state, make an API call, and re-render a complex component, all that execution is added up here.

This is the component where code changes have the most impact.

3. Presentation Delay

The time from when callbacks finish until the browser renders the next frame with the applied changes. This includes style recalculation, layout, and compositing. A very large DOM, style changes that force reflow, or non-compositor CSS transforms can inflate this number significantly.

The sum of all three phases is the INP for that interaction. The page’s INP is the highest value (or close to maximum) from all interactions recorded during the session.

The Real State of INP in 2025: Who Fails and Why

Data from the Chrome UX Report processed by DebugBear in 2025 shows the current global INP picture. On desktop, 97% of sites achieve good INP (≤200ms). On mobile, that drops to 77%. That 20-percentage-point gap is not primarily explained by poorly optimized code — it is explained by devices.

In the United States, Germany, or Japan, the median mobile INP is 100ms — within the good threshold. In the Philippines, the 90th percentile of the slowest sites reaches 600ms. In Lesotho or Angola, even median websites exceed 300ms. The 23% of mobile sites that fail INP are, in large part, users in countries with low-end devices and unstable connections processing the same JavaScript that other users run on a recent iPhone.

The HTTP Archive’s Web Almanac 2025 confirms that the top 1,000 most-visited sites improved from 53% to 63% of pages with good INP in that year — a gain of 10 percentage points in 12 months. But across the entire web, the room for improvement remains substantial.

Sectors with consistently poor INP are e-commerce (heavy filter logic, cart, real-time validations) and media sites (programmatic advertising scripts, analytics trackers with costly handlers). Static sites or sites with minimal JavaScript are the ones that most easily achieve INP in the good range.

Why INP Matters for Business: The redBus Case

Performance metrics make sense when they translate into concrete results. The redBus case — India’s largest bus booking platform — is the reference benchmark for INP’s business impact.

redBus had INP problems specifically in search fields and filters. Their most critical interactions reached durations of 870–900ms — four times Google’s good threshold. The team identified three sources of latency:

Undebounced scroll event handler: The scroll handler was firing on every pixel of movement, saturating the main thread. The fix was to add debounce to the handler and use requestAnimationFrame to prioritize rendering work before the next frame.

Lazy-loading results in batches of 30: Each lazy load fetched 30 items, generating a costly processing and rendering task. Reducing the batch to 10 items fragmented the work into smaller tasks and spread the load.

Form state synced to Redux on every keystroke: Updating the global Redux store on each keypress triggered full re-renders of the component tree. The solution was to manage input state locally (React local state) and sync to the store only on the blur event — when the user leaves the field.

The result: a 72% reduction in input field INP, with interactions dropping from 870–900ms to 350–370ms. The business impact was a 7% increase in total sales. redBus documented the full methodology using Google’s web-vitals library with RUM through an ELK stack (Elasticsearch-Logstash-Kibana), measuring at the 95th percentile — not the median.

The Four Root Causes of Poor INP

1. Long Tasks on the Main Thread

A long task is any task that occupies the main thread for more than 50ms. During that time, the browser cannot respond to user events, which translates directly into input delay. Common culprits: parsing and execution of heavy JavaScript at interaction time, timers running costly work, and third-party scripts (analytics, chat widgets, A/B testing scripts) that run on the main thread without yielding control.

The solution is to break those long tasks into smaller subtasks. Addy Osmani, engineering manager at Google Chrome and a leading authority on web performance, frames it directly: “JavaScript is your most expensive asset” — not for its download size, but for the parsing and execution work it demands on the main thread.

2. Event Handlers Doing Too Much Synchronous Work

An event handler that does too much synchronous work blocks the main thread until it finishes. If a click on “add to cart” triggers stock validation, updates global state, recalculates the total price, and re-renders the header with an updated counter, all of that happens in the same task. The next frame cannot be painted until that task completes.

The solution is to separate urgent work (updating the UI immediately to give visual feedback to the user) from deferrable work (syncing with the server, updating secondary counters, logging the analytics event). Deferrable work can run in a separate task after the next frame is rendered.

3. Costly Reconciliation in JavaScript Frameworks

React, Angular, and Vue manage the DOM through an abstraction layer that adds extra work when state changes. In large applications, a simple interaction can trigger the re-rendering of a component tree containing dozens or hundreds of elements.

For React specifically, the most effective tools are: React.memo to prevent unnecessary re-renders of components that haven’t changed, useMemo for memoizing expensive calculations, useCallback for stabilizing function references, and startTransition (React 18+) to mark state updates as non-urgent and let the browser prioritize immediate visual feedback.

4. Excessively Large DOM

A DOM with more than 1,400 nodes is a Lighthouse warning signal. Every time JavaScript modifies the DOM, the browser needs to recalculate styles and layout. In a very large DOM tree, those recalculations are more expensive and contribute to presentation delay. List virtualization — rendering only the elements visible in the viewport — is the standard technique for sites with extensive dynamic content.

Concrete INP Optimization Techniques

Yielding to the Main Thread

The yielding technique involves breaking a long task into smaller subtasks, ceding control to the browser between them so it can process pending events. The simplest pattern uses setTimeout with a delay of 0:

button.addEventListener('click', () => {
  // Urgent work: immediate visual feedback
  updateButtonState('loading');

  // Yield control to the browser before continuing
  setTimeout(() => {
    processExpensiveWork();
    updateUI();
  }, 0);
});

The scheduler.yield() API (available in Chromium since 2024) offers a more granular version of this pattern with better prioritization guarantees. It is the evolution of manual yielding with setTimeout and is expected to expand to other browsers.

Separating Rendering Work from Post-Frame Work

For interactions where you need to update something visually and then do additional work, the requestAnimationFrame + setTimeout(0) pattern from web.dev is precise:

textInput.addEventListener('input', (event) => {
  // Update UI (rendering work — must run before the frame)
  updateDisplay(event.target.value);

  // Schedule non-visual work for after the frame
  requestAnimationFrame(() => {
    setTimeout(() => {
      runSpellCheck(event.target.value);
      syncToStore(event.target.value);
    }, 0);
  });
});

The requestAnimationFrame ensures updateDisplay runs in the correct rendering cycle. The setTimeout(0) inside the callback defers the remaining work to a new task, after the frame has been painted.

Debounce and Throttle for High-Frequency Events

input, scroll, and resize events can fire dozens of times per second. Running expensive logic on every firing saturates the main thread. Debounce (run only after the user has stopped interacting for N ms) and throttle (run at most once every N ms) dramatically reduce execution count without affecting perceived responsiveness.

CSS content-visibility for Large DOM

The CSS property content-visibility: auto tells the browser it can skip rendering sections outside the viewport, reducing layout and paint costs. On pages with heavy below-the-fold content, this property can reduce initial rendering time and ease presentation delay on interactions that modify the DOM.

How to Diagnose INP with Real Tools

PageSpeed Insights: Enter the URL to get both the field INP (CrUX data from real users) and the lab INP (simulated Lighthouse). The field data is what Google uses for ranking. If there is a large gap between both, investigate whether there are interactions Lighthouse does not simulate but real users actually perform.

Chrome DevTools — Performance tab: Record while interacting with the page. Look for red bars on the main thread that indicate long tasks (>50ms). Click an interaction to see the breakdown into input delay, processing time, and presentation delay. The flame chart shows which functions consume the most time within each task.

Google Web Vitals extension: Shows INP in real time as you browse. Useful for identifying which specific interactions are the slowest in your real user flow.

web-vitals.js library in production: For RUM in production, Google’s official library reports INP with attribution of the element that triggered it. This is the same methodology redBus used to identify their input fields as the source of their problems.

import { onINP } from 'web-vitals/attribution';

onINP(({ value, attribution }) => {
  console.log(`INP: ${value}ms`);
  console.log(`Element: ${attribution.interactionTarget}`);
  console.log(`Type: ${attribution.interactionType}`);
});

INP and Its Relationship with Google Rankings

INP is one of the three Core Web Vitals Google uses as a ranking signal since March 2024, alongside LCP and CLS. Poor INP does not trigger a direct ranking penalty, but it operates as a comparative disadvantage: when two pages are equivalent in content and authority, page experience signals — including INP — act as a tiebreaker.

DebugBear’s report on the Google Core Update of December 2025 documented 31% visibility drops for pages with INP above 300ms on mobile. Not all ranking losses are attributed exclusively to INP — most core updates affect multiple signals — but the pattern confirms that poor INP forms part of the technical profile of pages that lose positions.

For e-commerce, where cart responsiveness, filters, and internal search have direct conversion impact, INP optimization has a double ROI: it improves ranking and improves conversion rate independently.

Want to know where your site’s INP stands and which specific interactions are dragging it down? We review it as part of any technical audit. Tell us about your case.