Tree Shaking

Tree Shaking ist eine Build-Optimierung, bei der ungenutzer JavaScript-Code automatisch aus dem finalen Bundle entfernt wird. Der Name stammt von der Metapher eines Baumes: Man schuettelt den Abhaengigkeitsbaum, und der "tote" Code (Dead Code) faellt ab wie trockene Blaetter.

Tree Shaking ist ein zentraler Mechanismus moderner JavaScript-Bundler wie Webpack, Rollup, esbuild und Vite. Ohne Tree Shaking wuerden Anwendungen den gesamten Code importierter Libraries einbinden — auch Teile, die nie verwendet werden. Das Ergebnis: aufgeblaehte Bundles, langsamere Ladezeiten und hoeherer Total Blocking Time (TBT).

Wie Tree Shaking funktioniert

ES Modules als Grundlage

Tree Shaking basiert auf der statischen Struktur von ES Modules (import/export). Im Gegensatz zu CommonJS (require) sind ES Module Imports zur Compile-Zeit analysierbar — der Bundler weiss vor der Ausfuehrung, welche Exports importiert werden und welche nicht.

Der Prozess

1. Analyse: Der Bundler erstellt einen Abhaengigkeitsgraph aller Module
2. Markierung: Exports, die nirgendwo importiert werden, werden als "unused" markiert
3. Entfernung: Markierte Exports werden beim Bundling aus dem Output entfernt
4. Minification: Der verbleibende Code wird zusaetzlich durch einen Minifier (z. B. Terser) komprimiert

Beispiel

Eine Utility-Library exportiert 50 Funktionen. Die Anwendung importiert nur 3 davon:

// Library: utils.js (exportiert 50 Funktionen)
export function formatDate() { ... }
export function formatCurrency() { ... }
export function slugify() { ... }
// ... 47 weitere Funktionen

// Anwendung: page.js
import { formatDate, slugify } from './utils.js'

Mit Tree Shaking enthaelt das Bundle nur formatDate und slugify. Die anderen 48 Funktionen werden entfernt.

Seiteneffekte und Tree Shaking

Was sind Seiteneffekte?

Ein Seiteneffekt ist Code, der beim Import etwas ausfuehrt, ohne dass ein Export davon abhaengig ist — zum Beispiel das Registrieren eines Event-Listeners, das Modifizieren eines globalen Objekts oder das Ausfuehren eines Polyfills.

sideEffects in package.json

Libraries deklarieren ueber das sideEffects-Feld in package.json, ob sie Seiteneffekte enthalten:

Ohne diese Deklaration geht der Bundler vom Worst Case aus und behaelt den gesamten Code.

Tree Shaking in der Praxis

Optimale Import-Syntax

Das Barrel-File-Problem

Viele Libraries nutzen eine zentrale index.js, die alle Exports re-exportiert (Barrel File). Das kann Tree Shaking behindern, wenn der Bundler die Re-Exports nicht korrekt aufloest. Die Loesung: Direkte Imports aus dem Quellpfad.

// Suboptimal (ueber Barrel)
import { Button } from '@/components'

// Optimal (direkt)
import { Button } from '@/components/ui/Button'

Library-Auswahl

Die Wahl der Dependencies beeinflusst Tree Shaking erheblich:

• Lodash: lodash-es statt lodash nutzen (ES Module statt CommonJS)
• date-fns: Natuerlich tree-shakeable dank modularer Architektur
• Moment.js: Nicht tree-shakeable — Alternative wie date-fns oder dayjs bevorzugen
• Icons: Einzelne Icons importieren statt komplette Icon-Bibliotheken

Tree Shaking in Next.js

Next.js nutzt Webpack (oder Turbopack) und fuehrt Tree Shaking automatisch im Production-Build durch. Zusaetzliche Optimierungen:

• modularizeImports: In next.config.js konfigurierbar, wandelt Barrel-Imports automatisch in direkte Imports um
• React Server Components: Server-Components landen nicht im Client-Bundle — die ultimative Form des Tree Shakings
• Bundle Analyzer: @next/bundle-analyzer zeigt, welche Dependencies wie viel Platz einnehmen

Bundle-Groesse analysieren

Tools zur Analyse:

Die regelmaessige Bundle-Analyse ist ein wichtiger Teil der Page-Speed-Optimierung. Jedes Kilobyte JavaScript, das entfernt wird, verbessert FCP, TBT und die gesamte Ladeerfahrung.