Core Web Vitals in 2026: what changed and what it means for your stack
INP replaced FID. Interaction budgets are tighter. Here's how we keep every Next.js platform at 98+.
INP replaced FID as a Core Web Vital in March 2024. By mid-2025 it had become the metric we spend the most time optimising in production. Here's what we've learned from eighteen months of INP work across thirty-plus Next.js platforms.
- INP measures what FID missed
- The main thread is the bottleneck — always
- Yielding to the main thread is the primary intervention
- Field data > lab data for INP
INP measures what FID missed
FID (First Input Delay) measured the time from the first user interaction to the point where the browser started processing it. It only captured the first interaction, and it only captured the delay — not the actual processing time.
INP (Interaction to Next Paint) measures every interaction, and it measures the full duration from interaction trigger to the browser painting the visual response. It's a harder metric to hit because it captures actual UI responsiveness, not just input scheduling.
The main thread is the bottleneck — always
Poor INP scores almost always come back to the same root cause: the browser's main thread is occupied when the user interacts. Long tasks — JavaScript that runs for more than 50ms without yielding — are the primary offender.
In Next.js applications, the most common sources of long tasks are: large third-party scripts (analytics, chat widgets, A/B testing), synchronous state updates that trigger expensive re-renders, and event handlers that do too much computation inline.
Yielding to the main thread is the primary intervention
The fix for most INP problems is task scheduling — breaking long synchronous work into smaller chunks and using `scheduler.yield()` or `setTimeout(0)` to yield control back to the browser between chunks.
In React, the practical version of this is: move expensive computations out of render, use `startTransition` for non-urgent state updates, and defer non-critical event handler work with `queueMicrotask` or `setTimeout`. We've seen INP scores improve from 400ms+ to 120ms with these changes alone.
Field data > lab data for INP
INP is inherently variable — it depends on what users actually do on the page, not a scripted user journey in a lab environment. Lighthouse gives you a simulated INP score that is directionally useful but can diverge significantly from real-user data.
We instrument every platform with the `web-vitals` library reporting to a custom analytics endpoint, segmented by device type, connection speed, and geographic region. Real INP problems in southeast Asia on mid-range Android devices simply don't show up in Lighthouse running on a MacBook Pro.