Performance-Budget Grenzwerte je Seitentyp für Felddaten und Ressourcen, mit Eigentümer, Alarm und Ausnahmeprozess
Ein Performance-Budget legt fest, wie langsam eine Seite höchstens werden und wie viel sie höchstens laden darf, getrennt nach Seitentyp und Markt. Es macht aus Zielwerten eine Regel, die jedes Release, jede Kampagne und jedes neue Tag durchläuft. Das Budget ist der Maßstab der Performance-Kontrolle im Betrieb: Gemessen, abgenommen und berichtet wird gegen das Budget. Die Umsetzung liegt bei dem Team, das die Plattform entwickelt.
Bestandteile eines Performance-Budgets: Grenzwerte für Felddaten und Ressourcen-Budgets
web.dev unterscheidet Budgets auf Mengen wie Seitengewicht und Zahl der Anfragen, auf Zeitpunkte des Seitenaufbaus und auf regelbasierte Punktwerte, und empfiehlt eine Kombination aus Mengen und nutzerzentrierten Kennzahlen (Performance budgets 101). Für Enterprise-Plattformen bewährt sich eine Aufteilung in zwei Ebenen:
- Grenzwerte für Felddaten: Largest Contentful Paint, Interaction to Next Paint und Cumulative Layout Shift im 75. Perzentil auf Mobilgeräten, je Seitentyp und Markt, dazu die Time to First Byte als Diagnosewert. Sie sind der Maßstab der Abnahme.
- Ressourcen-Budgets: komprimiert übertragenes JavaScript, Bildgewicht, Zahl der Drittanbieter und Hauptthread-Zeit, im Labor als Total Blocking Time gemessen. Sie lassen sich vor dem Merge prüfen.
Beide Ebenen haben verschiedene Aufgaben. Felddaten zeigen die Wirkung erst nach dem Livegang und im Chrome User Experience Report über 28 Tage gemittelt. Ressourcen-Budgets greifen vorher, bilden die Felddaten aber nur näherungsweise ab. Ein Lighthouse-Punktwert gehört in keine der beiden Ebenen, weil er eine gewichtete Labormessung ohne Einwilligung und ohne Interaktion ist, wie unter Core Web Vitals messen beschrieben.
Zielwert, Grenzwert und Alarm: drei Schwellen mit verschiedenen Folgen
| Schwelle | Bedeutung | Folge |
|---|---|---|
| Zielwert | angestrebter Wert mit Abstand zur Schwelle von Google | Planung im Backlog, Bericht im Monatsreport |
| Grenzwert | Wert, den kein Release überschreiten darf | Build oder Release wird abgelehnt, sofern keine Ausnahme genehmigt ist |
| Alarm | Annäherung an den Grenzwert oder Abweichung im Feld | Ticket mit Release, Seitentyp und Ursache |
Ein Beispiel für den Largest Contentful Paint: Google bewertet Werte bis 2,5 Sekunden als gut (web.dev: Web Vitals). Der Grenzwert liegt bei 2,5 Sekunden, der Zielwert bei 2,2 Sekunden, damit die Streuung abgefangen wird, bevor die Felddaten von Google kippen. Der Alarm löst aus, wenn das Real User Monitoring den Zielwert an zwei Tagen in Folge überschritten sieht.
Budgetwerte ableiten: Ausgangsmessung, Schwellen von Google und Stufen
- Ausgangsmessung je Seitentyp, Markt und Gerät: das 75. Perzentil der Felddaten aus dem Chrome User Experience Report und dem eigenen Monitoring, Ressourcen und Hauptthread-Zeit aus Labormessungen über mehrere Läufe.
- Schwellen von Google als Obergrenze für die Felddaten: 2,5 Sekunden für Largest Contentful Paint, 200 Millisekunden für Interaction to Next Paint, 0,1 für Cumulative Layout Shift, 800 Millisekunden für die Time to First Byte (web.dev: TTFB).
- Liegt der Ausgangswert unter der Schwelle, wird der heutige Stand zum Grenzwert. Das Budget verhindert dann einen Rückschritt.
- Liegt er darüber, gilt ebenfalls der heutige Stand als Grenzwert, und der Zielwert sinkt in Stufen je Quartal bis zur Schwelle.
- Ressourcen-Budgets folgen dem Feld-Zielwert: Seitentypen, die im Feld bestehen, liefern die Größenordnung für JavaScript, Bilder und Drittanbieter der übrigen.
Wie groß der Abstand im Markt ist, zeigt der Core Web Vitals Benchmark 2026: Auf Smartphones bestehen 65,1 Prozent der AEM-Auftritte und 64,2 Prozent der Magnolia-Auftritte die Core Web Vitals, über alle erfassten Websites in Deutschland, Österreich und der Schweiz sind es 68,7 Prozent. Ein bestandener Wert ist ein Stand, den das Budget gegen das nächste Release absichert.
Performance-Budget in der Auslieferungskette: Lighthouse CI, PerfDelta und Real User Monitoring
Ressourcen- und Laborbudgets prüft eine Messung je Seitentyp in der Auslieferungskette. Lighthouse CI führt Lighthouse in der Pipeline aus und vergleicht die Ergebnisse mit festgelegten Grenzen; ein Build, der sie reißt, schlägt fehl. Wie Budgets mit Lighthouse funktionieren, beschreibt web.dev unter Use Lighthouse for performance budgets. Die Grenze dieser Prüfung: Sie misst in der Testumgebung, in der produktive Tags, Einwilligung und Unterschiede zwischen Märkten oft fehlen.
Die Performance-Budgets in PerfDelta gelten für ein Projekt oder eine einzelne Seite und umfassen Seitengewicht, JavaScript, Bilder, Schriften, Drittanbieter, Zahl der Anfragen, Laborwerte und die mobilen Felddaten von LCP, INP, CLS, FCP und TTFB. Kommt ein Wert auf zehn Prozent an seine Grenze heran, warnt das Werkzeug; beim Überschreiten schlägt die Prüfung fehl. Auf Wunsch sinkt eine Grenze nach 30 Tagen ohne Überschreitung schrittweise in Richtung Zielwert. Das Ergebnis lässt sich über die REST-API in die Pipeline einbinden. Offenlegung: PerfDelta ist ein eigenes Werkzeug, Einzelheiten stehen unter Core Web Vitals messen.
Die Grenzwerte für Felddaten prüft das Real User Monitoring täglich je Seitentyp, der Abgleich mit dem Chrome User Experience Report folgt monatlich. Erst die drei Ebenen zusammen, Pipeline, Monitoring und Google-Daten, machen aus einem Budget eine Kontrolle.
Verantwortung und Ausnahmeprozess: wer ein Performance-Budget überschreiten darf
- Ein Eigentümer je Seitentyp. Meist der Product Owner, der auch über Funktionen und Kampagnenbausteine dieses Seitentyps entscheidet.
- Ausnahmen genehmigt der Eigentümer, nicht das umsetzende Team. Der Antrag nennt Begründung, betroffenen Wert, erwartete Überschreitung, Dauer und Plan zum Ausgleich.
- Jede Ausnahme ist befristet. Nach Ablauf gilt wieder das Budget, oder es wird bewusst und dokumentiert neu festgelegt.
- Neue Tags laufen durch denselben Prozess. Was aus Marketing und Tag-Verwaltung kommt, wird vor dem Livegang gegen das Budget geprüft, wie unter Drittanbieter-Skripte beschrieben.
- Abnahme getrennt von der Umsetzung. Wer ein Ergebnis erzeugt, prüft es nicht selbst. Den Ablauf beschreibt Website Performance Optimierung.
Budget je Seitentyp und Markt: Beispieltabelle mit getrennten Grenzwerten
Ein einziges Budget für die ganze Domain verdeckt die Seitentypen, an denen es klemmt. Startseiten tragen die meisten Kampagnenbausteine, Produktseiten die meisten Bilder, Formularstrecken die meisten Interaktionen. Märkte unterscheiden sich in Geräten, Netzen, Inhalten und Tags; ein eigenes Budget je Markt lohnt sich, sobald dort andere Tags oder Inhalte laufen. Die folgenden Werte sind ein Beispiel ohne Bezug zu einer bestimmten Plattform. Sie zeigen den Aufbau, keine Empfehlung.
| Kennzahl | Startseite | Produktseite | Formularstrecke |
|---|---|---|---|
| LCP, 75. Perzentil Feld | 2,5 s, Ziel 2,2 s | 2,5 s, Ziel 2,2 s | 2,5 s, Ziel 2,0 s |
| INP, 75. Perzentil Feld | 200 ms, Ziel 180 ms | 200 ms, Ziel 180 ms | 200 ms, Ziel 150 ms |
| CLS, 75. Perzentil Feld | 0,1, Ziel 0,05 | 0,1, Ziel 0,05 | 0,1, Ziel 0,05 |
| JavaScript, komprimiert | 450 KB | 400 KB | 300 KB |
| Bildgewicht | 1.200 KB | 1.000 KB | 300 KB |
| Drittanbieter-Hosts | 12 | 10 | 6 |
| Total Blocking Time, Labor | 400 ms | 300 ms | 200 ms |
Die Formularstrecke trägt in diesem Beispiel die strengsten Ziele für die Reaktionszeit, weil dort jede Eingabe zählt. Wie solche Werte in abnehmbare Tickets übergehen, zeigen die Core Web Vitals Abnahmekriterien.
Kostenfreie Performance-Erstanalyse buchen
30 Minuten per Video. Sie sehen die Google-Nutzerdaten Ihrer Plattform je Seitentyp als Ausgangspunkt für ein Performance-Budget.
Häufige Fragen zum Performance-Budget
Was ist ein Performance-Budget?
Ein Satz von Grenzwerten je Seitentyp und Markt: für die Felddaten von Largest Contentful Paint, Interaction to Next Paint und Cumulative Layout Shift sowie für Ressourcen wie JavaScript, Bilder, Drittanbieter und Hauptthread-Zeit. Jedes Release, jede Kampagne und jedes neue Tag wird dagegen geprüft, bevor es live geht.
Wer legt die Werte eines Performance-Budgets fest?
Die Eigentümer der Seitentypen, meist die Product Owner, zusammen mit IT, Marketing und der umsetzenden Agentur. Grundlage sind die Ausgangsmessung je Seitentyp und die Schwellen von Google. Wer Ausnahmen genehmigt, steht im Budget selbst, damit der Konflikt zwischen Funktion und Geschwindigkeit nicht im Release entschieden wird.
Reicht ein Lighthouse-Punktwert als Performance-Budget?
Nein. Der Punktwert ist eine gewichtete Labormessung ohne Einwilligung und ohne Interaktion. Google bewertet nach Felddaten echter Besucher. Ein Budget enthält deshalb Grenzwerte für Felddaten und messbare Ressourcen; Lighthouse-Messungen dienen der Prüfung vor dem Merge, wie unter Core Web Vitals messen beschrieben.
Was passiert, wenn ein Release das Budget überschreitet?
Die Prüfung in der Pipeline schlägt fehl, und das Release geht ohne genehmigte Ausnahme nicht live. Die Ausnahme beantragt das Team beim Eigentümer des Seitentyps, mit Begründung, Dauer und Plan zum Ausgleich. Zeigt sich die Überschreitung erst im Feld, entsteht ein Ticket mit Release und Ursache.
Wie oft wird ein Performance-Budget angepasst?
Planmäßig einmal im Quartal. Liegt ein Seitentyp über der Schwelle von Google, sinkt der Zielwert in Stufen. Hält ein Seitentyp seinen Wert über längere Zeit mit Abstand, wird der erreichte Stand zur neuen Obergrenze. Außerplanmäßig ändert sich ein Budget nur über eine dokumentierte Entscheidung des Eigentümers.