JavaScript-Bundle-Optimierung: Schlanker Code für schnellere Seiten

JavaScript ist teurer als jedes Bild: Ein Skript muss geladen, geparst und ausgeführt werden und blockiert dabei die Interaktion. Bundle-Optimierung heißt deshalb nicht nur weniger Kilobytes, sondern weniger Code auf dem kritischen Pfad — aufteilen, Drittanbieter messen und prüfen, was der Nutzer tatsächlich spürt.

Bilder sind schwer, aber JavaScript ist teuer: Ein Bild kostet Bandbreite, ein Skript kostet zusätzlich Parsing- und Ausführungszeit auf dem Gerät. Auf einem Mittelklasse-Telefon dauert die Verarbeitung von 300 Kilobyte JavaScript länger als das Laden von einem Megabyte Bild — und blockiert dabei die Interaktion.

##Wie sehen Sie, was im Bundle steckt?

Jeder Bundler kann einen Bericht erzeugen, der die Größe je Modul zeigt. Der Blick darauf ist regelmäßig ernüchternd: eine vollständige Icon-Bibliothek für vier Symbole, eine Datumsbibliothek mit allen Sprachen für ein deutsches Format, eine Animationsbibliothek für zwei Übergänge, zwei Versionen desselben Pakets über unterschiedliche Abhängigkeiten. Diese vier Muster erklären in den meisten Projekten die Hälfte des Gewichts.

• ›Einzelimporte statt Sammelimporte, damit Tree Shaking überhaupt greifen kann.
• ›Datums- und Zahlenformatierung über die eingebaute Intl-API statt über eine Bibliothek.
• ›Icons als SVG-Komponenten der tatsächlich genutzten Symbole.
• ›Doppelte Abhängigkeiten auflösen — der Bundler zeigt sie im Bericht als zwei Einträge desselben Pakets.

##Warum aufteilen statt alles laden?

Was nicht zur ersten Darstellung gehört, muss nicht im ersten Paket sein: ein Video-Player, eine Karte, ein Diagramm, ein aufwendiger Editor. Dynamische Importe laden diese Teile, wenn sie gebraucht werden — beim Klick, beim Scrollen in den sichtbaren Bereich oder nach der Interaktion. Wichtig ist der Platzhalter mit fester Höhe, sonst tauscht man Ladezeit gegen einen Layoutsprung.

Bei serverseitig gerenderten Seiten lohnt zusätzlich die Frage, wie viel überhaupt Interaktivität braucht. Ein Textabschnitt, eine Tabelle, ein Footer brauchen kein JavaScript. Je mehr Teile rein serverseitig bleiben, desto kleiner wird das, was der Browser hydratisieren muss.

##Warum sind Drittanbieter der größte Posten?

In der Praxis stammt das schwerste Skript selten aus dem eigenen Code, sondern von außen: Tag-Manager, Chat-Widget, Analyse, Bewertungs-Widget. Jedes davon gehört mit Name, Zweck und Gewicht in eine Liste, und jede Position ohne belegten Nutzen wird entfernt. Was bleibt, lädt nach der Einwilligung und nach dem Inhalt — nie davor.

##Wie messen Sie, was der Nutzer spürt?

Die Kilobyte im Bericht sind ein Zwischenergebnis; entscheidend ist INP — die Zeit von der Eingabe bis zur sichtbaren Reaktion. Ein kleineres Bundle, das dieselbe Arbeit im Hauptthread erledigt, verbessert nichts. Prüfen Sie deshalb im Performance-Profil, welche Aufgaben länger als 50 Millisekunden blockieren, und zerlegen Sie genau diese.

Nützlich ist außerdem der Vergleich zwischen Labor und Feld: Der Testlauf auf dem Entwicklerrechner ist optimistisch, die Felddaten der Search Console zeigen echte Geräte. Weichen beide stark voneinander ab, ist das Bundle für Mittelklasse-Telefone zu groß, auch wenn der Laborwert grün ist.

##Warum ist Dranbleiben der eigentliche Teil?

Bundles wachsen mit jedem Feature, das jemand „nur schnell" einbaut. Ohne eine wiederkehrende Prüfung ist der aufgeräumte Zustand nach einem halben Jahr verschwunden. Ein Blick pro Quartal in den Größenbericht, ergänzt um die Budgetprüfung im Build, hält den Aufwand bei Minuten statt bei einem erneuten Aufräumprojekt.