# INP Replaces FID in Core Web Vitals: What It Measures and What to Watch
Table of Contents
As of March 12, 2024, one of the metrics Google uses to judge the quality of a web page changes. A metric called FID is being retired and replaced by another one, INP. The change concerns the Core Web Vitals, the set of indicators that measure the experience of loading and using a site. This isn’t a small, niche technical tweak: it touches both how a site feels to the people using it and how Google factors performance into ranking. So it’s worth understanding what actually changes, in plain terms.
What Core Web Vitals are
The Core Web Vitals are a small group of metrics Google uses to measure, with concrete numbers, how pleasant a page is to use. They don’t judge the content or the design: they look at technical behavior. Historically there are three, each with a simple question behind it.
- LCP (Largest Contentful Paint): how long before the main content appears, which also depends on how fast the server’s first response is? Considered good under 2.5 seconds.
- CLS (Cumulative Layout Shift): how much do elements “jump” while the page loads? Considered good under 0.1.
- The third one is about responsiveness, meaning how quickly the page reacts when you tap or click something. This is the one that changes.
Until March 2024, responsiveness was measured with FID (First Input Delay). From that date it’s measured with INP (Interaction to Next Paint).
What INP is and what it measures
INP stands for Interaction to Next Paint. It measures something everyone has felt without having a name for it: that small delay between the moment you click a button, open a menu, or tick a checkbox, and the moment the screen shows that something happened.
When that delay is short, the site feels ready and alive. When it’s long, you’re left with the feeling of having pressed nothing: you’re tempted to click again, and the page seems stuck or broken, even when it isn’t.
According to web.dev’s documentation, the time of an interaction breaks down into three parts:
- the input delay, the time before the browser starts running the code tied to the interaction (often because it’s busy with something else);
- the processing time, how long the code takes to do its work in response to the click;
- the presentation delay, the time it then takes to draw the updated result on the screen.
INP accounts for all three parts. What counts as an interaction is mouse clicks, taps on a touchscreen, and key presses; scrolling and simply hovering the pointer over an element do not count.
What changes compared to FID
The old FID measured only the input delay of the first interaction of the visit. It had two important limits. First: it looked only at the first tap, so if the first click was fast but every later one was slow, the score stayed good while failing to reflect the real experience. Second: it measured only the initial wait, ignoring how long the code then took to respond and to show the result.
INP fixes both points. It observes all interactions during the entire visit, not just the first, and it considers the whole path, from the click to when the screen updates. The reported value is close to the slowest interaction observed (setting aside rare, isolated cases), so it represents the worst experience the user actually ran into, not the best one. In practice it’s a more honest measure, and harder to make “look good” by chance.
The threshold: good under 200 ms
The practical reference is simple. web.dev’s documentation gives three bands:
- good: INP at or below 200 milliseconds;
- needs improvement: between 200 and 500 milliseconds;
- poor: above 500 milliseconds.
A millisecond is a thousandth of a second, so 200 ms is a fifth of a second: the line that separates a page that feels responsive from one that starts to feel sluggish.
One important detail about how the value is read: you don’t look at the luckiest user, but at the 75th percentile of real visits, measured separately for mobile and desktop devices. Put simply, to be considered good a site has to respond under 200 ms for at least 75% of visits. It’s a way to keep problems from hiding behind an average: what matters is that the experience is good for the large majority, not just in ideal conditions.
Why it matters for SEO, and the timeline of the change
Core Web Vitals aren’t just about tidiness: they’re one of the factors Google considers for page experience, and so they can influence ranking in search results. They aren’t the only nor the most important criterion, but with equal content a responsive site starts ahead of one that reacts late. The link with SEO is therefore indirect but real, and it runs mostly through the experience offered to the people who actually visit the site.
On the practical side, the switch has already happened: as of March 12, 2024, INP is fully a Core Web Vital and FID no longer is. Google announced the change well in advance, in May 2023, and the metric had been available in experimental form even before that. Retiring FID is gradual across tooling: it was removed right away from the main Search Console report, while other tools set a transition period to give developers time to adjust. Anyone who was watching FID simply needs to shift their attention to INP.
How to keep it in check and improve it
The first useful thing is to measure with real data. INP is best assessed in the field, meaning on actual visits, not just in the lab: tools like Search Console (in the Core Web Vitals report), PageSpeed Insights, and Chrome’s CrUX data show the value collected from real users, on their devices and their connections.
As for causes, a high INP usually means the user’s device is too busy running code to respond quickly to interactions. The general levers follow from that, and they act mostly on the browser side.
- Lighten the browser’s workload. The less code runs in response to a click, the sooner the screen can update. Cutting the unnecessary work triggered by every interaction, for instance by handing positioning that’s now done with custom scripts over to native CSS anchoring, is often the most effective step.
- Break up long tasks. A heavy, uninterrupted task keeps the browser busy and blocks responses. Splitting it into smaller pieces leaves room to handle interactions between one chunk and the next.
- Rein in third-party scripts and widgets. External trackers and tools add work that isn’t always visible but weighs on responsiveness. It’s worth checking their real cost: on a store packed with modules it’s often the first place to look.
- Prioritize what the user sees and touches. Deferring non-urgent activity, so that immediate interactions take precedence, helps keep the perceived delay low.
As always in these cases, it pays to measure before and after each change: responsiveness depends on many factors, and the right approach is to understand where the browser loses time instead of changing everything at random.
In short
As of March 12, 2024, a page’s responsiveness is measured with INP instead of FID. INP looks at all the interactions in a visit and considers the whole path from click to visible result, giving a more realistic picture of how the site responds. The threshold to keep in mind is 200 milliseconds for at least 75% of visits. It matters for two reasons that hold together: a more responsive site is more pleasant to use and, in turn, starts with a slight advantage on the SEO side too. The starting point stays the same: measure with real data, find where the delay comes from, and act on the right layer.
