Was sind Core Web Vitals?

Core Web Vitals sind drei von Google definierte Messgrößen für wichtige Aspekte des Nutzererlebnisses auf Webseiten. Largest Contentful Paint, kurz LCP, bewertet das Laden des größten sichtbaren Inhaltselements. Interaction to Next Paint, kurz INP, misst, wie schnell die Seite nach einer Eingabe eine visuelle Rückmeldung geben kann. Cumulative Layout Shift, kurz CLS, erfasst unerwartete Verschiebungen sichtbarer Elemente. Die Bewertung nutzt reale Seitenaufrufe und betrachtet das 75. Perzentil getrennt für Mobilgeräte und Desktop. Die empfohlenen guten Werte sind höchstens 2,5 Sekunden für LCP, höchstens 200 Millisekunden für INP und höchstens 0,1 für CLS. Diese Kennzahlen helfen, technische Verbesserungen an konkreten Problemen auszurichten. Sie beschreiben aber nicht die gesamte Qualität einer Webseite: Inhalte, Zugänglichkeit und die Verständlichkeit der Bedienung bleiben ebenfalls wichtig.

Für Largest Contentful Paint gilt ein Wert von höchstens 2,5 Sekunden als gut. Interaction to Next Paint sollte höchstens 200 Millisekunden betragen, und Cumulative Layout Shift sollte bei höchstens 0,1 liegen. Diese Schwellen beziehen sich auf das 75. Perzentil der gemessenen Seitenaufrufe, wobei mobile und Desktop-Daten getrennt betrachtet werden. Ein Durchschnittswert oder ein einzelner schneller Testlauf sagt deshalb nicht dasselbe aus wie Felddaten. Auch eine Zahl knapp unter einem Grenzwert garantiert nicht, dass jede Person auf jedem Gerät dieselbe Erfahrung macht. Prüfen Sie zusätzlich betroffene Seitentypen und häufige Abläufe, etwa Navigation, Filter und Formulare. In der Search Console können Sie URL-Gruppen mit Problemen identifizieren; PageSpeed Insights und DevTools helfen anschließend bei der Ursachenanalyse.

Interaction to Next Paint bewertet die Reaktionsfähigkeit einer Seite während der gesamten Nutzung. Es beobachtet geeignete Klicks, Tipp- und Tastatureingaben und berichtet in der Regel die langsamste Interaktion, wobei bei sehr vielen Interaktionen Ausreißer berücksichtigt werden können. First Input Delay, kurz FID, maß dagegen nur die Wartezeit vor der Verarbeitung der ersten Eingabe. FID erfasste weder spätere Interaktionen noch die vollständige Zeit bis zur nächsten sichtbaren Rückmeldung. INP hat FID deshalb als Core Web Vital abgelöst. Ein Menü, das erst beim dritten Klick träge reagiert, kann bei FID unauffällig gewesen sein und nun durch INP sichtbar werden. Für die Diagnose sollten Teams die betroffene Interaktion und ihre Teilzeiten untersuchen, statt nur einen Gesamtwert zu optimieren.

Ein fehlender INP-Wert in PageSpeed Insights bedeutet nicht automatisch, dass die Webseite schnell ist. Das Tool kann Felddaten aus dem Chrome UX Report nur anzeigen, wenn ausreichend geeignete reale Nutzungsmessungen für die betreffende URL oder den Ursprung vorliegen. Außerdem entsteht ohne relevante Klick-, Tipp- oder Tastatureingabe für einen Besuch kein INP-Messwert; Scrollen und Hover gehören nicht zu den erfassten Interaktionen. Lighthouse erzeugt im Labor einen simulierten Seitenaufruf und kann deshalb keinen vollständigen INP aus einer echten Nutzungssitzung liefern. Es weist stattdessen etwa mit Total Blocking Time auf mögliche Probleme hin. Wenn Felddaten fehlen, untersuchen Sie wichtige Interaktionen selbst in DevTools und erwägen eine datenschutzgerecht implementierte Real-User-Messung. Berichten Sie dabei klar, welche Datenquelle Sie verwenden.

Google empfiehlt gute Core Web Vitals für ein gutes Seitenerlebnis und den Erfolg in der Suche. Die Messwerte gehören zum Themenfeld Page Experience; Google beschreibt gute Werte jedoch nicht als Garantie für bessere Rankings. Ein technisch schneller Auftritt kann bei fehlender Relevanz oder schwachen Inhalten schlechter abschneiden als eine hilfreichere Seite. Auch Suchintention, Crawlbarkeit, klare Informationen und Vertrauen müssen berücksichtigt werden. Für Unternehmen ist der direkte Nutzen der Performance-Arbeit mindestens ebenso wichtig: Menschen können Inhalte früher sehen, Formulare flüssiger bedienen und Angebote ohne springende Elemente vergleichen. Legen Sie deshalb nicht nur einen pauschalen Score fest, sondern prüfen Sie die wichtigsten Seiten und Nutzerwege. Dokumentieren Sie Felddaten vor und nach Änderungen und beurteilen Sie Sichtbarkeit nicht anhand eines einzelnen Testlaufs.

Ein schlechter INP-Wert sollte zuerst einer konkreten Interaktion zugeordnet werden: Welcher Klick, welche Eingabe oder welcher Filter reagiert verzögert? Die Verzögerung kann entstehen, bevor ein Event-Handler startet, während JavaScript ausgeführt wird oder bevor der Browser die nächste visuelle Aktualisierung zeigt. Prüfen Sie im Performance-Panel der DevTools lange Aufgaben auf dem Hauptthread und wiederholen Sie typische Abläufe auch während des Seitenladens. Reduzieren Sie unnötige Skripte, teilen Sie schwere Arbeit auf und verschieben Sie nicht sichtbare Folgearbeiten, sodass die Rückmeldung früher erscheinen kann. Eine Verbesserung im Labor ist erst ein Zwischenschritt. Vergleichen Sie danach reale Felddaten, besonders für Mobilgeräte und häufig genutzte Seitentypen. So vermeiden Sie Optimierungen an einer wenig relevanten Demo-Interaktion.

Nutzen Sie zuerst Felddaten, wenn diese verfügbar sind: Der Core-Web-Vitals-Bericht der Search Console zeigt betroffene URL-Gruppen, und PageSpeed Insights kann Daten aus dem Chrome UX Report für eine URL oder einen Ursprung anzeigen. Diese Daten stammen aus geeigneten realen Chrome-Besuchen; nicht jede Seite erreicht die nötige Datenmenge. Anschließend helfen Labortests in Chrome DevTools, ein langsames Hero-Bild, blockierendes JavaScript oder springende Elemente gezielt nachzustellen. Bei INP sind echte Klicks, Formulare und andere typische Interaktionen nötig; ein reiner Seitenlade-Test reicht nicht. Prüfen Sie Mobilgeräte und Desktop getrennt und halten Sie Messzeitraum sowie Seitenvorlage fest. Nach einer Änderung vergleichen Sie die Felddaten erneut, statt einen einzelnen Lighthouse-Score als Erfolg für die gesamte Website auszugeben.