Tree Shaking

Was ist Tree Shaking?

Tree Shaking ist eine Optimierungsmethode für JavaScript, bei der ein Bundler nicht verwendete Exporte aus dem ausgelieferten Programmcode entfernt. Dadurch kann das JavaScript-Bundle kleiner werden. Browser müssen weniger Daten übertragen, analysieren und ausführen, was je nach Website die Ladezeit und die Reaktionsfähigkeit verbessert.

Was bedeutet Tree Shaking?

Tree Shaking bedeutet wörtlich das Ausschütteln eines Baums. Der Baum steht für die Abhängigkeiten einer Anwendung: Module bilden Äste, einzelne Funktionen oder Exporte die Blätter. Beim Erstellen des fertigen JavaScript-Bundles prüft das Build-System, welche Exporte tatsächlich erreichbar sind. Nicht benötigte Bestandteile können aus der Produktionsdatei herausfallen.

Tree Shaking arbeitet überwiegend auf Modulebene. Importiert eine Anwendung aus einer Bibliothek nur eine Funktion, kann ein geeigneter Bundler die übrigen Exporte ausschließen. Voraussetzung ist, dass Struktur und Abhängigkeiten statisch erkennbar sind. Bei dynamisch zusammengesetzten Modulpfaden oder schwer vorhersehbaren Laufzeitaufrufen muss der Bundler vorsichtiger arbeiten und behält häufiger zusätzlichen Code.

Wie funktioniert Tree Shaking?

Tree Shaking beginnt mit einer Abhängigkeitsanalyse. Der Bundler startet bei den Einstiegspunkten der Anwendung und verfolgt alle verwendeten Importe. Ein Export, den kein erreichbares Modul benötigt, wird als ungenutzt markiert. Während der anschließenden Optimierung entfernt der Bundler diesen Code oder übergibt ihn an einen Minifier, der die endgültige Bereinigung durchführt.

Ein vereinfachtes Beispiel zeigt die Mechanik. Ein Modul stellt zwei Funktionen bereit, von denen die Anwendung nur eine importiert:

Das Modul exportiert berechnePreis() und formatiereDatum(). Importiert die Anwendung ausschließlich berechnePreis(), kann formatiereDatum() beim Produktions-Build entfallen. Bei zehn Funktionen mit jeweils 5 Kilobyte und nur zwei verwendeten Funktionen könnte das unkomprimierte Beispiel-Bundle von 50 auf 10 Kilobyte sinken. Das ist eine Beispielrechnung, kein allgemeiner Richtwert.

Die Rechnung zeigt zugleich eine wichtige Einschränkung: Eine nicht aufgerufene Funktion verschwindet nicht automatisch. Der Bundler muss beweisen können, dass das Entfernen keine beobachtbare Wirkung verändert. Führt ein Modul bereits beim Import Code aus, verändert globale Variablen oder registriert Ereignisse, kann diese sogenannte Nebenwirkung das Entfernen verhindern.

Voraussetzungen für Tree Shaking

Am zuverlässigsten funktioniert Tree Shaking mit ECMAScript-Modulen, kurz ES-Modulen. Deren import– und export-Anweisungen lassen sich bereits beim Build statisch auswerten. Das ältere CommonJS-System verwendet dagegen häufig require() und dynamische Objektstrukturen, wodurch nicht immer eindeutig feststeht, welche Bestandteile zur Laufzeit benötigt werden.

Für ein wirksames Tree Shaking sollten Entwickler folgende Bedingungen prüfen:

  • Die Anwendung verwendet statische import– und export-Anweisungen.
  • Der Produktions-Build hat die Optimierung und Minifizierung aktiviert.
  • Bibliotheken stellen modular aufgebaute und tree-shake-fähige Dateien bereit.
  • Die Angabe sideEffects in der package.json beschreibt Nebenwirkungen korrekt.
  • Importe greifen möglichst gezielt auf benötigte Exporte statt auf vollständige Bibliothekspakete zu.

Die Einstellung sideEffects: false darf nur verwendet werden, wenn Module beim Import keine notwendigen Aktionen ausführen. Eine falsche Kennzeichnung kann dazu führen, dass Stylesheets, Polyfills, Registrierungen oder Initialisierungscode aus dem Bundle verschwinden. Tree Shaking muss deshalb nach jedem Build mit Funktionsprüfungen und automatisierten Tests abgesichert werden.

Tree Shaking und PageSpeed

Tree Shaking kann den PageSpeed verbessern, weil ein kleineres JavaScript-Bundle weniger übertragenen und zu verarbeitenden Code enthält. Die Dateigröße ist dabei nur der erste Effekt. Der Browser muss JavaScript zusätzlich entpacken, analysieren, kompilieren und ausführen. Besonders auf Mobilgeräten kann unnötiger Code dadurch den Hauptthread länger belegen und Nutzereingaben verzögern.

Eine Meldung zu ungenutztem JavaScript in einer Ladezeiten-Analyse beweist allerdings nicht, dass Tree Shaking fehlt. Ungenutzter Code kann auch durch Tracking-Skripte, eingebettete Dienste, globale Themes oder Funktionen entstehen, die erst nach einer Interaktion benötigt werden. Prüfe deshalb zuerst, ob der Code aus dem eigenen Bundle, einer Bibliothek oder einem externen Skript stammt.

Tree Shaking beeinflusst keine Core-Web-Vitals-Kennzahl nach einer festen Formel. Ein kleineres Bundle kann die Darstellung und Interaktionsbereitschaft verbessern, die tatsächliche Wirkung hängt jedoch von Ausführungszeit, Gerät, Netzwerk und Seitenaufbau ab. Weitere technische Stellschrauben findest du in den SEO-Tipps für Ladezeiten und HTML-Code.

Abgrenzung zu ähnlichen Methoden

Der Unterschied zwischen Tree Shaking und Minifizierung liegt im Auswahlprinzip. Tree Shaking entfernt Programmteile, die nicht gebraucht werden. Minifizierung verkürzt den verbleibenden Code, etwa durch kürzere Variablennamen sowie das Entfernen von Kommentaren und Leerzeichen. Beide Verfahren ergänzen sich und werden in Produktions-Builds häufig nacheinander ausgeführt. JavaScript-Bundler und Minifizierung gehören deshalb zu den üblichen Maßnahmen der technischen Ladezeitenoptimierung.

MethodeWas wird verändert?Typischer Zweck
Tree ShakingNicht verwendete Exporte und ModuleUnnötigen Programmcode ausschließen
MinifizierungSchreibweise des benötigten CodesDateigröße des verbleibenden Codes senken
Code SplittingAufteilung in mehrere TeilpaketeCode erst bei Bedarf laden
Dead Code EliminationNicht erreichbare AnweisungenUnwirksame Programmzweige entfernen

Tree Shaking und Code Splitting lösen ebenfalls unterschiedliche Aufgaben. Tree Shaking entscheidet, welcher Code überhaupt in den Build gehört. Code Splitting legt fest, wann benötigter Code geladen wird. Eine Shop-Anwendung kann beispielsweise den Code für den Checkout behalten, ihn aber erst beim Aufruf des Warenkorbs nachladen.

Tree Shaking richtig prüfen

Messbar ist Tree Shaking durch einen Vergleich der Produktions-Bundles vor und nach der Optimierung. Vergleiche die komprimierte Dateigröße, den Anteil ungenutzten JavaScripts sowie die Lade- und Ausführungszeiten unter identischen Bedingungen. Ein kleineres Bundle allein genügt nicht, wenn nach der Bereinigung Funktionen, Styles oder Ereignisbehandlungen fehlen.

Ein sinnvoller Prüfablauf besteht aus vier Schritten:

  • Erstelle einen Produktions-Build mit aktivierter Optimierung.
  • Analysiere, welche Module und Bibliotheken im Bundle enthalten sind.
  • Vergleiche übertragene Bytes und ungenutzten Code auf derselben URL.
  • Teste Navigation, Formulare, Tracking und dynamisch geladene Komponenten.

Bei einer technischen SEO-Analyse sollte Tree Shaking gemeinsam mit Render-Blocking, Drittanbieter-Skripten, Bildern und Serverantwortzeiten bewertet werden. Eine isolierte JavaScript-Optimierung behebt keine Ladezeitprobleme, die hauptsächlich aus großen Medien oder langsamen Serverprozessen entstehen. Ein strukturierter SEO-Audit ordnet die einzelnen Befunde deshalb nach Ursache und Wirkung.

Prüfe den aktuellen PageSpeed deiner Website und vergleiche die Werte nach dem nächsten Produktions-Build:

Mit Nutzung dieses PageSpeed-Checks erklären Sie, dass Sie die Datenschutzerklärung zur Kenntnis genommen haben und damit einverstanden sind, dass die von Ihnen angegebenen Daten elektronisch erhoben und gespeichert werden. Ihre Daten werden dabei nur streng zweckgebunden zur Bearbeitung des PageSpeed-Checks benutzt. Mit der Nutzung dieses PageSpeed-Checks erklären Sie sich mit der Verarbeitung einverstanden.

Häufige Fragen zu Tree Shaking

Entfernt Tree Shaking automatisch jedes ungenutzte JavaScript?

Nein. Tree Shaking entfernt nur Code, dessen Nichtverwendung während des Builds sicher erkannt wird. Dynamische Importe, CommonJS-Module und mögliche Nebenwirkungen können dazu führen, dass ungenutzter Code im Bundle bleibt.

Funktioniert Tree Shaking nur mit JavaScript?

Der Begriff wird vor allem für JavaScript und modulbasierte Build-Prozesse verwendet. Vergleichbare Optimierungen existieren auch in anderen Programmiersprachen, werden dort jedoch häufig als Dead Code Elimination oder Link-Time Optimization bezeichnet.

Kann Tree Shaking eine Website beschädigen?

Ja, wenn Module fälschlich als frei von Nebenwirkungen gekennzeichnet werden. Nach jeder Änderung sollten deshalb Formulare, Tracking, Styles, Navigation und dynamische Komponenten getestet werden.

Warum bleibt trotz Tree Shaking ungenutzter Code übrig?

Bundler behalten Code, wenn seine Nutzung oder Wirkung nicht eindeutig vorhersehbar ist. Häufige Ursachen sind dynamische Modulzugriffe, vollständige Bibliotheksimporte, CommonJS-Abhängigkeiten und externe Skripte.

Verbessert Tree Shaking automatisch die Core Web Vitals?

Tree Shaking kann übertragene und ausgeführte JavaScript-Mengen reduzieren, garantiert aber keine Verbesserung einzelner Messwerte. Die Wirkung hängt davon ab, ob JavaScript tatsächlich den Hauptthread, das Rendering oder die Reaktion auf Nutzereingaben belastet.

Was ist wichtiger: Tree Shaking oder Code Splitting?

Beide Methoden erfüllen verschiedene Aufgaben. Tree Shaking entfernt nicht benötigten Code, während Code Splitting benötigten Code auf mehrere Ladezeitpunkte verteilt. Viele Anwendungen profitieren von einer Kombination beider Verfahren.

Wenn du JavaScript, PageSpeed und weitere technische Faktoren gemeinsam bewerten lassen möchtest, bietet ein unverbindlicher Check eine klare Grundlage für die Priorisierung.

Kostenloser Potenzialcheck


Sie haben noch Fragen?

Kontaktieren Sie uns

Free Account erstellen


Weitere Inhalte