Wie man ein Performance-Budget aufsetzt.

Ein Performance-Budget ist eine Menge numerischer Grenzen, die eine Seite nicht überschreiten darf — und es wird erst zum Budget, wenn es in einem Test lebt, nicht in einem Dokument.

Das größte Problem der Performance-Arbeit: Die Verbesserung hält nicht. Eine Optimierungsrunde geschieht, die Metriken erholen sich, drei Deployments später ist alles wie zuvor. Die Ursache ist nicht böser Wille, sondern Unsichtbarkeit: Eine Bibliothek kommt hinzu, und niemand schaut auf das Gesamtgewicht.

Das Budget schließt diese Unsichtbarkeit. Ist die Grenze an einen Test gebunden, zeigt sich die Überschreitung im Deployment, und eine Debatte beginnt: Ist dieses Merkmal so viele Byte wert? Die Debatte selbst ist wertvoll — in einem Projekt ohne Budget wird diese Frage nie gestellt.

Was zu messen ist

Budgetposten teilen sich in zwei Familien: ressourcenbasiert und metrikbasiert. Beide gehören zusammen verwendet, denn sie fangen Verschiedenes.

1. Ressourcenbasiert — gesamtes JavaScript, gesamtes CSS, gesamte Bilder, Zahl der Schriftfamilien, Anfragenzahl. Schnell zu messen; zeigt die Ursache direkt.
2. Metrikbasiert — LCP, INP, CLS, Zeit bis zum ersten Byte. Zeigt das Nutzererlebnis, aber nicht seine Ursache.
3. Vorteil ressourcenbasiert — vor dem Deployment messbar, ohne Browser.
4. Vorteil metrikbasiert — misst das wirklich Wichtige.
5. Beide zusammen — das Ressourcenbudget ist die Frühwarnung, das Metrikbudget die Endkontrolle.

Das Ressourcenbudget ist besonders wertvoll, weil es billig ist: Eine Dateigröße zu messen dauert Millisekunden und kann bei jedem Build laufen. Die Metrikmessung braucht einen Browser, ist langsam und läuft seltener.

Woher die Zahl kommt

Die Budgetzahl sollte nicht willkürlich sein, muss aber auch nicht perfekt sein. Drei Ableitungswege funktionieren.

Erstens die Ableitung vom Ziel: Zielgerät und Zielnetz werden festgelegt, und die in der gewünschten Zeit unter diesen Bedingungen ladbare Bytemenge wird berechnet. Die solideste Methode — und die arbeitsintensivste.

Zweitens die Ableitung vom Ist-Zustand: Der heutige Wert wird gemessen und das Budget knapp darunter gesetzt. So wird das Budget kein Ziel, sondern ein Regressionswächter — und der ist für die meisten Projekte der wertvollste.

Drittens die Ableitung von der Schwelle: Googles gute Schwellen werden genommen und darunter ein Abstand gelassen. Das Budget dieser Website ist so gesetzt — die LCP-Schwelle ist 2,5 Sekunden, das Budget 1,8; die Verschiebungsschwelle 0,1, das Budget 0,05.

Der Grund für den Abstand: Messrauschen und künftige Last. Ein an der Decke klebendes Budget bricht bei der ersten kleinen Ergänzung, und dann wird hastig entschieden. Der Spielraum erlaubt die ruhige Entscheidung.

Das Budget bleibt unter der offiziellen Schwelle, damit die Regression sichtbar wird, bevor sie an die Schwelle stößt.

Wo es leben muss

Dass das Budget in einem Dokument steht, garantiert nichts; Dokumente werden nicht gelesen. Das Budget muss in einem Test leben, und dieser Test muss im Deployment-Prozess laufen.

Auf dieser Website stehen die Budgetposten in einem Block der Prüfsuite: die rohe JavaScript-Größe, die Layoutverschiebung, LCP und die Zahl der Schriftfamilien. Die Suite misst bei jedem Lauf und gibt bei Überschreitung Rot.

Die gemessenen Werte liegen unter der Decke: Vendor-Bibliotheken nach gzip 55,7 Kilobyte, eigener Code 28, die Stildatei 12,4. Zusammen rund 96 Kilobyte bei einer Decke von 150.

Eine letzte Entwurfsentscheidung: Die Budgetüberschreitung muss ein Fehler sein, keine Warnung. Warnungen sammeln sich und werden ignoriert; Fehler stoppen und erzwingen Entscheidungen. Der Test, ob ein Budget wirklich eines ist, ist, was bei seiner Überschreitung geschieht.

Wenn das Budget verletzt wird

Damit das Budget wirkt, muss vorab entschieden sein, was im Moment der Überschreitung geschieht. Sonst beginnt bei der ersten eine Debatte, sie zieht sich, und meist endet sie mit der Erhöhung des Budgets — und an diesem Punkt ist das Budget tot.

Eine gesunde Regel: Die Überschreitung stoppt das Deployment und bietet drei Optionen. Das Merkmal wird verkleinert, anderswo wird Platz geschaffen, oder das Budget wird bewusst und mit Begründung erhöht. Das Dritte ist legitim — als Entscheidung, nicht als Flucht.

1. Verkleinern — gibt es einen Weg, das Merkmal mit weniger Code zu bauen?
2. Platz schaffen — lässt sich eine nicht mehr genutzte Bibliothek entfernen?
3. Verschieben — wird das Merkmal beim ersten Laden gebraucht, oder kann es bei der Interaktion kommen?
4. Das Budget erhöhen — mit Begründung, Protokoll und gemessener Wirkungsschätzung.
5. Das Merkmal streichen — die am wenigsten geliebte, manchmal richtige Option.

Ob der fünfte Punkt auf dem Tisch liegt, bestimmt, ob das Budget wirklich eines ist. In einem Projekt, in dem kein Merkmal je gestrichen werden kann, ist das Budget bloß ein Wunsch.

Auf dieser Website leben die Budgetposten in einem Block der Suite, und die Überschreitung gibt direkt Rot — Fehler, nicht Warnung. Warnungen sammeln sich und werden ignoriert; Fehler stoppen und erzwingen Entscheidungen.

Eine praktische Checkliste

Übersetzt man diese Seite in einen Prüfschritt, ist am Budgetaufbau Folgendes zu prüfen. Die Liste bleibt kurz, denn lange Listen werden nicht abgeschritten; sechs Punkte passen in eine Sitzung.

1. Sind die Posten numerisch — „halten wir es klein“ ist kein Budget.
2. Gibt es ressourcen- UND metrikbasierte Posten?
3. Woher leitet sich die Zahl ab — Ziel, Ist-Zustand oder offizielle Schwelle?
4. Wurde unter der Schwelle ein Abstand gelassen?
5. Lebt das Budget in einem Test?
6. Stoppt die Überschreitung das Deployment — oder warnt sie nur?

Der sechste Punkt ist der einzige Test, ob ein Budget wirklich eines ist. Warnungen sammeln sich und werden ignoriert; Fehler stoppen und erzwingen Entscheidungen.

Der Test, ob ein Budget wirklich ein Budget ist, ist, was bei seiner Überschreitung geschieht.

Ein Schlussrahmen: Das Budget wirkt wie eine Auflage, arbeitet aber praktisch als Entscheidungswerkzeug. Im Projekt ohne Budget kommt jedes neue Merkmal lautlos hinzu, und seine Kosten werden nie besprochen; im Projekt mit Budget startet dasselbe Merkmal eine Debatte, und diese Debatte erzeugt meist eine bessere Lösung. Der Wert der Auflage liegt weniger in dem, was sie verhindert, als im Denken, das sie erzwingt.

Dazu kommt eine kulturelle Dimension, schwerer als die technische: Ein nicht vom ganzen Team getragenes Budget wirkt wie ein von einer Person auferlegtes Hindernis und bricht beim ersten Druck. Getragen wird es durch das Teilen seiner Begründung — woher die Zahl kommt, wen sie schützt, wer was erlebt, wenn sie überschritten wird. Sind diese drei Antworten bekannt, hört das Budget auf, eine Auflage zu sein, und wird zu einem gemeinsamen Standard.