Code Splitting ist eine Web-Performance-Technik, bei der der JavaScript-Code einer Anwendung in mehrere kleinere Dateien (Chunks) aufgeteilt wird. Statt den gesamten Code beim ersten Seitenaufruf zu laden, wird nur der fuer die aktuelle Seite benoetigte Code ausgeliefert. Weiterer Code wird bei Bedarf nachgeladen.
Code Splitting ist neben Tree Shaking die wichtigste Massnahme zur Reduzierung der JavaScript-Bundle-Groesse. Kleinere initiale Bundles bedeuten schnelleren First Contentful Paint (FCP), niedrigere Total Blocking Time (TBT) und eine insgesamt bessere Ladegeschwindigkeit.
Warum Code Splitting notwendig ist
Das Problem grosser Bundles
Eine typische Web-Anwendung besteht aus hunderten oder tausenden JavaScript-Modulen. Ohne Code Splitting wuerden alle Module in eine einzige Datei gebundelt. Auf einer Kontaktseite wuerde der Nutzer also auch den Code fuer die Portfolio-Galerie, den Blog-Editor und die Admin-Funktionen laden — obwohl er diese nie aufruft.
Der Einfluss auf Performance
| Bundle-Groesse (gzip) | Typische Parse-Zeit (Mobile) | Bewertung |
|---|---|---|
| < 100 KB | < 200ms | Gut |
| 100-300 KB | 200-600ms | Akzeptabel |
| 300-500 KB | 600-1500ms | Problematisch |
| > 500 KB | > 1500ms | Kritisch |
Mobile Geraete benoetigen 3-5x laenger als Desktop-Geraete, um die gleiche Menge JavaScript zu parsen und auszufuehren.
Strategien fuer Code Splitting
Route-basiertes Splitting
Die natuerlichste Form: Jede Seite/Route erhaelt ein eigenes Bundle. Der Nutzer laedt beim Seitenaufruf nur den Code fuer die aktuelle Route. Next.js implementiert dies automatisch — jede Datei im app/-Verzeichnis wird zu einem eigenen Chunk.
Komponentenbasiertes Splitting
Grosse oder selten genutzte Komponenten werden dynamisch geladen:
- Modal-Dialoge (werden erst bei Klick geladen)
- Bildergalerien mit komplexer Logik
- Rich-Text-Editoren
- Kartenkomponenten (z. B. Google Maps)
- Charting-Libraries
Vendor-Splitting
Third-Party-Libraries werden in ein separates Bundle ausgelagert. Da sich Vendor-Code seltener aendert als Anwendungscode, kann das Vendor-Bundle laenger im Browser-Cache bleiben.
Conditional Loading
Code wird basierend auf Bedingungen geladen:
- Feature Flags: Experimenteller Code nur fuer Testgruppen
- Geraetetyp: Touch-spezifischer Code nur auf mobilen Geraeten
- Nutzerrolle: Admin-Funktionen nur fuer Administratoren
Implementierung
Dynamic Imports
Der Standard-Mechanismus fuer Code Splitting ist der dynamische import():
// Statt:
import { HeavyComponent } from './HeavyComponent'
// Dynamisch:
const HeavyComponent = lazy(() => import('./HeavyComponent'))
Der Bundler erkennt dynamische Imports und erzeugt automatisch separate Chunks.
Code Splitting in Next.js
Next.js bietet mehrere Mechanismen:
| Mechanismus | Wann verwenden | Automatisch? |
|---|---|---|
| Route-basiert | Immer | Ja |
next/dynamic | Grosse Komponenten | Manuell |
React.lazy + Suspense | Client Components | Manuell |
| React Server Components | Server-only Code | Ja |
next/dynamic ist der empfohlene Weg fuer komponentenbasiertes Code Splitting in Next.js-Projekten. Es unterstuetzt SSR-Konfiguration, Loading-States und Named Exports.
Webpack-Konfiguration
In Webpack-basierten Projekten steuert splitChunks die Code-Splitting-Strategie:
- minSize: Minimale Chunk-Groesse (Standard: 20 KB)
- maxSize: Maximale Chunk-Groesse (Chunks werden weiter aufgeteilt)
- cacheGroups: Regeln fuer Vendor-Splitting und gemeinsam genutzte Module
Loading-Strategien
Prefetching
Chunks fuer wahrscheinliche naechste Navigationen werden im Hintergrund vorgeladen:
- Next.js prefetched automatisch alle sichtbaren
<Link>-Elemente <link rel="prefetch">fuer manuelle Kontrolle- Prefetching nutzt Leerlaufzeit des Browsers
Preloading
Chunks, die sicher benoetigt werden, werden mit hoeherer Prioritaet geladen:
<link rel="preload">fuer kritische Chunks- Vorsicht: Zu viel Preloading kann die Prioritaet wichtigerer Ressourcen senken
Loading States
Waehrend ein Chunk geladen wird, benoetigt der Nutzer visuelles Feedback:
- Skeleton Screens fuer Seitenuebergaenge
- Spinner oder Ladebalken fuer einzelne Komponenten
- Content-Platzhalter, die den Layout-Shift vermeiden
Best Practices
- Nicht ueberoptimieren: Zu viele kleine Chunks erzeugen HTTP-Overhead
- Chunk-Groesse balancieren: 20-150 KB (gzip) pro Chunk ist optimal
- Gemeinsame Abhaengigkeiten extrahieren: Shared Code nicht duplizieren
- Bundle-Analyse regelmaessig durchfuehren: Bundle-Groesse ueberwachen
- Lazy Loading fuer Below-the-Fold: Komponenten unterhalb des sichtbaren Bereichs dynamisch laden
Code Splitting ist keine einmalige Optimierung, sondern ein fortlaufender Prozess. Jede neue Abhaengigkeit und jede neue Seite beeinflusst die Bundle-Struktur — regelmaessige Analyse stellt sicher, dass die Performance nicht schleichend degradiert.