Performance baseline is documented
Why it matters
Without a performance baseline before launch, any future deployment that regresses Core Web Vitals (LCP, CLS, INP) goes undetected until users notice the slowness. ISO 25010:2011 performance-efficiency.time-behaviour defines response time as a measurable quality attribute — not measuring it means you cannot detect regressions. Beyond technical debt, Lighthouse performance scores directly influence Google Search ranking via Core Web Vitals signals: an unmeasured, slow launch can suppress organic traffic from day one without any visible indicator to the developer.
Severity rationale
Low because the absence of a performance baseline produces delayed detection of regressions rather than immediate harm, but it prevents the team from distinguishing intentional performance trade-offs from accidental degradation.
Remediation
Record a Lighthouse baseline against your production URL immediately after launch and store the report in the repository.
# Record baseline — save output to repo
npx lighthouse https://yoursite.com --output=json --output-path=./lighthouse-baseline.json
For automated enforcement, install @lhci/cli and create .lighthouserc.json with performance score thresholds — Lighthouse CI runs on every PR and fails the build if scores drop below your baseline. At minimum, add your performance targets to the README: Target: LCP < 2.5s, CLS < 0.1, Performance score ≥ 80. Add the web-vitals package to track real-user Core Web Vitals from production traffic.
DetectionPro
The detection method for this pattern is part of AuditBuffet Pro.
The full method (what to look for, pass and fail conditions, and how results get reported) ships inside the Pre-Launch Checklist Audit. The pattern definition, severity rationale, and remediation remain openly licensed under CC-BY-4.0.
External references
- iso-25010:2011 · performance-efficiency.time-behaviour
Taxons
History
- 2026-04-18·v1.0.0·Initial import from pre-launch·automated