v10r

Budgets nützen wenig, wenn nichts sie durchsetzt — und sind nicht durchsetzbar, wenn sie am Tag ihrer Einführung scheitern. Hier sind beide Aufgaben getrennt: Ziele sagen, wo wir hinwollen; Sperrklinken verhindern, dass die heutige Zahl zur morgigen Untergrenze wird.

Ziele

Wohin der Build kommen soll. Bewertet und angezeigt, aber nie build-brechend.

Metrik	Aktuell	Warnung / Fehler	Urteil
`route_js_kb`	483.8 KB	150 / 250	Schlecht
`baseline_js_kb`	79.6 KB	80 / 120	Gut
`doc_html_kb`	2.8 KB	50 / 100	Gut

Die schwerste Route liegt deutlich über ihrem Ziel, und genau das offen zu sagen ist der Sinn der Sache. Ein Dashboard, das nur Grün zeigt, hat aufgehört, eine Messung zu sein.

Sperrklinken

Der gemessene Wert zum Zeitpunkt seiner Annahme. Diese lassen den Build scheitern, wenn sie überschritten werden, und bewegen sich nur nach unten — eine zu senken ist die Art, eine Verbesserung festzuschreiben.

Metrik	Aktuell	Obergrenze	Spielraum (KB)
`route_js_kb`	483.8	630	+146.2
`baseline_js_kb`	79.6	82	+2.4
`median_route_js_kb`	213.8	372	+158.2
`total_client_js_kb`	2205.6	2270	+64.4
`doc_html_kb`	2.8	5	+2.2

Warum ausgerechnet Bundle-Größe

Nicht alles gehört in ein Gate. Bundle-Gewicht eignet sich ungewöhnlich gut dafür:

Es ist im Review unsichtbar — ein einzeiliger Import kann hundert Kilobyte hinzufügen, ohne dass man es im Diff sähe.
Es ist deterministisch — gleicher Quellcode, gleiche Zahl, also flackert die Prüfung nicht.
Es lässt sich nur vor dem Ausliefern abfangen — wenn Echtnutzerdaten es zeigen, haben Nutzer es längst heruntergeladen.

Gemessen am 2026-09-18 · NODE_ENV=production

Geht dieses Pattern noch besser? Sag uns, wie.

Feedback geben