Interaction to Next Paint (INP) is a Core Web Vital that measures how quickly a page responds to user interactions, the delay between a click, tap, or keypress and the moment the screen visibly updates. A low INP means the page feels responsive every time the user does something. INP replaced First Input Delay (FID) as a Core Web Vital on March 12, 2024, and is now one of Google’s three core responsiveness, loading, and stability metrics.
Why this entry was out of date, and what is true now
If you have read older INP explainers, including an earlier version of this one, you may have seen INP described as “experimental” and “set to become a Core Web Vital in March 2024.” That framing is now history. INP is no longer experimental and no longer upcoming: it has been a full Core Web Vital since March 2024, and FID has been retired. We are flagging the change explicitly because stale “upcoming metric” language is one of the most common errors still floating around on this topic.
What INP actually measures
FID, the metric INP replaced, only measured the delay before the browser could begin processing the first interaction. It captured the start of one interaction and ignored everything after. INP is broader on two counts: it looks at all interactions throughout the page’s life, not just the first, and it measures the full path from interaction to the next visible paint, not just the initial delay.
That full path has three parts: input delay (waiting for the main thread to be free), processing time (running the event handlers), and presentation delay (the browser painting the result). INP reports the worst, or near-worst, interaction a user experiences, because a single janky interaction is what people remember.
The thresholds
INP is measured in milliseconds, based on real user data:
- 200 ms or less: good. The page feels responsive.
- 200 to 500 ms: needs improvement. Not broken, but users will notice lag.
- Over 500 ms: poor. Interactions feel sluggish.
Crucially, INP is a field metric. It comes from real Chrome users, collected in the Chrome User Experience Report (CrUX), which feeds PageSpeed Insights and Search Console. A lab tool can estimate it, but the score Google uses is your real visitors’ experience.
How to improve INP, in priority order
INP problems live in one of three phases, and you fix them in that order:
- Reduce input delay. The interaction waits because the main thread is busy. Break up long JavaScript tasks, defer non-essential scripts to browser idle time, and remove unused code through code-splitting and tree-shaking. A lighter main thread responds faster.
- Reduce processing time. The event handlers themselves take too long. Give the user immediate visual feedback rather than waiting for a server response, and keep handler logic lean.
- Reduce presentation delay. The browser re-renders more than it needs to. In single-page-app frameworks, update only the part of the UI that changed (the counter, not the whole component). Avoid oversized DOMs and heavy layout work after an interaction.
How we diagnose it on client sites
Because INP is a field metric, the starting point is always real-user data, not a lab score. We read the CrUX-based INP in PageSpeed Insights and Search Console’s Core Web Vitals report to find which pages and which interactions are slow, then reproduce them with the Web Vitals Chrome extension and tools like DebugBear to see exactly which phase, input, processing, or presentation, is the bottleneck. The first question is always: which specific interaction is failing, and in which of the three phases? Everything else follows from that answer.
FAQ
Is INP a Core Web Vital? Yes. INP became a Core Web Vital on March 12, 2024, replacing First Input Delay. It is now one of Google’s three core metrics, alongside Largest Contentful Paint (loading) and Cumulative Layout Shift (visual stability).
What is a good INP score? 200 milliseconds or less is good. Between 200 and 500 milliseconds needs improvement. Over 500 milliseconds is poor. These thresholds are based on real Chrome user data from the CrUX dataset.
What is the difference between INP and FID? FID measured only the delay before the first interaction could be processed. INP measures the full responsiveness of all interactions throughout the page’s life, from the input through processing to the next visible paint. INP replaced FID in March 2024 because it reflects the real experience more completely.
How do I measure INP? With field tools, because INP is based on real user data. Use PageSpeed Insights and the Search Console Core Web Vitals report for the official CrUX figures, and the Web Vitals Chrome extension or DebugBear to diagnose specific slow interactions.
