INP Replaces FID: Preparing for the March 2024 Core Web Vitals

On March 12, 2024, INP replaces FID as the responsiveness Core Web Vital. First Input Delay gets deprecated in the same move, and the web.dev announcement of the switch confirms it. Running a WordPress site and seeing INP warnings pop up in Search Console? You have a few weeks left to work out which pages are hit and what to repair first. Below: what changes, where to look, and the order I’d do the work in.

What changes on March 12 when INP replaces FID?

Interaction to Next Paint becomes a Core Web Vital. First Input Delay leaves the program. That’s the whole swap. The Chrome team’s transition timeline lays out the history: INP showed up as an experimental metric in May 2022, moved to pending last year, and goes stable in March 2024. FID disappears from Search Console on March 12, though PageSpeed Insights and CrUX keep it around for a six-month deprecation period. And LCP and CLS? Untouched. So in Core Web Vitals 2024, only the responsiveness part is different.

How is Interaction to Next Paint different from First Input Delay?

FID could not capture aspects of interactivity that INP does. Hence the new metric. The old measurement looked at the first interaction of a visit and nothing else. Its successor watches interactions across the whole visit and tracks the time until the page visibly responds.

An interaction here means a click, a tap or a key press. In practice, a site that passed FID can still fail INP, because that slow menu or filter someone uses later in the session now counts. Which is exactly why warnings are appearing on pages that looked fine before.

Where to check your INP threshold status

First question: does your site’s INP pass the “good” threshold in field data? Field data means measurements from real visitors, not from your own machine. Core Web Vitals are scored in the field at the 75th percentile of page loads, and the exact boundary values are listed in the web.dev INP documentation. There are a few places to pull that data from:

• Search Console - the Core Web Vitals report groups affected URLs.
• PageSpeed Insights - shows CrUX data at origin level and sometimes for a single URL.
• The web-vitals JavaScript library - collects INP from your own visitors.

Lab tools that load a page with nobody clicking on it won’t show you the real picture. So trust the field first. Lab runs are for reproducing a problem you already know about.

Why INP is mostly a JavaScript problem, not a server one

INP measures what the browser does after a click. So it comes down to the scripts running on the page, not how fast the server answered. A reverse proxy or a quicker machine mainly moves time to first byte, and that’s a loading metric. Same story with picking a hosting location for distant readers: it shortens the route a response travels, not the work done on the device.

Network setup sits in that delivery bucket too, including the whole question of dedicated IPs and page speed. Keep the two problems apart, or the effort lands in the wrong place. Slow loading gets fixed on the infrastructure side. Sluggish reactions to input get fixed in the code the browser executes.

What to fix first to improve INP on a WordPress site

Start with the pages Search Console flags, then remove or delay the JavaScript that runs during interactions. I’d go through the list in this order:

1. Pick the flagged URL groups and reproduce the slow interaction on a real phone.
2. Audit plugins and deactivate those that load scripts on every page without need.
3. Defer or delay third-party scripts such as chat widgets, ad tags and analytics.
4. Check the theme and page builder for heavy menus, sliders and popups.
5. Break up long tasks in custom code so the browser can paint between them.
6. Reduce DOM size on long pages, since a large element tree makes every update costlier.

One change at a time. Re-test after each step. Sure, killing several plugins in one go may clear the warning, but then you have no idea which of them caused it (and the issue tends to come back with the next update).

What to do with FID reports and monitoring before the deadline

Swap FID for INP in dashboards, alerts and any code that reads it. First Input Delay is deprecated and will be removed from the program, so there’s no point keeping it alive. The cleanup usually touches these areas:

• Update scripts that pull the old metric from CrUX or PageSpeed Insights before the deprecation window closes.
• Switch real-user monitoring to INP through the web-vitals library.
• Stop reporting FID to clients or stakeholders, and explain why the figure is gone.

Field data updates slowly. Repairs made in February take time to show in reports, so don’t panic when nothing moves the next day. After deploying a change, start validation in Search Console and wait for fresh visitor measurements before judging the result.

INP replaces FID next month, and the order of work is honestly pretty simple: measure in the field, trim the JavaScript that blocks interactions, then update your monitoring so nothing still depends on the retired metric.

FAQ