TL;DR. Interaction to Next Paint measures how long a page takes to visually respond to a click, tap, or keypress, across every interaction in a visit rather than just the first one. It officially replaced First Input Delay as a Core Web Vital in March 2024, and two years later, 43 percent of websites still fail its 200 millisecond threshold, making INP the most commonly failed Core Web Vital on the web today.
What is Interaction to Next Paint?
Interaction to Next Paint records the time between a visitor's interaction, a click, a tap, a keyboard press, and the moment the browser next paints a visual update reflecting that action. Unlike its predecessor, which only clocked the delay before the very first interaction on a page, INP evaluates every interaction across an entire visit and reports the worst one, giving a far more honest picture of whether a page stays responsive as someone actually uses it.
Key highlights
- web.dev's official rollout announcement confirmed INP's promotion to a stable Core Web Vital in March 2024, ending nearly two years of it running as an experimental metric alongside First Input Delay before fully replacing it.
- Thestacc's 2026 field data puts the current INP failure rate at 43 percent of sites missing the 200 millisecond threshold, the highest failure rate of the three Core Web Vitals by a wide margin.
- A good INP score is 200 milliseconds or under; 200 to 500 milliseconds needs improvement, and past 500 milliseconds is poor.
- INP replacing FID matters most for interaction-heavy pages, since a page could pass FID perfectly by having a fast first click while every subsequent interaction, a menu, a filter, a form field, remained sluggish under FID's old measurement scope.
Why the whole visit matters, not just the first click
First Input Delay's single biggest blind spot was scope: a page loaded with heavy JavaScript could respond instantly to a visitor's very first tap, since the browser's main thread happened to be free at that exact moment, then bog down on every interaction after. INP closes that gap by sampling across an entire session and reporting the worst experience a visitor actually had, which is a far more accurate proxy for whether a page feels responsive throughout normal use.
What usually causes a poor INP
- Long JavaScript tasks that block the main thread, delaying the browser from processing the next interaction until the current task finishes.
- Large, unoptimized event handlers doing heavy work synchronously on every click rather than deferring non-critical updates.
- Excessive DOM size, since the browser has to do more work recalculating layout and style after any single update.
Frequently asked questions
When did INP replace FID?
March 2024, after roughly two years running as an experimental metric. FID has since been fully deprecated and removed from the Core Web Vitals program.
What counts as a good INP score?
200 milliseconds or under, measured across every interaction during a visit rather than just the first one.
Why do so many sites still fail INP?
Mostly heavy client-side JavaScript that blocks the main thread during interactions, a problem that tends to compound on content-heavy or ad-supported pages where dozens of scripts compete for the same processing time.