Code Splitting

Was ist Code Splitting?

Code Splitting ist eine Technik der Webentwicklung, bei der JavaScript in mehrere kleinere Dateien aufgeteilt wird. Statt den gesamten Anwendungscode beim ersten Seitenaufruf zu laden, ruft der Browser nur die aktuell benötigten Teile ab. Das kann Übertragungsmenge, Verarbeitungszeit und PageSpeed beim Einstieg verbessern.

Was Code Splitting bewirkt

Code Splitting, auf Deutsch etwa Code-Aufteilung, verkleinert das JavaScript-Paket, das eine Website beim ersten Aufruf laden, analysieren und ausführen muss. Zusätzliche Funktionen werden erst abgerufen, wenn der Nutzer eine bestimmte Route öffnet, ein Element einblendet oder eine Aktion ausführt.

Der zentrale Vorteil liegt im früheren Zeitpunkt der Nutzbarkeit. Eine Anwendung kann insgesamt mehrere Megabyte JavaScript enthalten, obwohl für die Startseite nur ein Teil davon erforderlich ist. Code Splitting verschiebt den übrigen Code in separate Dateien, die häufig als Chunks bezeichnet werden. Die gesamte Datenmenge sinkt dadurch nicht automatisch, sie verteilt sich jedoch auf verschiedene Ladezeitpunkte.

Wie funktioniert Code Splitting?

Ein Bundler analysiert die Abhängigkeiten einer Anwendung und erzeugt aus Modulen mehrere JavaScript-Dateien. Der Browser lädt zunächst den Basiscode. Trifft die Anwendung später auf einen dynamischen Import, fordert sie den zugehörigen Chunk über das Netzwerk an und führt ihn anschließend aus.

Ein dynamischer Import kann vereinfacht so aussehen: import('./produktvergleich.js'). Das Modul für den Produktvergleich wird damit erst geladen, wenn die Anwendung den Import tatsächlich ausführt. Moderne Entwicklungsumgebungen können daraus automatisch eine separate Datei erzeugen.

Aufteilung nach Seiten und Routen

Beim routenbasierten Code Splitting erhält jeder größere Seitenbereich einen eigenen Chunk. Ein Onlineshop kann beispielsweise getrennte Pakete für die Startseite, Produktdetailseiten, das Kundenkonto und den Checkout ausliefern. Ein Besucher der Startseite lädt dadurch noch keinen Code, der ausschließlich im Kundenkonto benötigt wird.

Aufteilung nach Funktionen

Funktionsbasiertes Code Splitting eignet sich für umfangreiche Komponenten, die nur unter bestimmten Bedingungen erscheinen. Typische Kandidaten sind Karten, Editoren, Diagramme, Konfiguratoren, Chats oder mehrstufige Formulare. Die Aufteilung lohnt sich besonders, wenn eine Funktion viel JavaScript benötigt und nur von einem Teil der Besucher verwendet wird.

Ein vereinfachtes Rechenbeispiel: Enthält ein ursprüngliches Bundle 900 Kilobyte JavaScript und benötigt die Einstiegsseite davon nur 250 Kilobyte, können 650 Kilobyte in später geladene Chunks verschoben werden. Das Beispiel beschreibt keine feste Einsparung, sondern zeigt das Prinzip: Der Browser verarbeitet beim Einstieg weniger Code.

Code Splitting und PageSpeed

Code Splitting kann den PageSpeed verbessern, weil weniger JavaScript vor der ersten Interaktion heruntergeladen und verarbeitet werden muss. Das betrifft nicht nur die Übertragung. Der Browser muss JavaScript außerdem entpacken, analysieren, kompilieren und auf dem Hauptthread ausführen. Besonders auf mobilen Geräten kann umfangreicher Code deshalb auch nach dem Download Rechenzeit beanspruchen.

Der häufige Denkfehler lautet: Mehr Chunks ergeben automatisch eine schnellere Website. Tatsächlich kann eine sehr feine Aufteilung zusätzliche Netzwerkanfragen und Abhängigkeiten erzeugen. Werden direkt benötigte Chunks erst nacheinander entdeckt, entsteht eine Anforderungskette. Der sichtbare Inhalt erscheint dann unter Umständen später als bei einem sinnvoll gebündelten Einstiegspaket.

Code Splitting beeinflusst die Core Web Vitals nur indirekt. Weniger blockierendes JavaScript kann den Largest Contentful Paint unterstützen und den Hauptthread für Interaktionen freihalten. Eine Verbesserung tritt jedoch nur ein, wenn Bilder, Schriften, Server-Antwortzeiten und externe Skripte nicht weiterhin den Seitenaufbau verzögern.

Abgrenzung zu ähnlichen Techniken

Der Unterschied zwischen Code Splitting und Lazy Loading liegt im Gegenstand der Optimierung. Code Splitting erstellt getrennte Dateien. Lazy Loading legt fest, wann eine Ressource nachgeladen wird. Beide Verfahren werden häufig kombiniert, sind aber nicht identisch.

Technik	Wirkung	Typischer Einsatz
Code Splitting	Teilt JavaScript in mehrere Chunks	Routen, Komponenten und Funktionen
Lazy Loading	Verschiebt das Laden bis zum tatsächlichen Bedarf	Bilder, Videos, Module und Inhalte
Tree Shaking	Entfernt nicht verwendete Exporte aus dem Bundle	Unbenutzte Funktionen aus Bibliotheken
Minifizierung	Verkleinert vorhandenen Code	JavaScript, CSS und HTML

Tree Shaking und Minifizierung reduzieren die Datenmenge, während Code Splitting den Ladezeitpunkt verändert. Eine Anwendung kann daher alle drei Verfahren gleichzeitig einsetzen: ungenutzten Code entfernen, den verbleibenden Code komprimieren und umfangreiche Funktionen bedarfsgerecht ausliefern.

Umsetzung und typische Fehler

Code Splitting sollte an den Nutzungspfaden einer Website ausgerichtet werden. Für den Einstieg benötigte Navigation, Layout-Logik und zentrale Interaktionen gehören in das initiale Paket. Selten genutzte Bereiche können später geladen werden. Eine rein technische Aufteilung nach Dateigröße berücksichtigt dagegen nicht, wann der Nutzer eine Funktion tatsächlich braucht.

Teile umfangreiche Routen und selten verwendete Komponenten zuerst auf.
Vermeide sehr kleine Chunks, wenn sie bei jedem Seitenaufruf gemeinsam benötigt werden.
Plane Ladezustände für Module ein, damit beim Nachladen keine leeren Flächen entstehen.
Prüfe, ob gemeinsam genutzte Bibliotheken mehrfach in verschiedenen Chunks enthalten sind.
Nutze Preloading nur für Ressourcen, die mit hoher Wahrscheinlichkeit bald erforderlich sind.

Ein zu spät geladener Chunk kann eine zentrale Funktion blockieren. Betrifft das Nachladen beispielsweise die Navigation, den Warenkorb oder das erste Formularfeld, verschiebt Code Splitting die Wartezeit lediglich vom Seitenaufruf zur Nutzeraktion. Prüfe deshalb jeden Split anhand des tatsächlichen Nutzungspfads.

Wirkung auf SEO, SEA und GEO

Für SEO verbessert Code Splitting die technische Grundlage, wenn Inhalte schneller sichtbar und Seiten früher bedienbar werden. Der Nutzen entsteht über eine bessere Nutzererfahrung und eine effizientere Verarbeitung im Browser. Weitere technische Stellschrauben findest du in den wichtigsten SEO-Tipps für Technik und Ladezeiten.

Für SEA kann Code Splitting die Nutzererfahrung auf Kampagnen-Landingpages unterstützen. Besucher benötigen dort häufig nur wenige zentrale Funktionen. Code für Kundenkonten, komplexe Filter oder andere Seitenbereiche muss beim Anzeigenklick noch nicht geladen werden. Technische Änderungen sollten dabei gemeinsam mit Conversion-Daten bewertet werden.

Für GEO, also Generative Engine Optimization, ist Code Splitting kein direkter Optimierungsfaktor. Serverseitig ausgelieferte, klar strukturierte Inhalte bleiben für Suchmaschinen und KI-Crawler leichter zugänglich als Inhalte, die erst nach mehreren JavaScript-Aktionen erscheinen. Die laufende Kontrolle der technischen SEO sollte deshalb auch prüfen, ob zentrale Inhalte ohne verzögerte Interaktion verfügbar sind.

Code Splitting richtig messen

Messbar ist Code Splitting durch einen Vorher-Nachher-Vergleich derselben Seitentypen unter gleichen Bedingungen. Prüfe die übertragene JavaScript-Menge beim Einstieg, die Anzahl der Chunks, lange Aufgaben auf dem Hauptthread und die Core Web Vitals. Seitengröße und Ladezeit sollten gemeinsam betrachtet werden, da eine Seite neben JavaScript auch HTML, CSS, Bilder und weitere Medien überträgt.

Der Technik-Crawler der Performance Suite kann Ladezeiten und Seitengrößen verschiedener URLs überwachen. Dadurch lässt sich erkennen, ob technische Änderungen dauerhaft wirken oder einzelne Seitentypen erneut größer und langsamer werden. Die zugrunde liegenden Messwerte sollten zusätzlich mit dem Browser-Netzwerkprotokoll geprüft werden.

Prüfe den aktuellen PageSpeed deiner Website direkt mit dem kostenlosen Ladezeiten-Check:

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.

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)

Ladezeiten (Mobile)

Häufige Fragen zu Code Splitting

Braucht jede Website Code Splitting?

Nein. Eine kleine Website mit wenig JavaScript profitiert möglicherweise kaum von zusätzlichen Chunks. Code Splitting eignet sich vor allem für umfangreiche Webanwendungen, Onlineshops und Seiten mit Funktionen, die nicht jeder Besucher benötigt.

Wie viele Chunks sind sinnvoll?

Eine feste optimale Anzahl gibt es nicht. Die Chunks sollten sich an Routen, Funktionen und Nutzungspfaden orientieren. Viele winzige Dateien können zusätzliche Anfragen und schwer nachvollziehbare Abhängigkeiten erzeugen.

Kann Code Splitting die Website langsamer machen?

Ja. Wird unmittelbar benötigter Code zu spät nachgeladen, wartet der Nutzer bei der ersten Interaktion. Auch serielle Anforderungsketten oder mehrfach eingebundene Bibliotheken können die Ladezeit verlängern.

Funktioniert Code Splitting ohne JavaScript-Framework?

Ja. Code Splitting hängt nicht zwingend von einem Framework ab. Dynamische Imports und geeignete Bundler können auch in Anwendungen ohne React, Vue oder Angular getrennte Chunks erzeugen.

Was ist ein Vendor Chunk?

Ein Vendor Chunk enthält häufig gemeinsam genutzten Code externer Bibliotheken. Die Trennung kann das Browser-Caching verbessern, wenn sich der Anwendungscode öfter ändert als die eingebundenen Bibliotheken.

Kann Google Inhalte aus nachgeladenen Chunks erkennen?

Google kann JavaScript ausführen, doch das Rendering benötigt zusätzliche Ressourcen und Zeit. Zentrale Inhalte und interne Links sollten deshalb nicht erst nach einer Nutzeraktion oder einer unnötig langen Anforderungskette erscheinen.