INP replaces FID in March: what it means for your site

In March 2024, Google drops FID (First Input Delay) from Core Web Vitals and replaces it with INP (Interaction to Next Paint). In plain terms: until now, what counted was how fast a page reacted to the first click. From now on, it's how fast it reacts to every click. If your site feels sluggish when someone opens the menu, taps a filter or hits "Book now," that will show up in the reports.

What FID measured, and why it wasn't enough

FID measured one thing: how long the browser waited before it started handling the first interaction on a page. It didn't count how long the response itself took, and it ignored the second or tenth click entirely.

That left out exactly the moments that frustrate people. A visitor lands on the site, the first click works fine, then they open the gallery, pick a date in the calendar, and the page freezes for a second. FID saw none of it.

What INP measures

INP tracks mouse clicks, taps on a touchscreen and key presses for the whole visit. Scrolling, zooming and hovering don't count. For each interaction, INP adds up three pieces of time:

1. Input delay: how long the browser waits before running the code that responds to the click, usually because it's busy with something else.
2. Processing: how long that code takes.
3. Presentation: how long until the browser paints the result on screen.

The reported value is, roughly, the slowest interaction of the visit. On pages with a lot of interactions, Google ignores one in every 50, so a single hiccup doesn't sink the score.

The threshold applies at the 75th percentile of real visits, separately for mobile and desktop. In other words, three out of four visits need to stay under 200 ms for the page to count as "good."

Where to see your site's INP

• PageSpeed Insights: at the top, in the field data, you'll see INP if the site has enough traffic in Chrome's dataset (CrUX). It tells you whether there's a problem, not what's causing it.
• Search Console: Google has announced that the Core Web Vitals report will move from FID to INP when the switch happens.
• Lab tests (Lighthouse, the lower half of PageSpeed) don't give you a real INP, because they don't click on anything. The closest stand-in there is Total Blocking Time. If it's high, INP is probably going to be bad too.

To find out exactly which button is losing time, you need data from real visitors (RUM tools), which attribute each value to a specific interaction.

What usually breaks it

Almost always, the culprit is JavaScript keeping the browser's main thread busy. Any chunk of code that runs for more than 50 ms without a break is a "long task," and while it runs, the page can't respond to a click.

The causes we run into most on small business sites and small online stores:

• Third-party scripts: chat widgets, ad pixels, review widgets, maps loaded on every page.
• Heavy themes and plugins that load all their code everywhere, even when the page uses a tenth of it.
• Very large pages (a DOM with thousands of elements), which make every repaint more expensive.
• Code that does too much on a click: a filter that recalculates the whole list, or a form that sends its data before showing that the button was pressed.

What to do before March

1. Run PageSpeed Insights on your key pages (home, a product or service page, contact) and write down the mobile INP.
2. List your external scripts and remove the ones you no longer use. The rest can load later, or only on the pages that need them.
3. Ask your developer to break long tasks into smaller pieces and to show the visual reaction to a click first (the pressed button, a loading indicator), with the rest of the work coming after.
4. On very long pages, rendering of the sections that aren't on screen yet can be deferred.

Google says plainly that the work done for FID is a good foundation for INP. Google also says that good Core Web Vitals scores alone don't guarantee better rankings. INP is mostly about people: if the button responds right away, the visitor doesn't tap three times and leave.

If you want to know where your site stands, we can take a look; see what we do at Web Design. For the other two metrics, there's an older guide: Core Web Vitals in plain language.