Eine Audit-Warnung wie „JS/CSS too large“ ist zunächst ein Diagnosehinweis, kein Beweis für ein SEO-Problem. Sie sagt, dass eine Seite mehr JavaScript oder CSS überträgt, als das Tool für sinnvoll hält. Ob dies echte Nutzer beeinträchtigt, hängt unter anderem von Route, Gerät, Netzwerk, Cache, Ausführungszeit und dem tatsächlich verwendeten Code ab.
Die richtige Reaktion ist daher nicht, wahllos Dateien zu löschen. Zuerst muss klar werden, welcher Code auf welcher Route geladen wird, warum er dort landet und welche reale Metrik darunter leidet.
Warum Dateigröße allein nicht genügt
Zwei gleich große JavaScript-Dateien können sehr unterschiedliche Kosten verursachen:
- Eine Datei wird komprimiert schnell übertragen und erst nach einer Interaktion ausgeführt.
- Die andere blockiert früh den Main Thread, wird geparst, kompiliert und ausgeführt, bevor die Oberfläche reagieren kann.
Bei CSS ist ebenfalls entscheidend, ob Regeln den ersten Render blockieren, ob sie für die Route benötigt werden und ob Styles später nachgeladen werden. Ein großer, gut gecachter Stylesheet ist nicht automatisch das dringendste Problem. Unbenutzte Regeln verursachen dennoch Netzwerk- und Verarbeitungsaufwand.
Tool-Grenzwerte sind deshalb ein Startpunkt. Die Priorität bestimmen Messdaten und die Importstruktur.
Wie Bundles Core Web Vitals beeinflussen können
Die drei Core Web Vitals messen unterschiedliche Teile der Nutzererfahrung:
- Largest Contentful Paint (LCP) misst, wann das größte sichtbare Inhaltselement gerendert ist. Render-blockierendes CSS, konkurrierende Downloads oder JavaScript, das den Inhalt erst erzeugt, können den LCP verzögern.
- Interaction to Next Paint (INP) misst die Reaktionsfähigkeit über die Seitennutzung. Lange JavaScript-Aufgaben, aufwendige Hydration und große clientseitige Zustandsupdates sind typische Ursachen für schlechte Interaktionen.
- Cumulative Layout Shift (CLS) misst unerwartete Layoutverschiebungen. Die Dateigröße ist hier selten die direkte Ursache; fehlende Größen für Bilder, spät ersetzte Fonts oder nachträglich eingefügte Komponenten sind meist relevanter.
„Weniger Kilobyte“ ist also kein eigenständiges Ziel. Eine Optimierung sollte zeigen, welche Render-, Main-Thread- oder Layoutkosten sie tatsächlich reduziert.
Typische Ursachen in Next.js
Zu breite Client-Grenzen
Im App Router sind Pages und Layouts standardmäßig Server Components. Sobald eine Datei mit "use client" markiert ist, gehören ihre Imports und untergeordneten Komponenten zur Client-Grenze. Ein clientseitiges Root-Layout kann dadurch Navigation, Icons, Content-Helfer und weitere Bibliotheken in den Browser ziehen, obwohl nur ein kleiner Button interaktiv sein müsste.
Die Next.js-Dokumentation zu Server und Client Components empfiehlt, Client Components so tief wie sinnvoll im Baum zu platzieren. Nicht jede Komponente mit einem interaktiven Kind muss selbst clientseitig sein.
Große Bibliotheken für kleine Aufgaben
Häufige Kandidaten sind:
- komplette Icon-Pakete statt einzelner Icons,
- Datums- oder Utility-Bibliotheken mit breiten Imports,
- Editoren, Diagramme, Maps oder Animationen im Initial Bundle,
- Syntax-Highlighter auf Routen ohne Codebeispiele,
- mehrere Libraries mit überlappender Funktion.
Entscheidend ist nicht der Paketname, sondern die Importkette. Tree Shaking kann nur entfernen, was Paketformat und Importstruktur tatsächlich entfernbar machen.
Route-unspezifische Komponenten
Ein Chat-Widget, ein komplexer Rechner oder eine Kartenansicht muss nicht auf jeder Seite im Initial Load liegen. Wird eine solche Funktion nur auf wenigen Routen oder erst nach einer Aktion gebraucht, kommen Route Splitting und dynamisches Nachladen infrage.
Globales CSS und doppelte Styles
Globale Styles sammeln sich über Jahre. Dazu kommen Komponentenbibliotheken, alte Utility-Klassen und mehrfach definierte Tokens. Bei Tailwind entstehen Probleme häufig nicht durch die Anzahl der Klassen im Quellcode, sondern durch falsche Quellerkennung, externe Pakete oder dynamisch zusammengesetzte Klassennamen. Wie ungenutzte Styles sicher reduziert werden, erklärt unser Guide zu ungenutztem CSS in Tailwind und Next.js.
Third-Party-Skripte
Consent Manager, Analytics, Video-Player, A/B-Tests und Support-Widgets erscheinen nicht immer vollständig im eigenen Bundle. Sie können trotzdem Netzwerk, Main Thread und Interaktionen belasten. Ein reiner Build-Report übersieht diesen Teil; dafür ist ein Laufzeit-Trace nötig.
Diagnose: vom Symptom zur Importkette
1. Produktionsbuild verwenden
Messen Sie keinen Development-Server. Entwicklungsbuilds enthalten zusätzliche Prüfungen und nicht dieselben Optimierungen wie Produktion. Erstellen und starten Sie einen produktionsnahen Build, bevor Größen und Laufzeitverhalten verglichen werden.
2. Bundle pro Route analysieren
Die aktuelle Next.js-Dokumentation beschreibt sowohl den integrierten Turbopack Analyzer als auch @next/bundle-analyzer für Webpack. Der passende Weg hängt von Next.js-Version und Bundler ab. Der offizielle Guide zu Package Bundling zeigt, wie Module nach Route und Umgebung gefiltert und Importketten verfolgt werden.
Suchen Sie nicht nur nach dem größten Rechteck. Fragen Sie:
- Ist das Modul Client- oder Server-Code?
- Auf welchen Routen wird es ausgeliefert?
- Welche Datei importiert es erstmals?
- Wird das gesamte Paket oder nur ein Export eingebunden?
- Ist die Funktion im ersten sichtbaren Zustand notwendig?
3. Coverage und Performance Trace nutzen
Chrome DevTools Coverage zeigt, welcher Anteil einer geladenen JS- oder CSS-Datei im untersuchten Ablauf verwendet wurde. Das Ergebnis gilt nur für diesen Ablauf: Eine nicht angeklickte Funktion erscheint als unbenutzt, obwohl sie später gebraucht wird.
Der Performance-Trace zeigt zusätzlich lange Tasks, Script-Ausführung, Rendering und Layout. Die Chrome-Dokumentation zu Lighthouse und DevTools beschreibt, wie Coverage und Main-Thread-Arbeit gemeinsam untersucht werden.
4. Feld- und Labordaten verbinden
Lighthouse reproduziert einen kontrollierten Ladefall. CrUX oder eigenes Real User Monitoring zeigen dagegen reale Geräte, Netzwerke und Interaktionen. Nutzen Sie Felddaten für Priorisierung und Labordaten für Diagnose. Ein schlechtes Bundle ohne erkennbare Nutzerwirkung kann trotzdem technische Schuld sein, ist aber nicht automatisch wichtiger als ein klarer INP-Ausreißer auf einer umsatzrelevanten Route.
Maßnahmen mit überschaubarem Risiko
Client Components verkleinern
Verschieben Sie statischen Inhalt und Datenzugriff in Server Components. Geben Sie kleinen interaktiven Komponenten nur die serialisierbaren Props, die sie brauchen. Das reduziert Client-JavaScript, ohne Funktionalität zu verlieren.
Schwere Funktionen gezielt nachladen
Editoren, Charts oder Karten können dynamisch geladen werden, wenn sie nicht für den ersten Render benötigt werden. Das verschiebt Kosten, entfernt sie aber nicht. Prüfen Sie deshalb auch die Interaktion, die den Download auslöst, und zeigen Sie einen stabil dimensionierten Ladezustand.
Imports präzisieren
Importieren Sie nur benötigte Exporte, sofern das Paket dies unterstützt. Prüfen Sie, ob eine kleinere API oder eine serverseitige Transformation dieselbe Aufgabe erfüllt. Ersetzen Sie eine Bibliothek nicht blind: Wartbarkeit, Barrierefreiheit und Fehleranfälligkeit gehören in die Entscheidung.
CSS nach Eigentümer ordnen
Trennen Sie globale Tokens und Basestyles von komponentenspezifischem CSS. Löschen Sie Regeln erst, wenn relevante Templates, Zustände, Breakpoints und CMS-Inhalte getestet sind. Eine visuelle Regression ist teurer als einige Kilobyte Ersparnis.
Drittanbieter budgetieren
Laden Sie optionale Anbieter erst, wenn Zweck und Consent-Status dies erlauben. Definieren Sie pro Kategorie ein Performance-Budget und prüfen Sie, ob ein Anbieter doppelt eingebunden ist oder auf Routen läuft, auf denen er keinen Nutzen bringt.
Was nach jeder Änderung geprüft werden muss
- Produktionsbuild und Bundle-Diff,
- Startseite sowie wichtige Landing- und Conversion-Routen,
- mobile und langsame Gerätesimulation,
- Interaktionen nach dynamischem Import,
- visuelle Zustände und Breakpoints,
- Analytics-, Consent- und Fehlertracking,
- LCP, INP und CLS in Felddaten nach ausreichend Traffic.
Ein kleineres Bundle ist nur dann eine Verbesserung, wenn die Seite weiterhin korrekt funktioniert und die Nutzerkosten sinken.
SEO realistisch einordnen
Google nennt Core Web Vitals als Teil seiner Systeme zur Bewertung der Page Experience, weist aber ausdrücklich darauf hin, dass gute Tool-Scores keine Top-Rankings garantieren. Die offizielle Page-Experience-Dokumentation empfiehlt eine ganzheitliche Nutzererfahrung statt Score-Optimierung um ihrer selbst willen.
Große Bundles sind damit kein isolierter Rankingfehler. Sie können aber Nutzererfahrung, Conversion, Rendering und Wartbarkeit verschlechtern. Genau diese Folgen machen eine fundierte Optimierung sinnvoll.
Audit-Checkliste
- Die Warnung wurde auf konkreten URLs reproduziert.
- Produktions- statt Development-Bundles wurden gemessen.
- Client- und Server-Anteile sind getrennt betrachtet.
- Die Importkette großer Module ist bekannt.
- Third-Party-Skripte sind im Laufzeit-Trace enthalten.
- Coverage wurde über relevante Interaktionen hinweg erfasst.
- Änderungen wurden mit Bundle-Diff und Funktionsprüfung validiert.
- Feldmetriken entscheiden über die endgültige Priorität.
Fazit
„JS/CSS zu groß“ ist eine Einladung zur Ursachenanalyse, keine Anweisung zum pauschalen Kürzen. In Next.js führen schmale Client-Grenzen, route-spezifische Imports, kontrolliertes Nachladen und klar strukturiertes CSS meist weiter als kosmetische Minifizierung.
Die beste Optimierung ist nachvollziehbar: Sie benennt die Importkette, reduziert eine messbare Browserlast und besteht anschließend den Funktions- und Felddatencheck.