INP Replaced FID: What Actually Changed in Core Web Vitals

First Input Delay is gone. If you’re still optimizing for it, you’re optimizing for a metric Google stopped using in Google Search Console and PageSpeed Insights back in March 2024. Interaction to Next Paint replaced it as the third Core Web Vital, and the change wasn’t cosmetic — INP measures something meaningfully different, and it’s caught a lot more WordPress sites off guard than most people realize.

What actually changed

INP officially became a Core Web Vital on March 12, 2024, fully replacing FID. Google removed FID from Search Console immediately on that date, though other tools got a short deprecation window. The metric had been building toward this for a while — it launched as an experimental metric in May 2022, then spent about ten months as a “pending” Core Web Vital starting May 2023 before graduating.

The core difference is what each metric actually measures. FID only measured the delay before the browser could begin processing the very first interaction on a page — a narrow window that told you almost nothing about how the page behaved afterward. INP measures the latency of every interaction across the entire page visit and reports (roughly) the worst one, capturing the full time from a user’s click, tap, or keypress to the next visual update on screen. A page could ace FID by having a fast first click, then feel completely broken on every subsequent interaction — and FID would never have caught that. INP does.

The actual thresholds

Google’s official guidance, measured at the 75th percentile of page loads:

• Good: 200 milliseconds or less
• Needs improvement: 200–500 milliseconds
• Poor: more than 500 milliseconds

That 200ms bar is tight. It has to cover the entire round trip — input delay, processing time, and the time until the browser paints the next frame — for whichever interaction on the page turns out to be the slowest. On a content-heavy WordPress site with several plugins hooking into the DOM, that’s a much harder bar to clear than FID ever was.

Why WordPress sites specifically tend to struggle with this

In my experience looking at sites through a support lens, INP problems on WordPress rarely come from one big offender. They come from an accumulation of small ones:

• Heavy JavaScript on interactive elements — mega menus, filter widgets, and comment forms that all fire their own event listeners, each adding a few milliseconds of main-thread work that stacks up.
• Third-party scripts — chat widgets, ad networks, and analytics tags that hijack the main thread at exactly the moment a user tries to click something.
• Render-blocking work triggered by state changes — a click that triggers a re-layout of a large chunk of the page (opening an accordion that shifts everything below it, for instance) forces the browser to recalculate more than it needs to.
• Plugin stacking — five plugins that are each individually fine can combine into main-thread congestion that no single one of them would cause alone.

None of these show up as dramatically as a slow page load. That’s exactly why INP catches people off guard — a site can have a genuinely fast Largest Contentful Paint and still fail INP badly, because the problem only appears once a real person starts clicking around.

INP measures what FID never could: not just whether the page opened fast, but whether it stays responsive after someone actually starts using it.

What’s actually worth doing about it

The fixes that move INP are less about “optimizing images” (that’s an LCP lever) and more about reducing main-thread work at the moment of interaction:

1. Audit third-party scripts first. They’re consistently the biggest single lever. Anything you can defer, lazy-load, or remove outright tends to have an outsized effect.
2. Break up long JavaScript tasks. Code that runs in one long uninterrupted block blocks everything else, including the browser’s ability to respond to a click. Splitting work into smaller chunks lets the browser stay responsive between them.
3. Be deliberate about what fires on interaction. A menu click shouldn’t trigger unrelated work elsewhere on the page. Isolate what actually needs to run.
4. Test on mid-range mobile hardware, not your dev laptop. INP problems are dramatically worse on slower devices — Chrome’s own field data (which is what actually determines your Core Web Vitals scores) is dominated by real-world phones, not high-end desktops.

How to actually find your worst offenders

Chrome DevTools’ Performance panel and the Web Vitals extension both let you record a real interaction and see exactly which part of the 200ms budget is being consumed — input delay waiting for the main thread, processing time actually running your event handler, or presentation delay waiting for the browser to paint. That breakdown matters because the fix is different for each: input delay usually points to a long task blocking the thread before the click even registers, processing delay points to inefficient code running in response to the click itself, and presentation delay often points to an expensive re-layout triggered by the interaction. Guessing at which one applies without measuring it directly tends to send people optimizing the wrong thing.

I haven’t found a further official update from Google specifically revising the INP thresholds since the March 2024 change — the 200/500ms bar has held steady. If your Search Console is still showing you Core Web Vitals data organized around FID-era assumptions, or you haven’t checked your INP numbers since before 2024, that’s worth doing before you assume your site’s performance story is unchanged. A lot of pages that looked completely fine under the old metric are quietly failing this one.