Tree Shaking

Wie funktioniert Tree Shaking?

Tree Shaking, deutsch sinngemäß das Ausschütteln ungenutzten Codes, untersucht die Abhängigkeiten einer Anwendung während des Build-Prozesses. Ein Bundler verfolgt dazu die import– und export-Anweisungen der einzelnen JavaScript-Module. Exporte, die von keinem erreichbaren Einstiegspunkt verwendet werden, können aus dem finalen Bundle entfernt werden.

Die Analyse funktioniert besonders zuverlässig mit ES-Modulen, weil deren Import- und Exportstruktur überwiegend statisch feststeht. Der Bundler kann bereits vor der Ausführung erkennen, welche Funktion aus welcher Datei benötigt wird. Dynamisch zusammengesetzte Abhängigkeiten und ältere CommonJS-Aufrufe wie require() lassen sich dagegen schwerer eindeutig auswerten.

Voraussetzungen für Tree Shaking

Tree Shaking benötigt einen Produktions-Build mit aktivierter Optimierung und einen statisch analysierbaren Modulgraphen. Der Modulgraph beschreibt, welche Dateien und Funktionen voneinander abhängen. Eine Entwicklungsumgebung entfernt Code häufig bewusst noch nicht, damit Debugging, verständliche Fehlermeldungen und schnelle neue Builds möglich bleiben.

Für eine zuverlässige Entfernung ungenutzter Bestandteile sind vor allem diese Bedingungen relevant:

• Die Anwendung verwendet ES-Module mit klaren import– und export-Anweisungen.
• Der eingesetzte Bundler führt Tree Shaking im Produktionsmodus aus.
• Bibliotheken stellen ihre Module in einer analysierbaren Form bereit.
• Seiteneffekte sind korrekt gekennzeichnet und werden nicht irrtümlich entfernt.
• Dynamische Importe und Sammeldateien werden gezielt statt pauschal eingesetzt.

Seiteneffekte richtig behandeln

Ein Seiteneffekt liegt vor, wenn ein Modul beim Import eine Aktion ausführt, die außerhalb seines eigenen Rückgabewerts wirkt. Dazu gehören beispielsweise das Registrieren eines globalen Event-Listeners, das Verändern eines globalen Objekts oder das Laden einer CSS-Datei. Ein Bundler darf ein solches Modul nicht allein deshalb löschen, weil kein Export direkt verwendet wird.

Viele Pakete kennzeichnen Seiteneffekte über die Eigenschaft sideEffects in der package.json. Eine pauschale Kennzeichnung als seiteneffektfrei kann den Build verkleinern, zugleich aber benötigten Initialisierungscode entfernen. Prüfe nach Änderungen deshalb Navigation, Formulare, Tracking, Styles und interaktive Komponenten in einem vollständigen Produktions-Build.

Tree Shaking und PageSpeed 2026

Tree Shaking kann den PageSpeed verbessern, weil weniger JavaScript übertragen und verarbeitet werden muss. Der Effekt betrifft neben der Downloadgröße auch die CPU-Arbeit im Browser: JavaScript wird entpackt, geparst, kompiliert und ausgeführt. Besonders auf mobilen Geräten kann ein kleineres Bundle deshalb schneller auf Nutzereingaben reagieren.

Ein kleineres Bundle führt jedoch nicht automatisch zu besseren Core Web Vitals. Entfernt Tree Shaking ausschließlich Code, der erst nach einer Interaktion geladen worden wäre, kann der initiale Seitenaufbau nahezu unverändert bleiben. Befand sich der entfernte Code dagegen im kritischen Ladepfad, können sich der Largest Contentful Paint und die Reaktionsfähigkeit verbessern. PageSpeed wird unter anderem über die Core Web Vitals eingeordnet.

Für SEO entsteht der Nutzen vor allem über eine bessere technische Nutzererfahrung und eine geringere Belastung bei JavaScript-basierten Websites. Tree Shaking ist kein direkter Ersatz für sauberes Rendering: Werden zentrale Inhalte erst nach umfangreicher Skriptausführung sichtbar, bleiben serverseitiges Rendering, sinnvolle Ladeprioritäten und kontrolliertes JavaScript weiterhin relevant. JavaScript-SEO behandelt genau solche Inhalte, die erst im Browser erzeugt werden.

PageSpeed konkret messen

Messbar ist Tree Shaking durch einen Vergleich zweier Produktions-Builds. Prüfe jeweils die Größe der JavaScript-Dateien, die tatsächlich übertragenen Bytes, den Anteil ungenutzten JavaScripts und die Ausführungszeit im Browser. Für eine belastbare Bewertung sollten Testgerät, Netzwerkprofil, Cache-Zustand und untersuchte URL identisch bleiben.

Ein kostenloser Ladezeiten-Check zeigt dir, wie schnell eine konkrete URL lädt und an welchen Stellen Optimierungspotenzial besteht. Prüfe die Seite vor und nach dem neuen Build, damit die Veränderung nicht nur im Bundle-Report, sondern auch beim ausgelieferten Dokument sichtbar wird.

Analyse starten

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.

🔒

Tageslimit erreicht!

Erstelle dir einen Free Account für die Performance Suite und erhalte trotzdem weitere Daten zu deiner URL.

Direkter Zugriff mit Free Account

Ladezeiten-Score: N/A von 100

i Ladezeiten (Desktop):	N/A
i Ladezeiten (Mobile):	N/A
i PageSpeed (Desktop):	N/A
i PageSpeed (Mobile):	N/A
i CMS:
i Gehosted bei:
i WordPress Theme:

Ladezeiten (Desktop)

Check fehlgeschlagen

✕ Optimierungsvorschläge

Leistungsmessung i

Performance-Möglichkeiten i

Ladezeiten (Mobile)

Check fehlgeschlagen

✕ Optimierungsvorschläge

Leistungsmessung i

Performance-Möglichkeiten i

Abgrenzung zu anderen Verfahren

Der Unterschied zwischen Tree Shaking und allgemeiner Dead Code Elimination liegt im betrachteten Bereich. Tree Shaking entfernt vor allem ungenutzte Exporte und Abhängigkeiten aus dem Modulgraphen. Dead Code Elimination ist weiter gefasst und kann auch unerreichbare Anweisungen innerhalb einer Funktion beseitigen, etwa Code nach einem bedingungslosen return.

Minifizierung kann ein Bundle deutlich verkürzen, entfernt aber nicht automatisch jede ungenutzte Funktion. Code Splitting verschiebt Bestandteile in separate Chunks und lädt sie beispielsweise erst beim Aufruf einer Route. Für kurze Startzeiten werden Tree Shaking, Minifizierung, Code Splitting und serverseitige Komprimierung deshalb häufig kombiniert.

Typische Fehler beim Tree Shaking

Ein häufiger Fehler ist der Import einer vollständigen Bibliothek, obwohl nur eine einzelne Funktion benötigt wird. Ob der Bundler die übrigen Bestandteile entfernen kann, hängt von der Modulstruktur und den Exporten der Bibliothek ab. Präzise Einzelimporte erleichtern die Analyse und machen im Quellcode sichtbar, welche Funktion tatsächlich verwendet wird.

• Sammeldateien exportieren zahlreiche Module erneut und erschweren die Nachverfolgung.
• CommonJS-Abhängigkeiten verhindern eine vollständige statische Analyse.
• Falsch gesetzte sideEffects-Angaben entfernen erforderlichen Initialisierungscode.
• Ein Bundle wird nur minifiziert und deshalb irrtümlich als vollständig bereinigt betrachtet.
• Die Prüfung erfolgt im Entwicklungsmodus statt am ausgelieferten Produktions-Build.

Tree Shaking sollte nie nur anhand einer erfolgreichen Build-Meldung bewertet werden. Ein Build kann technisch abgeschlossen sein und trotzdem große ungenutzte Abhängigkeiten enthalten. Vergleiche deshalb die Bundle-Zusammensetzung und teste anschließend die reale Seite. Ein umfassendes technisches SEO-Audit ordnet JavaScript-Größe, Rendering und Ladezeiten gemeinsam ein.

Tree Shaking in der Praxis

Die Umsetzung beginnt mit einer Bundle-Analyse. Suche nach großen Bibliotheken, mehrfach eingebundenen Abhängigkeiten und Modulen, deren Funktionen nur teilweise genutzt werden. Stelle anschließend gezielte Importe her, aktualisiere ungeeignete Paketformate und prüfe die Produktionskonfiguration des Bundlers.

Eine sinnvolle Reihenfolge umfasst folgende Schritte:

• Ausgangsgröße und Ladeverhalten des Produktions-Bundles dokumentieren.
• Ungenutzte Exporte und große Abhängigkeiten identifizieren.
• ES-Module und präzise Importe konsequent einsetzen.
• Seiteneffekte auf Modulebene korrekt kennzeichnen.
• Neuen Build funktional und unter identischen Bedingungen messen.

Bei einer technischen Onpage-Optimierung sollte Tree Shaking gemeinsam mit Bildgrößen, Schriftdateien, Drittanbieter-Skripten, Caching und dem kritischen Rendering-Pfad geprüft werden. Ein reduziertes eigenes Bundle gleicht beispielsweise kein schweres Tracking- oder Chat-Skript aus, das weiterhin früh und blockierend geladen wird.

Wenn du JavaScript-Bundles, Rendering und Ladezeiten strukturiert prüfen lassen möchtest, bietet ein Potenzialcheck eine belastbare Ausgangsbasis.

Kostenloser Potenzialcheck

Häufige Fragen zu Tree Shaking