Your site felt fast because Google was only testing the first click. First Input Delay (FID) measured a single interaction and called it a day. In March 2024, Google replaced it with Interaction to Next Paint (INP), a Core Web Vital that tracks every interaction throughout the entire page session and reports the worst one[1]. Sites that passed FID comfortably started failing overnight.
Why It Matters
Consider a page that responds quickly to the first click but freezes on the third scroll-triggered filter. FID gave that a passing grade. INP does not. It captures every tap, click, and keypress, then reports the slowest response using the 98th percentile for pages with many interactions. That is a much harder bar to clear, and it exposed responsiveness problems that had been hiding behind FID's single-interaction model for years.
For agents, responsiveness is even more consequential. Agents interact with your site programmatically, filling forms, clicking through navigation, and triggering dynamic content loads. When JavaScript blocks the main thread, those interactions time out or produce unexpected results. Sites that respond quickly are more reliably crawlable and more likely to surface complete content.
How It's Measured
INP is measured in milliseconds. Google considers 200ms or less to be good, 200 to 500ms needs improvement, and above 500ms is poor[2].
Each interaction breaks down into three phases:
- Input delay: time between the user's action and when the event handler starts running
- Processing time: how long the event handler takes to execute
- Presentation delay: time from handler completion to the next frame being painted
INP captures all three. A bottleneck in any phase contributes to the total latency, but most poor scores trace back to input delay or processing time rather than presentation delay.
Common Causes of Poor INP
- Long JavaScript tasks that exceed 50ms block the main thread and delay the visual response
- Heavy event handlers that trigger expensive DOM manipulation, state updates, or synchronous network requests on click or input
- Excessive re-renders where frameworks rebuild large component trees in response to minor state changes
- Third-party scripts like analytics, chat widgets, and social embeds competing for main thread time
- Large DOM size with thousands of nodes, which slows updates and repaints
How to Fix It
- Break up long tasks using `requestIdleCallback`, `setTimeout`, or `scheduler.yield()` to split work across frames
- Debounce input handlers for search inputs and filters to avoid firing on every keystroke
- Minimize DOM size by keeping the DOM under 1,500 nodes where possible and virtualizing long lists
- Defer non-critical JavaScript so only the code needed for the current interaction loads
- Use CSS containment with `contain: content` on off-screen sections to prevent unnecessary layout and paint work
- Optimize framework rendering with `React.memo`, `useMemo`, and virtualization to reduce re-render scope
How Site Scanner Helps
Site Scanner evaluates INP as part of its Performance dimension using Lighthouse and real-world interaction simulation. Pages with INP above 200ms are flagged in the scan report with specific recommendations for improvement.