Investigating INP: The New Core Web Vital
The Death of First Input Delay
For years, First Input Delay (FID) was the primary metric for measuring the interactivity of a website. However, developers quickly realized its flaw: it only measured the first interaction (like a solitary click) and only measured the delay before the processing started, entirely ignoring the actual time it took to update the UI visually.
Google has officially replaced FID with completely new metric: Interaction to Next Paint (INP).
Understanding INP
INP observes the latency of all clicks, taps, and keyboard interactions with a page throughout its entire lifespan. The final INP value is usually the single longest interaction observed, covering three phases:
- Input Delay: Time waiting for the main thread to be free.
- Processing Time: Running your JavaScript event handlers.
- Presentation Delay: Rendering the resulting pixels to the screen.
Common Causes of Poor INP
If your INP is solidly in the "Needs Improvement" (over 200ms) or "Poor" (over 500ms) category, the culprit is almost definitively a blocked main thread. This commonly happens due to:
- Massive React re-renders triggering off a single state update.
- Heavy DOM manipulation occurring synchronously during an event.
- Third-party scripts (like heavy analytics trackers) executing long tasks right when the user tries to click a button.
Strategies for Mitigation
To conquer INP, you need to yield to the main thread. If an interaction requires heavy calculation, provide immediate visual feedback (like a loading spinner), then defer the heavy work using setTimeout(..., 0), requestIdleCallback, or breaking large tasks into smaller execution chunks. Furthermore, optimizing DOM sizes and utilizing the new React 18 Concurrent Features (like useTransition) can drastically lower your processing phase times.