INP Is Now a Core Web Vital: What Changed on 12 March

If your Core Web Vitals report suddenly looks worse this week, here is why. As of 12 March 2024, INP replaces FID as a Core Web Vital: Interaction to Next Paint (INP) has officially taken the place of First Input Delay (FID). INP now sits next to Largest Contentful Paint (LCP) and Cumulative Layout Shift (CLS), and FID is gone from the set.

Nothing about your site changed overnight. What changed is the ruler Google uses to measure how quickly your pages respond when people click, tap or type. In this article I explain what INP measures, what changed in Google’s tools on 12 March, and what I would check first on your site.

What Changed on 12 March 2024

Google first said INP would replace FID back in May 2023, and set March 2024 as the date. I covered that announcement in our guide to preparing for INP. In January 2024, Chrome’s team confirmed the exact day: 12 March.

Now it has happened. Here is what is different from today:

• The Core Web Vitals are now LCP, INP and CLS. FID is no longer one of them.
• Search Console has swapped FID for INP in its Core Web Vitals report. Your mobile and desktop charts now group URLs by INP status instead of FID.
• PageSpeed Insights now uses INP in its Core Web Vitals assessment, the pass or fail box at the top of the report.
• FID is deprecated. PageSpeed Insights and the Chrome UX Report (CrUX, Google’s public dataset of real Chrome user experiences) keep FID data for a six-month transition period. In its launch post, Chrome says anyone pulling FID from the CrUX or PageSpeed Insights APIs should move to INP by 9 September 2024.

The “good” target for INP is 200 milliseconds or less. That has to be true for at least 75% of page visits, measured separately for mobile and desktop.

What INP Measures, in Plain Words

INP measures responsiveness. It asks one simple question: when a visitor clicks, taps or presses a key, how long until the screen shows a reaction?

That “reaction” is the next paint, the moment the browser draws the next frame. It could be a menu opening, a button changing colour, or an item appearing in a cart. If nothing visible happens for half a second, the page feels broken, even if it loaded fast.

Which Interactions Count

INP only looks at three kinds of input:

• Mouse clicks
• Taps on a touchscreen
• Key presses on a physical or on-screen keyboard

Scrolling, hovering and zooming do not count on their own. So a slow scroll effect will not hurt INP, but a slow “Load more” button will.

How the Single INP Number Is Picked

A visitor might interact with a page dozens of times. INP watches all of those interactions during the whole visit, not just the first one. It then reports one of the slowest.

On most pages, that is simply the worst interaction. On pages with lots of interactions, Chrome ignores one of the slowest for every 50 interactions, so a single random hiccup does not define the whole visit. Then Google takes the 75th percentile across all visits to get your page’s INP.

The Three Parts of One Interaction

Every interaction INP measures has three parts. Knowing them helps a lot when you try to fix a slow score:

1. Input delay. The time before the browser can even start handling the click. This is usually long when the browser is busy running other JavaScript.
2. Processing time. The time your event handlers (the code that runs on the click) take to finish.
3. Presentation delay. The time from when that code finishes until the browser actually draws the new frame on screen.

FID only measured the first part, and only for the first interaction. That is the heart of this change.

INP Replaces FID: Why Google Made the Switch

FID had two big blind spots. It only measured the first interaction on a page, and it only measured the waiting time before the code ran. It ignored how long the code took and how long the screen took to update.

So a page could pass FID with ease and still feel slow. Think of a product page where the first tap is fine, but every filter click after that freezes for a second. FID would call that page good. INP will not.

In my opinion, this is the main reason FID scores looked so healthy for so long. Most sites passed it, which made it a weak signal for both Google and site owners. INP is harder to pass, but it matches what real visitors feel much more closely.

Do not be fooled by the bigger number. A 200 ms INP target is harder to hit than a 100 ms FID target, because INP measures much more of each interaction.

Does INP Affect Google Rankings?

Core Web Vitals are part of the page experience signals that Google’s ranking systems use. Since INP is now a Core Web Vital, it is part of that set. I explained how page experience works across devices in our page experience on desktop guide.

But keep this in proportion. Google has said many times that relevance and helpful content come first. A good page experience will not lift a weak page above a much better answer.

Here is how I think about it. If your INP moved from green to orange this week, you will not see a sudden ranking drop from that alone. The real cost of poor INP is that visitors get frustrated, abandon forms and leave. That hurts leads and sales whether Google notices or not.

One more point. Google’s March 2024 core update started on 5 March, just a week before this switch. If your traffic is moving right now, the core update is a far more likely cause. I’d read our breakdown of the March 2024 core update before blaming INP.

How to Check Your INP Score

INP needs real visitor data. A lab test on its own cannot give you a true INP, because nobody is clicking around the page. Here is the order I check things in.

Search Console Core Web Vitals Report

Start here if your site has enough traffic. Open Experience and then Core Web Vitals in Search Console. Open the mobile report first, because mobile is where INP problems usually show up.

Look for issues named “INP issue: longer than 200ms (mobile)” or “longer than 500ms”. Click into one and you will see groups of similar URLs. Search Console groups pages that look alike, such as all blog posts or all product pages. That grouping tells you which template to fix.

PageSpeed Insights

Use PageSpeed Insights to check one URL at a time. The field data at the top now shows INP in the Core Web Vitals assessment. If there is no data for the exact URL, switch to the origin view to see your whole site. If you need a refresher on reading the report, see our PageSpeed Insights guide.

Remember that the lab section below does not show INP. Lighthouse uses Total Blocking Time (TBT, how long the main thread was blocked during page load) as a rough stand-in. A high TBT often means a poor INP, but not always.

Real User Monitoring

CrUX only covers pages with enough Chrome traffic, and it only gives you a final number. To see which button or form is slow, you need your own field data. Google’s free web-vitals JavaScript library can report INP from real visits, and its attribution build tells you which element was involved.

Here is a simple example that logs INP to the browser console. In practice, you would send it to your analytics tool instead:

import {onINP} from 'web-vitals/attribution';

onINP(({value, attribution}) => {
  console.log('INP:', value, 'ms');
  console.log('Element:', attribution.interactionTarget);
});

On larger sites, I always recommend some form of real user monitoring. Without it, you are guessing which interaction is the slow one.

What Usually Causes a Poor INP

When I look at sites that fail INP, the same few causes come up again and again. Almost all of them come back to one thing: too much JavaScript running on the main thread (the single lane where the browser runs scripts and draws the page).

• Long tasks. Any script that runs for more than 50 ms blocks the browser. If a visitor clicks during that time, the click has to wait.
• Third-party scripts. Chat widgets, ad scripts, tag managers full of old tags, and tracking pixels all compete for the main thread.
• Heavy event handlers. A click that triggers a big calculation, a full re-render of a page section, or many network calls before showing anything.
• Very large pages. A huge DOM (the tree of elements that makes up the page) makes every update slower to draw.
• Page builders and bloated themes. I usually see this on WordPress sites with several plugins that each add their own scripts to every page.

How to Improve INP: A Practical Plan

You do not need to fix every page. Fix the templates that fail, starting with the ones that matter most to your business. This is the process I follow.

1. Find the failing page groups. Use the Search Console Core Web Vitals report to see which templates fail INP on mobile.
2. Find the slow interaction. Use real user data or the attribution build of web-vitals to see which element visitors click when INP is slow. If you have no field tools, test the obvious ones by hand: menus, filters, add-to-cart buttons, forms and accordions.
3. Reproduce it in Chrome DevTools. Record the interaction in the Performance panel with CPU throttling turned on, so your fast laptop acts more like a mid-range phone. Look for long tasks around the click.
4. Cut or delay the JavaScript. Remove scripts you no longer need. Load the rest later, or only on pages that use them.
5. Break up long tasks. Split big pieces of work into smaller chunks so the browser gets a chance to respond between them. A common way is to update the screen first, then run the less urgent work afterwards with setTimeout.
6. Show feedback right away. Change the button state or show a loading message the moment someone clicks. Then do the heavy work.
7. Check again after four weeks. Field data in CrUX and Search Console uses a rolling 28-day window, so improvements show up slowly.

Quick Wins for Non-Developers

If you run a small business site and do not write code, you can still make progress:

• Remove plugins and widgets you do not really use. Each one often adds JavaScript to every page.
• Clean out your tag manager. Old campaign tags and duplicate tracking codes add up.
• Ask your developer or theme provider whether their theme has been tested for INP.
• Be careful with “all-in-one” page builders on key landing pages. In my experience, they are a common source of heavy scripts.

Common Mistakes I’d Avoid

Because this switch is new, there is a lot of confusion about it. These are the mistakes I’d steer clear of:

• Chasing the lab score. A 100 in Lighthouse does not mean a good INP. INP comes from real visitors.
• Testing only on desktop. Phones have slower processors, so the same script that feels instant on your laptop can lag on a mid-range phone.
• Judging fixes after a few days. The 28-day window means you need patience before the report turns green.
• Panicking about rankings. Treat INP as a user experience fix first. Any ranking help is a bonus, not the main reason.
• Forgetting the FID API deadline. If you or your agency built dashboards on FID data from the CrUX or PageSpeed Insights APIs, update them to INP before 9 September 2024.

Conclusion

Now that INP replaces FID, this is the biggest change to Core Web Vitals since they launched. From 12 March 2024, Google measures how fast your pages respond to every click, tap and key press, not just the first one. Many sites that passed FID easily will now see pages in “needs improvement” or “poor”.

That does not call for panic, but it does call for a plan. Your next step: open the mobile Core Web Vitals report in Search Console today, note which page groups fail INP, and start with the template that brings you the most leads or sales. Google’s web.dev guide to Interaction to Next Paint is a good technical reference to share with your developer.