Core Web Vitals für Einsteiger: LCP, INP und CLS messen und verbessern

Core Web Vitals messen drei Aspekte eines Websitebesuchs: wie schnell der größte sichtbare Inhalt erscheint, wie zügig die Seite auf Interaktionen reagiert und ob sich das Layout unerwartet verschiebt. Die aktuellen Kennzahlen heißen Largest Contentful Paint (LCP), Interaction to Next Paint (INP) und Cumulative Layout Shift (CLS). Prüfen Sie zunächst die Ergebnisse realer Nutzer. Suchen Sie anschließend mit einer kontrollierten Browseraufzeichnung nach dem Element, der Interaktion oder der Layoutänderung hinter dem Problem.

Eine Seite kann fertig aussehen und trotzdem schlecht auf einen Fingertipp reagieren. Sie kann sofort reagieren, während eine Anzeige den gerade gelesenen Absatz nach unten schiebt. Das sind unterschiedliche Probleme. Wer sie als einen allgemeinen Geschwindigkeitswert behandelt, erschwert die Optimierung unnötig.

Entscheidend ist nicht allein, ob Ihre Website schnell ist. Entscheidend ist, welcher Teil des Besuchs für welche Besucher scheitert und welche Beobachtung die Wirkung Ihrer Änderung belegen würde.

Lesen Sie die drei Kennzahlen vor dem Gesamtwert

Googles Methodik für die Core-Web-Vitals-Grenzwerte verwendet getrennte Ziele für Laden, Reaktionsfähigkeit und visuelle Stabilität. Die folgenden Grenzen gelten für die Messwerte, nicht für den farbigen Lighthouse-Leistungswert.

LCP verfolgt während des Ladens das größte berücksichtigte Bild oder Textelement im sichtbaren Bereich. Das kann ein Produktfoto, eine Artikelüberschrift oder ein großer Textblock sein. Der Wert bezeichnet nicht den Zeitpunkt, an dem jedes Bild heruntergeladen wurde. Ein schnell sichtbares kleines Logo gleicht verspäteten Hauptinhalt nicht aus.

INP beschreibt die Verzögerung zwischen einer erfassten Interaktion und der nächsten sichtbaren Aktualisierung. Klicks, Berührungen und Tastatureingaben zählen; reines Scrollen ist nicht dieselbe Messung. Der gemeldete Wert entspricht im Allgemeinen der langsamsten Interaktion des Besuchs, wobei bei sehr vielen Interaktionen Ausreißer berücksichtigt werden. Er umfasst das Warten auf den Hauptthread, die Ausführung der Ereignisbehandlung und die Vorbereitung des nächsten Bildes.

CLS ist ein einheitenloser Wert für unerwartete Bewegungen sichtbarer Inhalte. Dabei zählen sowohl der betroffene Anteil des sichtbaren Bereichs als auch die Entfernung der Verschiebung. Die Kennzahl verwendet die größte relevante Folge von Verschiebungen, anstatt sämtliche Bewegungen eines beliebig langen Besuchs zu addieren. Manche Bewegungen nach einer kürzlich erfolgten Eingabe sind ausgeschlossen. Trotzdem ist nicht jede durch Interaktion ausgelöste Layoutänderung unproblematisch.

Diese Unterschiede erklären, warum eine einzelne Maßnahme selten alles löst. Ein komprimiertes Hauptbild kann das Laden verbessern, entfernt aber kein aufwendiges JavaScript aus einem Filterknopf. Reservierter Platz für eine Einbettung stabilisiert das Layout, ohne deren Skript zu beschleunigen.

Verstehen Sie die Aussage des 75. Perzentils

Core-Web-Vitals-Bewertungen verwenden das 75. Perzentil, meist p75 genannt. Ordnen Sie die Messwerte vom schnellsten zum langsamsten: Ungefähr drei Viertel der gemessenen Erfahrungen liegen bei oder unter p75. Es ist weder der Durchschnitt noch der Wert Ihres letzten eigenen Besuchs.

Stellen Sie sich zur Veranschaulichung eine Gruppe von Besuchen vor, bei der die meisten Menschen die Seite schnell sehen, eine erhebliche Minderheit aber deutlich länger wartet. Ein Durchschnitt kann diese ungleiche Erfahrung verdecken. Ein Perzentil zeigt, ob ein breiter Besucheranteil das Ziel erreicht, ohne die gesamte Bewertung von wenigen Extremfällen abhängig zu machen.

Bewerten Sie Mobilgeräte und Desktopgeräte getrennt. Ein responsives Design kann dieselbe URL verwenden und dennoch unterschiedliche Bilder liefern, andere Bedienelemente anzeigen und auf anderer Hardware laufen. Ein gutes Desktop-Ergebnis beweist keine ebenso gute mobile Erfahrung.

Für eine vollständige Bewertung aller drei Kennzahlen müssen die jeweiligen p75-Werte sämtliche guten Grenzwerte erfüllen. Fehlende Messungen sind gesondert zu behandeln. Ein Besuch ohne relevante Interaktion erzeugt insbesondere keinen INP-Wert. Tragen Sie dafür keine Null in eine Tabelle ein: Das würde eine tatsächlich gemessene sofortige Reaktion bedeuten.

Googles Berichtswerkzeuge haben außerdem eigene Regeln für ausreichende Datenmengen. PageSpeed Insights kann LCP und CLS bewerten, wenn genügend INP-Daten fehlen. Lesen Sie die tatsächliche Bewertung und die Datenabdeckung. Erfinden Sie keinen fehlenden Wert und unterstellen Sie nicht allen Werkzeugen identische Darstellungsregeln.

Trennen Sie Nutzungsberichte von kontrollierten Tests

Felddaten beschreiben aufgezeichnete Besuche, Labordaten einen kontrollierten Test. Beide sind nützlich, beantworten aber unterschiedliche Fragen.

Der Chrome User Experience Report, kurz CrUX, fasst geeignete Chrome-Nutzungserfahrungen zusammen. Seine API liefert ein rollierendes Erfassungsfenster von 28 Tagen. PageSpeed Insights nutzt CrUX im Abschnitt über reale Nutzer und führt im Laborabschnitt Lighthouse unter festgelegten Bedingungen aus. Die Ergebnisse dürfen voneinander abweichen.

Ein Labortest lädt vielleicht die Startseite ohne gespeicherte Einwilligung, Anmeldung oder Interaktion. Ihre Besucher schließen dagegen einen Hinweis, öffnen das Menü, filtern Produkte, scrollen zu einem eingebetteten Video und kehren zu einer zwischengespeicherten Seite zurück. Diese Abläufe aktivieren Arbeit, die ein reiner Ladetest nie ausführt.

Auch der umgekehrte Fall ist möglich. Ein eingeschränkter Labortest kann schlechter ausfallen als die Erfahrung eines großen Teils Ihres Publikums. Untersuchen Sie dann die Bedingungen, statt das Ergebnis zu verwerfen. Der Test kann einen echten Engpass zeigen, der auf langsamerer Hardware oder bei schwächeren Verbindungen wichtig wird.

CrUX repräsentiert außerdem nicht jeden Browser und jeden Besucher. Seiten benötigen genügend geeigneten Traffic und müssen Aufnahmekriterien erfüllen. Ein fehlender Bericht ist eine Frage der Datenverfügbarkeit, kein Beweis für eine schnelle oder langsame Seite. Google veröffentlicht keine allgemeingültige Besucherzahl, die die Aufnahme garantiert.

Nutzen Sie unseren Leitfaden zu Feld- und Labordaten, wenn Berichte widersprüchlich wirken. Notieren Sie vor dem Vergleich URL, Gerätekategorie, Erfassungszeitraum und den Bezug auf eine einzelne URL oder den gesamten Origin.

Wählen Sie den Bericht passend zur Frage

PageSpeed Insights ist ein sinnvoller Einstieg für eine öffentliche URL. Prüfen Sie zuerst die Nutzerdaten, sofern vorhanden. Achten Sie darauf, ob sie die angeforderte Seite beschreiben oder auf den Origin zurückfallen. Ein Origin umfasst Seiten mit demselben Schema, Hostnamen und Port; er diagnostiziert nicht jede Vorlage einzeln.

Untersuchen Sie danach den Laborabschnitt. Seine Diagnosen und Hinweise nennen mögliche Ursachen. Sie sind keine Liste unabhängiger Punktabzüge. Addieren Sie geschätzte Einsparungen nicht zu einem versprochenen Gesamtergebnis: Mehrere Empfehlungen können dieselbe zugrunde liegende Verzögerung betreffen.

Search Console zeigt URL-Gruppen mit ähnlichen Nutzungsproblemen. Das ist besonders hilfreich, wenn eine gemeinsame Vorlage viele Artikel oder Produkte betrifft. Öffnen Sie repräsentative URLs und prüfen Sie deren gemeinsame Umsetzung. Die Bearbeitung einer Beispielseite behebt nicht automatisch das Problem der gesamten Gruppe.

Chrome DevTools ermöglicht die Untersuchung des tatsächlichen Ablaufs. Zeichnen Sie zum Prüfen von LCP das Laden auf, für die Reaktionsfähigkeit die Interaktionen. Beobachten Sie Layoutverschiebungen, während Sie später erscheinende Inhalte, Hinweise oder Einbettungen reproduzieren. Halten Sie die Aufzeichnungsbedingungen fest, damit andere den Befund nachvollziehen können.

Eine eigene Erfassung realer Nutzungsdaten, häufig RUM genannt, ergänzt Details, die aggregierte Berichte nicht liefern. Sie kann eine Verschlechterung einer Veröffentlichung oder Vorlage zuordnen, abhängig von Datenabdeckung und Datenschutzentscheidungen. Erwarten Sie keine exakte Übereinstimmung mit CrUX: Nutzergruppen, Browser-APIs und Messdetails können sich unterscheiden.

Verfolgen Sie bei langsamem LCP die Ressource

Identifizieren Sie zuerst das LCP-Element in der Aufzeichnung, und zwar für die relevante Größe des sichtbaren Bereichs. Ein großes Desktopbild kann auf dem Smartphone einem kleineren Bild oder einem Textblock weichen. Optimieren Sie die Ressource, die die Kennzahl tatsächlich bestimmt.

Bei bildbasiertem LCP untersuchen Sie vier Abschnitte: die Zeit bis zum ersten HTML-Byte, die Verzögerung bis zum Beginn der Bildanfrage, die Bildübertragung und die Zeit zwischen Downloadende und Darstellung. Selbst eine kleine Datei kann spät erscheinen, wenn JavaScript ihre URL erst nach dem Anwendungsstart einfügt.

Prüfen Sie zunächst, ob das Bild im ursprünglichen HTML auffindbar ist, fälschlich verzögert geladen wird oder wegen einer falschen responsiven Konfiguration unnötig groß ausfällt. Untersuchen Sie anschließend, ob ein Stylesheet oder Skript die Darstellung nach dem Download verhindert.

Dieses Beispiel gibt einem wichtigen Bild feste Abmessungen und eine hohe Abrufpriorität. Die genannten Bilddateien müssen im Projekt vorhanden sein.

<img
  src="/images/article-hero-960.webp"
  srcset="/images/article-hero-960.webp 960w,
          /images/article-hero-1600.webp 1600w"
  sizes="(max-width: 960px) 100vw, 960px"
  width="1600"
  height="900"
  fetchpriority="high"
  alt="A request moving from a browser to a server"
>

Dass loading="lazy" fehlt, ist Absicht. fetchpriority ist ein Hinweis für die Ressourcenplanung, kein Befehl, der jede Browserentscheidung außer Kraft setzt. Verwenden Sie ihn für tatsächlich wichtige Ressourcen und nicht für eine ganze Galerie.

Kommt bereits das HTML spät an, kann Bildoptimierung die Verzögerung vor der Entdeckung der Seite nicht beseitigen. Untersuchen Sie Serverantwortzeit und TTFB, insbesondere Weiterleitungen, Cache-Misses und Anwendungsarbeit. Kommt das Bild rechtzeitig an, bleibt aber unsichtbar, untersuchen Sie Rendering und Hauptthreadarbeit.

Reproduzieren Sie bei schlechtem INP eine echte Interaktion

Wählen Sie eine konkrete Handlung: das Navigationsmenü öffnen, eine Produktvariante auswählen, eine Suche absenden oder einen langen Abschnitt aufklappen. Zeichnen Sie sie nach dem Laden auf, während typische Hintergrundskripte aktiv sind. Eine Aufzeichnung ohne Interaktion erklärt keine langsame Interaktion.

Die Verzögerung kann vor Ihrem Handler entstehen, wenn ein anderes Skript den Hauptthread belegt. Sie kann im Handler liegen, etwa wenn ein Filter eine große Sammlung neu berechnet. Oder sie entsteht danach, während der Browser für eine große Änderung Stile, Layout und Bildausgabe berechnet.

Behandeln Sie diese Phasen getrennt. Das Entfernen eines überflüssigen Analyse-Callbacks behebt keine teure Layoutoperation. Ein kürzerer Handler beseitigt keine Aufgabe, die seinen Start blockiert. Die Aufzeichnung sollte die dominierende Phase zeigen, bevor Sie eine Maßnahme auswählen.

Reduzieren Sie zuerst unnötige Arbeit. Teilen Sie anschließend Arbeit auf, die nicht vor der sichtbaren Rückmeldung abgeschlossen sein muss. Kontrollabgabe zwischen Teilaufgaben schafft Gelegenheiten für andere Browserarbeit. Geeignete Berechnungen ohne DOM-Zugriff können in einen Worker verlagert werden. Keine dieser Techniken rechtfertigt einen Algorithmus, der unnötige Daten wiederholt verarbeitet.

Ein gewöhnlicher Lighthouse-Navigationstest verwendet Total Blocking Time als nützlichen Laborindikator für Hauptthreadblockaden. TBT ist nicht INP und gehört nicht in das INP-Feld eines Prüfwerkzeugs. Kontrollierte interaktive Aufzeichnungen können Interaktionslatenzen messen. Beschränkt ist der reine Ladetest, nicht jede Labormessung.

Finden Sie bei CLS die Ursache der Bewegung

Das verschobene Element kann betroffen sein, ohne die Ursache zu bilden. Wird ein Absatz nach unten gedrückt, prüfen Sie, was oberhalb erschienen ist. Ein nachträglich eingefügter Hinweis oder ein Bild ohne reservierte Abmessungen kann den verfügbaren Platz verändert haben.

Beginnen Sie bei Bildern und Videos. Abmessungen oder ein geeignetes Seitenverhältnis ermöglichen die Platzreservierung vor dem Eintreffen der Medien. Prüfen Sie anschließend Anzeigen, eingebettete Player, Empfehlungen und andere asynchrone Inhalte. Ein Platzhalter braucht für jeden Umbruchpunkt eine realistische Größe, nicht nur eine dekorative Ladeanimation.

Auch Schriften verdienen Aufmerksamkeit. Ersatzschrift und heruntergeladene Webschrift können unterschiedliche Zeichenbreiten und vertikale Metriken haben. Der Wechsel verändert möglicherweise Zeilenumbrüche und verschiebt Nachbarinhalte. Wählen Sie passendes Ladeverhalten und erwägen Sie angepasste Ersatzschriftmetriken. Sofort sichtbarer Text beseitigt nicht automatisch jedes Layoutrisiko.

Beheben Sie Verschiebungen nicht auf Kosten der Zugänglichkeit. Fest positionierte Überlagerungen können Inhalte oder Bedienelemente verdecken, besonders bei schmalen Ansichten oder vergrößerter Schrift. Prüfen Sie nach Änderungen an Hinweisen oder reservierten Flächen Tastaturbedienung, Zoom und den Platz für die eigentliche Aufgabe.

Eine reine Neuladeaufzeichnung kann spätere Verschiebungen übersehen. Lassen Sie die Aufnahme beim Scrollen, Öffnen der relevanten Bedienelemente und Warten auf späteren Inhalt weiterlaufen. Vergleichen Sie die beobachtete Bewegung mit dem Feldproblem, bevor Sie die Korrektur als abgeschlossen betrachten.

Bauen Sie eine kleine, wiederholbare Messroutine auf

Wählen Sie repräsentative Seiten statt nur der Startseite. Nehmen Sie einen Artikel, eine Kategorie, eine Produktseite oder eine andere wichtige Vorlage auf. Notieren Sie gemeinsame Komponenten wie Navigation, Schriften, Werbeflächen und Einwilligungssteuerung.

Bewahren Sie für jede relevante Gerätekategorie eine Ausgangsmessung auf. Speichern Sie Bericht, Datum, getestete Version und wichtige Kennzahlen. Wiederholen Sie vergleichbare Labortests unter denselben Bedingungen. Ein einzelnes günstiges Ergebnis unterscheidet noch keine Verbesserung von normaler Schwankung.

Für ein Projekt, das das Paket web-vitals bereits bündelt, protokolliert dieses kleine Diagnosemodul die vom Browser gemeldeten Kennzahlen. Es dient der lokalen Fehlersuche und ist kein vollständiges Analysesystem.

import { onCLS, onINP, onLCP } from 'web-vitals';

function logMetric(metric) {
  console.log({
    name: metric.name,
    value: metric.value,
    rating: metric.rating,
    id: metric.id
  });
}

onLCP(logMetric);
onINP(logMetric);
onCLS(logMetric);

Einige Callbacks hängen vom Seitenlebenszyklus oder Ihren Interaktionen ab. Erwarten Sie nicht sofort drei aussagekräftige Werte, wenn Sie lediglich einen ruhigen Tab öffnen. Eine produktive Erfassung benötigt einen Endpunkt, Aggregation, Stichprobenentscheidungen und angemessenen Datenschutz. Konsolenausgaben leisten das nicht.

Überwachen Sie nach der Veröffentlichung mögliche Verschlechterungen und geben Sie dem Erfassungsfenster Zeit für neue Besuche. Ein rollierendes Fenster enthält frühere und spätere Erfahrungen, bis genügend Zeit vergangen ist. Wiederholte Lighthouse-Läufe beschleunigen diesen Prozess nicht und erzeugen keinen fehlenden CrUX-Traffic.

Ordnen Sie Core Web Vitals im SEO richtig ein

Google Search Central erklärt, dass die Rankingsysteme Core Web Vitals verwenden, gute Berichte aber keine hohen Platzierungen garantieren. Relevanz, hilfreiche Inhalte und weitere Aspekte der Seitenerfahrung bleiben wichtig. Es gibt keine dokumentierte Umrechnung von Lighthouse-Punkten in Rankingpositionen.

Das hilft bei der Priorisierung. Können Besucher einen Filter nicht verwenden, beheben Sie ihn, weil er ihre Aufgabe behindert. Lädt ein wichtiges Bild auf einer häufig verwendeten Vorlage spät, bearbeiten Sie die gemeinsame Ursache. Verbrauchen Sie nicht das gesamte Budget für einen zusätzlichen synthetischen Punkt, während wichtige Inhalte schwer auffindbar oder bedienbar bleiben.

Machen Sie aus dem ersten Befund eine konkrete Änderung

Wählen Sie eine repräsentative URL und eine problematische Kennzahl. Notieren Sie beobachtete Ursache, geplante Änderung und den anschließend vorgesehenen Vergleich. So entsteht eine klar begrenzte Aufgabe, die ein Entwickler umsetzen und ein Prüfer bewerten kann.

Nutzen Sie den Core-Web-Vitals-Prüfer zur Einordnung gemessener Werte und behalten Sie Quelle und Einheit bei. Verfolgen Sie die Umsetzung mit der Performance-Checkliste. Die weiteren Core-Web-Vitals-Leitfäden zeigen den nächsten Diagnoseschritt, sobald der betroffene Teil des Besuchs feststeht.