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.
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.
What the trend is telling us:
- 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.
Sibling cards merchants should reference together
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.
Cross-connector reconciliation: primarily internal (with
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.