At a glance
Interaction to Next Paint p75 over time, daily time-series of mobile INP from CrUX. Pairs with crux_inp_p75 snapshot for trend analysis. The most JS-driven of the CWV trends: INP regressions usually trace to specific JavaScript changes (new third-party tag, framework upgrade, widget refactor) rather than gradual content drift. Critical caveat: INP definition changed in March 2024 (replaced FID); year-over-year comparisons across that boundary are not apples-to-apples.
| What it counts | Time-series of interaction_to_next_paint p75 across the rolling 28-day CrUX window. Each daily data point reflects the trailing 28 days of real-user interaction measurements. |
| Sample type | Field data sourced from CrUX. No direct lab-data trend equivalent (lab approximates via psi_lab_tbt). |
| The March 2024 boundary | Pre-March 2024 trend data is FID, not INP. Comparing across the boundary requires acknowledging the methodology change: FID measured first-input delay only, INP measures all interactions. Most sites saw INP “regression” of 100-300ms vs equivalent FID simply because the metric definition changed; this isn’t a real regression. |
| Common INP drift patterns | (1) Step regression on framework upgrades: React 17→18, jQuery version bumps, BC theme updates can introduce new INP hotspots. (2) Step regression on third-party additions: a new chat widget, A/B testing tool, or analytics library that adds main-thread JS. (3) Slow drift from accumulated tags: GTM bloat over months. (4) Cyclical: peak shopping periods often show INP degradation as servers slow + more users on slower devices arrive. |
| Reading the trend | Same pattern as LCP trend: direction (up = bad), slope, inflection points, threshold crossings (200ms = good/needs-improvement boundary). |
| The 28-day rolling smoothing | Same smoothing as LCP: real-world step regressions appear as gradual rises in the trend over 28 days. |
| Why INP regressions often appear weeks after the actual change | Users have to encounter the slow interaction first. New filter widget added today; users need 28 days of real-world filtering on it before the metric stabilises. |
| Sample size threshold | CrUX requires sufficient real-user volume (~1,000+ sessions per 28 days). |
| Currency | n/a, time-series of milliseconds. |
| Time window | 28D rolling × T |
| Alert trigger | current value > 200ms OR 7-day rolling delta > +50ms (regression). |
| Sentiment key | psi_inp |
| Roles | owner, marketing, operations |
Calculation
Calculated automatically from your Website Performance (PageSpeed + CrUX) data. See the At a glance summary above for what the metric tracks and the worked example below for a typical reading.Worked example
A US-based BigCommerce home goods store, mobile INP trend over 6 months ending Wednesday 15 May 26.| Month | INP p75 | Δ vs prior | Notes |
|---|---|---|---|
| Nov 25 | 240ms | (baseline, post-MPP era) | Just over good threshold |
| Dec 25 | 260ms | +20ms | Minor drift |
| Jan 26 | 320ms | +60ms | Klaviyo SDK update added behavior tracking |
| Feb 26 | 380ms | +60ms | Tidio chat widget version bump (heavier mount logic) |
| Mar 26 | 460ms | +80ms | New filter widget on collection pages |
| Apr 26 | 500ms | +40ms | Hotjar session recording added |
| May 26 | 520ms | +20ms | Current state, “poor” band |
| Cumulative drift Nov→May | +280ms (+117%) | 6-month silent regression |
- INP doubled over 6 months. Each individual change felt acceptable in isolation; cumulatively the site is now in the poor band, paying CWV ranking penalty. Same pattern as LCP drift but driven by JS changes rather than content/image changes.
-
Five distinct contributing events identifiable from inflection points:
- Jan 26 Klaviyo SDK update (+60ms): vendor-side update added behavior tracking event listeners
- Feb 26 Tidio version bump (+60ms): heavier chat widget mount logic
- Mar 26 filter widget refactor (+80ms): in-house JS rewrite that introduced new long tasks
- Apr 26 Hotjar addition (+40ms): session recording adds main-thread overhead
- May 26 stabilisation (+20ms): typical month-over-month variance
- Vendor-side updates are the trickiest contribution because the merchant didn’t make a code change. Klaviyo and Tidio pushed new versions; the merchant inherited the regression. Defence: pin third-party script versions where vendors permit; otherwise monitor for vendor-update regressions specifically.
- The filter widget refactor in Mar 26 is the only first-party-controlled change and the largest single contribution (+80ms). Refactor opportunity: the new widget added long tasks that didn’t exist before; a yield-to-main-thread pattern would have prevented the regression.
- Recovery path: (a) defer non-critical third-party scripts (Tidio, Hotjar) to post-load, saves 200-300ms; (b) refactor filter widget with debouncing + virtualisation, saves 100-200ms; (c) audit Klaviyo SDK for unused event listeners, saves 50-100ms. Total recovery: 350-600ms, dropping INP from 520ms toward 200ms target.
- Watch for INP regressions specifically when: (a) deploying framework or theme version bumps; (b) adding new third-party scripts; (c) refactoring interactive widgets (filters, sort, modals); (d) changing main-thread-heavy code paths. INP regressions are JS-driven and trace cleanly to JS changes.
- Identify whether trend shows drift or step regression. Step = single event; drift = cumulative.
- Cross-reference inflection points with deploy log + third-party-vendor announcements.
- Profile current worst-INP interactions (covered in
psi_worst_inp_urls) to validate where time is spent. - Apply yield-to-main-thread + deferral patterns to recover.
| Time horizon | Action |
|---|---|
| First 1 hour | Identify inflection events; map to deploy log + vendor updates. |
| First 7 days | Defer non-critical third-party JS. |
| First 14 days | Refactor heaviest interactive widgets. |
| Day 28 | Trend reflects fixes as 28-day rolling window absorbs. |
Sibling cards merchants should reference together
| Card | Why merchants reach for it |
|---|---|
crux_inp_p75 | Static snapshot. |
crux_lcp_trend | Sister CWV trend. |
crux_cls_trend | Sister CWV trend. |
crux_pass_rate_trend | All-three pass rate trend. |
psi_score_trend | Lab score trend; correlated. |
crux_regression_timeline | Composite regression detection. |
psi_worst_inp_urls | Per-URL INP ranking. |
psi_third_party_cost | Third-party drift commonly drives INP regression. |
psi_unused_js | Unused JS contributes to INP. |
Reconciling against the vendor’s own dashboard
Where to look:- GSC → Core Web Vitals trend, surfaces 90-day INP trend (post-March 2024).
- CrUX BigQuery dataset, historical INP data; FID prior to March 2024.
- Web Vitals Chrome extension, live INP measurement during page interaction.
| Reason | Direction | What to do |
|---|---|---|
| Pre-March 2024 data is FID, not INP. | Different metric basis | Anchor comparisons within the post-March-2024 era. |
| Window timing. | Vortex IQ lags 1-2 days | Wait for refresh. |
| Smoothing. Each daily point is 28-day rolling p75. | Smoothed | Real regressions appear as gradual rises. |
crux_inp_p75, psi_lab_tbt).
Quick rule for support tickets: if a merchant says “INP regressed without me changing anything”, the most common cause is third-party vendor updates pushing heavier scripts. Check Klaviyo, Tidio, Hotjar, and similar vendor changelogs for the date matching the inflection.
Known limitations / merchant FAQs
My INP “regressed” 200ms in March 2024 but I didn’t change anything. What happened? Google replaced FID with INP as the official Core Web Vital in March 2024. Pre-March 2024 data was FID; post-March 2024 is INP. The two metrics are different by design: FID measured the first interaction’s delay; INP measures the longest. Most sites saw a 100-300ms “regression” simply from the metric definition change. My INP keeps drifting up despite my best efforts. Why? Third-party vendor updates often. Klaviyo, Tidio, Optimizely, Hotjar, GTM tags push new versions that ship heavier JS. The merchant inherits the regression without making a code change. Defence: monitor the trend; when an inflection happens, check vendor changelogs for the matching date. Why is INP harder to recover from than LCP? LCP fixes are mostly mechanical (image format, preload). INP fixes require code changes (refactor heavy widgets, defer scripts, yield to main thread). A 6-week INP recovery cycle is typical; LCP recovery often completes in 2-3 weeks. Should I pin third-party script versions? Where vendors permit, yes. Pinning prevents inherited regressions. However: pinning means missing security patches and bug fixes. Best practice: pin major versions; allow patch versions; review monthly for upgrades. Can Vortex IQ alert me on INP drift before it crosses the threshold? Yes; alert at7-day rolling delta > +50ms catches drift early. Earlier signal than waiting for the absolute threshold breach.
How long does INP recovery take to reflect?
28 days for full reflection. Same as LCP, the rolling window is identical.