Google has confirmed that INP will replace FID as a Core Web Vital in March 2024. If you look after a website, the short version is this: the way Google measures responsiveness is getting much stricter, and many sites that pass today will not pass under the new metric. You have about ten months to prepare, and that is enough time if you start now.
In this guide, I explain what was announced, what INP (Interaction to Next Paint) actually measures, why it is harder to pass than FID, and the steps I am taking on the sites I manage.
INP Will Replace FID: What Google Announced on 10 May 2023
On 10 May 2023, Google published two posts at the same time. The Google Search Central blog announced that INP will become a Core Web Vital in March 2024. The Chrome team posted the technical details on web.dev the same day.
Here is what the announcement says:
- INP is no longer experimental. It is now a “pending” Core Web Vital. That means Google considers it ready to replace FID.
- FID stays until March 2024. Until then, FID (First Input Delay) is still the official responsiveness metric, next to LCP and CLS.
- In March 2024, INP takes over. INP will join LCP (Largest Contentful Paint) and CLS (Cumulative Layout Shift) as one of the three stable Core Web Vitals.
- Search Console will change. Google says INP will be added to the Core Web Vitals report later in 2023. When INP replaces FID, the report will stop showing FID data.
- Developer tools are renaming fields. Chrome UX Report (CrUX) data and the PageSpeed Insights API are moving from an “experimental” INP field to a regular one.
Google also repeats a point I always share with clients: good Core Web Vitals scores do not guarantee good rankings. They are one part of page experience, which is one part of a much bigger system.
What Is INP (Interaction to Next Paint)?
INP measures how quickly a page responds when someone interacts with it. An interaction is a click, a tap or a key press. Scrolling and hovering do not count.
For each interaction, INP measures the full time from the moment the user acts until the browser paints the next frame on screen. In plain words: how long does the user wait before they see that something happened?
That wait has three parts:
- Input delay. The time before the browser can even start handling the click, usually because it is busy running other JavaScript.
- Processing time. The time the page’s own code (the event handlers) takes to run.
- Presentation delay. The time the browser needs to work out the new layout and draw the update.
INP watches every interaction during the whole visit. At the end, it reports one of the slowest. On pages with lots of interactions, it ignores a small number of extreme outliers so one freak result does not decide the score.
INP Thresholds
Google uses these thresholds, measured at the 75th percentile of page visits (so 3 in 4 visits need to hit the target):
- Good: 200 milliseconds or less
- Needs improvement: more than 200 and up to 500 milliseconds
- Poor: more than 500 milliseconds
INP vs FID: Why the New Metric Is Harder to Pass
FID was always an easy metric to pass. It only looked at the first interaction on a page. And it only measured the input delay, which is the first of the three parts above.
So if your page took 50 milliseconds to start handling the first click, but then 800 milliseconds to run the code and show the result, FID still said 50 milliseconds. The user waited almost a second, and FID called it fast.
INP closes both gaps. It looks at all interactions, not just the first one, and it measures the whole wait, not just the start.
| Question | FID | INP |
|---|---|---|
| Which interactions count? | Only the first one | All clicks, taps and key presses during the visit |
| What part of the wait is measured? | Only the input delay | Input delay, processing and the next paint |
| “Good” threshold | 100 ms or less | 200 ms or less |
| Can it be measured in a lab test? | No, field data only | Mainly field data; lab tests need real interactions |
The Chrome team’s own numbers show the gap. On mobile, about 93% of sites have good FID, but only about 65% have good INP. That means a lot of sites that look fine in Search Console today will see “needs improvement” or “poor” after the switch.
My honest view: INP is a much better metric. FID let heavy, slow pages look fast. INP matches what users actually feel when they tap a menu or press “Add to cart” and nothing happens.
Does INP Affect Rankings?
Core Web Vitals are part of Google’s page experience signals. Since the page experience update reached desktop in 2022 (I covered that in what changed when page experience came to desktop), these metrics have applied on both mobile and desktop.
When INP replaces FID in March 2024, it becomes the responsiveness part of that picture. But I would not expect big ranking swings from it. Google has said many times that relevance and helpful content come first, and that good scores do not guarantee good rankings.
Where I do see a real cost is with users. A page that freezes when someone taps a button loses sales and leads, whatever Google thinks of it. That is the main reason I take INP seriously.
How to Check Your INP Score Today
You do not need to wait for March 2024 to see your INP. The data is already collected from real Chrome users.
PageSpeed Insights
Run any URL through PageSpeed Insights. The field data section at the top shows INP from the Chrome UX Report, for both the page and the whole origin (your domain) when there is enough traffic. If you are new to the tool, my guide to reading a PageSpeed Insights report explains each section.
One important point: the lab section (the Lighthouse score lower down) cannot measure INP, because no one clicks anything during that test. Look at Total Blocking Time (TBT) in the lab data instead. High TBT usually means long JavaScript tasks, and those are the most common cause of poor INP.
Search Console
Right now, the Core Web Vitals report in Search Console still shows FID. Google says INP will be added later in 2023. When it appears, check it before March 2024 so you can see which groups of URLs fail.
Chrome UX Report and Other Field Tools
- CrUX dashboards and BigQuery: useful if you want monthly trends for your domain and competitors.
- The Web Vitals Chrome extension: shows INP live as you click around your own pages. I use this first because it shows which click is slow.
- The web-vitals JavaScript library: lets your developer send real INP values from your users into your own analytics, with details of which element was clicked.
In my experience, the extension plus PageSpeed Insights is enough for most small and mid-sized sites. Custom tracking is worth it for ecommerce sites and web apps with lots of interactive features.
What Usually Causes Poor INP
When I look at slow interactions, the same causes come up again and again:
- Too much JavaScript. Big theme bundles, page builders and frameworks that load code for features the page never uses.
- Third-party scripts. Chat widgets, ad scripts, A/B testing tools, heatmaps and several tracking tags all competing for the same main thread (the part of the browser that runs code and handles clicks).
- Long tasks. Any single piece of JavaScript that runs for more than 50 milliseconds blocks the browser. If a user taps during that time, they wait.
- Heavy click handlers. Code that does a lot of work right after a click, such as filtering a big product list or sending several tracking events, before updating the screen.
- Large page updates. Opening a mega menu or a filter panel that changes thousands of page elements at once.
- Very large pages. Pages with a huge number of HTML elements take longer to update after every interaction.
The pattern I usually see on WordPress and Shopify sites is a stack of plugins and apps, each adding its own scripts. No single one is the problem, but together they keep the browser busy.
How to Prepare for INP Before March 2024
Here is the process I follow. You can do steps 1 to 3 yourself. Steps 4 to 6 usually need a developer.
- Find your current INP. Run your key templates through PageSpeed Insights: home page, a category or service page, a product or article page, and your contact or checkout page. Note the field INP for each, and the origin score.
- Find the slow interactions. Open those pages with the Web Vitals extension switched on. Click the things users click: the menu, filters, tabs, accordions, add to cart, form fields. Note which ones feel slow or show high numbers.
- List every third-party script. Open your tag manager and your plugin or app list. For each script, ask: do we still use this, and does it need to load on every page? Remove what nobody uses.
- Break up long tasks. Your developer can split heavy JavaScript into smaller pieces, so the browser gets a chance to respond to clicks in between. A common approach is to update the screen first and run less urgent work (such as analytics calls) afterwards.
- Cut unused JavaScript. Use the Coverage panel in Chrome DevTools to see how much loaded code is never used. Load scripts only on the pages that need them, and delay non-essential ones until after the page is ready.
- Make page updates smaller. Keep the number of HTML elements reasonable, and avoid changes that force the browser to redraw large parts of the page after a click.
After you make changes, remember that field data is based on a rolling 28-day window. Give it about a month before you judge the result in PageSpeed Insights.
A Practical Example
Picture a typical online store category page. The user taps “Filter by size”. The site then runs a tracking event, re-renders 60 product cards, updates the URL and recalculates the layout, all before showing anything new.
FID would only measure the short delay before that code starts. INP measures the whole wait until the filtered products appear. A common fix is to show a quick visual change first (for example, a loading state on the button), then do the heavy work, and send the tracking event last.
What I Would Prioritise First
Not every site needs a big project. Here is how I decide:
- If your origin INP is already under 200 ms: keep an eye on it, and check new plugins or scripts before adding them. That is it.
- If it is between 200 and 500 ms: start with the third-party script audit. In my experience, that alone often makes a clear difference, and it costs no development time.
- If it is over 500 ms: treat it as a development task. Focus on the templates with the most traffic and the most important actions, such as checkout and lead forms.
I would also not throw away work you have done for FID. Google itself says FID improvements are a good base for INP, because both depend on keeping the main thread free.
Common Mistakes to Avoid
- Chasing the Lighthouse score. A 100 in the lab test tells you nothing about INP. Real users’ interactions are what count.
- Testing only on a fast laptop. Most poor INP happens on mid-range phones. Test on a real phone, or use CPU throttling in Chrome DevTools.
- Testing only the home page. The slowest interactions are often deeper in the site, on filters, forms and carts.
- Adding a “speed plugin” and hoping. Caching and image tools help LCP, but they rarely fix slow JavaScript. Some even add more script.
- Waiting until March 2024. Field data takes weeks to update, and development work takes time. Starting late means going into the switch with a failing score.
How INP Fits Into Your Wider SEO Plan
INP matters, but I would not put it above content quality, crawling and indexing problems or a broken site structure. If you are planning the rest of the year, my SEO priorities for 2023 puts page experience in context with the other work.
The good news is that INP work tends to pay off twice. A page that responds quickly feels better to use, and people who do not get stuck waiting are more likely to buy, book or get in touch.
Conclusion: Get Ready for INP Now
INP will replace FID as a Core Web Vital in March 2024, and it is a much tougher test of responsiveness. FID only checked the start of the first click. INP checks the full wait for every click, tap and key press.
Your next step is simple: run your five most important page types through PageSpeed Insights today and write down the INP for each. If any are over 200 milliseconds, start with a third-party script audit, then bring in a developer for the long tasks. For the technical background, the Chrome team’s post on advancing Interaction to Next Paint is worth sharing with your developer.
