At a glance
Per-URL ranking of pages whose performance regressed most vs the prior 7-day baseline. Surfaces URLs that suddenly got slower across any CWV (LCP, INP, CLS) or composite Performance Score. The “what just broke?” view: when a deploy, a content change, a third-party update, or an upstream issue degrades performance, this card surfaces which pages were affected and how badly. Critical for incident-response after a deploy and for catching subtle ongoing regressions.
| What it counts | List of URLs ranked by absolute regression magnitude across the four key metrics: LCP delta (ms), INP delta (ms), CLS delta (score points), Performance Score delta (points). Calculated as current_value - 7day_baseline_value; positive deltas for LCP/INP/CLS = worse, positive delta for score = better, so regressions are negative score / positive timing. |
| Sample type | Lab data (per-URL Lighthouse audits compared run-to-run). Field data trends available in crux_regression_timeline. |
| What “regression” means | A statistically meaningful change beyond run-to-run variance. Lighthouse run-to-run variance is typically ±10 percent for LCP, ±15 percent for INP, ±5 percent for score. Vortex IQ flags as regression: changes exceeding 2x typical variance (so >20 percent LCP, >30 percent INP, >10 points score). Smaller changes are noise; larger changes are signal. |
| Common regression causes | (1) Deploy with new render-blocking resources (theme update, new third-party tag). (2) Content change: marketer uploaded an unoptimised hero image. (3) Third-party update: a vendor pushed a new version of their script that’s heavier. (4) CDN configuration change: cache miss rate increased. (5) Backend slowness: TTFB regression cascading to LCP. (6) Auto-applied recommendations in marketing tools changing tag behaviour. |
| Why this card matters for ops | Performance regressions often go undetected until a customer complains weeks later. The card surfaces them within the first audit run after the regression. For BC stores deploying frequently, daily monitoring of this card catches deploy-induced regressions before they cause meaningful traffic loss. |
| Currency | n/a, list with delta values per metric. |
| Time window | T vs 7D baseline (current vs 7-day rolling baseline). |
| Alert trigger | top regression > 1500ms LCP delta OR top regression > 15 score points. |
| Sentiment key | null (multi-metric card). |
| Roles | owner, 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 UK-based BigCommerce fashion store, 30-URL audit comparing Wednesday 15 May 26 vs 7-day baseline ending 08 May 26.| Rank | URL | LCP delta | INP delta | CLS delta | Score delta | Probable cause |
|---|---|---|---|---|---|---|
| 1 | /products/spring-floral-maxi-dress | +1,840ms | +60ms | +0.04 | -18 | New hero image uploaded 14 May at 2.4MB unoptimised |
| 2 | / (homepage) | +680ms | +20ms | +0.02 | -8 | Deploy 14 May: new Klaviyo popup CSS render-blocking |
| 3 | /products/leather-tote-bag | +540ms | +0ms | +0.00 | -6 | Same hero-image upload pattern as rank 1 |
| 4 | /collections/new-arrivals | +320ms | +180ms | +0.06 | -8 | Filter widget update introduced layout shift + slower interaction |
| 5 | /checkout | +0ms | +120ms | +0.00 | -3 | Stripe.js version bump, slightly heavier |
| 6 | /cart | +0ms | +60ms | +0.00 | -2 | Same Stripe.js bump |
| 7 | /products/silk-scarf-print | +0ms | +0ms | +0.00 | -1 | No regression (within variance) |
| … | (24 more URLs, no significant regression) |
- Two distinct regression events triggered by activity on 14 May 26. Rank 1 and rank 3 share a pattern: hero product images uploaded as 2.4MB unoptimised PNGs by the merchant’s content team. Rank 2, 4, 5, 6 all trace to a deploy on the same day that updated Klaviyo, the filter widget, and Stripe.js.
- Rank 1 is the most actionable single fix. The Spring Floral Maxi Dress PDP regressed 1,840ms LCP and lost 18 points of Performance Score because someone uploaded a 2.4MB hero image. Direct fix: re-export the image at WebP quality 80 with responsive variants. 30-minute task; immediate restoration of pre-regression performance.
-
Rank 2 (homepage) regression came from the deploy. The new Klaviyo popup CSS landed in
<head>as a render-blocking external stylesheet. Fix: defer the popup CSS load to post-paint (covered inpsi_render_blockingplaybook). Estimated post-fix: homepage returns to within ±100ms of baseline LCP. - Rank 4 (collection page) had two independent regressions in one deploy: the filter widget update introduced a layout-shift bug AND increased interaction cost. Two-part fix: (a) reserve fixed-pixel container for filter widget to eliminate CLS regression; (b) review filter widget JS for the new long task and apply yield-to-main-thread pattern.
- Rank 5 and 6 (checkout, cart) regressions are minor (60-120ms INP delta, 2-3 score points). Stripe.js version bumps occasionally introduce performance changes; the magnitude here is below the “fix immediately” threshold but worth monitoring. If sustained, file with Stripe and request comment.
- Ranks 7+ are within run-to-run variance and not real regressions. Don’t chase them.
-
Recommended response sequence:
- Immediate (today): Have content team re-export the unoptimised hero image. Request stricter upload-time policy (cap source images at 2MB).
- Today/tomorrow: Engineering rolls back the render-blocking Klaviyo CSS or wraps it with deferred-load. Audit the filter widget for the new layout-shift behaviour.
- This week: Monitor Stripe.js regression for sustained pattern.
- Identify the date of regression. Cross-reference with deploy log + content-management activity.
- Categorise by cause type: deploy / content / third-party / infrastructure.
- Apply the right fix per cause:
- Deploy regression: roll back the specific change OR fix-forward with deploy-time check.
- Content regression: instruct content team; consider stricter upload policies.
- Third-party regression: defer, downgrade, or replace the third party.
- Infrastructure regression: investigate CDN, server, or DNS issues.
- Re-audit after each fix to confirm regression closed.
| Time horizon | Action |
|---|---|
| First 1 hour | Identify the worst single regression; categorise the cause. |
| First 4 hours | Fix or roll back the cause. |
| First 24 hours | Re-audit. Confirm regression closed. |
| First 7 days | Implement deploy-time guardrails to prevent future regressions of the same type. |
Sibling cards merchants should reference together
| Card | Why merchants reach for it |
|---|---|
crux_regression_timeline | Field-data regression timeline; reveals sustained vs transient regressions. |
psi_slowest_lcp_urls | Per-URL LCP ranking; pairs to identify if the regression made an already-slow URL worse. |
psi_worst_cls_urls | Per-URL CLS ranking. |
psi_worst_inp_urls | Per-URL INP ranking. |
psi_score_trend | Performance score trend; surfaces gradual regressions the per-URL view may miss. |
crux_lcp_trend | Origin-level LCP trend. |
crux_inp_trend | Origin-level INP trend. |
crux_cls_trend | Origin-level CLS trend. |
psi_third_party_cost | Third-party scripts often cause regression on auto-update. |
psi_image_optimisation | Content uploads are a common regression source; image opportunity surfaces them. |
psi_perf_score_summary | Composite score; large regressions show here first. |
Reconciling against the vendor’s own dashboard
Where to look:- Lighthouse CI, runs Lighthouse in your build pipeline; can fail builds on regression.
- PageSpeed Insights, single-snapshot view; doesn’t show regression directly but useful for re-confirming the post-fix state.
- Internal deployment log, cross-reference deploy timestamps with regression detection times.
| Reason | Direction | What to do |
|---|---|---|
| Detection threshold. Vortex IQ flags regressions exceeding 2x typical variance; manual checks may notice smaller regressions sooner. | Vortex IQ may miss sub-threshold regressions | Lower the threshold for sensitive pages (configurable per integration). |
| Audit cadence. Vortex IQ audits daily by default; deploys mid-day appear at next audit. | Up to 24 hours of regression before detection | Increase audit frequency for high-deploy-velocity sites. |
| Run-to-run variance. A single anomalous audit run can falsely flag regression. | Either direction | The 7-day baseline smooths this; single-run anomalies fall below the variance threshold. |
crux_regression_timeline, psi_score_trend, and the per-CWV trend cards).
Quick rule for support tickets: if a merchant says “a deploy went out today but Vortex IQ doesn’t show any regression yet”, the most common cause is audit cadence, the next-scheduled audit hasn’t run yet. Manually trigger an audit run, or wait for the next scheduled run.
Known limitations / merchant FAQs
A regression appeared but I don’t know what changed. What do I do? Cross-reference the regression timestamp with: (a) deploy log, (b) content management system audit log (image uploads, copy changes), (c) third-party tool dashboards (recent updates), (d) infrastructure team’s change log. Most regressions trace to one of these four sources; if none match, investigate cache states and CDN configuration. The regression card flagged something but PSI shows the page is fine. Why? Three possibilities. (1) Run-to-run variance: Lighthouse occasionally produces anomalous runs; a single bad audit can trigger a false regression flag. The 7-day baseline smooths this but doesn’t eliminate edge cases. (2) Refresh timing: PSI is real-time; Vortex IQ’s audit might be from earlier, before the actual regression occurred OR before the fix landed. (3) URL set differences: Vortex IQ’s audit URL list may differ from the URL pasted into PSI. My deploy contained 5 changes. How do I know which caused the regression? Bisect. Roll back changes one at a time and re-audit. Modern deploy systems support feature flags or partial rollback; use them. Avoid bisecting in production: deploy the rollback to a staging environment and audit there if possible. Should I block deploys that cause regressions? For high-traffic high-revenue sites, yes. Lighthouse CI can fail builds when LCP regresses by more than X ms or score drops by more than Y points. The thresholds are configurable; start permissive (block on >30 percent regression) and tighten over time as the team adapts. Can Vortex IQ roll back my deploy automatically? Read-only by design. Vortex IQ surfaces the regression and recommends investigation; the merchant’s developers or operations team execute the rollback. What if the regression is from a third-party update I can’t control? Three options. (1) Defer the third party more aggressively (move from<head> to post-load). (2) Switch to a self-hosted version of the script if available. (3) Remove the third party and replace its functionality with a faster alternative. The right choice depends on the third-party’s commercial value.
Why does the homepage regression appear smaller than the PDP regression?
Different baselines. The PDP’s hero image change introduced a 2.4MB unoptimised file (large absolute change). The homepage Klaviyo CSS change is render-blocking but smaller bytes. Both are real regressions; the magnitude differs by cause type.