Tree Shaking

Moderne Webseiten und Apps bestehen aus Programmcode, den Entwickler nicht komplett selbst schreiben. Sie binden fertige Sammlungen von Bausteinen ein, sogenannte Bibliotheken. Eine solche Bibliothek kann hunderte Funktionen enthalten, obwohl ein Projekt vielleicht nur drei davon braucht. Tree Shaking ist ein Verfahren, das genau diesen ungenutzten Teil vor der Veröffentlichung wieder herauswirft. Der Name kommt vom Bild eines Baums: Man schüttelt ihn, und alles, was nicht fest angewachsen ist, fällt herunter. Übrig bleibt nur der Code, der tatsächlich irgendwo aufgerufen wird.

Warum jedes Kilobyte im Browser zählt

Wenn du eine Webseite aufrufst, muss dein Gerät den Programmcode erst herunterladen. Erst danach kann er ausgeführt werden und die Seite wird bedienbar. Je größer die Datei, desto länger starrst du auf eine halb geladene Seite. Auf einem schnellen WLAN merkt man das kaum. Im Zug mit schwachem Mobilfunk sind es plötzlich mehrere Sekunden Unterschied.

Diese Sekunden haben messbare Folgen. Studien großer Onlineshops zeigen seit Jahren, dass langsamere Seiten weniger verkaufen. Auch Suchmaschinen bewerten die Ladezeit einer Seite mit. Deshalb ist die Größe des ausgelieferten Codes für Entwicklerteams eine echte Kennzahl, die überwacht wird.

Der Effekt von Tree Shaking ist dabei oft überraschend groß. Eine populäre Werkzeugsammlung wie Lodash umfasst mehrere hundert Kilobyte. Ein Projekt, das daraus nur zwei Hilfsfunktionen nutzt, kommt nach dem Aussortieren mit wenigen Kilobyte aus. Der Rest wird nie zum Nutzer geschickt, weil er dort ohnehin nichts täte.

Wie der Bundler entscheidet, was wegfällt

Die Arbeit erledigt ein Programm namens Bundler. Es sammelt alle Code-Dateien eines Projekts ein und schnürt daraus ein Paket für den Browser. Bekannte Vertreter heißen Webpack, Rollup oder esbuild. Beim Zusammenschnüren analysiert der Bundler, welche Bausteine überhaupt jemand anfordert.

Er beginnt beim Startpunkt des Programms und verfolgt jede Verbindung weiter. Ruft die Startdatei Funktion A auf, und A benutzt B, gelten beide als erreichbar. Funktion C, die niemand erwähnt, wird als toter Code markiert und gelöscht. Fachleute sprechen deshalb auch von Dead Code Elimination. Der Unterschied ist fein: Tree Shaking schaut auf ganze Module und deren Verbindungen, klassische Dead Code Elimination eher auf einzelne Zeilen innerhalb einer Datei.

Damit das klappt, muss die Analyse ohne Ausführung möglich sein. Der Bundler liest den Code nur, er startet ihn nicht. Deshalb funktioniert Tree Shaking gut mit der modernen Schreibweise aus import und export, bei der alle Abhängigkeiten fest im Text stehen. Wird Code dagegen zur Laufzeit dynamisch zusammengesetzt, kann das Werkzeug nicht sicher entscheiden. Im Zweifel behält es den Baustein lieber, denn ein zu kleines Paket, das abstürzt, wäre der schlimmere Fehler.

Tree Shaking in Frameworks und Build-Pipelines

Als eigenes Werkzeug musst du Tree Shaking praktisch nie installieren. Es ist in den Standard-Werkzeugketten moderner Web-Frameworks wie React, Vue oder Svelte bereits eingebaut. Sobald ein Projekt für den echten Betrieb gebaut wird, läuft der Schritt automatisch mit. In der Entwicklungsphase bleibt er meist abgeschaltet, weil er Zeit kostet und beim Suchen von Fehlern stört.

Sichtbar wird das Thema in Diskussionen über Bibliotheken. Wenn Entwickler schreiben, eine Bibliothek sei tree-shakeable, meinen sie: Man kann einzelne Teile davon nutzen, ohne den ganzen Rest mitzuschleppen. Das ist heute ein handfestes Verkaufsargument, mit dem Projekte auf ihrer Startseite werben.

Ein verbreiteter Irrtum ist, Tree Shaking würde die Ausführung des Programms schneller machen. Es entfernt nur Ballast, der ohnehin nie ausgeführt wurde. Schneller wird dadurch das Herunterladen und das anfängliche Einlesen des Codes, nicht die eigentliche Rechenarbeit. Für gefühlte Geschwindigkeit ist das trotzdem einer der wirksamsten Hebel.