Understanding First Input Delay and Interaction to Next Paint (INP)

In early 2024, Google replaced First Input Delay (FID) with Interaction to Next Paint (INP) as the third official Core Web Vital. If you've been optimizing for FID and wondering why your scores look different now, or you're just trying to understand what INP actually measures, here's a practical breakdown.

Why FID Was Replaced

First Input Delay only measured the delay before the browser began processing a user's first interaction with the page — it said nothing about how long that interaction actually took to complete, and nothing about any interactions after the first one. A page could have a great FID score while still feeling sluggish and unresponsive throughout the rest of the user's session. INP addresses both gaps.

What INP Actually Measures

Interaction to Next Paint measures the latency of all interactions throughout a page's lifecycle — clicks, taps, and key presses — and reports the worst (or near-worst) one as the page's overall score. Critically, it measures the full duration: from when the user interacts, through the browser processing that interaction, to when the next frame is painted showing a visual response. A good INP score is under 200 milliseconds; anything over 500ms is considered poor.

Why This Matters More Than FID Did

INP captures a much more realistic picture of responsiveness throughout an entire visit, not just the very first tap. A page that loads fine but becomes sluggish after a user has scrolled, filtered results, or opened a modal — common patterns in modern interactive applications — would have looked fine under FID but will correctly show poor INP if those later interactions are slow.

Common Causes of Poor INP

Heavy JavaScript execution on the main thread. If your JavaScript is busy running other work when a user interacts, their interaction has to wait in queue before it can even begin processing — this is by far the most common cause of poor INP.

Large DOM size. A very large, deeply nested DOM makes even simple operations (like toggling a class) more expensive, since the browser has more to recalculate.

Unoptimized event handlers. Event handlers that do expensive, synchronous work (large loops, expensive calculations, synchronous layout reads) directly delay the visual response to that interaction.

Third-party scripts hogging the main thread. Ad scripts, analytics, and widgets running heavy processing can block your own application's ability to respond quickly to user interactions, even if your own code is well-optimized.

Practical Fixes for INP

Break up long tasks. JavaScript tasks longer than 50ms block the main thread from responding to new interactions. Breaking large synchronous operations into smaller chunks (using techniques like setTimeout scheduling or the newer scheduler.yield() API) lets the browser handle interactions in between chunks rather than making users wait for the entire operation to finish.

Debounce and throttle expensive handlers. For interactions that fire rapidly (scroll, resize, input typing), debouncing or throttling expensive logic prevents redundant work from piling up and delaying visual feedback.

Optimize React/framework re-renders. In component-based frameworks, unnecessary re-renders triggered by state changes can be a significant hidden cost. Memoization and careful state management reduce wasted rendering work that would otherwise delay the browser's next paint.

Use CSS for simple visual feedback instead of JavaScript. For things like hover states or simple toggles, CSS-only solutions respond faster than waiting for JavaScript execution, since they're handled by the browser's rendering engine more directly.

Reduce third-party script impact. Audit and defer non-essential third-party scripts, and load them after critical interactivity is established rather than competing with your core application's JavaScript for main thread time.

Measuring INP

Since INP depends on actual user interaction patterns, lab testing tools (which simulate a single scripted interaction) give a limited picture. Real-user monitoring data — from Chrome UX Report data in PageSpeed Insights, or your own real-user monitoring setup — gives a far more accurate and complete picture of your actual INP across real user sessions and interaction patterns.

The Bottom Line

INP represents a meaningfully more complete measure of interactivity than its predecessor, and it's directly tied to how "snappy" your site actually feels to use throughout an entire visit, not just at the very first click. For interactive, JavaScript-heavy applications especially, this is worth taking seriously as both a UX and SEO consideration.