FID is gone. INP is the new standard. If you want to keep your site technically sharp, this is the most important shift in the Core Web Vitals of recent years. And unlike the old metric, this one is a lot harder to get right.
I work as an SEO and GEO specialist under JSResults, and INP now comes up in virtually every technical SEO audit I run. LCP and CLS are often already fine, but the site fails on INP. In this article I explain exactly what changed, what INP measures, and which fixes deliver the most in practice.
Quick overview: the three Core Web Vitals
Core Web Vitals are three metrics from Google that measure the experience of real visitors. They are a confirmed ranking signal. These are they:
- LCP (Largest Contentful Paint): how fast the largest element appears. This measures loading speed.
- INP (Interaction to Next Paint): how fast your site responds to what the visitor does. This measures responsiveness.
- CLS (Cumulative Layout Shift): how much the page shifts unexpectedly. This measures visual stability.
The big change: FID out, INP in
On March 12, 2024, Google replaced FID (First Input Delay) with INP. Since then INP has been a full member of the Core Web Vitals, and by 2026 it is fully established as a signal.
Why the swap? FID measured only a tiny slice of reality. It only looked at the delay of the very first interaction, and only at the start of it. A site could have a fine FID score and still feel slow at everything you did afterwards. INP closes that gap.
What exactly does INP measure?
INP looks at all interactions during the whole visit, so every click, tap and keystroke. From all those interactions it effectively takes the slowest one as your score. It measures the full chain, from the action to the moment you see the next frame.
That chain has three parts:
The difference with FID in one sentence: FID only measured that first bit of input delay of the first interaction. INP measures the whole chain, at every interaction, throughout the visit. That makes it a much more honest picture of how your site really feels.
The thresholds in 2026
The official thresholds have not changed. I say this deliberately, because there are reports circulating that Google tightened the LCP limit or hands out manual actions for Core Web Vitals. That is not true. Core Web Vitals is an automated signal, not a manual penalty, and these are the current limits according to Google itself:
| Metric | Good | Needs improvement | Poor |
|---|---|---|---|
| LCP (loading) | 2.5 s or faster | 2.5 s to 4 s | longer than 4 s |
| INP (responsiveness) | 200 ms or faster | 200 ms to 500 ms | longer than 500 ms |
| CLS (stability) | 0.1 or lower | 0.1 to 0.25 | higher than 0.25 |
An important detail: Google measures at the 75th percentile of your visits, split by mobile and desktop. So you don’t need every visitor under the limit, but three quarters of them. And note: this is field data from real visitors, not the lab score you see in a test on your own laptop.
Why INP is so much harder than FID
On paper INP looks mild. The threshold for ‘good’ is 200 ms, while FID sat at 100 ms. Yet many sites struggle with it, and that makes sense.
- INP measures the whole visit, not one moment. A single slow interaction later on the page drags your score down.
- It measures the full chain, including processing your JavaScript and repainting the screen.
- Modern sites lean heavily on JavaScript. That is exactly what blocks the main thread and worsens INP.
In short: INP punishes heavy, sluggish interfaces. That is precisely where many sites, especially those with lots of scripts and trackers, go wrong.
Which fixes deliver the most
This is what it comes down to. Based on what I see in audits, this is the order in which I would tackle INP. The biggest wins usually sit at the top.
- Break up long tasks. Anything that occupies the main thread longer than 50 ms blocks interactions. Split heavy JavaScript into smaller chunks and give the browser air in between.
- Reduce and defer JavaScript. Load non-critical scripts later or only on interaction. Every kilobyte of JavaScript you don’t execute immediately helps.
- Clean up third-party scripts. Chat widgets, trackers and A/B testing tools are notorious INP killers. Keep only what you really need, and defer the rest.
- Keep event handlers light. In a click handler, do only the essentials. Heavy work can wait until after the first visual response.
- Show first, compute later. Give immediate visual feedback on an interaction (a status, for example) and do the computation afterwards. The visitor experiences the site as fast.
- Shrink and simplify the DOM. A huge, deeply nested page makes every recalculation slower. Fewer elements means faster responses.
- Use CSS instead of JavaScript where possible. Animations and showing or hiding are often faster and smoother with pure CSS.
Notice the pattern? Almost everything is about relieving your main thread. At its core, INP is a JavaScript problem, not an image or server problem.
How do you measure INP?
Always measure with real field data, because that is what Google uses. These tools help:
- Google Search Console, Core Web Vitals report: shows which groups of pages fail on mobile and desktop.
- PageSpeed Insights: shows both field data (from the Chrome User Experience Report) and a lab test.
- Chrome DevTools, Performance tab: use it to track down the slow interactions and long tasks on your own page.
- The web-vitals JavaScript library: measures INP for your real visitors and sends it to your analytics.
My advice: start with Search Console to see which page groups fail, then zoom in on the slow interactions themselves with DevTools. Want me to map this out for your site, with an action plan ordered by impact? That is what I do in a technical SEO audit, or book a call right away.
Frequently asked questions
What is the difference between INP and FID?
FID only measured the delay of the first interaction, and only the first part of it. INP measures every interaction during the whole visit and the full chain until the screen responds. That makes INP a much more honest picture.
What is a good INP score?
200 milliseconds or faster is good. Between 200 and 500 ms needs improvement, and above 500 ms is poor. Google measures this at the 75th percentile of your real visitors.
Did the Core Web Vitals thresholds change in 2026?
No. The official limits are unchanged: LCP 2.5 s, INP 200 ms and CLS 0.1 for a good score. Reports about a stricter LCP limit or manual actions are incorrect.
What usually ruins my INP?
Almost always heavy or badly timed JavaScript blocking the main thread. Think trackers, chat widgets and sluggish event handlers. Cleaning those up or deferring them delivers the biggest win.
Sources
This article combines my own audit practice with Google’s official documentation. I checked the thresholds and definitions against:
- web.dev, Web Vitals and the INP documentation: web.dev/articles/vitals
- web.dev blog, Interaction to Next Paint becomes a Core Web Vital on March 12: web.dev/blog/inp-cwv-march-12
- Google Search Central, Understanding Core Web Vitals and Google search results: developers.google.com