At a glance
Composite regression timeline across all CWV trends, surfaces the dates of significant CWV regressions across the LCP / INP / CLS / TTFB / FCP trends in a single chronological view. The “what changed when” diagnostic surface: instead of reading 5 separate trend cards, this card shows every regression event ranked by severity and decorated with the affected metric. Critical for incident-response retrospective: when leadership asks “why did our pass rate drop?”, this card produces the answer in one screen.
| What it counts | Chronological timeline of regression events detected across all CWV trends. Each event includes: date, affected metric (LCP / INP / CLS / TTFB / FCP / score / pass rate), magnitude (delta), severity classification, and inferred cause when correlatable with deploy / content events. |
| Sample type | Field data for CrUX-derived metrics; lab data for score-derived events. The composite uses both data sources to surface a unified timeline. |
| Detection criteria | A regression event is recorded when: (a) field metric moves > +2x typical run-to-run variance over a 7-day rolling window; (b) lab metric moves > 5 points / 200ms / 0.05 within a single audit; (c) threshold crossing: the metric crosses a Google-defined band boundary (e.g. CWV pass rate from above to below 75 percent). |
| Severity classification | Critical: threshold crossing (passing → failing band). High: regression > 30 percent of band width without crossing threshold. Medium: regression > 15 percent without crossing. Low: persistent drift beyond noise but small in magnitude. |
| Inference of cause | When deploy log or CMS audit log is available, the timeline cross-references regression dates with shipped changes. High-confidence inferences (deploy on the same day, single-metric pattern matching the change-type): annotated as “likely cause: X”. Lower-confidence: surfaces candidate events without claiming attribution. |
| Why this card matters | The trio of TTFB + FCP + LCP trends already reveals regression class (server vs render-blocking vs LCP-element). This card aggregates the trio + INP + CLS trends + score trend + pass rate trend into a unified timeline. Saves 10-15 minutes of cross-card cross-referencing per incident-response investigation. |
| The “leadership read” framing | When leadership asks “why is our CWV failing?”, the card produces a 2-3 line answer: “Three regressions in the last 6 months: Feb 26 hero carousel deploy (+460ms LCP), Mar 26 marketing-stack expansion (+660ms LCP, +60ms INP), Apr 26 BFCM imagery (+580ms LCP, +0.02 CLS). Recovery requires reversing each contribution; estimated 6-week cycle.” |
| Currency | n/a, timeline view. |
| Time window | T-180D rolling timeline (default 6-month look-back). |
| Alert trigger | New critical-severity event detected (threshold crossing). |
| Sentiment key | null (composite view). |
| 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, regression timeline over 6 months ending Wednesday 15 May 26.| Date | Severity | Affected metrics | Magnitude | Inferred cause |
|---|---|---|---|---|
| 14 Jan 26 | High | LCP, FCP | LCP +260ms, FCP +280ms | Klaviyo popup CSS landed as render-blocking external stylesheet |
| 03 Feb 26 | Critical | Pass rate (84% → 78%) | -6pp pass rate; LCP +460ms | Hero carousel deploy (heavier images, 4 PNGs at 2.8MB) |
| 17 Feb 26 | Critical | Pass rate (78% → 72%) | Threshold crossing below 75% | Compounded with Klaviyo popup, pushed below threshold |
| 12 Mar 26 | Critical | TTFB, score | TTFB +260ms, score -8 | BFCM-prep dynamic-pricing widget disabled CDN caching |
| 18 Mar 26 | High | INP | INP +60ms | Klaviyo SDK update added behavior tracking |
| 25 Mar 26 | High | INP | INP +80ms | Filter widget refactor introduced long tasks |
| 09 Apr 26 | High | LCP | LCP +580ms | BFCM hero campaign images uploaded unoptimised |
| 22 Apr 26 | Medium | INP | INP +40ms | Hotjar session recording added |
| Most recent | Failing | All composite | 64.8% pass rate | Sustained sub-75% for 3 months |
- Eight distinct regression events identified over the 6-month window, with two critical-severity threshold crossings (Feb 03 and Feb 17). The cumulative effect is the current 64.8% pass rate.
- Two critical events were missable in real-time because each individual event seemed minor. Feb 03 was a single hero deploy; Feb 17 was a “stabilisation” of the previous deploy. The threshold crossing happened because cumulative effect crossed 75%, not because any single deploy was catastrophic.
- The Mar 12 critical TTFB regression had a different shape. Single dominant cause (cache config change), single dominant metric (TTFB), single dominant severity (critical). Easier to attribute and easier to fix than the cumulative-drift pattern.
- Clear leadership story: “We had 8 regression events over 6 months; 3 critical, 4 high, 1 medium. Two threshold crossings put us in CWV failing band. The dominant causes were image-related (hero carousel, BFCM imagery) and cache-related (BFCM dynamic-pricing widget). Recovery requires reversing the image and cache changes, estimated 6-week cycle, expected to cross back above 75% threshold by week 4-5.”
-
Recovery prioritisation by impact × ease-of-fix:
- Mar 12 cache config: highest leverage, easy fix (config rollback). Tackle first.
- Apr 09 BFCM imagery: high leverage, mechanical fix (image format conversion). Tackle second.
- Feb 03 hero carousel: high leverage, requires re-export workflow. Tackle third.
- Jan 14 Klaviyo CSS: medium leverage, easy fix (defer). Tackle in parallel with above.
- Mar 18, Mar 25, Apr 22 INP events: medium leverage, more invasive (refactor). Tackle in week 3-4.
- Defence going forward: enable critical-severity alerts (threshold crossings) + high-severity alerts (>30% band-width regression). The timeline becomes a continuous monitoring surface rather than a retrospective tool.
- Read top-3 by severity. Critical events first, then high, then medium.
- Cross-reference deploy / content / vendor logs for each event date.
- Plan recovery sequence by impact × ease-of-fix.
- Re-enable alerts for ongoing monitoring.
| Time horizon | Action |
|---|---|
| First 1 hour | Identify critical-severity events; understand each cause. |
| First week | Begin recovery on highest-leverage easiest-fix events. |
| First month | Field metrics begin reflecting cumulative recovery. |
| Quarter onward | Continuous monitoring via alerts. |
Sibling cards merchants should reference together
| Card | Why merchants reach for it |
|---|---|
crux_lcp_trend | LCP-specific trend; this card aggregates. |
crux_inp_trend | INP-specific trend. |
crux_cls_trend | CLS-specific trend. |
crux_ttfb_trend | TTFB-specific trend. |
crux_fcp_trend | FCP-specific trend. |
crux_pass_rate_trend | Composite pass rate trend. |
psi_score_trend | Lab score trend. |
psi_biggest_regression | Per-URL regression detection. |
Reconciling against the vendor’s own dashboard
Where to look: This is a Vortex IQ-derived composite card; no direct external equivalent. The closest comparable view is reading GSC’s CWV trend chart while cross-referencing your deploy log manually, that’s exactly the work this card automates. Why the timeline may include events external tools wouldn’t see:| Reason | What it means |
|---|---|
| Sub-threshold but persistent regressions. Smaller deltas that don’t trigger a single-trend alert but accumulate. | The composite catches drift; single-trend alerts catch step changes. |
| Cross-metric correlation. TTFB regression on date X plus FCP regression on date X = single root-cause event. | Surfaces unified incidents that single-trend views fragment. |