Performance-Budget: Definition und Beispiele

Was ist ein Performance-Budget?

Ein Performance-Budget ist ein Satz von Grenzwerten für Messgrößen, die die Geschwindigkeit einer Website beeinflussen, etwa Skriptgröße, Anzahl der Requests, Seitengewicht oder Ladezeiten. Das Team legt die Grenzen vorab fest und behandelt sie wie jede andere Anforderung: Eine Änderung, die die Seite über eine Grenze schiebt, wird korrigiert, oder die Grenze wird bewusst angepasst. So wird aus "mach es schneller" eine Zahl, die du bei jedem Release prüfen kannst.

Arten von Performance-Budgets

• Mengenbasiert. Anzahlen und Größen: JavaScript in Kilobyte, Anzahl der Requests, Webfonts, Drittanbieter-Ressourcen.
• Zeitmarken. Momente im Ladevorgang wie First Contentful Paint oder Time to Interactive sowie nutzerzentrierte Metriken: Largest Contentful Paint, Interaction to Next Paint und Cumulative Layout Shift.
• Regelbasiert. Ein Mindestwert im Lighthouse-Score oder eine Regel wie keine render-blockierenden Skripte.

web.dev empfiehlt, mengenbasierte Grenzen mit nutzerzentrierten Metriken zu kombinieren.

Beispiel

Lighthouse liest eine Budgetdatei und berichtet dagegen:

# budget.json
[
  {
    "path": "/*",
    "timings": [{ "metric": "interactive", "budget": 3000 }],
    "resourceSizes": [
      { "resourceType": "script", "budget": 125 },
      { "resourceType": "total", "budget": 300 }
    ],
    "resourceCounts": [{ "resourceType": "third-party", "budget": 10 }]
  }
]

lighthouse https://example.com --budget-path=./budget.json

Das Beispiel begrenzt Time to Interactive auf 3000 ms, JavaScript auf 125 KB, das Gesamtgewicht auf 300 KB und Drittanbieter-Requests auf 10. Einheiten sind Millisekunden für Zeiten und Kilobyte für Größen. Wähle die Zahlen aus eigenen Messungen, nicht aus einem Beispiel.

Die Zahlen festlegen

1. Drei bis fünf repräsentative Seiten mit gedrosseltem Mobilprofil messen.
2. Jede Grenze auf oder knapp unter den heutigen Wert setzen, damit der erste Lauf besteht und jede Verschlechterung auffällt.
3. Die "guten" Schwellen der Core Web Vitals als Zielwerte nutzen: LCP höchstens 2,5 Sekunden, INP höchstens 200 Millisekunden, CLS höchstens 0,1, bewertet am 75. Perzentil der Seitenaufrufe (web.dev). Siehe Core Web Vitals.
4. Eigene Budgets je Seitentyp festlegen.

Bilder sind meist das schwerste Element, schau daher zuerst auf die Bildgröße.

So setzt du ein Budget durch

• Im Build. Lighthouse mit Budgetdatei, eine Bundle-Größenprüfung oder ein Tool wie Lighthouse CI, sodass ein Pull Request bei Überschreitung fehlschlägt.
• In Produktion. Eine Build-Prüfung sieht nur den Code. Zeitgesteuerte Audits der Live-Seite fangen Verschlechterungen durch Drittanbieter-Tags, Inhalte und Infrastruktur ab. Das Page-Speed-Monitoring von LoadFocus führt zeitgesteuerte Lighthouse-Audits aus 25 Cloud-Regionen aus, erlaubt Core-Web-Vitals-Budgets und alarmiert per E-Mail, Slack oder Microsoft Teams, wenn ein Wert die Schwelle überschreitet. Für einen einmaligen Blick gibt es den Core Web Vitals Checker.

Der Leitfaden Performance-Budgets für Web-Apps festlegen (englisch) geht tiefer auf die Einführung ein.

Häufige Fehler

• Zu enge Budgets, bei denen jede Änderung scheitert und das Team die Prüfung abschaltet.
• Warnungen, auf die niemand reagiert.
• Einen einzelnen verrauschten Lauf bewerten statt mehrere Läufe oder Trends.
• Nur Labordaten nutzen, obwohl echte Nutzer langsamer unterwegs sein können.
• Drittanbieter-Skripte vergessen, die oft den größten Teil des Budgets verbrauchen.

Häufige Fragen: Performance-Budget

Wie sieht ein erstes Budget aus?

Starte mit deinen gemessenen Werten für einige Schlüsselseiten, setze die Grenzen auf oder knapp darunter und ergänze die Core-Web-Vitals-Schwellen als Zeitziele. Später verschärfen.

Worin unterscheidet sich ein Performance-Budget von den Core Web Vitals?

Die Core Web Vitals sind die Metriken. Ein Performance-Budget ist die vereinbarte Grenze des Teams für diese Metriken und für Dinge wie Skriptgröße und Request-Anzahl.

Sollen Budgets auf Labor- oder Felddaten beruhen?

Auf beiden. Labortools wie Lighthouse eignen sich für Build-Prüfungen, weil sie wiederholbar sind. Felddaten zeigen, was echte Nutzer erleben.