Performance Budgets
Degrades become visible
Define budgets on the metrics that matter so a bad deploy produces a clear signal, not a vague “scores dropped” thread. Combine thresholds with scheduled testing to catch regressions early, align engineering and stakeholders on limits, and tune what counts as a breach for your stack and SLAs.
Why it matters
Concrete limits, fewer slow-creep regressions, less noisy debate.
Thresholds you own
LCP, INP, CLS, FCP, TBT, Speed Index, performance score, set per site (and mobile/desktop where applicable).
Breach = signal
Scheduled tests evaluate against budgets; violations open alerts.
Cooldown-aware
Repeat failures do not spam the inbox; behaviour matches alert cooldowns.
The boiling frog problem
Without budgets, performance slips gradually: no single change looks wrong until a client or Google notices. Budgets make degradation visible the moment a metric crosses the line. Pair wording with our Core Web Vitals page for definitions stakeholders already recognise.
Metric budgets (starting points)
| Metric | Example budget |
|---|---|
| LCP | ≤ 2.5s |
| INP | ≤ 200ms |
| CLS | ≤ 0.1 |
| Performance score | ≥ 90 |
Per-site configuration; mobile and desktop can diverge. See Mobile & desktop monitoring.
Smart cooldowns and what’s next
After an alert fires, you should not get repeat spam on every scheduled run while the metric stays bad. Cooldown logic mirrors Alerts & digests. CI/CD gates that fail builds when budgets regress are on the roadmap.