Performance-Budget im CI: Regressionen automatisch stoppen

Performance ist keine Eigenschaft, die man einmal herstellt und die dann bleibt. Sie ist ein Zustand, der bei jeder Codeänderung neu auf dem Spiel steht. Das Tückische an Performance-Regressionen ist, dass sie schleichend passieren und keinen sichtbaren Fehler erzeugen: Die Seite funktioniert weiterhin, sie lädt nur etwas langsamer, reagiert etwas träger oder verschiebt beim Aufbau kurz das Layout. Für die Person, die die Änderung eingecheckt hat, sieht auf dem schnellen Büro-Rechner mit stabilem Netz alles gut aus. Erst die echten Nutzer auf Mittelklasse-Smartphones im Mobilfunknetz spüren die Verschlechterung – und die tauchen in keinem Fehlerbericht auf, sondern springen einfach ab.

Die wirtschaftlichen Folgen sind gut belegt. Schon 0,1 Sekunden (Deloitte) schnellere Ladezeit steigerten in einer branchenübergreifenden Analyse die Conversions im Handel um 8,4 Prozent (Deloitte). Umgekehrt steigt die Wahrscheinlichkeit, dass ein Nutzer die Seite wieder verlässt, um 32 Prozent (Google/SOASTA), wenn die Ladezeit von einer auf drei Sekunden wächst. Und die Conversion-Rate sinkt laut einer Auswertung von Millionen Seitenaufrufen um rund 4,4 Prozent (Portent) mit jeder zusätzlichen Sekunde in den ersten fünf Sekunden. Jede unbemerkte Regression kostet also messbar Geld. Der klassische Gegenmittel-Reflex – alle paar Monate ein großes Performance-Audit – kommt für diese kleinen, kontinuierlichen Verschlechterungen zu spät: Bis zum nächsten Audit haben sich Dutzende Mini-Regressionen aufsummiert, und niemand weiß mehr, welche Änderung welchen Anteil hatte.

Ein Performance-Budget dreht die Logik um. Statt Verschlechterungen im Nachhinein zu suchen, verhindert es sie beim Entstehen. Es macht Performance zu einer Bedingung, die jede Änderung erfüllen muss, bevor sie in den Hauptzweig darf – so wie automatisierte Tests dafür sorgen, dass eine Änderung keine bestehende Funktion zerstört. Wer die drei Core Web Vitals im Zusammenhang verstehen möchte, findet die Einordnung im Beitrag zu den Core Web Vitals 2026; hier geht es darum, wie man ihre Einhaltung dauerhaft erzwingt.

Das Herzstück ist eine schlichte Textdatei namens budget.json. Sie beschreibt in einem klar lesbaren Format, welche Obergrenzen gelten – getrennt nach Zeit-Metriken (timings) und Ressourcen-Mengen (resourceSizes und resourceCounts). Jede Regel bezieht sich auf einen Pfad, sodass sich unterschiedliche Seitentypen unterschiedlich behandeln lassen. Die Datei liegt im Repository neben dem Code und wird damit selbst versioniert: Jede Änderung am Budget ist nachvollziehbar, und das Budget durchläuft dieselben Reviews wie der Rest des Projekts.

In diesem Beispiel darf das LCP höchstens 2.500 Millisekunden betragen, die Total Blocking Time höchstens 200 Millisekunden, und das ausgelieferte JavaScript höchstens 400 Kilobyte. Lighthouse liest diese Datei, vergleicht die gemessenen Werte mit den Budgets und markiert jeden Posten, der darüber liegt, als über Budget. Das allein stoppt allerdings noch keinen Build – es erzeugt nur einen Bericht. Damit aus dem Bericht ein echtes Gate wird, braucht es einen zweiten Baustein: Lighthouse CI.

Ein Budget ist nur so nützlich wie seine Schwellen. Sind sie zu locker, rutschen Regressionen durch und das Gate wiegt in falscher Sicherheit. Sind sie zu streng oder zu nah an der aktuellen Messung, schlägt der Build schon bei normalem Messrauschen fehl – und ein Team, das ständig rote Läufe ohne echten Grund sieht, gewöhnt sich an, sie zu ignorieren. Ein gutes Budget beginnt deshalb bei den offiziellen Zielwerten und lässt einen kleinen, bewussten Puffer. Der Median aus mehreren Läufen und ein Warn-Level unterhalb der harten Fehlergrenze helfen, das Rauschen von echten Verschlechterungen zu trennen.

Wichtig ist außerdem, das Budget pro Seitentyp zu differenzieren. Die Startseite, eine Kategorieseite, eine Produktseite und ein Blogartikel haben völlig verschiedene Realitäten: Was für eine textlastige Artikelseite großzügig ist, wäre für eine bildlastige Produktseite unrealistisch eng. Deshalb erlaubt die budget.json unterschiedliche Regeln je Pfad. Ein häufiger Auslöser für gerissene Budgets sind Drittanbieter-Skripte, die sich über Tag-Manager unbemerkt einschleichen; wie man diese Last gezielt reduziert, behandelt der Beitrag zum Entschlacken von Drittanbieter-Skripten.

So wirksam ein CI-Budget ist – es misst im Labor, nicht bei echten Nutzern. Das Labor liefert reproduzierbare Werte unter kontrollierten Bedingungen und ist deshalb ideal, um Regressionen zwischen zwei Ständen zu erkennen. Was echte Menschen auf ihren Geräten und in ihren Netzen erleben, zeigen aber nur Felddaten. Und der Unterschied ist wirtschaftlich relevant: Wächst die Ladezeit von einer auf fünf Sekunden, steigt die Absprungwahrscheinlichkeit um 90 Prozent (Google/SOASTA), und im Reisesegment brachten schon 0,1 Sekunden schnelleres Laden 10,1 Prozent (Deloitte) mehr Conversions. Diese Effekte entstehen im Feld, nicht im Labor.

Deshalb gehören Labor-Budget und Feldmessung zusammen: Das Budget im CI verhindert, dass eine Regression überhaupt live geht; die Feldmessung bestätigt, dass sich die Werte auch bei echten Nutzern halten. Wie sich Labor- und Felddaten – also Lighthouse-Läufe, RUM und die CrUX-Daten von Google – sinnvoll zu einer Gesamtstrategie verbinden lassen, vertieft der Beitrag zu RUM, CrUX und Performance-Budgets. Und weil das INP im Labor nur über die TBT annäherbar ist, lohnt der ergänzende Blick auf die INP-Optimierung im Detail.

Genau so gehen wir bei der Einrichtung vor: Wir bestimmen die kritischen Seitentypen, kalibrieren realistische Budgets für LCP, INP und CLS, verankern Lighthouse CI als Pflicht-Check in Ihrer Pipeline und begleiten das Team, bis rote Läufe als hilfreiches Signal und nicht als Störung verstanden werden. Welche Leistungen dazugehören, zeigt unsere Übersicht der Performance-Leistungen; für die konkreten Frontend-Hebel, mit denen sich ein gerissenes Budget wieder einfangen lässt, hilft die Frontend-Optimierung.