Ein modernes JavaScript-Bundle wiegt schnell 300 bis 500 Kilobyte. Der Teil, der mich in meiner Beratung immer wieder verblüfft: Auf einer einzelnen Seite braucht der Browser davon oft nur ein Fünftel. Der Rest wird übertragen, geparst und im Speicher gehalten – und nie benutzt. Bei einer Million Seitenaufrufen im Monat summiert sich allein dieser ungenutzte Ballast auf mehrere Hundert Gigabyte Datenübertragung, die niemand gebraucht hätte.
Genau hier setzt Guideline 3.3 an. Sie fordert, große und bandbreitenintensive Komponenten in kleinere Module aufzuteilen, die erst dann laden, wenn sie wirklich gebraucht werden.
Das eine Erfolgskriterium von Guideline 3.3 (meine Übersetzung des Originals):
Code-Splitting: Teile große oder bandbreitenintensive Komponenten in kleinere Module auf, die nur bei Bedarf geladen werden. Vermeide übermäßiges Aufteilen, da dies den Overhead erhöhen, die Caching-Effizienz verringern und die Wartbarkeit des Codes verschlechtern kann.
Meine Einordnung
Das Kriterium beschreibt eine simple Idee mit großer Wirkung: Statt den kompletten Code beim ersten Seitenaufruf auszuliefern, lädt der Browser einzelne Teile erst im Moment ihres Bedarfs. Der Klassiker ist eine schwere Funktion, die nur ein Teil der Besucher überhaupt öffnet – eine interaktive Karte, ein Videoplayer, ein komplexes Formular. Solcher Code lässt sich per dynamischem Import erst beim Klick nachladen, statt ihn allen von Anfang an aufzuzwingen.
Rechnen wir das durch. Nehmen wir eine interaktive Karte mit 150 Kilobyte Code, die nur jeder fünfte Besucher öffnet. Bei einer Million Aufrufen laden dann 800.000 Menschen diese 150 Kilobyte umsonst – zusammen rund 120 Gigabyte. Nach der Faustregel, dass ein Megabyte weniger pro Aufruf über eine Million Aufrufe etwa 400 Kilogramm CO₂ spart, sind das rund 48 Kilogramm CO₂ im Monat. Für eine einzige Komponente.
Und Code-Splitting endet nicht im Browser. Auch serverseitig lohnt es sich, selten genutzte Logik erst bei Bedarf zu laden, statt sie bei jedem Request vorzuhalten. Der Gedanke bleibt derselbe: Nichts übertragen und nichts verarbeiten, was für die konkrete Aufgabe nicht gebraucht wird.
Der zweite Satz des Kriteriums ist mir aber genauso wichtig wie der erste. Denn Aufteilen hat eine Kehrseite. Wer jede Kleinigkeit in ein eigenes Modul zerlegt, erzeugt Dutzende zusätzlicher HTTP-Anfragen, von denen jede ihren eigenen Overhead mitbringt. Gemeinsam genutzter Code landet mehrfach in verschiedenen Bruchstücken, und das Caching wird schlechter statt besser. Meine Faustregel: Teile dort, wo sich die Nutzung klar trennt – nicht dort, wo sich der Code technisch trennen ließe.
Wo ich weiter gehe
Code-Splitting ist eine Effizienztechnik. Sie liefert denselben Code klüger aus – später, gezielter, in kleineren Häppchen. Die Frage, die ich in meiner Beratung zuerst stelle, ist aber eine andere: Muss diese schwere Komponente überhaupt sein?
Effizienz senkt, wann und wie etwas lädt. Suffizienz senkt, ob es überhaupt lädt. Bevor ich eine Bibliothek aufteile, prüfe ich deshalb, ob ein natives HTML-Element oder ein paar Zeilen CSS denselben Zweck erfüllen. Sehr oft ersetzt ein natives Details-Element ein ganzes Akkordeon-Skript, und ein CSS-Scroll-Snap ersetzt eine schwere Slider-Bibliothek. Was ich nicht einbaue, muss ich später auch nicht mühsam modularisieren.
Dein erster Schritt heute
Bevor Du irgendetwas aufteilst, solltest Du wissen, wo Dein Code überhaupt ungenutzt bleibt. Diese Zahl liefert Dir Dein Browser kostenlos.
Diese eine Messung verändert den Blick. Du siehst nicht mehr abstrakt “zu viel Code”, sondern konkret, welche Zeilen für die aktuelle Seite überflüssig sind. Das ist die Grundlage jeder sinnvollen Modularisierung – und oft auch die Grundlage für die Erkenntnis, dass sich Weglassen mehr lohnt als Aufteilen.
Die effizienteste Komponente ist die, die nur dann lädt, wenn jemand sie wirklich braucht. Die nachhaltigste ist die, die es gar nicht erst gibt.
Quellen: W3C-Fassung von Guideline 3.3 · Interpretation bei Sustainable Web Design