Interaction to Next Paint (INP)

Interaction to Next Paint, or INP, is one of Google's three Core Web Vitals. It measures responsiveness: how quickly a page reacts when someone clicks, taps or presses a key. A low INP means the interface responds almost instantly; a high one means the visitor clicks and then waits, watching a page that appears frozen. INP became a Core Web Vital in March 2024, replacing First Input Delay, and it is the metric that captures whether a page feels alive under real use.

What INP measures

INP observes every interaction a visitor makes throughout the life of the page and measures how long each one takes to produce a visual response. An interaction is a discrete input such as a click, a tap or a key press. Scrolling and hovering do not count, because they do not depend on the same event-handling path. From all of those measured interactions, INP reports a single value that represents the page's worst realistic response time, so it reflects the slowest moments a visitor actually felt rather than an average that hides them.

On pages with many interactions, INP discards a small number of extreme outliers so that one freak delay does not define the score, but the intent is clear: the metric is deliberately strict, because a single unresponsive interaction is exactly what makes a page feel broken.

The three phases of an interaction

Every interaction latency breaks into three consecutive parts, and knowing which one dominates is the whole game:

• Input delay: the time from the input until the browser can start running the event handler. This is usually where the main thread is busy with other work.
• Processing time: how long your event handlers take to run.
• Presentation delay: the time from the handlers finishing until the browser paints the next frame that reflects the change.

A slow INP is almost never all three at once. Long input delay points to a blocked main thread; long processing time points to heavy handlers; long presentation delay points to expensive rendering or layout. Measuring the split tells you exactly where to work.

An interaction that freezes: the three phases in practice

Picture a product page with filters. The visitor taps a filter chip. First, the browser may already be busy running an analytics script, so the tap has to wait before the handler can start: that is input delay. When the handler finally runs, it re-sorts a list of 500 products and rebuilds the DOM synchronously: that is processing time. Then the browser lays out and paints the new list: that is presentation delay. Added up, the visitor waited 600 milliseconds after a single tap, well into the poor range. The fix is not one change but three small ones, each aimed at a different phase: keep analytics off that critical moment, defer the re-sort so the chip can highlight first, and shrink the DOM work that follows.

What is a good INP score

Google defines three bands, measured at the 75th percentile of real interactions across mobile and desktop:

• Good: 200 milliseconds or less
• Needs improvement: between 200 and 500 milliseconds
• Poor: more than 500 milliseconds

The 200 millisecond target is the threshold below which an interaction feels immediate. Because the score sits at the 75th percentile, three out of four interactions must clear it, and mobile devices with slower processors are usually what decides whether you pass.

How INP differs from First Input Delay

INP replaced First Input Delay because FID measured too little. FID only looked at the input delay of the very first interaction on the page, ignoring processing time, presentation delay, and every interaction after the first. A page could score a perfect FID and still be painful to use once the visitor started clicking. INP measures every interaction from input to the next paint, which is far closer to the real experience and much harder to game. FID has been retired from Core Web Vitals entirely.

How INP is measured: lab and field

INP needs real interactions, so field data from the Chrome UX Report and real user monitoring is authoritative. Lab tools cannot produce a true INP because there is no user clicking; instead they use Total Blocking Time as a proxy for how likely the main thread is to be blocked when an interaction arrives. Treat a poor Total Blocking Time in the lab as a warning that field INP will suffer.

You can record real interactions in the browser with the Performance API, filtering to the ones long enough to matter:

new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    console.log('interaction:', entry.name, Math.round(entry.duration), 'ms');
  }
}).observe({ type: 'event', durationThreshold: 40, buffered: true });

Google's web-vitals JavaScript library reports INP with attribution, naming the slowest interaction and its element, and the Chrome DevTools Performance panel shows an interactions track on the timeline. Any of these tells you which interaction to fix first.

What causes a high INP

Poor responsiveness almost always traces back to the main thread being busy or your handlers doing too much:

• Long tasks that occupy the main thread block it from responding to input, inflating input delay.
• Heavy event handlers that run expensive work synchronously inflate processing time.
• Large or complex DOM makes every style and layout recalculation after an interaction slower, inflating presentation delay.
• Framework hydration and re-rendering can tie up the main thread, especially on single-page apps early in the page's life.
• Third-party scripts run their own tasks on your main thread, competing with your handlers.

How to improve INP

1. Break up long tasks and yield to the main thread

Any task longer than about 50 milliseconds blocks input. Split long work into smaller chunks and hand control back to the browser between them so it can respond to interactions and paint. The modern API is scheduler.yield(), with a fallback for browsers that lack it:

async function doWork(items) {
  for (const item of items) {
    process(item);
    // let the browser handle pending input and paint
    if (scheduler?.yield) {
      await scheduler.yield();
    } else {
      await new Promise(r => setTimeout(r));
    }
  }
}

2. Give feedback first, defer the heavy work

Inside an event handler, do the minimum needed to show the visitor something happened, then let the browser paint before running the expensive part:

async function handleClick() {
  showSpinner();            // cheap: instant visual feedback
  await scheduler.yield();  // let the browser paint the spinner
  renderExpensiveResults(); // the heavy work runs after the paint
}

The interaction now feels immediate even when the underlying work takes time, because the next paint is no longer waiting on it.

3. Reduce the JavaScript you ship

Less script means a freer main thread and shorter tasks. Code-splitting, tree shaking and removing dead code all lower the baseline load on every interaction. See reduce unused JavaScript, which is the most direct lever on input delay.

4. Move heavy computation off the main thread

Work that does not touch the DOM, such as parsing, sorting large datasets or image processing, can run in a Web Worker on a separate thread. The main thread stays free to respond to input while the worker computes.

5. Debounce and throttle expensive handlers

Handlers bound to rapid events, such as input or resize, can fire far more often than needed. Debounce or throttle them so the expensive work runs once the activity settles rather than on every event.

6. Keep the DOM and rendering lean

A smaller DOM makes post-interaction style and layout work faster, shortening presentation delay. Batch DOM reads and writes to avoid layout thrashing, and in frameworks avoid unnecessary re-renders through memoization and by not updating state that does not need to change.

7. Tame third-party scripts

Third-party code runs tasks on your main thread. Load non-essential tags after the page is interactive, use facades for heavy widgets, and remove tags that no longer earn their cost, so they stop competing with your own handlers.

8. Handle framework rendering

Single-page apps concentrate work on the main thread, so framework tools matter. In React, mark non-urgent state updates with startTransition so an interaction can paint before the expensive re-render runs, and use useDeferredValue to keep a typing input responsive while a heavy list updates behind it. Avoid re-rendering large trees on every keystroke, and memoize components that do not need to change. During initial load, hydration can block interactions, so partial or progressive hydration, or an islands architecture, keeps the page interactive sooner. Other frameworks offer similar deferral, and all of them benefit from not running a full synchronous re-render inside an event handler.

9. Reduce INP in WordPress

On WordPress, high INP usually comes from too many plugins and heavy third-party embeds, each adding scripts that run on the main thread. Remove plugins you no longer use, defer non-essential scripts with a performance plugin, and replace heavy embeds such as chat widgets and video players with facades that load on interaction. Test the interactions that matter afterwards, since aggressive script deferral can delay handlers a page genuinely needs.

How to verify your INP

Because INP is a field metric, the real confirmation comes from the Chrome UX Report over its trailing 28-day window, or from real user monitoring that reports INP sooner on your own traffic. For debugging, use the DevTools Performance panel to record an interaction and read its three phases, and check that Total Blocking Time has improved in the lab as a leading indicator. Test on a mid-range mobile device with CPU throttling, since that is where slow interactions surface, and exercise the interactions that matter most, such as opening menus, filtering lists and submitting forms.

The attribution build of the web-vitals library goes further, reporting which of the three phases dominated and which element and event caused the slowest interaction, so you can target the exact handler instead of guessing.

INP and the other Core Web Vitals

INP is one of three Core Web Vitals alongside Largest Contentful Paint, which measures loading speed, and Cumulative Layout Shift, which measures visual stability. They share a root cause more than they compete: the same excess JavaScript that slows loading also blocks the main thread that responsiveness depends on, so reducing script tends to help both LCP and INP. Fix INP as its own goal, but expect the main-thread work you remove to pay off across more than one metric.

Frequently asked questions

What is a good INP score?

200 milliseconds or less at the 75th percentile of real interactions is good. Between 200 and 500 milliseconds needs improvement, and more than 500 milliseconds is poor.

What is the difference between INP and FID?

First Input Delay only measured the input delay of the first interaction. INP measures every interaction across the whole page, end to end, including processing time and the next paint. INP replaced FID as a Core Web Vital in March 2024.

What causes a high INP?

Usually a busy main thread and heavy event handlers: long tasks, expensive handler code, a large DOM, framework hydration, and third-party scripts all inflate one of the three phases of interaction latency.

Does scrolling count towards INP?

No. INP measures discrete interactions such as clicks, taps and key presses. Scrolling and hovering are not counted.

How do I measure INP?

Use field data from the Chrome UX Report or real user monitoring, since INP needs real interactions. For debugging, use the DevTools Performance panel and the web-vitals library, and watch Total Blocking Time in the lab as a proxy.

Is INP a Google ranking factor?

Yes. INP is one of the three Core Web Vitals, which are part of Google's page experience signals and are assessed on real-user field data.