Interaction to Next Paint (INP) · Definition & Explanation 2026

Interaction to Next Paint (INP) is a Core Web Vitals metric that assesses a page's overall responsiveness by observing the latency of all click, tap, and keyboard interactions throughout a user's visit. The final INP value is the longest interaction observed (or the 98th percentile for pages with 50+ interactions).

INP measures the full interaction lifecycle in three components:

• •Input Delay — Time the interaction waits in a queue because the main thread is busy (e.g., executing a long JavaScript task). This is what FID used to measure.
• •Processing Time — Time spent executing the event handlers (onclick, onkeydown, etc.) associated with the interaction.
• •Presentation Delay — Time for the browser to recalculate styles, perform layout, paint, and composite the visual update after event handlers complete.

The total of these three components is the interaction latency. A 'good' INP is ≤ 200ms — meaning the user sees a visual response within 200 milliseconds of every interaction.

INP replaced FID because FID had critical blind spots: it only measured the first interaction and only measured input delay (ignoring processing and presentation). A page could pass FID easily (fast first click) while having terrible responsiveness for subsequent interactions. INP eliminates these blind spots entirely.

INP was developed by the Chrome Web Vitals team to address the well-known limitations of First Input Delay (FID).

Key milestones:

• •May 2022 — INP introduced as an experimental metric, available in CrUX and the Web Vitals library.
• •February 2023 — INP promoted to 'pending' Core Web Vital status, signaling it would replace FID.
• •March 2024 — INP officially replaces FID as a stable Core Web Vital. FID is retired from all CWV reports.
• •2025–2026 — The 200ms threshold remains unchanged. No tightening has been announced.

The transition was impactful because many sites that easily passed FID began failing INP. FID had a pass rate of ~93% (most sites had a fast first click), but INP pass rates dropped to ~65% — revealing widespread responsiveness issues that FID had been hiding.

INP observes all click, tap, and keyboard interactions during a page visit. For each interaction, the browser measures total latency from input to the next painted frame (input delay + processing + presentation delay). The reported INP is the worst interaction (or 98th percentile for pages with 50+ interactions).

Field Data:

• •CrUX / PageSpeed Insights — Real-user INP at p75
• •Google Search Console — CWV report
• •Web Vitals JS library — Custom RUM collection

Lab Data:

• •Chrome DevTools Performance panel — Interaction traces showing all three components
• •Lighthouse TBT (proxy) — TBT correlates strongly with INP
• •Web Vitals Extension — Real-time INP as you interact

Important: INP requires real user interaction to measure. Lighthouse cannot directly measure INP — it uses TBT as a lab proxy. For accurate INP debugging, use Chrome DevTools Performance panel while manually interacting with the page.

Input Delay (main thread blocked):

• •Long JavaScript tasks (> 50ms) from framework rendering, third-party scripts, or heavy computation.
• •Multiple scripts competing for the main thread during/after page load.

Processing Time (slow event handlers):

• •Expensive DOM manipulation in click/input handlers.
• •Synchronous API calls or heavy computation in event handlers.
• •Large React/Vue/Angular component re-renders triggered by state changes.
• •Layout thrashing — reading and writing DOM properties in alternation.

Presentation Delay (slow rendering):

• •Excessive DOM size (> 1,500 nodes) causing slow style recalculation.
• •Complex CSS selectors requiring expensive matching.
• •Forced synchronous layouts triggered by JavaScript.
• •Large paint areas without CSS containment.