Core Web Vitals in 2026: INP Replaced FID and Your Dashboard Should Reflect It

In March 2024, Google officially retired First Input Delay (FID) from Core Web Vitals and replaced it with Interaction to Next Paint (INP). Two years later, a surprising number of performance dashboards, monitoring tools, and QA pipelines still report FID as a primary metric, or worse, report nothing for interactivity at all. If your monitoring has not adapted, you are measuring a metric that no longer exists in Google's ranking algorithm and missing the one that does.

The shift from FID to INP was not a cosmetic rename. INP fundamentally changes what "good interactivity" means, and sites that comfortably passed FID can fail INP badly. Understanding why requires looking at what each metric actually measures and what they miss.

What FID Measured and Why It Was Not Enough

FID measured the delay between a user's first discrete interaction (a click, tap, or key press) and the moment the browser began processing the event handler for that interaction. Critically, FID only measured the input delay component of the first interaction. It did not measure how long the event handler took to run, and it did not measure the time for the browser to paint the result.

This created a significant blind spot. A page could have a FID of 10 milliseconds (the browser started processing quickly) but then run a 500ms event handler that froze the UI. The user experienced half a second of unresponsiveness, but FID reported 10ms. From a user experience perspective, the page was sluggish. From a FID perspective, it was excellent.

The "first" limitation was equally problematic. FID only captured the very first interaction. If a user's first click was on a lightweight element during a quiet moment on the main thread, FID would be fast. But their second, third, and tenth interactions, opening dropdown menus, toggling accordions, submitting forms, could be painfully slow due to JavaScript executing in the background. FID would never know because it stopped measuring after the first interaction.

By the time Google deprecated FID, the metric had become nearly useless as a discriminator. According to the Chrome UX Report from early 2024, over 95% of origins had "good" FID scores. The threshold was 100ms, and the bar was so low that virtually every website passed it. A metric that nearly everyone passes provides no meaningful signal.

How INP Measures Interactivity

INP takes a fundamentally different approach. It observes every discrete interaction during the entire page lifecycle, not just the first one. For each interaction, INP measures the total time from the user's input to the next frame being painted on screen. This includes three components:

1. Input delay: The time between the user's interaction and the start of the event handler. This is what FID measured. It is typically caused by long tasks blocking the main thread when the user interacts.
2. Processing time: The time the event handler(s) take to execute. This includes your click handlers, state updates, component re-renders, and any synchronous work triggered by the interaction.
3. Presentation delay: The time from when event handlers finish to when the browser paints the next frame. This includes style recalculation, layout, compositing, and paint. Heavy DOM changes or layout thrashing during the handler extend this phase.

After observing all interactions, INP reports a single value: the duration of the worst interaction, measured at the 98th percentile. The p98 choice is deliberate. It ignores the absolute worst outlier (which might be a fluke) while still capturing consistently slow interactions. For pages with fewer than 50 interactions, the worst interaction is used directly.

The thresholds are:

Rating	INP Value	User Perception
Good	200ms or less	Interactions feel instant and responsive
Needs improvement	200ms to 500ms	Noticeable delay, user may hesitate
Poor	Over 500ms	Feels broken, user may abandon the task

Why Sites That Passed FID Fail INP

The gap between FID and INP catches teams off guard because the two metrics measure almost entirely different things. Here are the most common scenarios where a site with perfect FID scores gets a poor INP rating:

Heavy dropdown menus and accordions. The first click on a page might land on a simple navigation link, giving a great FID score. But when a user opens a mega-menu that renders 200 DOM nodes with JavaScript-driven animations, that interaction can take 400ms from click to paint. FID never saw it. INP catches it every time.

Client-side form validation. Submitting a form that triggers synchronous validation across dozens of fields, especially with complex rules or regex patterns, can block the main thread for hundreds of milliseconds. The submit button click registers instantly (good input delay), but the processing time and re-render time push total interaction latency well past 200ms.

Third-party scripts running during interactions. Analytics libraries, A/B testing tools, chat widgets, and ad scripts frequently schedule long tasks on the main thread. If a user clicks a button at the moment a third-party script is executing a 150ms task, the input delay alone might not exceed FID's threshold, but combined with your own event handler processing and the resulting paint, the total INP easily exceeds 200ms.

React and virtual DOM reconciliation. In complex React applications, a state change triggered by a user interaction can cause a cascade of component re-renders. The diffing and reconciliation process happens synchronously on the main thread. For component trees with hundreds of nodes, this processing time adds directly to INP. Memoization and selective rendering become performance requirements, not optimizations.

Scroll-linked layout thrashing. Event handlers attached to scroll events that read layout properties (like offsetTop, getBoundingClientRect()) and then write DOM changes (like toggling classes or modifying styles) force the browser into synchronous layout recalculation on every frame. This does not directly affect INP since scroll is not a discrete interaction, but the queued layout work delays discrete interactions that happen during scrolling.

Measuring INP: Field Data vs. Lab Approximation

INP is inherently a field metric. It requires real user interactions across the full page session to produce a meaningful value. This makes it fundamentally different from metrics like LCP or CLS, which can be reasonably approximated in lab settings.

Chrome UX Report (CrUX) is the authoritative source for field INP data. It aggregates real Chrome user experiences over a 28-day rolling window and reports the 75th percentile (p75) at the origin and URL level. This is the dataset Google uses for search ranking signals. Access it through the CrUX API, BigQuery, or PageSpeed Insights.

The web-vitals JavaScript library lets you collect INP from your own users. Add the library to your site, and it reports INP values as users interact. Ship these to your analytics backend to get INP data segmented by page, device type, geography, and user behavior patterns. This is essential because CrUX data has a 28-day lag and only reports at aggregated percentiles.

The implementation is straightforward. Import onINP from the web-vitals library and pass a callback that sends the metric to your analytics endpoint. The library handles the p98 calculation and reports when the page is backgrounded or unloaded. Critically, set reportAllChanges: true if you want to debug which specific interactions contribute to poor INP, not just the final value.

Lighthouse and lab tools cannot measure INP directly because there is no real user interacting with the page. Lighthouse reports Total Blocking Time (TBT) as a lab proxy for interactivity. TBT sums the blocking portions of all long tasks (the time beyond 50ms for each task) during the page load period. While TBT correlates with INP in many cases, it misses post-load interactions entirely. A page that loads cleanly but has slow interactions when the user clicks buttons will have a good TBT but poor INP.

Chrome DevTools Performance panel lets you manually profile interactions. Record a trace, perform interactions, and inspect the "Interactions" track to see the input delay, processing time, and presentation delay breakdown for each interaction. This is the primary debugging tool for specific slow interactions.

Optimization Strategies That Actually Move the Needle

Improving INP requires attacking all three components: input delay, processing time, and presentation delay. The strategies are different for each.

Break long tasks with scheduler.yield(). The scheduler.yield() API (available in Chrome, with a polyfill for other browsers) allows you to voluntarily yield the main thread during a long-running function. When your event handler needs to do 300ms of work, break it into chunks and yield between them. This lets the browser process pending user interactions and paint frames between chunks, dramatically reducing input delay for subsequent interactions. Unlike setTimeout(fn, 0), yielding with the scheduler API preserves task priority so your work resumes promptly.

Defer non-critical work from event handlers. Not everything triggered by a user click needs to happen synchronously. Analytics tracking, logging, prefetching, and non-visible state updates can be deferred using requestIdleCallback() or queueMicrotask(). Keep the event handler focused on the minimum work needed to produce the visible result, and schedule everything else for later.

Move computation to Web Workers. Any CPU-intensive work that does not require DOM access, such as data transformation, sorting large arrays, JSON parsing of large payloads, or cryptographic operations, should run in a Web Worker. Workers run on a separate thread and cannot block the main thread. Libraries like Comlink simplify the messaging interface between the main thread and workers to simple async function calls.

Minimize DOM size and update scope. Large DOM trees (over 1,400 nodes, per Lighthouse's threshold) make every layout and paint operation slower. When an event handler modifies the DOM, the browser recalculates styles and layout for affected elements and their ancestors. Use CSS containment (contain: layout) to limit the scope of layout recalculation. In framework applications, use virtualization for long lists so the DOM only contains visible items.

Audit and control third-party scripts. Third-party scripts are the single most common cause of unexpected main thread contention. Evaluate each script's impact using the Long Tasks API or Chrome DevTools. Load non-essential scripts with async or defer attributes and consider using a facade pattern, where a lightweight placeholder loads the full third-party script only when the user interacts with it. Chat widgets and video embeds are prime candidates for facades.

Avoid layout thrashing in handlers. If your event handler reads a layout property and then writes a DOM change, and does this multiple times, each write invalidates the layout and each subsequent read forces a synchronous recalculation. Batch all reads first, then batch all writes. Or use requestAnimationFrame() to defer writes to the next frame.

The Three Core Web Vitals in 2026

With the FID-to-INP transition complete, the current Core Web Vitals consist of three metrics, each targeting a distinct aspect of user experience:

Metric	Measures	Good Threshold	What It Catches
LCP	Loading	2.5 seconds	Slow server responses, render-blocking resources, lazy-loaded hero images
INP	Interactivity	200 milliseconds	Long JavaScript tasks, heavy event handlers, layout thrashing
CLS	Visual stability	0.1	Images without dimensions, dynamic content injection, web fonts causing reflow

Together, these three metrics answer the questions users implicitly ask when they load a page: Did it load quickly? Did it respond when I interacted with it? Did things stay where I expected them to be? If any one of these fails, the user experience suffers, and Google's ranking algorithm reflects that.

The key takeaway for QA teams and developers: if your performance monitoring still references FID, it is out of date. If your CI pipeline checks interactivity using only TBT (the lab proxy), you need to supplement it with field INP data from real users. And if your site passes all three Core Web Vitals today, you need continuous monitoring to ensure it stays that way as your codebase and third-party dependencies evolve.

Test your Core Web Vitals including INP scores →