INP: Google's New Metric for Web Interactivity 2026

The metric nobody was measuring until March 2024

For years, the SEO community obsessed over LCP and CLS as the most ranking-relevant Core Web Vitals metrics. FID (First Input Delay) existed as the third metric, but it rarely caused problems: it only measured the delay between the user’s first interaction and the start of its processing, and most pages passed it effortlessly. All it took was for the main thread not to be completely blocked at the moment of the first click.

In March 2024, Google removed FID and replaced it with INP (Interaction to Next Paint). The change was not cosmetic. INP measures something fundamentally different: the complete latency of all user interactions throughout the entire life of the page, not just the first one. And the result was revealing: according to Web Almanac data from HTTPArchive published in 2025, 27% of websites that passed the FID threshold now fail INP. Nearly three out of ten sites that believed they had good interactivity discovered they did not.

What makes INP relevant for SEO is its weight as a ranking signal. Google integrated it into Core Web Vitals with equal importance to LCP and CLS. Pages with an INP above 500ms are classified as poor in Google Search Console, and the field data Google uses to evaluate this factor comes from Chrome UX Report, which collects the 98th percentile of all real interactions over the past 28 days. There is no room to ignore this metric.

What INP is and why it replaced FID

Interaction to Next Paint measures a web page’s responsiveness by quantifying how much time passes from when the user interacts — a click, a tap, a key press — until the browser paints the resulting visual update. This complete cycle includes three phases:

Input delay

The time elapsed between the user interaction and when the browser begins executing the associated event handlers. If the main thread is busy executing JavaScript, the interaction queues until the thread becomes free. This was the only phase that FID measured.

Processing time

The time the event handlers (JavaScript callbacks) take to execute. A click event handler that runs a complex function — filtering a list, validating a form, recalculating a layout — can take hundreds of milliseconds if the code is not optimized.

Presentation delay

The time from when the event handlers finish until the browser completes the next visual frame (paint). This includes style recalculation, layout, compositing, and paint time. If the event handlers extensively modify the DOM or styles, this phase can be the most expensive.

FID only measured the first phase of the first interaction. INP measures all three phases of all interactions and reports the 98th percentile as the final value. This means that a single extremely slow interaction during the entire session is enough to degrade the INP score.

Google made the decision to replace FID with INP because field data showed that FID did not reflect the actual user experience. A site could have an excellent FID — the main thread happened to be free when the user made their first click — but deliver a terrible experience on subsequent interactions: buttons taking 400ms to respond, forms freezing during validation, filters blocking the browser for half a second.

How INP measures interactivity: the complete cycle

To understand how to optimize INP, it is necessary to comprehend the complete processing cycle of a browser interaction.

When a user clicks a button, the sequence is as follows:

1. The browser registers the event and adds it to the main thread queue. If the main thread is free, it begins processing immediately. If it is executing a JavaScript long task (> 50ms), the event waits until the current task finishes. This waiting time is the input delay.

2. Event handlers execute. All JavaScript associated with the event (click, pointerdown, keydown listeners, etc.) runs sequentially on the main thread. If multiple handlers are registered for the same event, they execute in order. The total execution time is the processing time.

3. The browser recalculates styles, runs layout, and paints. If the event handlers modified the DOM or CSS styles, the browser must recalculate all affected layout, composite the visual layers, and paint the updated pixels. This process is the presentation delay.

4. The next visual frame appears on screen. The total time from step 1 to step 4 is what INP measures for each interaction.

A relevant technical detail: the browser operates at 60fps (frames per second) when everything runs smoothly, which means one frame every 16.7ms. If the complete processing of an interaction fits within a single frame, the response feels instantaneous to the user. When processing exceeds 200ms — Google’s INP threshold — the user perceives a noticeable delay.

The Long Animation Frames API (LoAF), available in Chrome since version 123, enables precise measurement of what happens during each prolonged frame. It provides granular data about which scripts are executing, how long each takes, and where the bottleneck occurs. This API replaces the Long Tasks API for INP diagnosis because it reports not only the duration but also the chain of scripts responsible for the delay.

INP thresholds: good, needs improvement, and poor

Google defines three ranges for INP:

• Good: below 200ms. The interaction is perceived as instantaneous or near-instantaneous. According to CrUX data from 2025, 63% of web origins achieve this threshold on mobile.

• Needs improvement: between 200ms and 500ms. The user perceives a noticeable delay but not long enough to abandon the interaction. 21% of origins fall within this range.

• Poor: above 500ms. The interaction is perceived as blocked or frozen. The user may attempt to click repeatedly or abandon the page entirely. 16% of origins have a poor INP.

One aspect that distinguishes INP from the other Core Web Vitals metrics is that it uses the 98th percentile instead of the 75th for evaluation. This has a significant practical implication: if a page receives 100 interactions during a session, the reported INP will be the second-worst interaction. This high percentile was deliberately chosen by Google to capture the worst representative experience without being distorted by extreme outliers.

INP’s ranking impact is measured at the origin (domain) level, not at the individual URL level. Google aggregates field data from all pages on a domain to calculate the overall INP. This means that a few pages with very slow forms or filters can degrade the INP of the entire domain, even if the rest of the pages are fast.

Diagnosis: how to identify slow interactions

Diagnosing INP problems requires tools that identify which specific interactions are slow and what is causing the delay in each phase of the cycle.

Chrome DevTools — Performance tab. Record a session in which you interact with the problematic elements on the page: button clicks, filter interactions, form typing. In the recording, look for interactions marked with a red or yellow indicator in the “Interactions” section. Each interaction shows the input delay, processing time, and presentation delay broken down. Orange blocks on the timeline are long tasks that are potentially causing input delay.

Long Animation Frames API (LoAF). In the Chrome console, the code performance.getEntriesByType('long-animation-frame') returns all frames that exceeded 50ms, including the specific scripts that ran during each frame. For INP diagnosis, filter frames that coincide temporally with problematic interactions. This API identifies not only the script but the specific function and the line of code responsible for the delay.

Web Vitals Chrome Extension. Shows INP in real time and highlights the interaction that is determining the current value. Hovering over the INP indicator reveals which element was interacted with and the time breakdown.

PageSpeed Insights and CrUX. Provide the field INP — the real 98th percentile from the last 28 days — which is the value Google uses for ranking. Lab INP is useful for diagnosis but may not match field data if real users’ interaction patterns differ from what the developer simulates.

Google Search Console. The Core Web Vitals report in Search Console classifies domain URLs by their INP status (“Good,” “Needs Improvement,” “Poor”) and groups URLs with similar patterns, enabling identification of templates or page types sharing a common problem.

The most common causes of high INP

The causes of high INP group into three categories directly related to the three phases of the interaction cycle:

Long tasks on the main thread (input delay)

Any JavaScript task lasting more than 50ms blocks the main thread and delays interaction processing. The most frequent sources of long tasks are: analytics scripts (Google Analytics, Hotjar, Mixpanel) that process data synchronously, advertising scripts that evaluate bidding and load creatives, polyfills or JavaScript transpilations that execute unnecessary code in modern browsers, and JavaScript frameworks performing heavy hydration during page load.

According to Web Almanac 2025 data, third-party JavaScript is responsible for 65% of long tasks on commercial sites. A single misconfigured analytics script can add 100 to 300ms of main thread blocking, degrading the input delay of any interaction that occurs during its execution.

Slow event handlers (processing time)

JavaScript callbacks executing in response to an interaction can be expensive for multiple reasons: extensive DOM manipulation (inserting, removing, or reorganizing hundreds of nodes), computationally heavy logic running on the main thread (sorting, filtering, complex form validation), synchronous calls to APIs or localStorage, and forced layout recalculation by reading properties like offsetHeight or getBoundingClientRect() after modifying the DOM.

Expensive visual updates (presentation delay)

When event handlers extensively modify the DOM or CSS styles, the browser must execute style recalculation, layout, compositing, and paint before displaying the next frame. The most expensive operations are: modifying properties that force relayout (width, height, top, left, font-size), adding or removing elements from the document flow, and changing CSS classes that affect many DOM elements.

Optimization techniques: long tasks, event handlers, and web workers

INP optimization is structured in three levels corresponding to the three phases of the interaction cycle:

Level 1: Eliminate or reduce long tasks (input delay)

The most effective technique is breaking long tasks into sub-50ms blocks that allow the browser to process interactions between blocks. Modern options include:

• scheduler.yield() (available in Chrome 129+): allows the browser to pause script execution to process pending events and resume afterward. It is the cleanest API for splitting long tasks.
• scheduler.postTask(): schedules tasks with priority (user-blocking, user-visible, background), ensuring user interactions always take precedence over background work.
• requestIdleCallback(): delegates work to moments when the browser is idle, ideal for non-urgent tasks like data pre-loading or analytics.

For third-party scripts that cause long tasks but cannot be modified, the solution is loading them with defer or async, or moving them to a Web Worker. A Web Worker executes JavaScript on a separate thread that does not block the main thread, eliminating its impact on input delay.

Level 2: Optimize event handlers (processing time)

Key techniques include:

• Debounce and throttle: for interactions that fire repeatedly (scroll, input, resize), limiting handler execution frequency prevents redundant processing. A search input with 150ms debounce executes the filter function only when the user stops typing, rather than on every keystroke.
• List virtualization: for interfaces displaying hundreds of elements, rendering only those visible in the viewport and recycling DOM nodes reduces processing time from O(n) to O(1). Libraries like react-window or @tanstack/virtual implement this pattern.
• Offload to Web Workers: any computationally heavy logic — sorting, data processing, image transformation — can run in a Worker without blocking the main thread. The event handler sends data to the Worker via postMessage() and receives the result back.

Level 3: Reduce visual cost (presentation delay)

Techniques for minimizing the impact of DOM changes:

• Use transform and opacity instead of relayout-forcing properties for animations triggered by interactions.
• Batch DOM modifications so the browser executes a single layout cycle instead of multiple ones.
• Use content-visibility: auto on off-viewport sections so the browser does not recalculate their layout during interactions.
• Avoid forcing synchronous layout by reading layout properties after writing to the DOM within the same frame.

The combination of these three optimization layers can reduce a site’s INP from 500ms to below 150ms without altering visible functionality. According to data published by web.dev in 2025, sites that implemented scheduler.yield() to split their main long tasks reported INP improvements of 40 to 60% in field data.

Web performance and interactivity share the same root causes: a main thread overloaded with JavaScript delays both the initial load (LCP) and the response to interactions (INP). Optimizing one metric typically improves the other, making main thread performance the single most determinant technical factor across all three Core Web Vitals.