INP Explained: What Is Interaction to Next Paint and Why It Replaced FID

You ran your site through PageSpeed Insights and saw "INP" sitting next to a number you don't recognize, replacing a metric you'd finally gotten comfortable with. That's a fair reaction — Google retired First Input Delay (FID) in March 2024, and Interaction to Next Paint (INP) took its place as the third official Core Web Vital.

This post explains what INP actually measures, why its 200-millisecond threshold works differently than you'd expect, and why Google decided FID wasn't telling the full story anymore. If you already have a handle on Largest Contentful Paint (LCP), think of this as the natural next piece of the Core Web Vitals puzzle — the one that measures how your site feels to interact with, not just how fast it loads.

What Is Interaction to Next Paint (INP)?

INP measures the time between a user's interaction with your page — a click, a tap, a key press — and the moment the browser visually updates in response. In plain terms: how long does someone wait after clicking a button before they see anything happen?

Unlike metrics that measure a single moment during page load, INP measures responsiveness across the entire lifespan of a page visit. It samples every interaction a user makes during their session and reports the slowest one (with some statistical trimming for pages with a lot of interactions) as your page's INP score.

Why "Next Paint" Matters as a Concept

The word "paint" here refers to the browser rendering an update to the screen — not necessarily the final result of whatever the interaction triggered, just visual proof that something happened. A button that changes color on click, even before the actual form submission completes, counts as a paint. A page that click-and-freezes for a full second before anything visibly changes has a bad INP, even if the underlying action eventually succeeds.

The Three Phases of an Interaction

INP isn't a single measurement — it's the sum of three distinct phases that happen every time a user interacts with a page.

Input delay. The time between the user's physical action (the click itself) and when the browser's main thread actually starts processing it. If the main thread is busy running something else — a long JavaScript task, a heavy script from a third-party tag — the interaction sits in a queue during this phase.

Processing time. The time your event handlers actually take to run. This is where your own code — form validation, state updates, API calls triggered synchronously — does its work.

Presentation delay. The time between your code finishing and the browser actually painting the visual update to the screen. Complex layout recalculations or large DOM updates can stretch this phase even after your JavaScript has technically finished executing.

A slow INP score can originate from any one of these three phases, which is exactly why "just optimize INP" is such vague advice — the actual fix depends entirely on which phase is the bottleneck on your specific page.

The INP Thresholds: What Counts as Good, Needs Improvement, or Poor

Google defines three bands for INP scores, measured in milliseconds [ADD SOURCE LINK — cite Google's official web.dev Core Web Vitals INP thresholds page]:

• Good: 200 milliseconds or less
• Needs Improvement: Between 200 and 500 milliseconds
• Poor: Over 500 milliseconds

That 200ms threshold is stricter than it might sound at first. It's not measuring how long an entire action takes to complete — it's measuring how long the user waits before seeing any visual acknowledgment. Two hundred milliseconds is close to the edge of what humans perceive as instantaneous; past that point, an interaction starts to feel sluggish even if the user can't articulate exactly why.

Why the Threshold Applies to Your Worst Interaction, Not Your Average

This is the detail that trips people up most. INP doesn't average your interactions together — it reports something close to your worst one (technically, a high percentile of all interactions on that page load, to filter out extreme outliers while still capturing real pain points). A page with 50 fast interactions and one slow modal-open animation gets scored on that one slow interaction, not the 50 fast ones.

This design choice is deliberate. A user who experiences one frustrating, laggy click remembers that moment — they don't mentally average it against everything else that went smoothly.

Why Google Replaced FID with INP

First Input Delay measured only the input delay phase — the queue-waiting time before the browser could even start processing a user's first interaction with the page. It never measured processing time, never measured presentation delay, and never looked at any interaction after the first one.

What FID Measured (and Its Blind Spot)

FID could tell you whether your page was slow to acknowledge a user's very first click. It couldn't tell you whether that click actually resulted in a fast, visible update, and it said nothing at all about the fifth, tenth, or fiftieth interaction during that same visit — which, for anything more interactive than a static blog post, is most of the actual experience.

A page could score a perfect FID and still feel completely broken to use, if every interaction after the first one triggered a multi-second freeze. That gap is exactly why FID never fully captured what "responsive" means to an actual visitor.

The Specific Gap INP Closes

INP measures the full interaction lifecycle — input delay, processing time, and presentation delay — across every interaction during the page's lifespan, not just the first one. It's a far more complete picture of whether a page stays responsive under real use, rather than just whether it responds acceptably to a single opening click.

FID vs. INP: A Direct Comparison

FID (Retired)INP (Current)MeasuresInput delay onlyInput delay + processing time + presentation delayInteractions coveredFirst interaction onlyAll interactions during the page visitWhat it missesEverything after the first click; whether the response was actually fastNothing structural — it's the more complete replacement"Good" thresholdUnder 100msUnder 200msRetiredMarch 2024Current official Core Web Vital

The threshold difference (100ms vs. 200ms) isn't INP being more lenient — it's measuring a longer, more complete pipeline, so the acceptable ceiling reflects that broader scope.

What Causes Poor INP Scores

A handful of root causes show up repeatedly across sites with poor INP, and most trace back to the main thread being too busy to respond quickly.

• Long JavaScript tasks. Any script execution over 50 milliseconds blocks the main thread from processing new interactions until it finishes — several of these stacked together during page load is one of the most common INP killers.
• Heavy event handlers. A click handler that runs expensive synchronous work — complex state recalculation, large re-renders, blocking API calls — directly inflates the processing-time phase.
• Third-party scripts. Chat widgets, analytics tags, and ad scripts run on the same main thread as your own code, and a poorly optimized third-party script can hijack the thread at the exact moment a user tries to interact.
• Large, complex DOM structures. A bloated DOM makes every layout recalculation more expensive, which drags out the presentation-delay phase even after your JavaScript has finished running.
• Unnecessary re-renders in JavaScript frameworks. Frameworks that re-render more of the page than an interaction actually requires waste processing time on work the user never asked for.

How to Measure Your Site's INP

INP can be measured two different ways, and they answer two different questions.

Field data comes from real users on real devices, aggregated through the Chrome User Experience Report (CrUX) and surfaced in Google Search Console and PageSpeed Insights. This is the data that actually affects your Core Web Vitals assessment for ranking purposes, because it reflects genuine visitor conditions — including slower phones and spotty networks a developer's machine never experiences.

Lab data comes from a controlled, simulated test — Chrome DevTools' Performance panel or a synthetic monitoring tool run against a specific page. Lab testing is useful for diagnosing why a page is slow, since it lets you record a specific interaction and inspect exactly which of the three phases is the bottleneck. It can't fully replicate field conditions on its own, though — a controlled test on a fast connection will often score better than what a real visitor on a mid-range phone experiences.

The two together are more useful than either alone: field data tells you whether you have a problem and how urgent it is, and lab data helps you find exactly what to fix.

Common Mistakes When Interpreting INP

Treating INP like a page-load metric. INP isn't measured during initial page load the way LCP is — it only exists once a user actually interacts with the page. A site with excellent LCP and TTFB can still have a poor INP if its interactive elements are heavy.

Optimizing for the wrong phase. Teams often jump straight to "reduce JavaScript" without confirming which of the three phases — input delay, processing, or presentation — is actually the bottleneck on their slowest interaction. That diagnosis step matters, because the fix for each phase looks completely different.

Ignoring third-party scripts because "we didn't write that code." Third-party scripts run on your page's main thread regardless of who authored them, and they count fully against your INP score. A slow chat widget is just as responsible for a poor score as a slow first-party script.

Assuming a good average interaction means a good INP. As covered earlier, INP is scored on your worst interactions, not your typical ones. A handful of fast, simple clicks doesn't offset one slow, janky modal or dropdown.

FAQ

What is a good INP score? Under 200 milliseconds is classified as "good" by Google's official Core Web Vitals thresholds. Between 200 and 500 milliseconds is "needs improvement," and anything over 500 milliseconds is "poor."

Why did Google replace FID with INP? FID only measured the delay before a page's first interaction started processing, and said nothing about how long that processing actually took or how the page performed on every interaction after the first one. INP measures the full interaction lifecycle across the entire page visit, giving a far more complete picture of real-world responsiveness.

Is INP measured during page load? No. INP only exists once a user actually interacts with the page — clicking, tapping, or pressing a key. A page can have excellent load-time metrics like LCP and still score poorly on INP if its interactive elements are slow to respond.

Does INP affect Google rankings? Yes, INP is one of the three current Core Web Vitals, alongside LCP and Cumulative Layout Shift (CLS), which Google factors into its page experience signals.

Can a fast website still have a bad INP score? Yes. A site can load quickly and still feel sluggish to use if its buttons, dropdowns, or forms trigger heavy JavaScript execution on interaction. Load speed and interaction responsiveness are related but genuinely separate problems.

How is INP different from page speed in general? "Page speed" usually refers to how quickly a page loads and becomes visible — metrics like LCP and TTFB. INP specifically measures what happens after the page has loaded, when a real user starts clicking and typing.

The Takeaway

INP measures something FID never could: whether your page stays responsive across an entire visit, not just at the very first click. Understanding the three phases — input delay, processing time, and presentation delay — is the difference between guessing at a fix and knowing exactly where your slowest interaction is actually losing time.

Run a free BugViso scan to get your site's INP measured alongside LCP and CLS, broken down by which phase is dragging your score down — not just a single number with no explanation attached.