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