What Is Interaction to Next Paint? The Metric After FID

Jul 19, 2026 · SEO Glossary

For years, sites passed their responsiveness metric with suspicious ease. First Input Delay — the original Core Web Vitals responsiveness measure — graded only the delay before processing the first interaction, and well over 90% of sites scored "good." Meanwhile users were still rage-clicking unresponsive buttons everywhere. The metric and the experience had drifted apart, and Google knew it.

What is Interaction to Next Paint? INP is the Core Web Vitals metric that measures how quickly a page responds to user interactions — clicks, taps, and key presses — throughout the entire page visit. For each interaction it measures the time from the user's input until the next frame is painted to the screen, and the page's INP is roughly the worst such interaction (technically, for very interactive pages, a high percentile). In March 2024, INP replaced First Input Delay as an official Core Web Vital, and the difference between the two metrics is the whole story.

What is Interaction to Next Paint fixing that FID missed?

Three design flaws in FID, each corrected deliberately:

• FID measured only the first interaction. A page could greet your first click promptly and then choke on every subsequent one — FID never noticed. INP watches every interaction for the whole visit and reports the worst offender, so a janky "add to cart" button on your twelfth click now counts.
• FID measured only the input delay. It clocked how long the browser took to start handling your click — not how long the handler ran, nor how long until the screen actually updated. INP measures the full span: input delay, plus processing time, plus the presentation delay before the next paint. What the user actually experiences, in other words.
• FID was too easy. When nearly everything passes, a metric can't differentiate. When INP took over, a large share of sites — especially mobile-heavy, JavaScript-heavy ones — dropped from "good" to "needs improvement" overnight without a single line of code changing. Their responsiveness hadn't gotten worse; it had finally been measured.

Reading your score

Google's thresholds, measured at the 75th percentile of real user visits:

One measurement subtlety that confuses everyone: INP is a field metric — it requires real user interactions, so lab tools can't fully compute it. Your authoritative source is real-user data (the CrUX dataset), surfaced in PageSpeed Insights and the Core Web Vitals report in Search Console. Lab tools like Lighthouse report Total Blocking Time as a proxy, which correlates with INP but isn't it. If your lab scores look fine and your field INP is poor, believe the field data — your users are on slower phones than your test machine. A client's dashboard app once measured 180 ms INP on the developer's M-series laptop and 720 ms in field data from mid-range Androids; both numbers were true, and only one of them mattered.

Where the milliseconds actually go

Slow INP is almost always JavaScript monopolizing the main thread. The recurring culprits from real diagnostics:

1. Long tasks blocking the thread. The browser can't respond to input while running a task. Any script chunk over 50 ms delays whatever interaction arrives during it. Third-party tags — analytics, chat widgets, ad scripts — are disproportionately guilty because nobody profiles them after pasting the snippet.
2. Heavy interaction handlers. The click itself triggers expensive work: recalculating a filter over 2,000 products, hydrating a component tree, synchronous state updates that cascade. The fix pattern is to paint first, compute after — give the user visual acknowledgment immediately, then do the heavy lifting asynchronously.
3. Layout thrashing. Handler code alternately reads and writes layout properties, forcing the browser to recalculate geometry repeatedly before it can paint a frame.
4. Oversized DOM. Pages with tens of thousands of nodes make every style and layout recalculation slower, dragging every interaction with them. This one's a page-weight problem wearing a responsiveness costume — and it often travels with the uncompressed-asset problems covered under gzip compression, since bloated pages tend to be bloated everywhere.

A realistic improvement workflow

Start with field data to find which pages and which interactions are slow — the Core Web Vitals report groups URLs for you. Then reproduce locally: open DevTools Performance panel, throttle CPU 4× (be honest about your users' hardware), record yourself performing the slow interaction, and read the flame chart for the long tasks. The fixes rank by effort-to-impact: remove or delay third-party scripts you don't need (the cheapest win, and often 100+ ms), break long tasks up so the browser can breathe between chunks, defer non-visual work in handlers until after the next paint, and trim the DOM on template-generated pages that repeat heavy markup.

Since INP is one of the three Core Web Vitals, it feeds Google's page experience signals — a modest ranking input, but one with a direct conversion-side payoff: users abandon pages that ignore their clicks, and no ranking factor compensates for that. Keeping an eye on it belongs in the same routine as your other technical checks — a recurring site audit that tracks slow pages alongside broken links and meta problems keeps responsiveness regressions from shipping silently in the next redesign.