On March 12, 2024, Google made Interaction to Next Paint (INP) a Core Web Vital and retired First Input Delay (FID). If you checked your Core Web Vitals report in Search Console this year and saw a page group you had never worried about suddenly marked "needs improvement", this change is the likely reason.
INP is a stricter, more honest measure of how responsive a page feels. Plenty of sites passed FID easily and now have real work to do.
What FID measured, and why it was too easy
FID measured one thing: the delay between a visitor's first interaction (a click, tap or key press) and the moment the browser could start handling it. It ignored everything after that first interaction, and it ignored how long the handler itself took to run and how long the screen took to update.
In practice that meant a page could pass FID while still feeling sluggish. The first click landed quickly, but opening a menu, filtering a product list or typing in a search box could freeze the page for half a second, and FID never saw it.
What INP measures instead
INP looks at every click, tap and key press during a visit, not just the first. For each one it measures the full time from the input until the browser paints the next frame, which is the moment the visitor sees something change. The page's INP is roughly the slowest of those interactions, with a small allowance for one-off outliers on pages with many interactions.
That full time breaks down into three parts:
- Input delay. The browser is busy with something else, often a script that is still loading or running, so it cannot start handling the input.
- Processing time. Your event handlers run. Heavy JavaScript here is the most common problem.
- Presentation delay. The browser recalculates styles and layout and paints the result. Large, complex pages make this slower.
Google's thresholds, measured at the 75th percentile of real visits:
- 200 milliseconds or less is good.
- Between 200 and 500 milliseconds needs improvement.
- Over 500 milliseconds is poor.
Why sites that passed FID are failing INP
The sites we see struggling with INP usually share a few traits:
- A lot of third-party JavaScript. Tag managers, chat widgets, A/B testing tools, heatmaps and ad scripts all compete for the same main thread your page uses to respond to visitors.
- Expensive handlers. A click that triggers a large re-render, a synchronous filter over thousands of items, or analytics code that runs before the visible update.
- Very large pages. Long product listings, mega menus and pages with thousands of DOM elements make every style and layout recalculation slower.
- Mobile hardware. INP is measured on real devices. A page that feels fine on a developer laptop can be slow on a mid-range phone, and that is where most of your field data comes from.
How to find your slow interactions
Start with field data, because INP is about what real visitors experience:
- Search Console's Core Web Vitals report shows which groups of URLs fail INP on mobile and desktop.
- PageSpeed Insights shows field INP for a specific URL or origin when Chrome has enough data.
- The web-vitals JavaScript library can report INP from your own visitors to your analytics, including which element was interacted with. This is the best way to find the specific button or form that causes trouble.
Then reproduce the problem in the lab. Lighthouse in its default mode does not measure INP, because it does not interact with the page. Use the Chrome DevTools Performance panel instead: record yourself using the slow element, ideally with CPU throttling turned on, and look for long tasks around the interaction.
Fixes that usually help
There is no single switch for INP, but these changes cover most of the cases we fix.
Break up long tasks
Any JavaScript task longer than 50 milliseconds blocks the page from responding. Split large pieces of work into smaller chunks and give control back to the browser between them, for example with setTimeout or requestIdleCallback. The goal is to let the browser paint the visible response first and finish the rest afterwards.
Do the visible update first
When a visitor clicks "Add to cart", they need to see the button react immediately. Sending analytics events, updating a recommendation widget or syncing state with a server can all happen after the next paint. Reordering handlers this way often fixes INP without removing any functionality.
Cut and defer third-party scripts
Audit every third-party script on the page and ask whether someone is actively using its data. Remove what nobody uses. Load the rest after the page is interactive, or only on the pages that need them. A tag manager makes adding scripts easy, which is exactly why it deserves a regular review.
Keep the page smaller
Reduce DOM size where you can: paginate or virtualize long lists, render menus on demand instead of on every page load, and simplify deeply nested layouts. The CSS property content-visibility: auto can help the browser skip work for content that is off screen.
Use your framework's tools
In React, rendering a large list or chart on every keystroke is a common INP problem. useTransition and useDeferredValue let React keep the input responsive and update the expensive part when it can. Memoizing heavy components avoids re-rendering parts of the page that did not change.
What this means for SEO
Core Web Vitals are one ranking signal among many, and relevance still matters far more. But a poor INP score is usually a symptom of something visitors notice: buttons that lag, forms that stutter and menus that hesitate. Those things cost conversions regardless of what they do to rankings.
If you passed FID and never looked at responsiveness again, now is a good time to check. The fixes are rarely glamorous, but they make the site feel faster for every visitor.
Want us to find what is slowing down your pages? Get in touch and we will look at your Core Web Vitals with you.