Core Web Vitals 2026: was das Ranking wirklich beeinflusst

Was die Core Web Vitals heute messen

Core Web Vitals sind drei Metriken, die beschreiben, wie sich eine Seite für echte Besucher anfühlt. Largest Contentful Paint (LCP) misst das Laden: wie lange es dauert, bis das Hauptbild oder der wichtigste Textblock sichtbar ist. Interaction to Next Paint (INP) misst die Reaktionsfähigkeit: wie schnell die Seite nach Tippen, Klicken oder Tastendruck sichtbar reagiert. Cumulative Layout Shift (CLS) misst die visuelle Stabilität: wie stark Inhalte beim Laden springen.

Eine Seite besteht, wenn mindestens 75 % der Besuche im „guten“ Bereich liegen: LCP höchstens 2,5 Sekunden, INP höchstens 200 Millisekunden und CLS höchstens 0,1. Mobil und Desktop werden getrennt bewertet, und mobil ist fast immer schwieriger.

INP hat im März 2024 First Input Delay (FID) als Core Web Vital abgelöst. FID maß nur die Verzögerung der ersten Interaktion; INP betrachtet die langsamsten Interaktionen des gesamten Besuchs. Viele Websites, die bei FID klar grün waren, wurden mit INP gelb oder rot.

Wie stark beeinflussen sie das Ranking?

Core Web Vitals gehören zu Googles Page-Experience-Signalen. Sie wiegen nicht schwerer als Relevanz: Eine langsame Seite mit der besten Antwort schlägt weiterhin eine schnelle Seite mit einer schwachen. Wichtig werden sie zwischen Seiten ähnlicher Qualität – und vor allem bei der Conversion: Besucher verlassen langsame, springende Seiten unabhängig vom Ranking.

Deshalb behandeln wir die Metriken zuerst als Geschäftskennzahl und erst dann als SEO-Kennzahl. Schnellere Seiten verkaufen mehr, bringen mehr Anfragen und machen bezahlten Traffic günstiger.

Felddaten und Labordaten

Lighthouse und die Laborwerte von PageSpeed Insights simulieren einen einzelnen Besuch auf einem gedrosselten Gerät. Sie helfen bei der Fehlersuche, aber Google bewertet anhand von Felddaten aus dem Chrome User Experience Report (CrUX), gesammelt von echten Chrome-Nutzern über 28 Tage.

Beginne mit dem Core-Web-Vitals-Bericht der Search Console, um zu sehen, welche URL-Gruppen bei welcher Metrik durchfallen. Nutze dann PageSpeed Insights für die Felddaten einer einzelnen URL und das Performance-Panel der Chrome DevTools, um die Ursache zu finden.

LCP verbessern

Die meisten LCP-Probleme haben vier Ursachen: eine langsame Serverantwort, ein spät entdecktes Hauptbild, render-blockierendes CSS und Schriften oder schlicht ein zu großes Bild.

• Bring die Time to First Byte unter etwa 800 ms: Full-Page-Caching für anonyme Besucher, ein CDN und schnelle Datenbankabfragen.
• Lade das LCP-Bild nie per Lazy Loading. Gib ihm fetchpriority="high" und lade es vorab, wenn es per CSS gesetzt wird.
• Liefere AVIF oder WebP in passender Größe mit srcset und sizes statt eines großen JPEGs.
• Binde kritisches CSS inline ein und lade den Rest nicht blockierend; hoste Schriften selbst und nutze font-display: swap.

INP verbessern

INP ist fast immer ein JavaScript-Problem. Ist der Main Thread mit einer langen Aufgabe beschäftigt – alles über 50 ms –, kann der Browser erst danach auf das Tippen des Nutzers reagieren.

Prüfe zuerst Skripte von Drittanbietern: Chat-Widgets, Heatmaps, A/B-Test-Tools und mehrere Tag-Container kosten oft Hunderte Millisekunden. Lade sie erst nach einer Interaktion oder nur auf bestimmten Seiten. Halte im eigenen Code Event-Handler klein, entprelle Eingabe-Handler und teile lange Arbeit in kleinere Stücke, damit der Browser zwischendurch zeichnen kann. Ein sehr großes DOM (mehrere tausend Elemente) bremst ebenfalls jede Interaktion – typisch bei Page Buildern.

// Let the browser paint between chunks of heavy work
async function processInChunks(items, handle) {
  for (const item of items) {
    handle(item);
    await new Promise((resolve) => setTimeout(resolve, 0));
  }
}

CLS verbessern

• Setze bei Bildern, Videos und iframes immer width und height (oder aspect-ratio).
• Reserviere Platz für Anzeigen, Einbettungen und Cookie-Banner, statt Inhalte beim Laden nach unten zu schieben.
• Füge nach dem Rendern keine Banner oder Hinweise oberhalb bestehender Inhalte ein.
• Nutze Fallback-Schriften mit passenden Metriken (size-adjust), damit der Text beim Laden der Webschrift nicht umbricht.

Besonderheiten bei Laravel und WordPress

Bei Laravel bringen Produktions-Caches (php artisan config:cache, route:cache, view:cache), OPcache, Redis für Cache und Sessions sowie Eager Loading gegen N+1-Abfragen, die das erste Byte verzögern, schnelle Erfolge. Baue Assets mit Vite, damit CSS und JavaScript minifiziert und versioniert sind, und verlagere langsame Arbeit wie E-Mails und API-Aufrufe in Queues.

Bei WordPress kommen die meisten Probleme von Plugins. Entferne unnötige Plugins, nutze einen richtigen Seiten-Cache (LiteSpeed Cache funktioniert auf LiteSpeed-Servern sehr gut), optimiere Bilder beim Hochladen, halte PHP auf einer unterstützten 8.x-Version und sei vorsichtig mit schweren Page Buildern.

Messen, dann warten

Binde die Open-Source-Bibliothek web-vitals ein, um echte LCP-, INP- und CLS-Werte an GA4 oder einen eigenen Endpunkt zu senden – so siehst du Änderungen in Tagen statt auf CrUX zu warten. Der Search-Console-Bericht nutzt ein gleitendes 28-Tage-Fenster; nach einer Korrektur dauert es daher etwa vier Wochen, bis der Status grün wird. Bestätige die Korrektur dort, sobald die neuen Daten da sind.

Für einen schnellen ersten Blick auf deine eigene Website meldet unser kostenloser Website-Check langsame Antworten, fehlende Komprimierung und andere häufige Ursachen.