INP (Interaction to Next Paint)
Core Web Vital measuring page responsiveness across all user interactions, not just the first.
What is INP?
Interaction to Next Paint (INP) is the Core Web Vital that measures a page's overall responsiveness to user interactions. Unlike its predecessor FID (which only measured the first interaction), INP observes all clicks, taps, and keyboard interactions throughout the entire page lifecycle and reports the worst interaction latency (with some statistical outlier filtering). INP became the official Core Web Vital for interactivity in March 2024, replacing FID.
INP measures the complete interaction cycle: from when the user interacts (input delay), through the browser processing event handlers (processing time), to when the browser paints the visual update (presentation delay). This end-to-end measurement provides a more accurate picture of how responsive a page feels to users.
How It's Calculated
The browser tracks the latency of every user interaction during a page visit. INP is typically the worst observed interaction latency, though for pages with many interactions, it uses a statistical method (approximately the 98th percentile) to avoid being skewed by a single outlier. Google's thresholds: under 200ms is "good," 200-500ms "needs improvement," and over 500ms is "poor."
Why It Matters for Publishers
INP is a significant challenge for ad-heavy publisher sites because ads inject JavaScript that competes with editorial content for the browser's main thread. Ad refresh cycles, lazy-loading ad units, and consent management interactions all create opportunities for poor INP scores. A page might load quickly (good LCP) but feel sluggish throughout the session (poor INP) because of ongoing ad-related JavaScript execution.
Since INP measures all interactions — not just the first — issues that occur mid-session (like ad refresh scripts blocking the main thread or heavy video ad initialization) now affect your Core Web Vitals score and potentially your search rankings.
Tips for Optimization
- Break up long tasks: Use the yield-to-main-thread pattern (scheduler.yield() or setTimeout) to break heavy JavaScript processing into chunks smaller than 50ms, keeping the main thread responsive.
- Optimize event handlers: Ensure click and scroll event handlers execute quickly. Move heavy processing out of event handlers and into requestAnimationFrame or requestIdleCallback callbacks.
- Audit ad script impact: Use Chrome DevTools Performance panel to identify which ad scripts cause long tasks during user interactions. Work with ad partners to optimize or defer these scripts.
- Reduce DOM size: Large DOM trees make rendering updates slower. Keep your page's DOM under 1,500 nodes where possible, especially in areas with interactive elements.
- Use web workers for heavy computation: Move data processing, analytics calculations, and other CPU-intensive work off the main thread using web workers.