Interaction to Next Paint (INP) Explained

Of the three Core Web Vitals, Interaction to Next Paint is the one most sites fail without realising it — because it only shows up when a real person clicks, taps or types, and most testing happens on an empty page with nobody touching it. This is INP explained properly: how it replaced First Input Delay, the three phases that make up every interaction, what causes each one to stall, and exactly how to fix it. If you want the full picture of all three Core Web Vitals first, start with Core Web Vitals explained; this article goes deep on INP alone.

From FID to INP: what actually changed

For years, the responsiveness vital was First Input Delay (FID). FID measured one narrow thing: the time between a user's first interaction with a page and the moment the browser was able to start processing it. It ignored everything about how long that processing took, ignored how long it took the screen to visually update afterwards, and — critically — it only looked at the first interaction of the visit. A page could pass FID with flying colours on that first tap and then lock up for a full second on every scroll and click afterwards, and FID would never know.

In March 2024, Google replaced FID with INP as the official Core Web Vital for responsiveness, and FID was retired. INP fixes both gaps at once:

• It covers the whole visit. INP samples the interactions a user makes throughout their time on the page — not just the first one — and reports a value close to the worst of them (technically, close to the highest, with an allowance for very interaction-heavy sessions so a handful of outliers don't unfairly tank the score).
• It measures the full interaction, not just the delay before it starts. INP accounts for the time from input to the next visual frame the browser paints, which is the part users actually feel.

That second point is the one worth sitting with. FID answered "did the browser notice you clicked, promptly?" INP answers "did the page actually respond, in a way you could see, promptly?" Those are very different questions, and INP is the one that matches what a frustrated user means when they say a site "feels laggy."

The three phases of every interaction

Every interaction INP measures — a click, a tap, a key press — passes through three distinct phases before the user sees a result. Knowing them matters because the fix for a slow phase-one problem is completely different from the fix for a slow phase-three problem, and guessing wastes time.

Diagnosing which phase dominates is the first real step, not an optional extra. Chrome DevTools' Performance panel records interactions with all three phases broken out on the timeline, so you can see, for a specific slow click, whether the browser was stuck waiting (input delay), busy running your code (processing), or busy re-rendering (presentation). Fixing the wrong phase — say, optimising a handler when the real problem is a queue of long tasks blocking input delay — will not move your INP score at all.

What causes poor INP

A handful of patterns account for almost every bad INP score:

• Long tasks on the main thread. Any JavaScript task that runs for more than 50ms blocks input from being handled until it finishes. Big bundles, heavy hydration, and dense synchronous logic all produce these.
• Third-party scripts. Tag managers, chat widgets, A/B testing tools and ad scripts are consistently the biggest INP offenders on real sites, because they run on your main thread but are entirely outside your control, and they often fire more work in response to the same interactions your own code is handling.
• Expensive event handlers. A click handler that does too much synchronous work — recalculating a large data set, formatting a big table, running unthrottled logic — makes the processing phase the bottleneck.
• Oversized DOM. A very large or deeply nested DOM makes style recalculation and layout expensive on every interaction, not just at page load, because the browser has more to check every time something changes.

How to fix INP, phase by phase

Break up long tasks and yield to the main thread. Splitting one large JavaScript task into smaller chunks, with a yield in between, lets the browser stop and handle a pending interaction before continuing. The modern way to do this is scheduler.yield() (with setTimeout(fn, 0) as a fallback for browsers that don't yet support it), and isInputPending() can tell a long-running task to check whether it should pause because a user has just interacted. This is the single highest-leverage fix for the input delay phase.

Defer or lazy-load third-party scripts. Load tag managers, chat widgets and A/B tools with async/defer, delay them until after the main content is interactive, or load them only when a user is likely to need them (for example, loading a chat widget only after a scroll or a click on a "help" affordance). Every third-party script you can delay is main-thread time you get back.

Move heavy work off the main thread with web workers. Computation that doesn't need direct DOM access — large data transforms, sorting, parsing — can often run in a web worker, leaving the main thread free to handle input the moment it arrives.

Debounce and throttle expensive handlers. If a handler runs on every keystroke or every scroll event, throttle it so it does the expensive work less often, and debounce anything that should only run once the user has paused.

Reduce DOM size, and use content-visibility for off-screen content. Applying content-visibility: auto to sections that are off-screen tells the browser to skip layout and paint work for them until they're needed, which shrinks the cost of every style recalculation — directly improving the presentation delay phase.

Where to find real INP data

Because INP is fundamentally a field metric, you need a source of real-user data, not just a synthetic test:

• Chrome User Experience Report (CrUX) — Google's own aggregated field data, and the source it uses for the page experience signal. This is the number that determines whether you pass or fail.
• Real User Monitoring (RUM) — if you have enough traffic, your own RUM setup gives you INP broken down by page, device and even individual long tasks, which is far more actionable than an aggregate CrUX figure.
• PageSpeed Insights — surfaces CrUX field data for a URL alongside a Lighthouse lab run, so you get both a real INP (if the URL has enough traffic to qualify) and lab diagnostics in one place.

Crawl Cove pulls CrUX field data automatically on every audit, so you see your real INP at the 75th percentile alongside the long tasks and third-party scripts likely causing it — no separate RUM setup required to get started. Check where any page stands with the free Core Web Vitals checker, and if responsiveness issues are tangled up with layout or mobile usability, the mobile-friendly checker is worth running alongside it, since heavy interactive elements often hurt both.

For the authoritative technical detail beyond what's practical to cover here, Google's own INP article on web.dev is the best primary source.

Wrap-up

INP replaced FID because responsiveness is not just about the first click — it's about every interaction, for the whole visit, measured all the way through to the moment the screen actually updates. When a page fails INP, the fix starts with working out which of the three phases — input delay, processing time, or presentation delay — is actually to blame, then targeting it directly: yielding long tasks, deferring third-party scripts, moving work to workers, debouncing handlers, or trimming the DOM. None of that is guesswork if you have real field data to point at the worst pages first. See how Crawl Cove surfaces INP, long tasks and the scripts behind them on every audit, so you're fixing the actual bottleneck instead of the one you assumed.