Why INP Replaced FID and What That Means for Your Site's Performance Score

In March 2024, Google replaced First Input Delay (FID) with Interaction to Next Paint (INP) as the responsiveness metric in the Core Web Vitals set. This wasn't a minor update to thresholds or methodology. It was a fundamental change in what Google measures when it evaluates whether a page is responsive to users.

If your site's responsiveness score looked fine under FID but has declined since the transition to INP, you're not alone. INP is a stricter metric that captures failures FID was structurally unable to detect. Understanding why the change happened and what INP actually measures is necessary context for fixing it.

Why FID Was Limited

FID measured the delay between a user's first interaction with a page (usually a click or tap) and the point at which the browser began processing the event. It captured only the delay before processing started, not the time required to complete the processing or render the visual response.

This meant FID could look good even on pages where interactions felt slow to users. A click could register within 50ms (good FID) but take another 500ms to complete its event handler and repaint the screen. The user's experience was sluggish, but FID reported a healthy score because FID's measurement stopped before the slow part began.

FID also measured only the first interaction. A page that was initially responsive but became slow after additional JavaScript loaded, after a user scrolled partway down, or after a data fetch completed would never register those later slowdowns in the FID metric. A rich single-page application that hydrated slowly after the initial click could have a great FID score and a terrible user experience.

Photo by ImageParty on Pixabay

What INP Measures Instead

INP measures the full latency of interactions from the user's input event through processing, to the next paint (the point at which the browser renders a visible response). It covers three phases: input delay (how long before processing starts), processing time (how long the event handlers run), and presentation delay (how long before the browser renders the result to screen).

INP also measures all interactions during a page session, not just the first one. It reports the worst-case interaction latency, specifically the 98th percentile of all interactions during the session. A page visited by a user who clicks a button, scrolls, opens a dropdown menu, and submits a form generates data from all of those interactions. The score reflects the slowest one observed during that session.

Google's thresholds are: under 200ms is good, 200-500ms needs improvement, and over 500ms is poor.

Why Sites That Passed FID Now Fail INP

FID failures were concentrated in JavaScript that ran synchronously at page load, blocking the main thread before the first user interaction. Fixing FID typically meant reducing that initial blocking work or reducing JavaScript bundle size.

INP failures include that category but extend significantly further:

Long event handlers. A click handler that triggers a data fetch, DOM update, and re-render chain can take hundreds of milliseconds to complete. FID only measured the input delay before the handler started. INP measures the entire cycle through the next paint. An event handler that was always slow was never measured by FID.

Interactions after initial load. JavaScript that loads asynchronously, framework hydration that completes after the initial page load, and third-party scripts that initialize late can all create INP failures that FID never captured. A rich application that hydrates on the client after server-side rendering is a common source.

Interactions on specific page states. An add-to-cart button on an e-commerce site might respond quickly when the page first loads but slowly when the user has been browsing for several minutes and the JavaScript heap is larger. INP captures that degradation over the full session; FID captured only the moment the page first loaded.

The Practical Impact of the Change

Sites built with JavaScript-heavy frameworks often saw INP scores decline relative to FID. React, Vue, Angular, and Next.js applications with complex component trees and frequent re-renders can produce measurable INP delay when user interactions trigger reconciliation.

The fix for FID was often "reduce JavaScript on initial load." The fix for INP is more nuanced: identify which specific interactions are slow, trace them to the event handlers and rendering work involved, and optimize the processing and presentation phases, not just the input delay phase.

Chrome DevTools added specific INP profiling support. The Interactions panel records every interaction and shows its breakdown across input delay, processing time, and presentation delay. This makes it possible to identify which interaction type (click, scroll, keypress) is causing the worst-case score on any given page.

What Good INP Optimization Looks Like

The goal is to get every interaction's total latency under 200ms from input to next paint. For interactions that trigger expensive work, this typically means:

• Breaking up the processing work so the browser can yield between chunks (using scheduler.yield() or setTimeout with 0ms delay as a fallback)
• Moving non-critical work out of the synchronous event handler and into a subsequent microtask or requestAnimationFrame call
• Reducing the scope of DOM updates triggered by each interaction, updating only the changed nodes rather than re-rendering large component subtrees
• Deferring or removing third-party scripts that add main-thread work during interaction handling

MDN Web Docs has detailed coverage of the Event Timing API that underlies INP measurement. Reading it alongside the web.dev articles on INP optimization gives a complete picture of what the browser is measuring and what specific changes will move the score.

Photo by MedPoint 24 on Pexels

Setting Expectations for Improvement Work

INP is a harder metric to improve than FID was, and its impact on rankings is the same as the other Core Web Vitals. If your site has a poor INP score, addressing it is worth the engineering investment, but it usually requires profiling specific interactions rather than applying general performance advice.

The diagnostic process starts with Search Console's field data to find which page templates have poor INP scores, then uses DevTools to profile those specific pages and identify the slowest interactions. Fixes tend to be localized to specific components or interaction paths rather than requiring broad architectural changes. Finding the right interaction to profile is often the most time-consuming part.

For teams working on sites with JavaScript-heavy frontends, INP optimization can surface previously unknown performance problems that were always there but never measured. That's a good thing. The metric accurately reflects real user experience in a way FID did not, and improving INP means improving actual usability, not just a number in a dashboard.

For a complete walkthrough of auditing Core Web Vitals including INP on a production site, 137Foundry published a detailed guide covering the full audit process: How to Audit and Fix Core Web Vitals on a Production Website.

"INP revealed what FID had been hiding. A lot of sites looked fine because their first click was fast. INP looked at the tenth click, the menu open after hydration, the filter change in a heavy data grid, and found the real picture. Teams that are surprised by their INP scores are often running event handlers that were always slow, just never measured." - Dennis Traina, founder of 137Foundry

The metric change is a net positive for the web. It correlates more closely with actual user experience than FID did, which means improving INP has real impact on how visitors perceive your site, not just on a score in a performance dashboard.