INP and SEO: The Core Web Vital That Replaced FID
Ranjeeth Kumar
Last updated on
Interaction to Next Paint (INP) measures how long a page takes to visually respond to any user interaction, click, tap, or keypress, across the entire page visit, not just the first one. It officially replaced First Input Delay (FID) as a Core Web Vital in March 2024, and the difference matters: a page can pass FID by responding well to the first click and still fail INP if every interaction after that one lags.
What You Need to Know About INP and SEO
- INP replaced FID as an official Core Web Vital in March 2024, measuring responsiveness across every interaction on a page, not just the first.
- Google considers an INP under 200 milliseconds “Good,” 200 to 500 milliseconds “Needs Improvement,” and over 500 milliseconds “Poor.”
- Unlike FID, which only measured the delay before the first response, INP captures the full time from interaction to the next visual update, including processing and rendering.
- SaaS product-adjacent marketing pages (interactive calculators, filterable comparison tables, multi-step forms) are the most common source of poor INP on a marketing site.
- Heavy JavaScript execution on the main thread is the dominant cause of poor INP, the same root cause FID targeted, just measured more completely.
What Is INP, and Why Did It Replace FID?
INP replaced FID because FID only measured the delay before a page’s first response to a user, which missed the far more common problem: a page that responds fine to the first click but lags on every interaction after that. INP measures the full interaction-to-paint cycle across a visit, using the worst (or near-worst) interaction to produce its score.
FID’s blind spot was structural. A page could show a fast first click and still frustrate a user through slow subsequent interactions, a scroll that stutters, a dropdown that lags, a form field that doesn’t update instantly, none of which FID’s first-interaction-only measurement ever captured.
- INP measures the entire visit, over one moment. It samples every interaction and reports a score representing the page’s overall responsiveness, rather than a single first-click snapshot.
- It includes processing and rendering time, beyond just delay. FID measured only the time before the browser started processing an input. INP adds the actual processing and paint time on top, giving a fuller picture of what the user experienced.
- The threshold is stricter in practice. A 200 millisecond “Good” bar across every interaction is a higher bar than passing FID once on the first click, which means sites that previously passed FID cleanly can still fail INP.
Consider a SaaS pricing page with a toggle between monthly and annual billing. FID measured only whether the page responded quickly to the very first click on the page, often a navigation link. INP catches the actual toggle interaction lagging by 400 milliseconds every time a visitor switches billing periods, a problem FID never had visibility into.
What Causes a Poor INP Score
Poor INP almost always traces back to JavaScript work blocking the browser’s main thread at the moment a user interacts, preventing the visual update from happening quickly even when the interaction itself is simple.
- Heavy JavaScript execution on the main thread. Large bundles, unoptimized event handlers, or expensive re-renders block the thread from responding promptly to input, the same underlying cause behind poor FID scores.
- Third-party scripts running expensive work on interaction. Analytics, chat widgets, and A/B testing tools can attach handlers that add processing time to otherwise simple clicks.
- Large DOM size and complex re-renders. Interactions that trigger a re-render of a large portion of the page take longer to paint than a targeted, minimal update.
- Long tasks queued ahead of the interaction handler. If the main thread is busy running an unrelated long task when the user clicks, the interaction has to wait in line before the browser can even start processing it.
How to Diagnose and Fix Poor INP
How to Improve INP, Step by Step
- Check Search Console’s Core Web Vitals report for INP-flagged URL groups. This surfaces which page templates are failing in the field, using real user data rather than a single lab test.
- Use Chrome DevTools’ Performance panel to record specific interactions. Recording an actual click or scroll shows exactly where time is being spent between the interaction and the next paint, isolating the specific bottleneck.
- Break up long JavaScript tasks. Splitting a large task into smaller chunks that yield back to the main thread lets the browser respond to user input between chunks, rather than blocking until the entire task finishes.
- Audit and defer non-critical third-party scripts. Chat widgets, analytics, and marketing pixels that aren’t essential to the immediate interaction should load with
asyncordefer, so they don’t compete for main thread time during a user’s click. - Reduce unnecessary re-renders on interaction. For pages built with a JavaScript framework, minimizing the scope of what re-renders on a state change keeps the paint step fast even on complex pages.
- Debounce or throttle high-frequency interactions, like scroll or resize handlers, so the browser isn’t asked to process and paint on every single event fired.
Most INP fixes require a developer, unlike some CLS fixes that a marketer can implement directly, since the root cause usually lives in JavaScript execution rather than layout or asset loading.
Common Mistakes to Avoid
Assuming a Good FID Score Means a Good INP Score
FID only measured the first interaction. A page can pass FID cleanly and still fail INP if interactions later in the visit, scrolling, form fields, toggles, lag behind the 200 millisecond threshold.
Treating INP as a Load Speed Metric
INP measures responsiveness to interaction, a distinct problem from LCP , which measures how fast content initially renders. A fast-loading page can still have poor INP if its JavaScript blocks the main thread once a user starts interacting.
Ignoring Third-Party Scripts as an INP Cause
Marketing and analytics tools you didn’t build are one of the most overlooked contributors to poor INP, since they’re easy to forget when auditing your own page templates for responsiveness issues.
Fixing Only the First Interaction on a Page
Since INP scores the whole visit, optimizing only the interaction a user hits first (often navigation) while ignoring later interactions like form fields or filters leaves the actual problem unaddressed.
How PipeRocket Digital Approaches INP
We diagnose INP by isolating which specific interaction is lagging, over treating it as a general speed problem, since the fix path differs based on whether the bottleneck is JavaScript execution, a third-party script, or an oversized re-render. This is part of the broader Core Web Vitals audit inside every technical SEO engagement. Get in touch if Search Console is flagging INP issues on your marketing pages.
Frequently Asked Questions
Is FID still a ranking factor now that INP has replaced it?
No. Google officially replaced FID with INP as a Core Web Vital in March 2024. FID is no longer part of the Page Experience ranking signals, and the tools that used to report it (PageSpeed Insights, Search Console) have moved to INP. See our FID glossary entry for the full history of the transition.
What’s a good INP score for a SaaS marketing site?
Google considers an INP under 200 milliseconds “Good.” Between 200 and 500 milliseconds is “Needs Improvement,” and above 500 milliseconds is “Poor.” Interactive elements like pricing toggles, filterable tables, and multi-step forms are the most common sources of a poor score on SaaS marketing pages specifically.
Can INP issues affect conversions even without hurting rankings?
Yes, and for most SaaS sites this is the more immediate cost. A pricing toggle or form field that lags noticeably frustrates a user in the moment they’re evaluating your product, which can cost a conversion regardless of whatever ranking impact the INP score eventually has.
