Interaction to Next Paint (INP): The Complete Guide

Interaction to Next Paint (INP) is the Core Web Vital that measures how quickly your page responds to everything a visitor does. It replaced First Input Delay (FID) on March 12, 2024, and it is a far harder test to pass. Plenty of sites that sailed through FID now show up as "needs improvement" or "poor" on INP, because INP looks at every interaction across a visit instead of just the first one. This guide explains what INP measures, the official thresholds, the three phases inside every interaction, why pages fail, how to diagnose problems, and the concrete fixes that move the number.

What INP is and why it replaced FID

INP became a Core Web Vital on March 12, 2024, taking the place of First Input Delay. Google announced the switch on its Search Central blog in 2023 and confirmed the date in early 2024, giving site owners time to prepare. FID was retired in the same transition.

The reason for the change is honesty. FID only measured the input delay of the first interaction on a page, and only the delay before the event handler started running. That left out almost everything users actually feel: the work the handler does, every interaction after the first, and the time it takes for the screen to visibly update. A page could score a perfect FID and still feel sluggish every time someone clicked a menu or typed in a search box.

INP closes that gap. As web.dev describes it, INP "assesses page responsiveness by observing the latency of all click, tap, and keyboard interactions that occur throughout the lifespan of a user's visit to a page." It measures the complete round trip from input to the next painted frame, and it reports a value close to the worst interaction a user experienced. That makes it a much closer proxy for how responsive a page genuinely feels.

How INP is measured and the official thresholds

INP is a field metric. It is collected from real users in the Chrome User Experience Report (CrUX), and Google evaluates it at the 75th percentile across mobile and desktop. In plain terms: 75 percent of your real visitors need to experience an INP at or below the target for the page to pass. One slow interaction for a small slice of users will not sink you, but a consistently heavy page will.

The documented thresholds from web.dev are exact and worth memorizing:

Those are the only numbers Google publishes for INP. Aim for 200 ms or less, and treat anything in the 200 to 500 ms band as a warning that real users are starting to feel friction.

The three phases of an interaction

To fix INP you have to understand what it is timing. Every interaction is split into three phases, and the full duration of all three is what INP records.

1. Input delay

This is the time between the user's action (the tap or key press) and the moment the browser can start running your event handlers. The most common cause of input delay is the main thread already being busy with other work, such as scripts still loading or a long task running in the background. If the thread is occupied, the input simply waits.

2. Processing duration

This is the time it takes to run all the event handler callbacks tied to the interaction. Bloated handlers that do too much in one go, such as heavy data work, spell-checking, or analytics calls, stretch this phase out.

3. Presentation delay

This is the time from when your callbacks finish to when the browser paints the next frame showing the result. Expensive rendering, layout recalculation, and a large or complex DOM all inflate this final phase.

A good INP score requires all three phases to stay short. Optimizing one while ignoring the others rarely moves the needle.

Common causes of poor INP

Almost every INP problem traces back to the same root: too much JavaScript blocking the main thread. When the browser is busy executing scripts, it cannot respond to the user or paint a new frame. The specific offenders tend to be:

• Heavy first-party bundles. Large JavaScript files that ship more code than the page needs, often because nothing is code-split.
• Long tasks. Any single piece of work that occupies the main thread for an extended stretch blocks every interaction queued behind it.
• Third-party tags. Analytics, A/B testing, chat widgets, and ad scripts frequently run long tasks you do not control.
• Oversized DOM. A deep or very large DOM makes rendering and layout slower, which drags out presentation delay.
• Layout thrashing. Reading computed styles right after changing the DOM in the same task forces the browser into synchronous layout work it could otherwise batch.

If you are also wrestling with slow responses at the server level, our guide to 5xx server errors and SEO covers the infrastructure side of speed problems.

How to diagnose INP

Because INP is a field metric, start with real-user data and then reproduce issues in the lab.

• CrUX and PageSpeed Insights. PageSpeed Insights surfaces your CrUX field data, including INP at origin and, where available, URL level. This is the authoritative view of how real users experience your page.
• The Web Vitals Chrome extension. It reports INP live as you interact with a page, breaking the number down by the slowest interaction so you can see exactly which control is the problem.
• Chrome DevTools Performance panel. Record a trace while you click or type, then inspect the interaction to see how input delay, processing, and presentation split the total. Long tasks show up clearly here.
• Real user monitoring (RUM). A RUM tool collects INP from your actual traffic continuously, which is the best way to catch interactions that only behave badly on real devices or specific pages.

The pattern is always the same: identify the slowest interaction from field data, then reproduce and profile it in DevTools to find which phase is eating the time.

How to fix INP

Once you know which phase is slow, the fixes are concrete.

Ship less JavaScript

The single biggest lever. Remove unused scripts, code-split so each page loads only what it needs, and audit every third-party tag for whether it earns its place. Less code on the main thread means shorter input delay and fewer long tasks.

Break up long tasks

Split large pieces of work into smaller chunks so the browser can respond to input between them. The classic approach is to defer non-urgent work with setTimeout, and modern browsers offer scheduler.yield() to yield to the main thread while keeping your place in the queue. Breaking one long task into several short ones lets pending interactions slot in.

Yield to the main thread

Inside event handlers, do only the visual update the next frame needs, then yield. Push everything else, such as logging, persistence, or counting, to after the paint. This keeps processing duration short and lets the user see a response fast.

Optimize event handlers and rendering

Keep callbacks lean. Avoid layout thrashing by not reading computed styles immediately after writing to the DOM in the same task. Use requestAnimationFrame() to schedule visual updates, and reserve heavy logic for after the frame renders.

Reduce DOM size and rendering cost

Flatten an overly deep DOM, add elements during interactions rather than rendering everything upfront, and use the CSS content-visibility property to skip rendering off-screen content until it is needed. Smaller render work means shorter presentation delay.

Responsiveness is increasingly important not just for human visitors but for automated agents reading your pages too. Our research on machine-readable web standards looks at how predictable, fast-responding pages serve both audiences.