> ## Documentation Index > Fetch the complete documentation index at: https://docs.vortexiq.ai/llms.txt > Use this file to discover all available pages before exploring further. # Biggest Regression, Website Performance (PageSpeed + CrUX) > Biggest Regression for Website Performance (PageSpeed + CrUX) stores. Tracked live in Vortex IQ Nerve Centre. How to read it, why it matters, and how to ac... **Metrics type:** [Supporting Metrics](/nerve-centre/overview#metrics-types-explained) • **Category:** [Website Performance](/nerve-centre/connectors#connectors-by-type) ## 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`](/nerve-centre/kpi-cards/website-performance/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) | | | | | | What the regression list is telling us: 1. **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. 2. **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. 3. **Rank 2 (homepage) regression came from the deploy.** The new Klaviyo popup CSS landed in `` as a render-blocking external stylesheet. **Fix**: defer the popup CSS load to post-paint (covered in [`psi_render_blocking`](/nerve-centre/kpi-cards/website-performance/render-blocking-resources) playbook). Estimated post-fix: homepage returns to within ±100ms of baseline LCP. 4. **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. 5. **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. 6. **Ranks 7+ are within run-to-run variance** and not real regressions. Don't chase them. 7. **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. The diagnostic flow when a regression appears: 1. **Identify the date of regression.** Cross-reference with deploy log + content-management activity. 2. **Categorise by cause type**: deploy / content / third-party / infrastructure. 3. **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. 4. **Re-audit after each fix** to confirm regression closed. Rapid-response playbook: | 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`](/nerve-centre/kpi-cards/website-performance/crux-regression-timeline) | Field-data regression timeline; reveals sustained vs transient regressions. | | [`psi_slowest_lcp_urls`](/nerve-centre/kpi-cards/website-performance/slowest-lcp-urls) | Per-URL LCP ranking; pairs to identify if the regression made an already-slow URL worse. | | [`psi_worst_cls_urls`](/nerve-centre/kpi-cards/website-performance/worst-cls-urls) | Per-URL CLS ranking. | | [`psi_worst_inp_urls`](/nerve-centre/kpi-cards/website-performance/worst-inp-urls) | Per-URL INP ranking. | | [`psi_score_trend`](/nerve-centre/kpi-cards/website-performance/performance-score-over-time) | Performance score trend; surfaces gradual regressions the per-URL view may miss. | | [`crux_lcp_trend`](/nerve-centre/kpi-cards/website-performance/load-speed-over-time) | Origin-level LCP trend. | | [`crux_inp_trend`](/nerve-centre/kpi-cards/website-performance/responsiveness-over-time) | Origin-level INP trend. | | [`crux_cls_trend`](/nerve-centre/kpi-cards/website-performance/layout-stability-over-time) | Origin-level CLS trend. | | [`psi_third_party_cost`](/nerve-centre/kpi-cards/website-performance/third-party-cost) | Third-party scripts often cause regression on auto-update. | | [`psi_image_optimisation`](/nerve-centre/kpi-cards/website-performance/image-optimisation) | Content uploads are a common regression source; image opportunity surfaces them. | | [`psi_perf_score_summary`](/nerve-centre/kpi-cards/website-performance/performance-score-summary) | Composite score; large regressions show here first. | ## Reconciling against the vendor's own dashboard **Where to look:** * **[Lighthouse CI](https://github.com/GoogleChrome/lighthouse-ci)**, runs Lighthouse in your build pipeline; can fail builds on regression. * **[PageSpeed Insights](https://pagespeed.web.dev)**, 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. **Why the Vortex IQ regression detection may differ from a manual investigation:** | 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. | **Cross-connector reconciliation:** primarily internal (with [`crux_regression_timeline`](/nerve-centre/kpi-cards/website-performance/crux-regression-timeline), [`psi_score_trend`](/nerve-centre/kpi-cards/website-performance/performance-score-over-time), 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 `` 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. *** ### Tracked live in Vortex IQ Nerve Centre *Biggest Regression* is one of hundreds of KPI pulses Vortex IQ tracks across Website Performance (PageSpeed + CrUX) and 70+ other ecommerce connectors. Nerve Centre runs the detection layer; Vortex Mind investigates the cause when something moves; Ask Viq lets you interrogate any number in plain English. [Start for free](https://app.vortexiq.ai/login) or [book a demo](https://www.vortexiq.ai/contact-us) to see this metric running on your own data.