Code Splitting

Code Splitting, auf Deutsch die Aufteilung des Codes, verkürzt den kritischen Ladepfad einer Website. Statt sämtliche Funktionen beim ersten Aufruf zu übertragen, erhält der Browser zunächst nur die Dateien für den sichtbaren Inhalt und die unmittelbar benötigten Interaktionen. Funktionen für weitere Seiten, Dialogfenster oder Benutzerkonten werden später geladen.

Wie funktioniert Code Splitting?

Moderne Webanwendungen bündeln JavaScript häufig in sogenannten Bundles. Ein Bundle kann Navigation, Produktsuche, Warenkorb, Kundenkonto und weitere Funktionen enthalten. Ohne Code Splitting lädt der Browser dieses gesamte Paket, obwohl ein Besucher auf einer einfachen Kategorieseite möglicherweise nur einen kleinen Teil davon nutzt.

Code Splitting zerlegt das Bundle anhand definierter Grenzen in einzelne Chunks. Ein Chunk ist eine separat abrufbare JavaScript-Datei. Der Browser lädt den Haupt-Chunk beim Seitenaufruf und fordert zusätzliche Chunks erst an, wenn eine Route, Komponente oder Funktion benötigt wird.

• Routenbasiert: Jede Seite oder Route erhält ein eigenes JavaScript-Paket.
• Komponentenbasiert: Umfangreiche Elemente wie Karten, Editoren oder Produktkonfiguratoren werden separat geladen.
• Funktionsbasiert: Selten verwendete Funktionen folgen erst nach einer konkreten Nutzeraktion.
• Abhängigkeitsbasiert: Gemeinsam genutzte Bibliotheken können in wiederverwendbaren Chunks liegen.

Dynamische Imports als Grundlage

Dynamische Imports ermöglichen es, ein JavaScript-Modul erst bei Bedarf anzufordern. Statt eines statischen Imports beim Programmstart verwendet die Anwendung beispielsweise import('./produktkonfigurator.js'). Der Build-Prozess erkennt diese Grenze und erstellt aus dem Modul einen eigenen Chunk.

Ein sinnvoller Auslöser kann ein Klick, ein Seitenwechsel oder das Erreichen eines bestimmten Bereichs sein. Der Produktkonfigurator eines Onlineshops muss beispielsweise nicht geladen werden, solange der Besucher nur die Startseite betrachtet. Öffnet der Besucher eine konfigurierbare Produktseite, fordert der Browser das zugehörige Paket an.

Code Splitting verbessert den PageSpeed

Der PageSpeed hängt nicht allein von der übertragenen Dateigröße ab. JavaScript muss heruntergeladen, analysiert, kompiliert und ausgeführt werden. Ein kleinerer initialer Chunk reduziert deshalb sowohl den Datentransfer als auch die Arbeit auf dem Hauptthread des Browsers. Der Hauptthread verarbeitet unter anderem Darstellung, Skripte und Nutzereingaben.

Code Splitting kann vor allem den Largest Contentful Paint und die Interaction to Next Paint beeinflussen. Der Largest Contentful Paint misst, wann das größte sichtbare Inhaltselement dargestellt wird. Die Interaction to Next Paint bewertet, wie schnell eine Seite auf Nutzereingaben reagiert. Eine Verbesserung entsteht jedoch nur, wenn das ausgelagerte JavaScript für die erste Darstellung und Bedienung tatsächlich entbehrlich ist.

Der verbreitete Denkfehler lautet: Je mehr Chunks eine Website verwendet, desto schneller wird sie. Viele sehr kleine Pakete erzeugen zusätzliche Netzwerkzugriffe und Verwaltungsaufwand. Werden kritische Abhängigkeiten erst über mehrere aufeinanderfolgende Anfragen geladen, entsteht eine Request-Kette. Prüfe deshalb nicht nur die Gesamtgröße, sondern auch die Anzahl, Reihenfolge und Abhängigkeiten der Dateien.

PageSpeed messbar prüfen

Messbar ist Code Splitting durch einen Vergleich vor und nach der Implementierung. Prüfe die übertragene JavaScript-Menge beim ersten Seitenaufruf, die Ausführungszeit auf dem Hauptthread und die Core Web Vitals getrennt für Mobilgeräte und Desktop. Aussagekräftig ist der Vergleich nur unter denselben Testbedingungen und mit identischen Seitentypen.

Mit dem kostenlosen Website-Speed-Test kannst du die Ladezeit einer URL prüfen und technische Optimierungspotenziale identifizieren. Teste mindestens die Startseite, eine Kategorie, eine Produktseite oder Leistungsseite und einen redaktionellen Beitrag, da diese Seitentypen meist unterschiedliche JavaScript-Pakete verwenden.

Analyse starten

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.

🔒

Tageslimit erreicht!

Erstelle dir einen Free Account für die Performance Suite und erhalte trotzdem weitere Daten zu deiner URL.

Direkter Zugriff mit Free Account

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)

Check fehlgeschlagen

✕ Optimierungsvorschläge

Leistungsmessung i

Performance-Möglichkeiten i

Ladezeiten (Mobile)

Check fehlgeschlagen

✕ Optimierungsvorschläge

Leistungsmessung i

Performance-Möglichkeiten i

Abgrenzung zu ähnlichen Methoden

Code Splitting wird häufig mit Lazy Loading, Tree Shaking und Minifizierung gleichgesetzt. Die Methoden greifen an unterschiedlichen Stellen an und können gemeinsam eingesetzt werden. Code Splitting bestimmt, wann und in welchem Paket Programmcode geladen wird. Die anderen Verfahren verändern dagegen den Umfang, den Ladezeitpunkt bestimmter Ressourcen oder die Schreibweise des Codes.

Der Unterschied zwischen Code Splitting und Lazy Loading liegt im Gegenstand der Optimierung. Code Splitting erstellt getrennte Dateien. Lazy Loading beschreibt den verzögerten Abruf einer Ressource. Ein Chunk kann daher durch Code Splitting erzeugt und anschließend per Lazy Loading geladen werden.

Relevanz für SEO, SEA und GEO

Für SEO kann Code Splitting die technische Qualität einer Website verbessern, wenn weniger blockierendes JavaScript geladen und die Hauptinhalte früher dargestellt werden. Gute Ladezeiten unterstützen die Nutzererfahrung und die Core Web Vitals. Code Splitting ersetzt jedoch keine vollständige Onpage-Optimierung, weil Server-Antwortzeit, Bilder, Schriftarten, CSS und externe Skripte ebenfalls den PageSpeed beeinflussen.

Für SEA sind schnelle Landingpages relevant, weil jeder Anzeigenklick auf eine konkrete Zielseite führt. Lädt eine Kampagnenseite zusätzlich den Code für Kundenkonto, Shop-Suche und komplexe Navigationsfunktionen, obwohl diese Elemente dort nicht benötigt werden, erhöht sich die anfängliche Datenmenge. Ein eigenes schlankes Bundle für den Landingpage-Typ kann den Seitenaufbau vereinfachen.

Für GEO, also Generative Engine Optimization, ist vor allem die zuverlässige technische Bereitstellung der Inhalte relevant. Liegen zentrale Texte oder strukturierte Informationen ausschließlich in spät geladenen JavaScript-Chunks, können Abrufprobleme die maschinelle Verarbeitung erschweren. Hauptinhalt, Überschriften, Produktdaten und interne Links sollten deshalb auch bei einer JavaScript-basierten Website stabil ausgeliefert werden.

Code Splitting richtig umsetzen

Eine sinnvolle Umsetzung beginnt mit einer Bundle-Analyse. Sie zeigt, welche Module besonders viel Speicher beanspruchen, welche Bibliotheken mehrfach vorkommen und welcher Code beim ersten Aufruf ungenutzt bleibt. Die größten Einsparungen entstehen meist bei umfangreichen Funktionen, die nur auf wenigen Seitentypen vorkommen.

• Definiere getrennte Chunks entlang von Seiten, Funktionen oder großen Komponenten.
• Lasse Navigation, Cookie-Auswahl und andere sofort benötigte Interaktionen im initialen Paket.
• Lade umfangreiche Module kurz vor ihrer erwarteten Nutzung vor, wenn das einen sichtbaren Lademoment verhindert.
• Vergib stabile Dateinamen mit Versionshashes, damit der Browser unveränderte Chunks weiter aus dem Cache nutzen kann.
• Teste Fehlerfälle, damit eine unterbrochene Chunk-Anfrage nicht die gesamte Bedienung blockiert.

Eine kurze Beobachtung aus technischen Audits: Häufig wird Code Splitting korrekt eingerichtet, während Drittanbieter-Skripte weiterhin den Hauptthread belasten. Analyse-, Chat-, Bewertungs- und Tracking-Skripte müssen deshalb in derselben Messung berücksichtigt werden. Prüfe die gesamte JavaScript-Ausführung, nicht nur die Dateien des eigenen Frontends.

Wann lohnt sich Code Splitting?

Code Splitting lohnt sich vor allem bei größeren Webanwendungen, Onlineshops und Websites mit vielen interaktiven Komponenten. Ein kleiner Internetauftritt mit wenigen Kilobyte eigenem JavaScript profitiert oft stärker von der Entfernung unnötiger Drittanbieter-Skripte, einer Bildoptimierung oder verbessertem Caching.

Die Entscheidung sollte anhand der initial übertragenen JavaScript-Menge und der tatsächlichen Nutzung getroffen werden. Enthält das Startpaket umfangreiche Module für Funktionen, die erst nach einem Seitenwechsel oder Klick benötigt werden, besteht ein klarer Ansatzpunkt. Eine technische Analyse im Rahmen eines SEO-Audits kann Code Splitting gemeinsam mit weiteren PageSpeed-Faktoren priorisieren.

Wenn du technische Ladezeitpotenziale strukturiert bewerten möchtest, kannst du deine Website unverbindlich prüfen lassen.

Kostenlosen Potenzialcheck anfragen

Häufige Fragen zu Code Splitting