Das JavaScript-Budget.

Ein JavaScript-Budget ist eine vorab gesetzte, nicht überschreitbare Obergrenze für die Codemenge, die eine Seite laden und ausführen darf.

JavaScript ist die teuerste Ressource einer Seite, und seine Kosten enden nicht bei der Größe. Ein Bild wird geladen und dekodiert; ein Skript wird geladen, geparst, kompiliert und ausgeführt. Bei gleicher Bytezahl verbraucht ein Skript ein Vielfaches der Prozessorzeit eines Bildes — und diese Zeit wird auf dem Hauptthread verbraucht, dort, wo die Oberfläche einfriert.

Diese Asymmetrie erklärt, warum das Budget gerade für JavaScript gesetzt wird. Eine Seite mit zwei Megabyte Bildern kann langsam, aber benutzbar sein; mit zwei Megabyte Skript wird sie unbenutzbar.

Wie das Budget gesetzt wird

Damit ein Budget wirkt, braucht es drei Eigenschaften: numerisch, messbar und nicht verhandelbar. „Halten wir das JavaScript klein“ ist kein Budget; „die komprimierte Summe darf 150 Kilobyte nicht überschreiten“ ist eines.

1. Eine Einheit wählen — komprimierte Größe, Rohgröße oder Ausführungszeit? Alle drei lassen sich getrennt messen.
2. Die Grenze festlegen — die Zahl leitet sich vom Zielgerät und Zielnetz ab, nicht vom Durchschnitt der Konkurrenz.
3. Die Anteile trennen — wie viel für Vendor-Bibliotheken, wie viel für den eigenen Code?
4. An einen Test binden — ein in einem Dokument stehendes Budget ist keines; eines, das in einem Test lebt, schon.
5. Die Überschreitung blockieren — dass der Test rot leuchtet, genügt nicht; er muss das Deployment stoppen.

Auf dieser Website lautet das Budget: zusammen 150 Kilobyte gzip, darin die Vendor-Bibliotheken rund 56 Kilobyte und der eigene Code unter 60. Die gemessenen echten Werte — Vendor 55,7 Kilobyte, eigener Code 28 — liegen deutlich unter der Decke, und die Prüfsuite kontrolliert bei jedem Lauf.

Das Budget unter dem offiziellen Ziel zu halten ist bewusst. Ein an seiner Decke klebendes Budget bricht bei der ersten kleinen Ergänzung, und dann wird entweder das Budget erhöht oder hastig optimiert. Spielraum zu lassen erspart die eilige Entscheidung.

Inventur: was wirklich nötig ist

Wird das Budget überschritten, ist der erste Reflex die Optimierung — Code-Splitting, Lazy Loading, Tree Shaking. Der viel größere Gewinn steht aber meist einen Schritt davor: Ist diese Bibliothek wirklich nötig?

Auf einer typischen Website existiert ein beachtlicher Teil des geladenen Codes für ein einziges Merkmal, und das wird entweder kaum benutzt oder wäre mit Bordmitteln machbar. Datumsformatierung, Animation, Formularvalidierung und Icon-Sets sind die klassischen Mitglieder dieser Kategorie.

Auf dieser Website ist die Vendor-Liste auf fünf Module begrenzt, und jedes trägt ein wirklich genutztes Merkmal. Die Liste ist keine Vorliebe, sondern eine Auflage: Neue Abhängigkeiten sind in den Projektregeln ausdrücklich verboten, und externe Hosts blockiert die Content-Security-Policy ohnehin.

Die beste Code-Splitting-Strategie ist die Bibliothek, die nie lädt.

Drittanbieter-Skripte

Die Stelle, an der das Budget am häufigsten bricht, ist Code, den die Entwicklung nicht geschrieben hat: Analytik, Chat-Blase, Werbung, A/B-Test, Heatmap. Sie werden meist vom Marketing ergänzt, das technische Team weiß es womöglich nicht einmal, und ihre Summe steigt auf den meisten Websites auf ein Vielfaches des eigenen Codes.

Das Problem ist nicht nur die Größe, sondern die Kontrolle: Ein Drittanbieter-Skript fragt Sie nicht, wann es sich aktualisiert, und kann eines Tages schwer werden. Hängt Ihr Budget an diesem Skript, liegt Ihr Budget nicht in Ihrer Kontrolle.

Der praktische Ansatz hat drei Schritte: Messen Sie die Kosten jedes Drittanbieter-Skripts für den Hauptthread einzeln, fragen Sie, was Sie im Gegenzug gewinnen, und verzögern Sie den Rest bis nach der Interaktion. Eine Chat-Blase muss beim Laden der Seite nicht existieren; es genügt, wenn sie lädt, sobald der Nutzer sie anklickt.

Auf dieser Website gibt es keine Drittanbieter-Skripte, und der Datenschutztext sagt, dass keine Cookies verwendet werden; die Prüfsuite misst das bei jedem Lauf. Die Entscheidung ist so sehr Datenschutz wie Performance — und beide zeigen hier in dieselbe Richtung.

Code-Splitting und der echte Gewinn

Nach der Inventur und dem Entfernen unnötiger Abhängigkeiten kommt für den Rest das Code-Splitting: Jede Seite lädt nur den Code, den sie braucht. Im klassischen Ansatz landet ein großes Paket auf jeder Seite, und der Nutzer lädt auch den Code von Merkmalen, die er nie sehen wird.

Das Teilen hat eine natürliche Grenze: Zu viele Teile erhöhen die Anfragenzahl, und jedes Teil trägt eigenen Mehraufwand. Die praktische Balance: nach Routen teilen und die wirklich großen Komponenten zusätzlich herauslösen.

Die zweite Technik ist das verzögerte Laden: Ein Merkmal lädt erst, wenn der Nutzer es braucht. Ein Modalinhalt, eine Diagrammbibliothek oder ein Texteditor — nichts davon wird beim Seitenladen gebraucht.

Auf dieser Website war das Teilen unnötig, denn die Summe ist schon klein: eigener Code nach gzip 28 Kilobyte, und die Bewegungsschicht wird auf allen Seiten verwendet. Bei dieser Größe erzeugt die Komplexität des Teilens keinen Gewinn — und unnötige Komplexität ist auch ein Preis.

Das Budget hat auch eine Kommunikationsseite, schwerer als die technische. Das Team, das ein neues Merkmal wünscht, weiß meist nicht, wie viele Kilobyte es bringt — und selbst wenn, nicht, was die Zahl bedeutet. Was ein Budget wirksam macht, ist die Übersetzung der Zahl in Erlebnis: „Diese Bibliothek verzögert die Seite auf einem Mittelklasse-Telefon um eine halbe Sekunde“ überzeugt weit mehr als „sie fügt vierzig Kilobyte hinzu“.

Für diese Übersetzung braucht es Messung: Das Merkmal wird auf einem Zweig umgesetzt, seine Wirkung in einer verlangsamten Gerätesimulation gemessen, und die Entscheidung fällt mit dieser Zahl. Der Prozess wirkt langsam, doch einmal eingerichtet wiederholt er sich für jedes Merkmal — und verlegt die Debatte von der Meinung zur Messung.

Zum Abschluss eine Grenze: Ein Budget setzt eine Obergrenze; die Architektur richtet es nicht. Eine falsche Architekturwahl — etwa ein unnötiges clientseitiges Framework — hält das Budget unter Dauerdruck, und jedes neue Merkmal wird zum Streit. Das Budget zeigt dann das Symptom; die eigentliche Entscheidung gehört eine Schicht höher.

Eine praktische Checkliste

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

1. Wie groß ist die gzip-Summe — eigener Code und Vendor getrennt.
2. Wie viele Abhängigkeiten, und jede für welches Merkmal?
3. Gibt es unbenutzte Bibliotheken — die Inventur kommt vor der Optimierung.
4. Wie hoch ist die Drittanbieter-Summe — meist über dem eigenen Code.
5. Gibt es lange Aufgaben — jede über fünfzig Millisekunden friert die Seite ein.
6. Lebt das Budget in einem Test oder in einem Dokument?

Die auf dieser Website gemessenen Werte: Vendor nach gzip 55,7 Kilobyte, eigener Code 28, Drittanbieter null. Zusammen 83,7 Kilobyte bei einer Decke von 150 — der Spielraum ist bewusst gelassen.