Glossary

Interaction to Next Paint (INP): Complete Technical Guide & Optimization Standard

Comprehensive technical guide to Interaction to Next Paint (INP), main-thread responsiveness, event timing APIs, Core Web Vitals thresholds, and optimization strategies.
Reviewed on 2026-07-25

Interaction to Next Paint (INP) is an official Google Core Web Vital metric introduced to assess the overall interface responsiveness of web pages.

Unlike First Input Delay (FID), which evaluated only the initial interaction on page load, INP observes the latency of all user interactions (clicks, taps, and keyboard inputs) that occur throughout the entire lifespan of a user's visit to a page.

Answer-First Summary

Interaction to Next Paint (INP) is a Core Web Vital metric that measures the time elapsed from when a user interacts with a page (clicking, tapping, or pressing a key) until the browser presents the updated visual frame to the screen. INP latency consists of three sub-parts: Input Delay, Processing Duration, and Presentation Delay. A passing INP score is 200 milliseconds or less at the 75th percentile of real-user visits. In March 2024, INP officially replaced First Input Delay (FID) in Google's search ranking algorithms.

INP Score Thresholds & Rating Scale

To provide a responsive user experience, web pages must meet the following Core Web Vitals thresholds for INP evaluated at the 75th percentile of real-user field visits:

  • Good: $\le 200\text{ms}$ (Green) - Fast, fluid UI response that feels instantaneous to users.
  • Needs Improvement: $> 200\text{ms}$ and $\le 500\text{ms}$ (Amber) - Noticeable delay during clicks or taps that impacts user engagement.
  • Poor: $> 500\text{ms}$ (Red) - Severe interface freezing and main-thread blocking that leads to user frustration and high bounce rates.
INP LatencyPerformance RatingUser Experience ImpactGoogle Search Ranking Status
$\le 200\text{ms}$GoodInstant visual feedback upon tap or click.Full passing grade for Core Web Vitals assessment.
$201\text{ms} - 500\text{ms}$Needs ImprovementLaggy interactions; noticeable delay updating UI state.May experience ranking penalties on competitive keywords.
$> 500\text{ms}$PoorUnresponsive buttons, frozen UI, and main-thread deadlocks.Fails Core Web Vitals assessment; active ranking penalty.

The Three Components of INP Interaction Latency

When a user interacts with an element on a web page, the total interaction latency measured by INP consists of three sequential phases:

  1. Input Delay: The time elapsed between when the user initiates the physical interaction (click, tap, or key press) and when the browser's main thread begins executing the associated event handlers. Input delay is primarily caused by main-thread congestion from long background JavaScript tasks running during page load or component re-renders.
  2. Processing Duration: The time spent executing the JavaScript code within all registered event listeners for that interaction (such as onclick, onkeydown, or framework reactive state update handlers).
  3. Presentation Delay: The time elapsed after event handlers complete until the browser finishes calculating style recalculation, layout, painting updated pixels, and displaying the next visual frame on the user's display hardware.

Mathematically, total INP latency for a single interaction is expressed as:

$$\text{INP Latency} = \text{Input Delay} + \text{Processing Duration} + \text{Presentation Delay}$$

Why Google Replaced FID with INP in March 2024

First Input Delay (FID) measured only the input delay component of the very first interaction on a page. While FID helped identify pages where main-thread blocking prevented initial interaction, it suffered from two major technical limitations:

  • Single Interaction Scope: FID ignored all subsequent user interactions after page load, failing to capture sluggishness during complex single-page application (SPA) client-side navigation.
  • Incomplete Latency Measurement: FID measured only input delay, ignoring processing time and presentation delay entirely. An event handler that took 2,000ms to execute received a passing FID score if the initial input delay was under 50ms.

In March 2024, Google officially replaced FID with INP as an official Core Web Vital ranking factor. INP evaluates the 75th percentile of all interactions during a session, providing a far more comprehensive and realistic assessment of real-user experience across modern web applications.

Qualifying User Interactions vs Non-Qualifying Events

INP measures discrete user interactions where the user expects immediate visual feedback. Understanding which interactions count toward INP is essential for diagnostic profiling:

Measured Interactions

  • Mouse Clicks: Clicking on buttons, links, form controls, or custom interactive components.
  • Touchscreen Taps: Tapping elements on mobile devices or tablets.
  • Keyboard Press: Pressing physical or virtual keyboard keys (such as Enter, Space, or alphanumeric keys in text inputs).

Non-Measured Events

  • Scrolling & Panning: Scrolling a page or panning a map component does not trigger INP measurement.
  • Hovering: Moving the mouse cursor over an element without clicking is excluded from INP.
  • Page Load Animations: CSS animations that trigger automatically without user input do not count toward INP.

Proven Technical Strategies to Optimize High INP Scores

To reduce INP latency below the 200ms threshold, engineering teams should implement the following technical optimizations:

  1. Break Up Long Main-Thread Tasks: Use requestIdleCallback(), setTimeout(), or scheduler.yield() to break execution tasks longer than 50ms into smaller chunks, allowing the browser to process incoming user inputs immediately between task execution blocks.
  2. Optimize Framework State Updates: In Vue 3 and Nuxt 4 applications, defer non-critical UI re-renders using async component boundaries or deferred reactive ref updates.
  3. Minimize Layout Thrashing: Avoid reading DOM geometry properties (such as offsetHeight or getBoundingClientRect()) immediately after mutating DOM elements, which forces synchronous layout recalculation.
  4. Reduce DOM Tree Depth: Oversized DOM trees increase style calculation and layout cost during presentation delay. Keep total DOM element counts below 1,500 nodes per page.
  5. Optimize Third-Party Scripts: Heavy third-party scripts (analytics, ad networks, customer chat widgets) frequently hijack the main thread. Defer or web-worker offload non-essential third-party scripts.

Continuous INP Monitoring with SimpleOps

SimpleOps continuously tracks INP performance by capturing Chrome UX Report (CrUX) real-user field dataset metrics alongside synthetic Lighthouse audits. SimpleOps automatically alerts your team whenever your website's 75th percentile INP exceeds 200ms, ensuring your application remains fast, fluid, and optimized for search engine rankings.

Frequently Asked Questions

Common questions about this topic

24/7 Automated Website Monitoring

Ensure Your Website Stays Fast & Operational

SimpleOps continuously monitors uptime, SSL security certificates, API endpoints, and Core Web Vitals every 60 seconds from 15+ global check regions.