JS-Bundle-Größe reduzieren: die fünf größten Hebel

Warum Bundle-Größe wichtig ist

Jedes Kilobyte JavaScript muss geladen, geparst und ausgeführt werden. Auf einem typischen Mid-Range-Android-Phone kostet 100 KB Parse-Zeit etwa 100-200 ms nach dem Download. Bei 4G-Verbindung schlägt der Download mit nochmal 100-300 ms zu Buche.

Folge: ein zu großes Bundle blockiert INP, schiebt LCP nach hinten und frustriert User auf älteren Geräten. Ziel für moderne Sites: Initial-JS unter 100 KB (komprimiert).

Die fünf größten Bundle-Hebel

1. Bundle-Analyzer einschalten

webpack-bundle-analyzer, rollup-plugin-visualizer, esbuild-visualizer - alle zeigen welche Module wie viel Platz brauchen. Erstens immer mal anschauen: oft sind 1-2 Libraries für die Hälfte des Bundles verantwortlich.

2. Schwere Libraries ersetzen

Schwer	Leicht	Einsparung
moment.js (290 KB)	date-fns (~10 KB tree-shaken)	~280 KB
lodash (full)	lodash-es + per-method imports	~50-70 KB
axios	fetch (native)	~15 KB
jquery	vanilla JS + querySelector	~30 KB

3. Code-Splitting via Dynamic Imports

Komponenten die erst bei User-Interaktion gebraucht werden, lazy laden:

// Statt:
import HeavyDialog from './HeavyDialog';

// Lieber:
const HeavyDialog = React.lazy(() => import('./HeavyDialog'));

Der Modal-Code lädt erst, wenn der User auf "Öffnen" klickt - nicht beim Initial-Render.

4. Tree-Shaking sicherstellen

Tree-Shaking funktioniert nur mit ES-Modules und named exports. CommonJS-Libraries oder default-Imports verhindern es. lodash → lodash-es austauschen, und statt import _ from 'lodash' lieber import { debounce } from 'lodash-es'.

5. Third-Party-Scripts kritisch prüfen

Analytics, Chat-Widgets, A/B-Test-Tools sammeln sich gerne zu mehreren MB an. Mindestens alle async/defer laden, idealerweise per IntersectionObserver erst bei Scroll-Tiefe einbinden. Tools wie Partytown verlagern sie sogar komplett in einen Web Worker.

Konkreter Audit-Workflow

1. Build mit Source-Maps + Bundle-Analyzer
2. Top 3 schwerste Pakete identifizieren
3. Pro Paket: kann ich's ersetzen? Tree-shake-friendly aufrufen? Lazy laden?
4. Build erneut, Größe vergleichen
5. Lighthouse-Score messen, INP im Field beobachten

Typische erste Reduktion in echten Projekten: 30-50 % weniger initial-JS in einer Vormittagssession.