For years, FID (First Input Delay) was the interactivity metric that determined whether a site met Google’s Core Web Vitals. It was a “friendly” metric: it only measured the user’s first input and sites passed the threshold relatively easily.
In March 2024, Google replaced FID with INP (Interaction to Next Paint). The change wasn’t cosmetic: INP measures different things, is much stricter, and has left many sites in red that used to pass in green.
The data is clear: 40% of sites that passed FID don’t pass INP. If your site hasn’t adjusted its performance to the new standard in the last 24 months, you probably have a silent problem affecting your SEO without you knowing.
What INP measures and why it’s stricter than FID
FID measured the delay between the user’s first input (click, tap, key) and the moment the browser started processing it. Only the first input. Only the initial delay. Only the start of processing.
INP measures the worst-case interactivity of the entire user session. All inputs, not just the first. The full latency from user interaction to screen update. The “worst case” (p98, not the average).
This is a criteria change. FID could be good even if your site had a button that took 2 seconds to respond, as long as the first click was fast. INP detects that problematic button and reflects it in the metric.
Google’s current thresholds:
- Good INP: under 200 ms.
- Needs improvement: between 200 ms and 500 ms.
- Poor INP: over 500 ms.
Many sites with heavy JavaScript (modern frontend frameworks, many tracking tags, aggressive analytics libraries) easily sit above 200 ms on typical interactions. And they don’t even know.
The 3 technical problems that hurt INP the most
JavaScript blocking the main thread
The browser’s main thread processes both JavaScript and visual updates. When JavaScript occupies the thread more than 50 ms, the browser can’t respond to user inputs during that time.
Typical culprits:
- Aggressive tracking libraries (GA4 with many configurations, Segment, Hotjar, personalization scripts).
- Hydration of frontend frameworks on pages with many components.
- Third-party scripts for ads, recommenders, chatbots.
- Heavy event handlers that do complex calculations on click.
The solution isn’t removing JavaScript. It’s auditing what the main thread executes at each moment and moving what can be moved to Web Workers, lazy-loading or deferred execution.
Long tasks on click
When the user clicks a button and the click handler executes a heavy function (API call, data processing, complex state update in React/Vue), INP measures all that time.
The correct pattern: the click handler should update the visual UI immediately (show spinner, change button state) and move the heavy work to a setTimeout or requestIdleCallback.
Style and layout thrashing
When user interaction triggers massive layout recalculations (many elements resize, reposition, change styles), the time between input and next paint spikes.
Typical causes:
- CSS animations modifying properties that force layout recalc (width, height, margin, padding instead of transform/opacity).
- JavaScript reading and writing to the DOM intercalated without using requestAnimationFrame.
- Components that remount on any simple interaction.
How to diagnose INP on your site today
Step 1: Real CrUX data
The data Google uses to evaluate your site comes from Chrome UX Report (CrUX), which gathers anonymous metrics from real users. These are the metrics that count for SEO, not Lighthouse simulations.
Go to PageSpeed Insights and look at the “Discover what your real users are experiencing” section. If INP appears red or yellow for mobile and/or desktop, you have a problem affecting your SEO.
If it doesn’t appear (site with low traffic and no CrUX data), use Lighthouse in “user flow” mode simulating real interactions.
Step 2: Identify problematic interactions
Chrome DevTools includes a specific Performance panel. Start recording, use the site as a normal user (scroll, click, forms), stop recording.
The panel shows every long task that occupied the main thread. Tasks of 200+ ms are INP problem candidates. 500+ ms are definite problems.
For each long task, DevTools shows which code caused it. If it’s own code, you need to refactor. If it’s third-party (tags, analytics, widgets), you need to decide if the value it adds justifies the performance cost.
Step 3: Prioritize by interaction frequency
Not all interactions are equal. A click on a link that 90% of users make is critical. A click on a secondary menu that 5% use is less urgent.
Cross INP data with Google Analytics: which interactions are the most frequent. Prioritize fixing the ones that affect more users.
Why this changes technical SEO priorities
INP isn’t fixed by optimizing images or improving the server (that affects LCP, a different metric). INP is fixed by auditing the JavaScript your site executes.
This moves the center of gravity of technical SEO. For years, technical optimization focused a lot on the server side (compression, CDN, caching, response times). INP shifts the focus to frontend: what JavaScript runs, when it runs, how it runs.
Sites with the most INP problems are usually those built with heavy unoptimized frameworks (Next.js/Nuxt with many components without lazy-loading), sites with many marketing tags (Google Tag Manager with 30+ active tags), or sites with aggressive dynamic personalization.
What to do this week if INP is a problem
-
Audit the 10 most important URLs of your site on PageSpeed Insights. If INP is red on any, you have work.
-
Identify the heaviest JavaScript: go to DevTools → Performance → Coverage. You’ll see which JS files load and how much is actually used.
-
Ask your technical team which marketing tags are active and which add real value. It’s common to find 10-15 tags accumulated over years that no longer get used and keep running on every page.
-
Review frontend libraries: if you use React/Vue/Angular, do you code-split? Are components lazy? Are you hydrating components that could be static islands?
-
Measure weekly: create a simple Looker Studio dashboard with INP of main pages. What isn’t measured doesn’t improve.
The opportunity inside the problem
40% of sites don’t pass INP. That means if you optimize this well, you have direct competitive advantage over most of your sector.
And unlike other SEO metrics, INP is very actionable: improvements are technical, the roadmap is clear, and results are measurable in 4-6 weeks.
If your site has INP problems and you don’t know where to start, contact us for a technical diagnosis. We’ve spent 25 years optimizing performance and Core Web Vitals on large projects and we know what moves the needle in each case.
