Interaction to Next Paint (INP)

INP is a stable Core Web Vitals metric that measures a page's responsiveness to user input throughout the full session — not just at load time. It observes the latency of all qualifying interactions (clicks, taps, keystrokes) and reports a single value beneath which all (or nearly all) interactions fell. INP officially replaced First Input Delay (FID) as the responsiveness Core Web Vital on 12 March 2024, because FID only measured the first interaction's input delay, ignoring processing time, presentation delay, and all subsequent interactions.

---

Thresholds (as-of 2025-09-02)

Rating	INP value
Good	≤ 200 ms
Needs improvement	201–500 ms
Poor	> 500 ms

Assessed at the 75th percentile of page loads, segmented across mobile and desktop. (Source: web.dev/articles/inp, updated 2025-09-02)

---

How INP is calculated

Every qualifying interaction has three sub-parts that sum to its total latency:

1. Input delay — time from user action to event callbacks beginning. Caused by long tasks already running on the main thread.
2. Processing duration — time for all event handler callbacks to execute.
3. Presentation delay — time from callbacks finishing to the next frame being painted. Scales non-linearly with DOM size.

For pages with ≥ 50 interactions, one outlier interaction is excluded per 50 interactions (e.g. 100 interactions → 2 ignored), to prevent random spikes from dominating the score. (Source: web.dev/articles/inp, updated 2025-09-02)

Qualifying interactions: mouse clicks, touchscreen taps, key presses. Excluded: scrolling, hovering, zooming.

---

Why INP replaced FID

FID only measured the input delay of the first interaction. It missed: (a) processing time and presentation delay on that interaction; (b) all subsequent interactions across the session. Chrome usage data shows 90% of user time on a page is spent after it loads (as-of 2025-09-02, Source: web.dev/articles/inp) — making first-interaction-only measurement insufficient for real responsiveness.

The INP→FID transition timeline:

• May 2022: INP introduced as experimental metric
• May 2023: announced as future Core Web Vital
• 12 March 2024: INP becomes stable Core Web Vital; FID deprecated
• 9 September 2024: FID support removed from CrUX API and PageSpeed Insights API (Source: web.dev/blog/inp-cwv-launch, 2024-03-12)

---

Population benchmarks (as-of 2024)

• 74% of mobile and 97% of desktop websites passed the ≤200 ms threshold in 2024 (Source: Web Almanac 2024 Performance chapter, Figure 9.20)
• Mobile pass rate has improved year-on-year: 55% (2022) → 64% (2023) → 74% (2024) (Source: Web Almanac 2024, Figure 9.21)
• Top 1,000 most-visited mobile sites pass at only 53% — worse than the average — attributed to heavier JS, more third-party scripts, and richer interactivity (Source: Web Almanac 2024, Figure 9.22)
• Switching from FID to INP reduced the mobile "all three CWVs good" rate from 48% to 43% in 2024 (Source: Web Almanac 2024, Figure 9.1)

Ecommerce platform INP pass rates (as-of 2024)

Platform	Mobile INP good (%)
Magento	49% — worst of major platforms
BigCommerce	67%
WooCommerce	Struggling (below average)
Shopify	Improving year-on-year
Squarespace	60% (up from 33% in 2022)

(Source: Web Almanac 2024 Ecommerce chapter, almanac.httparchive.org/en/2024/ecommerce, published 2024-11-11)

---

Technology stacks hit hardest by FID→INP switch (as-of 2024)

Mobile good-CWV percentage point drop when FID→INP applied:

• 1C-Bitrix: −19 pp
• Next.js: −10 pp (attributed to reliance on client-side rendering despite SSR/SSG availability)
• Emotion (CSS-in-JS): −8 pp
• React, WordPress, Vue.js: −2–5 pp

(Source: Web Almanac 2024, Figure 9.3)

---

INP sub-part analysis (as-of 2024)

From RUMvision real-user data:

• At median: Presentation Delay (36 ms) is the biggest contributor
• At 75th percentile: input delay = 37 ms, processing = 56 ms
• At 90th percentile: input delay jumps to 155 ms and becomes the dominant driver

Median long task duration: 90 ms (desktop), 108 ms (mobile) — both over double the ≤50 ms threshold. At 90th percentile: 331 ms (desktop), 377 ms (mobile). Fewer than 25% of websites achieve optimal sub-50 ms task durations. (Source: Web Almanac 2024, Figure 9.25)

Median Total Blocking Time (lab proxy for INP): 67 ms (desktop), 1,209 ms (mobile) — 6× the good threshold. (Source: Web Almanac 2024, Figure 9.28)

---

Common causes of poor INP in ecommerce

Third-party scripts

The leading cause. Third-party scripts that fire during page load block the main thread at the exact moment users first interact (e.g. clicking "Add to Cart" while scripts are still executing). (Source: web.dev, DebugBear)

By script category, % of mobile pages with good INP (as-of 2024):

• User Behaviour tracking (Hotjar, Smartlook, NewRelic): only 37% good — worst category
• Consent management providers (Cookiebot, CookiePro, Usercentrics): 53% good (vs 76% desktop)
• Advertising scripts: majority poor on both devices
• Performance monitoring tools: least negative impact

(Source: Web Almanac 2024, Figures 9.26–9.27, RUMvision LoAF data)

Large DOM size

Large DOM sizes increase the scope of style calculations and layout work in the presentation delay phase of every interaction. (Source: web.dev/articles/dom-size-and-interactivity)

Long tasks

Any JS task exceeding 50 ms blocks the main thread and increases input delay. Median mobile long task is 108 ms — more than double the threshold. (Source: Web Almanac 2024)

Client-side rendering frameworks

Heavy client-side React/Next.js without SSR/SSG: every state update triggers rerenders on the main thread, increasing processing duration. Batching state updates, memoisation, and switching to SSR/SSG reduce this risk. (Source: developer.chrome.com/docs/aurora/inp-in-frameworks)

Layout thrashing

Writing then reading styles in the same task forces synchronous layout recalculation, causing spikes in processing duration. (Source: web.dev/articles/optimize-inp, 2025-09-02)

---

Optimisation techniques

Technique	What it addresses	Source
Break up long tasks with scheduler.yield()	Input delay	web.dev/articles/optimize-long-tasks
Debounce heavy event handlers	Processing duration + input delay	redBus case study
Reduce state management rerenders	Processing duration	redBus case study, Chrome Aurora docs
Code-splitting with dynamic import()	Input delay at load	web.dev/articles/optimize-long-tasks
Defer non-critical JS	Input delay during load window	web.dev
Move third-party scripts to web worker (e.g. Partytown)	Input delay from third parties	NitroPack
CSS content-visibility	Presentation delay	web.dev/articles/optimize-inp
Reduce DOM size	Presentation delay	web.dev/articles/dom-size-and-interactivity
requestIdleCallback for low-priority work	Input delay	web.dev/articles/optimize-long-tasks

---

Relationship to Long Animation Frames (LoAF)

Long Animation Frames (LoAF) — an update to the Long Tasks API that shipped in Chrome 123 (March 2024) — is the primary tool for diagnosing INP problems:

• LoAF captures the full rendering frame (including rendering work), not just JS tasks
• It links scripts to the specific frame they delayed, attributing blame to first-party or third-party code
• Particularly useful for diagnosing input delay: shows which scripts were executing in the animation frame immediately before the interaction was processed
• Starting with web-vitals library v4, the INP attribution object includes a longAnimationFrameEntries property, allowing RUM tools to attribute poor INP directly to specific scripts (Source: web.dev/articles/find-slow-interactions-in-the-field)

---

Ecommerce case studies

redBus — 7% sales increase from INP optimisation

Indian bus booking site. RUM tracked via web-vitals.js + ELK stack.

Root causes found:

• Scroll event handler with no debouncing → main thread blocked during lazy-load of search results
• Redux reducer called on every keystroke → unnecessary rerenders

Fixes applied:

• Debounce scroll handler; use requestAnimationFrame to prioritise rendering
• Reduce lazy-load batch size 30 → 10 results
• Sync Redux state only on input blur (not every keystroke)

Results: lazy-load INP dropped from 870–900 ms to 350–370 ms. Redux fix alone improved INP 72% on search results page. Outcome: 7% overall increase in sales. (Source: web.dev/case-studies/redbus-inp, published 2023-05-10)

Taboola — up to 36% INP improvement via LoAF

Taboola used LoAF data to identify and fix INP bottlenecks on publisher partner websites, improving INP by up to 36%. (Source: web.dev/case-studies/taboola-inp)

---

Measurement

Tool	Type	Notes
CrUX / PageSpeed Insights	Field (real-user)	Origin- and URL-level; Chrome users only; 75th percentile
web-vitals.js library	Field (real-user)	onINP(callback) — handles back-forward cache, visibilitychange, outlier exclusion
DebugBear, SpeedCurve, RUMvision	RUM (real-user)	Element-level attribution; integrates LoAF for script-level diagnosis
Lighthouse / WebPageTest	Lab	Cannot measure INP (no real interactions); uses TBT as proxy

INP can only be reliably measured with field (real-user) data. Lab tools use Total Blocking Time (TBT) as a proxy, but TBT does not capture actual interaction patterns. (Source: web.dev/articles/inp, 2025-09-02)

The canonical JavaScript implementation:

import {onINP} from 'web-vitals';
onINP(console.log);

(Source: web.dev/articles/inp)

---

Technical underpinning

INP is built on the W3C Event Timing API (W3C Working Draft, version WD-event-timing-20260319, March 2026). The API computes interaction timestamps inside the browser (removing instrumentation overhead) and enables capturing events that occur early in page load — previously hard to instrument. The spec references 100 ms as the threshold below which input handling is considered fast. (Source: W3C Event Timing API spec, w3.org/TR/event-timing/)

---

Key terms

Term	Meaning
Input delay	Time from user action to event callbacks starting — blocked by prior long tasks
Processing duration	Time for event handler callbacks to execute
Presentation delay	Time from callbacks finishing to next frame painted
Long task	Any JS task > 50 ms on the main thread
TBT (Total Blocking Time)	Lab-only proxy for INP; sum of blocking time of long tasks during load
CrUX	Chrome User Experience Report (CrUX) — Chrome's real-user dataset powering PageSpeed Insights
LoAF	Long Animation Frames (LoAF) — Chrome API for diagnosing which scripts caused long frames

---

Next frontier concepts (dangling links)

• Chrome User Experience Report (CrUX)
• Cumulative Layout Shift (CLS)
• Largest Contentful Paint (LCP)
• Synthetic Monitoring
• Value-Based Pricing