Interaction To Next Paint in 2026.

In March 2024, Interaction to Next Paint replaced First Input Delay as a Core Web Vital. The industry spent approximately eight months panicking, then approximately eight months optimizing, then approximately eight months returning to baseline levels of performance neglect.

In 2026, the thresholds have tightened. The "good" threshold is now 100 milliseconds, down from 200. The measurement percentile has shifted from the 75th to the 95th. Your site is likely failing, even if you optimized for the 2024 thresholds.

What INP Actually Measures

INP measures the latency of all interactions throughout a page visit and reports the single worst interaction. It does not measure the first interaction exclusively. It does not average all interactions. It reports the maximum, filtered for outliers.

This is a significantly more demanding metric than its predecessor. A single slow interaction, even one that occurs after the user has been on the page for several minutes, determines your INP score. The 95th percentile requirement means that one in twenty user sessions can drag your entire site into the "needs improvement" category.

The Framework-Specific Bottlenecks

1. React: The Re-Render Cascade

React's rendering model, in which state changes trigger re-renders of entire component subtrees, creates predictable INP vulnerabilities. An interaction that updates a high-level state value can cause hundreds of components to re-evaluate, even if only one component's visual output actually changes.

The Mitigation: useMemo and memo are necessary, not optional. The React compiler, which automatically memoizes components, has reduced the manual burden but has not eliminated the need for thoughtful component architecture. Audit your component re-renders with the React DevTools profiler. Identify components that re-render without prop changes. Memoize aggressively.

2. Vue: The Reactivity Granularity

Vue's reactivity system is more granular than React's, but it is not immune to INP issues. Computed properties with expensive dependencies, watchers that trigger cascading updates, and template expressions that invoke functions can all contribute to interaction latency.

The Mitigation: Profile with the Vue DevTools. Examine the render timeline. Identify components with high render costs. Move expensive computations off the main thread or cache their results aggressively.

3. Next.js and Nuxt: The Server Component Tax

Server components and server-side rendering introduce a new class of INP vulnerabilities. Interactions that require client-side JavaScript from server-rendered components may be delayed while the client hydrates the component tree.

The Mitigation: Audit your hydration strategy. Are you hydrating components that do not require interactivity? Use partial hydration techniques. Defer hydration for components below the fold. Consider islands architecture for highly interactive pages.

4. Third-Party Scripts

Third-party scripts remain the single largest contributor to poor INP scores. A chat widget, an analytics provider, or a personalization engine that executes JavaScript on the main thread will delay the browser's ability to respond to user interactions.

The Mitigation: Load third-party scripts with async or defer. Use resource hints (preconnect, dns-prefetch) to reduce negotiation latency. Consider self-hosting critical third-party resources. Audit the business necessity of each third-party script. The marketing team will claim every script is essential. This is rarely accurate.

Diagnostic Methodology

1. Field Data vs. Lab Data

Lab data (Lighthouse, PageSpeed Insights simulated throttling) is useful for debugging but does not reflect actual user conditions. Field data (Chrome User Experience Report, Real User Monitoring) reflects actual INP performance for real users on real devices.

Prioritize field data. If your lab data is good but your field data is poor, your users are experiencing conditions that your testing environment does not replicate. Identify the gap. Common causes include slow devices, congested networks, and third-party script variability.

2. Interaction Attribution

The INP diagnostic tools in Chrome DevTools can attribute interaction latency to specific event handlers, rendering work, or presentation delays. Expand the "Total" column. Examine the breakdown between input delay, processing time, and presentation delay.

Input delay indicates that the main thread was busy when the user interacted. Processing time indicates that your event handler executed slowly. Presentation delay indicates that the browser was slow to paint the visual feedback.

3. Long Tasks

The Long Tasks API identifies JavaScript execution blocks exceeding 50 milliseconds. Each long task represents a period during which the main thread cannot respond to user interactions.

Audit your long tasks. Are they caused by your application code? Third-party scripts? Garbage collection? Break up long tasks with setTimeout, scheduler.yield, or requestIdleCallback. The goal is not to eliminate all long tasks. It is to prevent long tasks from occurring during anticipated user interactions.

The 2026 Toolkit

1. Event Listener Optimization

Debounce and throttle are necessary for high-frequency events (scroll, resize, mousemove). They are not necessary for click events, which occur at human speed. Do not debounce clicks unless you are preventing double-submission.

2. Layout Thrashing Prevention

Read operations (accessing offsetHeight, getComputedStyle) force layout recalculation if performed after write operations (modifying style properties). Batch your read operations. Separate reads from writes. This has been best practice since 2012. It remains widely ignored.

3. Off-Main-Thread Processing

Web Workers execute JavaScript on a separate thread, isolated from the main thread and its interaction responsibilities. Offload expensive data processing, encryption, and parsing operations to workers.

The Comlink library simplifies worker communication by wrapping the postMessage API in a Promise-based interface. Use it.

The Threshold Reality

The 100 millisecond threshold is difficult. It requires discipline, measurement, and ongoing vigilance. It is not impossible.

Your competitors are likely ignoring INP. The correlation between Core Web Vitals and search ranking is real but not decisive. You can achieve good rankings with poor INP if your content is sufficiently authoritative.

But the user experience cost is real and independent of Google's ranking algorithm. Users perceive interactions that exceed 100 milliseconds as "slow." They perceive interactions that exceed 300 milliseconds as "broken." The metric reflects human perceptual limits, not arbitrary Google requirements.

Optimize for the users. The ranking improvement is a side effect.