INP vs FID: What Changed in 2024 and Why You Might Be Failing Now

In March 2024, Google replaced First Input Delay with Interaction to Next Paint as a Core Web Vital. A lot of sites that had green CWV scores suddenly had red ones. A lot of developers were confused. And a lot of stakeholders were frustrated that something they "already fixed" was broken again.

Here is the thing though. FID was never a great metric. It passed too easily for too many reasons. INP is harder to pass because it actually measures what users care about: does this page feel responsive when I interact with it? This guide explains what changed, why it matters, and what to do about it in 2026.

What FID Actually Measured (And Why It Was Flawed)

First Input Delay measured the delay between a user's very first interaction with a page (their first click, tap, or keypress) and when the browser began processing that event.

The key word there is "began processing." FID did not measure how long the browser took to handle the event or show a visual response. Just the waiting time before work started. And only for the very first interaction.

Here is why that was a problem. Imagine a user lands on your page. They click a button. The browser responds in 40ms. FID passes. Then for the next 10 minutes they click through your app and every interaction takes 2 seconds to respond because your JavaScript is doing expensive work. FID never captured any of that. FID said your site was fast because the first interaction was quick.

By 2023, around 95% of origins were passing FID. That sounds great until you realize that users were still reporting laggy, unresponsive sites in the same period. The metric was measuring something, but it was not measuring what users actually experienced.

What INP Measures Instead

Interaction to Next Paint measures a completely different thing. It tracks every single interaction a user makes during their entire visit. Every click. Every tap. Every keypress. For each one, it measures three phases:

• Input delay: How long before the browser even starts handling the event (what FID measured)
• Processing time: How long the event handler JavaScript takes to run
• Presentation delay: How long before the browser paints the visual response to the screen

It adds those three phases together for every interaction. Then it reports the 75th percentile value from all those interactions. So if a user clicked 100 times during their visit and the 75th worst interaction took 350ms, your INP is 350ms. That would be in the "needs improvement" range.

This is fundamentally different from FID. FID only looked at input delay for one interaction. INP looks at the full round-trip time for most interactions.

Why Sites That Passed FID Are Failing INP

If your site was built with heavy JavaScript frameworks, complex state management, or lots of event handlers that do significant work, you probably passed FID but are struggling with INP. Here is why:

FID only needed your first click to be fast. That is easy to achieve because when a user first lands on a page, there is usually nothing else running yet. The main thread is relatively free. So that first click goes through quickly.

INP checks every click, including the ones after your JavaScript framework has loaded, your analytics have fired, your chat widget has initialized, and your A/B testing library has done its setup work. By the time users are clicking through your app's core features, the main thread is much busier, and your interactions are slower.

React SPAs are particularly affected. React re-renders triggered by user interactions can be expensive. A variant selector on an e-commerce site that triggers a full component tree re-render might take 400ms. FID would have never seen that interaction. INP sees it every time.

The INP Thresholds

INP has a higher threshold than FID (200ms vs 100ms) because it measures more. It includes processing time and presentation delay on top of input delay. The 200ms threshold accounts for this extra measurement scope.

As of 2026, around 73% of origins globally pass INP, compared to the 95%+ that passed FID. That is a meaningful drop and explains why many sites that thought they had solved their interactivity problems are back to fixing things.

What INP Does NOT Measure

Scrolling and zooming are not measured by INP. Only discrete interactions: clicks, taps, and keyboard key presses. This is important to know because scroll jank, while annoying, is not in your INP score.

Continuous interactions like holding down a key also do not count in the same way. INP focuses on the moments where a user takes a deliberate action and expects a visible response.

How to Debug Your INP

Step 1: Install the web-vitals Chrome Extension

This extension from Google shows you your real INP as you interact with any page. Open it, interact with your page normally (click buttons, fill forms, open menus), and watch the INP value update in real time. When you see a spike, you have found a slow interaction.

Step 2: Get the Interaction Element from the Attribution API

Add this code to your page temporarily. It logs the exact element causing each slow interaction:

import { onINP } from 'https://unpkg.com/web-vitals@3/dist/web-vitals.attribution.js';

onINP(({ value, attribution }) => {
  if (value > 200) {
    console.log('Slow INP:', {
      value,
      element: attribution.interactionTarget,
      type: attribution.interactionType,
      inputDelay: attribution.inputDelay,
      processingDuration: attribution.processingDuration,
      presentationDelay: attribution.presentationDelay
    });
  }
});

Open your browser console, interact with your page, and look for the logged objects. The element field tells you exactly what element was slow. The three duration fields tell you which phase is the bottleneck.

Step 3: Profile in DevTools

Once you know which interaction is slow, go to Chrome DevTools Performance tab. Click Record. Do the specific interaction. Stop recording. Look at the Main thread. Find the long red task that corresponds to your click. Click it to see which JavaScript function is inside it.

That function is your fix target. If it is one of your own functions, you can optimize or break it up. If it is a third-party script, you need to defer or replace it.

The Most Common INP Fixes

Break Up Long Tasks with scheduler.yield()

// Chrome 115+
async function handleComplexClick() {
  // First chunk of work
  processPartOne(data);

  // Yield to let browser process other input
  await scheduler.yield();

  // Second chunk
  processPartTwo(data);

  await scheduler.yield();

  // Final chunk
  updateUI(result);
}

This pattern lets the browser process any queued input events between your chunks. Users who click multiple things in quick succession will feel the difference.

Defer Third-Party Scripts

Every third-party script that runs synchronously steals main thread time from user interactions. Analytics libraries, chat widgets, and marketing tools are the usual suspects. Load them with defer, or use Partytown to move them to a web worker entirely.

Reduce React Re-render Scope

If a click on a small button triggers a re-render of a large component tree, you have scoped your state too high. Move state closer to the components that need it. Use React.memo for components that should not re-render. Use useMemo and useCallback for expensive computations that do not change on every render.

FAQ

Is FID completely gone as a metric?

Yes. As of March 2024, Google replaced FID with INP in the Core Web Vitals set. FID is no longer used as a ranking signal. If you are still reading dashboards that show FID as a CWV metric, those dashboards need updating.

My FID was always under 100ms. Why is my INP failing?

Because FID only measured your first interaction. INP measures all of them. Interactions later in the user session, after your JavaScript has fully loaded and your page is active, are typically slower. Your first click was fast. Clicks 5-50 might not be.

How do I check my current INP in Google Search Console?

Go to Search Console, click Core Web Vitals, select the Mobile or Desktop report. INP now shows as one of the three required metrics. Pages with INP over 500ms appear as Poor. 200-500ms as Needs Improvement. Under 200ms as Good.

Does INP affect ranking the same way LCP and CLS do?

Yes. All three Core Web Vitals contribute to the Page Experience signal. Google has not officially broken down the weighting between them, but all three need to pass for a site to have a fully green Core Web Vitals assessment, which is what the Page Experience signal looks at.

Related Performance Guides