INP: The Core Web Vital That Replaced FID

What is INP, exactly?

INP measures the time from a user interaction — a click, tap, or key press — to the next frame the browser paints in response. In other words, it captures the delay you feel between doing something and seeing the page react. Over a visit, INP reports a value close to the slowest interaction, so a single janky menu or form field can define your score.

That is the point. Averages hide the moments that annoy people; INP is designed to surface them. If a page opens instantly but every button press stalls for half a second, users experience it as sluggish, and INP is the metric that finally reflects that.

How is INP different from FID?

FID only measured the input delay of the very first interaction — the time before the browser began processing it — and ignored how long the actual work took to run and paint. Because of that narrow definition, many pages scored "good" on FID while still feeling slow.

	FID (retired)	INP
What it measured	Delay before the first interaction was processed	Full latency of nearly all interactions
Scope	First interaction only	Every click, tap, and key press
"Good" threshold	Under 100 ms	200 ms or less
Status	Removed March 12, 2024	Current Core Web Vital

INP is harder to pass and harder to game, which is exactly why Google introduced it: it reflects the responsiveness of the whole session, not one favorable moment.

What are the INP thresholds?

The web.dev thresholds are straightforward: 200 milliseconds or less is good, 201 to 500 needs improvement, and over 500 is poor. As with every Core Web Vital, the score is taken at the 75th percentile of page visits, so you have to be fast for the great majority of your users, not just on your own fast laptop.

Mobile and desktop are assessed separately. Mobile is usually where INP struggles, because slower CPUs take longer to run the JavaScript that a click triggers — so test on a mid-range phone, not a flagship.

Why did Google replace FID?

Because FID flattered almost everyone. It measured only the moment before processing started and stopped counting once the handler began, so pages with heavy event handlers and slow rendering still passed. The metric was easy to satisfy and easy to misread as "our site is responsive" when it was not.

INP closes that gap by timing the entire interaction — delay, processing, and the paint that follows — across the visit. It is a more honest measurement, and a more demanding one, which is why some sites that comfortably passed FID now need real work to pass INP.

How do you fix a slow INP?

Almost always, the culprit is long JavaScript tasks hogging the browser's main thread, so that when a user clicks, the browser cannot respond until it finishes what it is doing. The practical fixes follow from that:

• Break up long tasks. Split heavy work into smaller chunks and yield to the main thread so the browser can respond to input between pieces.
• Ship less JavaScript. Defer or remove unused scripts, especially third-party tags — analytics, chat widgets, and ad scripts are frequent offenders.
• Keep event handlers light. Do the minimum inside a click or input handler; move expensive work off the critical path and debounce rapid events.
• Prefer CSS over JS for animations, transitions, and show/hide behavior where you can.
• Avoid giant re-renders. In component frameworks, an interaction that re-renders half the page is a classic INP killer.

Fix the worst interaction first. Because INP is driven by your slowest interactions, one stubborn dropdown or search box is often responsible for the whole poor score.

How do you measure INP?

Use both field and lab data. Field data — how real users actually experience your site — is what counts toward Core Web Vitals, and you can see it in the Chrome UX Report, PageSpeed Insights, and the Core Web Vitals report in Google Search Console. For debugging, the lab tools (Lighthouse, the Performance panel in Chrome DevTools, and the web-vitals JavaScript library) let you reproduce and profile a slow interaction locally.

The trap is optimizing only in the lab. A metric that looks fine on your machine can be poor in the field, where users are on slower devices and flakier networks — so always confirm against real-user data before declaring victory.

Does a fast INP matter for SEO?

It helps, but keep it in proportion. Core Web Vitals are part of Google's page-experience signals, which behave as a tiebreaker among pages of similar relevance rather than a primary ranking lever. You will not outrank genuinely better content by shaving milliseconds.

What speed does do is protect the visitors you already earn: a responsive page keeps people from bouncing and quietly reinforces that the site is well made. That is really a credibility point as much as a performance one — see what makes a website feel trustworthy for why "it works, and it's fast" is itself a trust signal.

INP is only one leg of the tripod. For the full picture, start with Core Web Vitals explained, then dig into the other two: improving Largest Contentful Paint for loading and fixing Cumulative Layout Shift for visual stability. For more on the engineering side, the Web Development tag and the Technology section go deeper.