Code Splitting

Definition: Code Splitting ist eine Build-Tool-Technik, bei der der JavaScript-Bundle einer Webanwendung in mehrere kleinere Teilpakete (Chunks) aufgeteilt wird, die nur bei tatsächlichem Bedarf geladen werden. Statt beim ersten Seitenaufruf den gesamten Anwendungscode zu laden, erhält der Browser nur den für die aktuelle Seite oder Route notwendigen Code sofort – restlicher Code wird bei Bedarf nachgeladen. Dadurch sinkt die initiale Datenmenge, der Browser muss weniger parsen und ausführen und Time to Interactive (TTI) sowie Interaction to Next Paint (INP) verbessern sich messbar. Webpack, Vite und Rollup unterstützen Code Splitting nativ; React, Vue und Angular bieten Framework-spezifische APIs.

Erläuterung

Ohne Code Splitting wächst der JavaScript-Bundle mit jeder neuen Seite und Feature linear: Eine SPA mit 20 Seiten lädt den Code aller 20 Seiten beim ersten Aufruf – obwohl der Nutzer vielleicht nur eine Seite besucht. Code Splitting ist die technische Antwort auf dieses Problem und eine der wirksamsten Maßnahmen für Frontend-Performance bei komplexen Web-Applikationen.

Code-Splitting-Strategien

Route-basiertes Splitting: Jede Seite/Route wird als separater Chunk gebundelt; wird erst geladen wenn Nutzer die Route besucht; reduziert Initial-Bundle um 60–80 % bei großen SPAs; React: React.lazy() + Suspense; Vue: defineAsyncComponent; Next.js und Nuxt: automatisch per Dateistruktur
Component-basiertes Splitting: Schwere Komponenten (Modal, Rich-Text-Editor, Chart-Bibliothek, PDF-Viewer) erst bei Bedarf laden; dynamic import() für Lazy Loading von Komponenten; Beispiel: Chart.js (400 KB) erst laden wenn Dashboard-Seite geöffnet wird
Vendor-Chunk-Splitting: Third-Party-Abhängigkeiten (node_modules) in separaten Chunk auslagern; lang cachebar weil sie sich selten ändern; App-Code-Bundle klein und aktualisiert sich häufig; separate Cache-Strategien für App und Vendor Chunks möglich
Entry-Point-Splitting: Mehrere Build-Einstiegspunkte für verschiedene Seiten-Typen (Landing Page, Dashboard, Checkout); jeder Entry-Point erzeugt eigenen Bundle; geeignet für Multi-Page Applications (MPA) die bestimmte JS-Features nur auf manchen Seiten brauchen

Dynamic Import und Lazy Loading

dynamic import() Syntax: const { default: Chart } = await import('chart.js'); lädt Modul erst bei Ausführung dieser Zeile; Promise-basiert; funktioniert in allen modernen Build-Tools; trigger-basiertes Laden (bei Klick, bei Scroll, bei Hover) möglich
React.lazy und Suspense: const MyComponent = React.lazy(() => import('./MyComponent')); kombiniert mit <Suspense fallback={<Loading />}>; automatisches Code Splitting für Komponenten; Suspense zeigt Fallback während Chunk lädt
Intersection Observer für Scroll-basiertes Laden: Komponenten erst laden wenn sie in den Viewport scrollen; geeignet für below-the-fold Inhalte; reduziert nicht nur Bundle-Größe sondern auch tatsächlich übertragene Datenmenge

Preloading und Prefetching

Preload für kritische Chunks: <link rel="preload" as="script"> für Chunks die mit hoher Wahrscheinlichkeit sofort gebraucht werden; lädt parallel zum Initial-Bundle; vermeidet Ladezeit-Spitze beim ersten Nutzer-Klick auf lazy-geladene Seite
Prefetch für wahrscheinliche Navigation: <link rel="prefetch"> für Chunks der nächsten wahrscheinlichen Route; Browser lädt in Idle-Zeit; Nutzer erlebt nahezu sofortigen Seitenwechsel; Next.js prefetcht automatisch alle verlinkten Seiten im Viewport
Magic Comments in Webpack: import(/* webpackPrefetch: true */ './route') und import(/* webpackPreload: true */ './module') für deklaratives Preload/Prefetch; Vite: ähnliche Mechanismen via Rollup-Konfiguration

Performance-Impact und Messung

Einfluss auf Core Web Vitals: Großes Initial-JS-Bundle blockiert Main Thread und verzögert LCP und INP; Code Splitting reduziert Parse+Execute-Zeit beim Initial Load; Lighthouse: «Reduce unused JavaScript» direkt adressiert durch Code Splitting; JavaScript Execution Time im Performance-Panel messbar
Bundle-Analyse nach Splitting: webpack-bundle-analyzer: Treemap aller Chunks nach Splitting; rollup-plugin-visualizer für Vite; identifiziert zu große Chunks die weiter aufgeteilt werden sollten; prüft ob Third-Party-Libs korrekt in Vendor-Chunk landen

Praxistipp: Starten Sie Code Splitting mit der einfachsten Maßnahme: Route-basiertes Splitting in Ihrer SPA. In React: ersetzen Sie alle statischen Seiten-Imports durch React.lazy(); in Next.js und Nuxt ist es automatisch aktiviert. Messen Sie danach mit Lighthouse den «Unused JavaScript»-Wert und «JavaScript Execution Time» – eine typische SPA-Optimierung reduziert den Initial-Bundle um 40–60 %. Als zweiten Schritt identifizieren Sie die drei größten Komponenten in Ihrem Bundle via webpack-bundle-analyzer und prüfen ob sie lazy-geladen werden können (Modal, Chart-Bibliothek, Rich-Text-Editor sind häufige Kandidaten für 100–400 KB spontane Einsparungen).