FID’s Replacement: What INP Measures Differently

Starting March 2024, Interaction to Next Paint (INP) will replace First Input Delay (FID) as a Core Web Vital. FID measures the gap between a user’s first interaction—such as a click, tap, or key press—and the moment the browser’s main thread can begin processing that event. If the main thread is occupied with parsing HTML, executing JavaScript, or handling other listeners, the new event queues up, and FID captures that waiting period.

The First Input Delay measures the time between the first user interaction (clicks, taps, key presses) until the browser can process the event

FID has two notable blind spots. It only tracks the first input, so later—and possibly slower—interactions go unmeasured. It also ignores everything that happens after the event handler starts, including layout recalculations and the time required to paint visual feedback.

From Input Delay to Whole-Interaction Latency

INP addresses those gaps by measuring the full lifecycle of every interaction a user makes during the page’s lifetime. Instead of focusing solely on input delay, INP accounts for:

  • Input Delay: the time from the user’s action until the browser can process the event
  • Processing Delay: the time the browser spends executing event handlers
  • Presentational Delay: the time needed for layout recalculation and painting pixels to the screen

INP also differs in aggregation: rather than isolating the first event, it records all interactions and reports the worst-measured score when the user leaves the page.

Since the worst-measured score throughout the page's lifespan was 120ms, the total INP score will be 120.

Optimizing Across the Interaction Lifecycle

FID optimization centered on keeping the main thread free and reducing long tasks. INP requires a broader approach, addressing each phase of the interaction timeline.

Cutting Processing Delay

Fast event handler execution matters as much as quick startup. Recommended practices include:

  • Profiling code to locate performance bottlenecks
  • Applying debounce or throttle to frequently firing handlers
  • Using code splitting and tree shaking to reduce unnecessary JavaScript
  • Breaking long tasks into smaller chunks that block interactions less

Minimizing Presentational Delay

Post-handler work—style recalculations, reflows, and repaints—can also delay visual feedback. To reduce it:

  • Use the will-change property judiciously for likely-animated elements
  • Animate transform and opacity, which tend to avoid layout recalculations
  • Leverage content-visibility to render only when needed
  • Avoid forced synchronous layouts by not reading layout properties immediately after writing them
  • Offload non-urgent, non-UI tasks to Web Workers to keep the main thread responsive

Streamlining Event Handling

Efficient event execution reduces the risk of slow interactions:

  • Defer non-critical events until the main thread is less busy
  • Use passive event listeners for scroll and touch events so the browser doesn’t wait for the listener
  • Delegate events by attaching listeners to a common parent rather than individual elements, reducing total listener count

Tracking INP in Production

Real User Monitoring (RUM) tools are essential for collecting actual-user performance data. Although INP is not yet officially stable, it can be measured today with tools such as Vercel Speed Insights, PageSpeed Insights, and Lighthouse’s Timespan feature.

INP’s wider lens captures the full time from interaction to visual response. Optimizing for it improves not only responsiveness but also the overall user experience. For Next.js users, adopting React 18’s concurrent features can further aid INP improvements.