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.