Was ist ein Performance-Budget?
Ein Performance-Budget ist ein Set von expliziten Limits auf Web-Performance-Metrics. Bundle-Sizes, Page-Weight, Core Web Vitals (LCP, INP, CLS), Request-Counts, Third-party-Script-Weight, zu denen sich das Team commitet. Enforced in CI failed das Budget Builds, die Limits überschreiten, und verhindert Performance-Regressions vom Shippen.
Ohne Budget ist Perf-Rot invisible. Ein Budget macht den Cost sichtbar.
Kategorien von Performance-Budgets
| Typ | Was es limitiert | Beispiel |
|---|---|---|
| Quantity-based | Anzahl Resources | ≤ 50 HTTP-Requests |
| Size-based | Bytes transferred | JS < 200KB gzipped |
| Time-based | Performance-Metrics | LCP < 2.5s on 4G |
| Score-based | Lighthouse-Scores | Lighthouse Perf ≥ 90 |
| Rule-based | Spezifische Anti-Patterns | Kein render-blocking JS |
Beispiel Performance-Budget
[
{
"path": "/*",
"timings": [{ "metric": "interactive", "budget": 3000 }],
"resourceSizes": [
{ "resourceType": "script", "budget": 200 },
{ "resourceType": "image", "budget": 500 },
{ "resourceType": "total", "budget": 1500 }
]
}
]Empfohlene Baselines
| Metric | Gutes Budget | Stretch-Goal |
|---|---|---|
| LCP | < 2.5s | < 1.8s |
| INP | < 200ms | < 100ms |
| CLS | < 0.1 | < 0.05 |
| JS-Bundle (gzipped) | < 200KB | < 100KB |
| Total Page-Weight | < 1.5MB | < 1MB |
| HTTP-Requests | < 50 | < 30 |
| Lighthouse-Perf-Score | ≥ 90 | ≥ 95 |
| Third-party-Requests | < 10 | < 5 |
Tools zum Enforcing
| Tool | Wie es enforced |
|---|---|
| Lighthouse CI | Runs Lighthouse auf jedem PR |
| SpeedCurve | Trackt Budget über Zeit |
| Bundle Analyzer | Visualisiert Bundle-Composition |
| size-limit | NPM-Package, CI failed if exceed |
| WebPageTest CI | Field-grade Testing |
| Calibre | Performance-Monitoring + Budgeting |
| Lighthouse (manual) | Local Dev |
| Cloudflare Observatory | Synthetic Tests |
Wo starten
- Current Performance auditen
- Budget at Current Baseline setzen
- Lighthouse CI hinzufügen
- PRs failen die Budget exceeden
- Iterieren: Budget tightnen
Performance-Budget Best Practices
- Mit current Performance starten.
- Budget per Page-Type.
- Loud failen in CI.
- Trends tracken.
- Auf langsamen Devices testen.
- Third-party-Impact separat tracken.
- Owner per Metric.
- Visible in Dashboard.
Häufige Fallstricke
- Aspirational Budgets.
- Kein Follow-up auf Regressions.
- Per-PR-Varianz.
- Lab-only Testing.
- Third-party vergessen.
- Page-Level only.
- Kein Budget für neue Pages.
Performance-Budget vs SLI/SLO
| Aspekt | Performance-Budget | SLI/SLO |
|---|---|---|
| Wann gemessen | Build-Time (Lab) | Production (Field) |
| Enforced via | CI Failing PRs | Alerts + Error-Budgets |
| Owner | Frontend-Team | SRE / Platform |
| Best at preventing | Code-side Regressions | Infra-Incidents |
FAQ: Performance-Budget
Was ist ein gutes Starter-Budget?
LCP < 2.5s, JS < 200KB gzipped, Lighthouse Perf ≥ 90.
Wie unterscheidet sich das von Core Web Vitals?
CWV sind die Metrics. Performance-Budget = das Commitment des Teams.
Kann ich per Page budgeten?
Ja. Lighthouse CI supportet per-URL Budgets.
Sollte ich auf Lab oder Field-Data budgeten?
Beide.
Was wenn PR Budget exceedet aber for good reason?
Bewusst Budget raisen oder optimieren.
Wie oft sollte ich Budgets reviewen?
Quartalsweise.
Brauchen SPAs verschiedene Budgets?
Ja, bigger JS-Bundles allowed, aber TTI/INP kritisch.
Enforce Performance-Budget mit LoadFocus
LoadFocus läuft Lighthouse-Audits aus 25+ Regionen on Schedule. Registrieren bei loadfocus.com/signup.
Verwandte LoadFocus-Tools
Setze dieses Konzept mit LoadFocus in die Praxis um, derselben Plattform, die alles antreibt, was du gerade gelesen hast.