Core Web Vitals für Next.js

Next.js ist das Framework hinter vielen der größten Markenseiten, Portale und Headless-Shops, die wir messen. Es kann Seiten auf dem Server rendern, HTML streamen, Bilder und Schriften optimieren und sehr wenig JavaScript an den Browser liefern. Es kann auch das Gegenteil: eine ganze Seite aus Client-Komponenten hydrieren, ein Megabyte Bibliotheken in den ersten Ladevorgang packen und das Hero-Bild im Browser rendern. Beide Muster gibt es in Produktion, weshalb Next.js-Websites in unseren Daten auf einer einzigen Plattform von den schnellsten bis zu den langsamsten reichen. Dieser Ratgeber zeigt, wo Next.js-Websites stehen, warum der INP ihre Schwachstelle ist und welche Framework-Funktionen das Bild verändern.

Aus den Messungen von PerfDelta: 41 % der 529 gemessenen Next.js-Websites bestehen alle drei Core Web Vitals (alle gemessenen Websites: 49 %). Gut sind 70 % beim LCP, 62 % beim INP und 72 % beim CLS. Alle Werte, weitere Plattformen und Regionen zeigt die Next.js Pagespeed-Statistik. Mehr dazu im Datenblock unten.

Wo Next.js-Websites stehen

In unseren Messungen bestehen Next.js-Websites die Core Web Vitals seltener als die durchschnittliche Website, und der Abstand liegt fast vollständig beim INP. LCP und CLS sind oft in Ordnung; der Hauptthread ist es nicht. Der Datenblock unten zeigt die aktuellen Werte, die Next.js Pagespeed-Statistik ergänzt Seitengewicht, Drittanbieter und Lighthouse-Befunde, dazu einen Regionsvergleich für Deutschland, Österreich und die Schweiz und Großbritannien. Die regionalen Unterschiede sind groß, was mehr darüber sagt, wer in welchem Markt mit Next.js baut, als über das Framework.

Was Next.js-Websites typischerweise bremst

Hydrierung großer Client-Komponentenbäume

Das serverseitig gerenderte HTML kommt schnell an, dann führt React den Komponentencode im Browser erneut aus, um Event-Handler anzuhängen. Auf einer Seite, deren Komponenten überwiegend Client-Komponenten sind, ist die Hydrierung ein einziger langer Task, der jedes Tippen blockiert, bis er fertig ist. Das ist der Mechanismus hinter den meisten schlechten INP-Werten bei Next.js, und er wächst mit der Zahl der Komponenten und der Größe ihrer Props.

Bundle-Größe

Barrel-Imports, die für eine Funktion eine ganze Bibliothek ziehen, UI-Kits mit hunderten Komponenten im gemeinsamen Chunk, Datums- und Diagrammbibliotheken auf jeder Route und Polyfills für Browser, die niemand nutzt. Jedes Kilobyte wird geparst und ausgeführt; siehe Ausführungszeit und nicht verwendetes JavaScript.

Im Client gerenderte LCP-Bilder

Ein Hero-Bild in einer Client-Komponente, die erst nach der Hydrierung rendert, oder ein Hintergrundbild per CSS-in-JS ist für den HTML-Parser unsichtbar. Der Browser entdeckt es spät, und der LCP leidet. Verzögertes Laden, das eine generische Bildkomponente auch auf das Hero-Bild anwendet, verschlimmert es.

Drittanbieter-Tags

Next.js-Websites großer Unternehmen tragen Tag Manager, Consent-Werkzeuge, A/B-Tests und Personalisierung wie jede andere Unternehmensseite, und diese Skripte konkurrieren mit der Hydrierung um den Hauptthread. Der Ratgeber zu Drittanbieter-Code gilt in vollem Umfang.

Datenabruf im Client

Seiten, die ein Skelett rendern, dann in useEffect Daten holen und erst dann den echten Inhalt rendern, schieben den LCP um einen vollen Hin- und Rückweg nach hinten und verursachen oft Layout-Verschiebungen, wenn der Inhalt eintrifft.

Maßnahmen innerhalb des Frameworks

1. Komponenten standardmäßig als Server Components. Im App Router ist eine Komponente eine Server-Komponente, solange sie kein 'use client' deklariert. Schieben Sie die Client-Grenze nach unten zu den Blättern, die Interaktivität brauchen (ein Button, ein Formular, ein Karussell), und lassen Sie Layout, Text und Datenabruf auf dem Server. Weniger Client-Code heißt weniger Hydrierung und ein kleineres Bundle.
2. Das LCP-Bild mit next/image und priority. <Image priority /> rendert das Hero-Bild im HTML, lädt es vorab, setzt fetchpriority="high" und schaltet das verzögerte Laden ab. Alle anderen Bilder behalten das verzögerte Laden. Geben Sie Bildern feste Maße oder fill in einem Container mit Größe, um Layout-Verschiebungen zu vermeiden.
3. next/font nutzen. Es hostet Schriften selbst, lädt sie vorab, setzt font-display und erzeugt eine größenangepasste Ersatzschrift. Das beseitigt schriftbedingten CLS und einen externen Ursprung in einem Schritt.
4. Bundle analysieren und aufteilen. Lassen Sie den Bundle-Analyzer laufen, ersetzen Sie Barrel-Imports durch direkte Importe (oder aktivieren Sie die Import-Optimierung des Frameworks für große Bibliotheken), laden Sie schwere Komponenten mit next/dynamic, mit ssr: false nur dort, wo sie wirklich nur im Client laufen, und lagern Sie selten genutzte Routen in eigene Chunks aus.
5. Daten auf dem Server abrufen. Server Components und Route Handler holen Daten während des Renderns, sodass das HTML vollständig ankommt. Nutzen Sie Streaming mit Suspense-Grenzen für langsame Daten, damit die Hülle zuerst erscheint, ohne Wasserfall im Client.
6. Drittanbieter-Skripte mit next/script laden. Die Strategien afterInteractive und lazyOnload halten Tags vom kritischen Pfad fern; beforeInteractive ist für das seltene Skript, das zuerst laufen muss, etwa einen Consent-Manager.
7. Lange Tasks im Client-Code aufteilen. Wo Interaktivität schwer bleibt, geben Sie zwischen den Schritten an den Hauptthread ab (siehe Ausführungszeit) und vermeiden Sie synchrone Layout-Abfragen in Event-Handlern.
8. Cachen und nah am Publikum hosten. Statische und inkrementell regenerierte Seiten vom Netzwerkrand halten die TTFB niedrig; vollständig dynamisches Server-Rendering in einer einzigen Region nicht.

Das Ergebnis messen

Verfolgen Sie den INP im Feld je Route, denn Startseite und eine Produkt- oder Artikelroute hydrieren sehr unterschiedlich. Im Labor beobachten Sie die Total Blocking Time und die Hauptthread-Aufschlüsselung in Lighthouse; die Hydrierung erscheint als ein breiter Task, der dem Framework-Chunk zugeordnet ist. Das Monitoring von PerfDelta zeigt den INP im Feld je URL neben dem Next.js-Median, sodass die Wirkung einer verschobenen Client-Grenze binnen des 28-Tage-Fensters sichtbar wird.

Häufige Fragen

Ist Next.js schlecht für die Core Web Vitals?

Nein. Das Framework bietet alles, was zum Bestehen nötig ist. Die Websites, die scheitern, liefern meist große Client-Komponentenbäume und schwere Bundles aus, was das Framework erlaubt, aber nicht verlangt.

App Router oder Pages Router für die Performance?

Der App Router mit Server Components gibt mehr Kontrolle darüber, wie viel JavaScript den Browser erreicht. Eine gut gebaute Pages-Router-Website kann ebenfalls bestehen; der Unterschied liegt in den Voreinstellungen, nicht in der Obergrenze.

Warum ist der INP schlecht, obwohl der LCP gut ist?

Schnelles HTML vom Server bringt den Inhalt auf den Bildschirm, dann belegen Hydrierung und Drittanbieter-Skripte den Hauptthread. Der Besucher sieht die Seite schnell, kann aber nicht mit ihr interagieren. Weniger Client-Code und aufgeteilte lange Tasks beheben das.

Hilft next/image immer?

Für das LCP-Bild nur mit priority; sonst lädt es das Hero-Bild verzögert und verschiebt den LCP. Für alles unterhalb des sichtbaren Bereichs sind die Voreinstellungen richtig.