Core Web Vitals sind Googles Rahmenwerk zur Messung der realen Seitenerfahrung und ein bestätigter Rankingfaktor. Next.js gibt dir gegenüber den meisten Frameworks einen deutlichen Vorsprung, aber eine schlecht konfigurierte Next.js-Seite kann bei diesen Metriken trotzdem scheitern. Hier ist eine praktische Anleitung, um jede davon zu diagnostizieren und zu beheben.
Schritt 1: Messen, Bevor du Behebst
Bevor du irgendetwas änderst, hol dir genaue Ausgangswerte. Es gibt zwei Arten von CWV-Daten:
Felddaten (Messungen echter Nutzer) — Verfügbar in Google Search Console unter "Core Web Vitals" und in PageSpeed Insights unter "Entdecke, was deine echten Nutzer erleben". Das nutzt Google für Rankings. Es braucht genug Traffic, um statistische Signifikanz zu erzeugen.
Labordaten — Verfügbar in Lighthouse (Chrome DevTools → Lighthouse-Tab) und PageSpeed Insights. Nützlich für die Entwicklung, aber Google nutzt sie nicht für Ranking-Entscheidungen.
Behebe immer basierend auf Felddaten, wo verfügbar. Laborwerte können irreführend sein — eine Seite kann in Lighthouse 100 Punkte erreichen und trotzdem ein schlechtes Feld-INP haben, wenn viel clientseitiges JavaScript vorhanden ist.
Schritt 2: LCP Beheben (Largest Contentful Paint)
LCP sollte unter 2,5 Sekunden liegen. Häufigste Ursachen auf Next.js-Seiten:
Hero-Bilder laden zu spät. Jedes Hero-Bild sollte die priority-Prop bei next/image nutzen. Das sagt Next.js, das Bild vorzuladen und nicht per Lazy Loading zu laden:
<Image src="/hero.webp" alt="Hero" width={1200} height={600} priority />
Falsches Bildformat. next/image liefert automatisch WebP und AVIF, aber nur, wenn du die Komponente nutzt. Wenn irgendwo <img>-Tags vorkommen — prüfe deine Markdown-Renderer und Drittanbieter-Komponenten —, werden diese Bilder nicht optimiert.
Langsame Serverantwort (TTFB). Auf Vercel sollte TTFB unter 200 ms liegen. Falls höher, prüfe, ob du langsame Datenbankaufrufe in generateStaticParams oder Layout-Komponenten machst. Bevorzuge statische Generierung gegenüber serverseitigem Rendering für Seiten, deren Inhalt sich selten ändert.
Render-blockierende Schriftarten. Füge display: "swap" zu allen Google-Fonts-Imports in Next.js hinzu:
const inter = Inter({ subsets: ["latin"], display: "swap" });
Schritt 3: CLS Beheben (Cumulative Layout Shift)
CLS sollte unter 0,1 liegen. Häufigste Ursachen auf Next.js-Seiten:
Bilder ohne explizite Abmessungen. Gib next/image immer width und height mit. Die Komponente nutzt diese, um vor dem Laden des Bildes Platz zu reservieren, und verhindert so Layout-Verschiebungen.
Webfonts, die FOUT verursachen. Nutze font-display: swap (wird von next/font/google automatisch gehandhabt) und stelle eine Preconnect-Verbindung zu Font-Quellen her. Vermeide das Laden von Fonts von CDNs ohne Preconnect.
Dynamisch eingefügte Banner oder Cookie-Hinweise. Wenn ein Cookie-Banner oder eine Benachrichtigung nach dem Laden der Seite über dem Content erscheint, verschiebt das den Content nach unten und erzeugt CLS. Reserviere den Platz in deinem Layout, oder nutze feste Positionierung, damit es überlagert statt verdrängt.
Schritt 4: INP Beheben (Interaction to Next Paint)
INP sollte unter 200 ms liegen. Es ersetzte 2024 den FID und ist der am schwersten zu behebende CWV, weil es die Interaktivität über den gesamten Seiten-Lebenszyklus misst, nicht nur beim Laden.
Schwere Client-Komponenten. Im Next.js App Router sollten Komponenten, die keine Interaktivität brauchen, Server-Komponenten sein. "use client" sollte nur erscheinen, wenn du wirklich Browser-APIs, Event-Handler oder Hooks brauchst. Unnötige Client-Komponenten vergrößern das JavaScript-Bundle, das geparst und ausgeführt werden muss.
Den Main Thread blockieren. Große, synchron ausgeführte JavaScript-Bundles blockieren Nutzerinteraktionen. Nutze dynamische Imports für schwere Komponenten:
const HeavyComponent = dynamic(() => import("./HeavyComponent"), { ssr: false });
Skripte von Drittanbietern. Analytics, Chat-Widgets und Werbeskripte sind eine häufige Quelle von INP-Problemen. Lade sie mit next/script über strategy="afterInteractive" oder strategy="lazyOnload", um ihre Ausführung zu verzögern, bis die Seite interaktiv ist.
Schritt 5: Monitoring Nach dem Fix
Fixes zeigen sich nicht sofort in Felddaten. Googles CrUX-Daten (die Search Console und die PageSpeed-Insights-Felddaten speisen) haben ein rollierendes 28-Tage-Fenster. Rechne mit 4–6 Wochen nach dem Deployment von Fixes, bevor sich Felddaten verbessern.
Verfolge in dieser Zeit Laborwerte, um zu bestätigen, dass die Fixes wirken. Richte Vercel Analytics ein, um Core Web Vitals echter Nutzer kontinuierlich zu überwachen — es zeigt INP-Probleme auf, die Labortools übersehen.
Sobald die Felddaten aufholen, solltest du korrelierende Verbesserungen bei organischen Rankings sehen, besonders bei Seiten, die zuvor im Bereich "verbesserungswürdig" oder "schlecht" lagen. Kombiniere diese Arbeit mit den übrigen Punkten unserer technischen SEO-Checkliste — Core Web Vitals sind einer von 20 Faktoren, die dein Ranking bestimmen.
Die Abkürzung: Von Anfang an Richtig Bauen
Jeder Schritt in diesem Leitfaden existiert, weil die Website nicht von Anfang an mit diesen Überlegungen gebaut wurde. Der kosteneffizienteste Ansatz ist, auf einem richtig konfigurierten Next.js-Fundament zu bauen, das mit grünen Core Web Vitals startet. Diese Verbesserungen haben auch über Rankings hinaus einen direkten geschäftlichen Effekt — die Daten zu Website-Geschwindigkeit und Conversion-Rate zeigen genau, wie messbar das ist.
Unser Webdesign- und Entwicklungsservice beinhaltet technisches SEO und Core-Web-Vitals-Optimierung standardmäßig bei jedem Projekt. Wenn du wissen willst, wo deine aktuelle Website steht, zeigt dir ein kostenloser Check genau, welche Metriken dein Ranking beeinflussen.
Bereit, dein Geschäft online wachsen zu lassen? Hol dir deinen kostenlosen Check →