Core Web Vitals verstehen: LCP, INP und CLS richtig prüfen
Vom richtigen Bericht bis zur konkreten Ursache: offizielle Zielbereiche, ein verzögertes Bild im Browserversuch und eine Diagnose ohne erfundene Erfolgszahlen.
Der PageSpeed-Bericht ist grün, trotzdem reagiert das mobile Menü manchmal zäh. Nach einer Bildkorrektur bleibt die Feldbewertung zunächst unverändert. Solche Beobachtungen widersprechen sich nicht zwangsläufig. Häufig werden unterschiedliche Messbedingungen oder Zeiträume miteinander verglichen.
Dieser Leitfaden erklärt die drei Metriken und einen nachvollziehbaren Prüfablauf anhand einer fiktiven Schulungsseite. Die Beispiele enthalten keine gemessenen Kundenerfolge und keine Rankingzusage. Quellenstand ist der 9. November 2026. Numerische Grenzwerte stammen aus der verlinkten offiziellen Dokumentation, nicht aus einer erfundenen eigenen Untersuchung.
1. Zuerst die Frage hinter dem Wert klären
Ein technischer Bericht kann mehrere Fragen beantworten. Wie verhält sich die Seite unter festgelegten Testbedingungen? Wie erleben sie bestimmte tatsächliche Besucher? Welche Ressource verzögert den sichtbaren Hauptinhalt? Diese Fragen sind verwandt, aber nicht identisch.
Im Beispiel sollen Interessenten eine Schulung verstehen und sich anmelden können. Ein schnelles erstes Erscheinen hilft wenig, wenn die Terminwahl später blockiert. Ebenso kann eine schnell reagierende Schaltfläche durch nachladende Inhalte unerwartet verschoben werden.
Beschreiben Sie deshalb zunächst den vollständigen Besucherablauf. Nehmen Sie neben der ersten Ansicht auch Menü, Terminwahl und Formular auf. Der spätere Messplan sollte diese Aufgabe abdecken.
Ein allgemeiner Wunsch nach mehr Punkten ist dafür zu unbestimmt. Konkreter ist die Frage, warum eine bestimmte Interaktion auf einem vorgesehenen Mobilgerät verzögert erscheint oder warum der Absenden-Button während des Lesens seine Position ändert.
2. Die drei Metriken richtig zuordnen
| Metrik | Betrachteter Aspekt | Offizieller guter Bereich |
|---|---|---|
| LCP | Erscheinen des größten berücksichtigten sichtbaren Inhalts | Höchstens 2,5 Sekunden |
| INP | Reaktionsfähigkeit bei berücksichtigten Interaktionen | Höchstens 200 Millisekunden |
| CLS | Unerwartete Layoutverschiebungen | Höchstens 0,1 ohne Zeiteinheit |
Die offizielle Web-Vitals-Übersicht nennt diese Zielbereiche und die Betrachtung des 75. Perzentils, getrennt nach Mobilgeräten und Desktop. Bei ausreichenden Daten werden die drei Metriken gemeinsam beurteilt.
Die Werte sind keine Schulnoten für Inhalt, Gestaltung oder Sicherheit. Eine Webseite kann die Zielbereiche erreichen und trotzdem unverständliche Texte oder ein fehlerhaftes Formular enthalten. Technische Qualität benötigt mehrere passende Prüfungen.
3. Das 75. Perzentil verständlich lesen
Ein Perzentil beschreibt eine Position in einer Verteilung. Der angezeigte Wert ist deshalb nicht einfach der Durchschnitt und nicht automatisch der schlimmste einzelne Besuch. Die Unterscheidung ist wichtig, wenn ein sehr gutes persönliches Erlebnis einem auffälligen Bericht gegenübersteht.
Prüfen Sie bei einer Besprechung zunächst, ob alle Beteiligten dieselbe Kennzahl meinen. Ein einzelner Laborlauf, ein Feld-Perzentil und ein Durchschnitt eigener Messungen lassen sich nicht ohne Weiteres gleichsetzen.
Dokumentieren Sie zudem den Gerätetyp. Wenn der mobile Bericht auffällig ist, kann ein schneller Desktoprechner das Problem verdecken. Die richtige Antwort ist eine passende Untersuchung, nicht das Ersetzen des unbequemen Berichts durch den angenehmeren.
Eine nützliche Ergebnisnotiz nennt Metrik, Quelle, betrachteten Bereich und Datum. Damit lässt sich später prüfen, ob eine Veränderung tatsächlich denselben Gegenstand betrifft.
4. Labordaten und Felddaten auseinanderhalten
Labordaten entstehen unter kontrollierten Bedingungen. Felddaten beruhen auf tatsächlich erfassten Nutzungen. Die web.dev-Erklärung zu Labor- und Felddaten beschreibt, warum beide für dieselbe Seite unterschiedlich ausfallen können.
Für die Fehlersuche ist ein wiederholbarer Test besonders hilfreich. Er erlaubt, eine Änderung unter möglichst gleichen Bedingungen zu untersuchen. Für die Einordnung tatsächlicher Nutzung ist dagegen entscheidend, welche Erfahrungen im Feld erfasst wurden.
Ein frischer Browser auf einem Testrechner kennt möglicherweise andere Cachezustände als wiederkehrende Besucher. Auch Geräte, Verbindungen und Nutzungsschritte können abweichen. Notieren Sie solche Unterschiede, bevor Sie eine Messung als falsch verwerfen.
Die beiden Perspektiven ergänzen einander. Ein auffälliger Feldwert kann eine gezielte Laboruntersuchung auslösen. Ein verbesserter Laborablauf muss anschließend unter tatsächlicher Nutzung weiter beobachtet werden.
5. URL-Daten und Origin-Daten nicht verwechseln
Ein Bericht kann eine einzelne Adresse oder einen größeren Ursprung zusammenfassen. Die CrUX-Methodik beschreibt Voraussetzungen und Aggregation. Nicht jede öffentlich erreichbare Seite besitzt automatisch einen eigenen ausreichend belegten Datensatz.
Fehlen Daten für die konkrete Schulungsseite, darf ein zusammengefasster Wert nicht als ausschließlich ihre Eigenschaft ausgegeben werden. Andere Seiten desselben Ursprungs können andere Vorlagen und Ressourcen verwenden.
Prüfen Sie deshalb die angezeigte Datenebene vor einer Optimierung. Sonst suchen Sie möglicherweise auf der falschen Seite nach einer Ursache. Eine ähnliche Domainansicht ist kein Ersatz für den tatsächlich ausgewiesenen Bezug.
Auch fehlende Felddaten sind kein Leistungsurteil. Sie können auf unzureichende Datenbasis zurückgehen. Für eine neue oder wenig besuchte Seite bleibt ein geeigneter technischer Test trotzdem sinnvoll.
6. LCP entlang des tatsächlichen Ladewegs untersuchen
Die LCP-Dokumentation beschreibt den Zeitpunkt des größten berücksichtigten sichtbaren Bild-, Text- oder Videoinhalts. LCP ist weder die erste sichtbare Farbfläche noch automatisch das Ende sämtlicher Netzwerkanfragen.
Identifizieren Sie zuerst das im konkreten Lauf erkannte Element. Auf der Schulungsseite könnte dies ein großes Einstiegsbild oder ein Textblock sein. Eine Optimierung des falschen Bildes kann am maßgeblichen Ergebnis wenig ändern.
Untersuchen Sie anschließend den Weg dorthin. Beginnt die Anfrage spät? Wartet die Darstellung auf weitere Ressourcen? Verändert eine andere Bildschirmgröße das maßgebliche Element? Die Diagnose sollte die beobachtete Verzögerung erklären.
Vermeiden Sie eine pauschale Maßnahme für alle Bilder. Ein früh benötigtes Einstiegsbild hat einen anderen Zweck als eine weit unten liegende Abbildung. Die Ladeentscheidung sollte zur tatsächlich benötigten Darstellung passen.
7. INP nicht mit einer einzelnen Serverantwort gleichsetzen
Die INP-Dokumentation betrachtet die Latenz berücksichtigter Klick-, Tipp- und Tastaturinteraktionen während des Besuchs. Es geht um die Reaktion bis zur nächsten Darstellung, nicht um die Gesamtdauer jeder späteren asynchronen Folgeaktion.
Für die Schulungsseite wäre daher zu prüfen, ob die Terminwahl zeitnah sichtbar reagiert. Eine zusätzliche Serverabfrage kann danach weiterlaufen. Die Oberfläche muss den tatsächlichen Zustand verständlich zeigen und darf keine noch nicht bestätigte Anmeldung als erledigt darstellen.
Eine blockierte Hauptausführung kann auch eine kurze eigentliche Handlerfunktion verzögern. Betrachten Sie deshalb den zeitlichen Zusammenhang statt nur die Länge des angeklickten Skripts. Andere gleichzeitig ausgeführte Arbeit kann zur beobachteten Latenz beitragen.
Ein reiner Ladetest ohne sinnvolle Interaktionen beantwortet diese Frage unvollständig. Ergänzen Sie die tatsächlich wichtigen Bedienabläufe und beobachten Sie auch langsamere vorgesehene Geräte.
8. CLS als Stabilität und nicht als Animationstempo verstehen
Die CLS-Dokumentation beschreibt unerwartete Layoutverschiebungen und die Bewertung über zusammengehörige Zeitfenster. Ein selbst geschriebener Summenzähler über sämtliche Verschiebungen wäre deshalb nicht automatisch dieselbe Metrik.
Eine typische Ursache sind nachladende Inhalte ohne vorgesehenen Platz. Wenn oberhalb des Formulars ein Bild Höhe erhält, kann die Schaltfläche nach unten rutschen. Das Problem ist die veränderte Anordnung, nicht allein die Dateigröße.
Unterscheiden Sie Layoutänderungen von anderen sichtbaren Bewegungen. Eine geeignete Untersuchung muss zeigen, welche Elemente ihre Layoutposition ändern und warum. Ein einzelnes Bildschirmfoto kann den zeitlichen Verlauf nicht belegen.
Prüfen Sie die Seite auch nach dem ersten Laden. Ein später erscheinender Hinweis oder ein nachgeladener Bereich kann die Nutzung verändern. Die erste ruhige Ansicht beweist noch keine durchgängig stabile Oberfläche.
9. Einen Bildbereich von Anfang an passend reservieren
Für ein normales inhaltliches Bild kann die Angabe passender Abmessungen helfen, das Seitenverhältnis früh bereitzustellen. Die web.dev-Anleitung zur CLS-Optimierung behandelt fehlende Bildabmessungen als häufige Ursache von Verschiebungen.
<img
src="detailbild.svg"
width="1200"
height="800"
alt="Schematische Darstellung des Schulungsraums"
style="display:block;width:100%;height:auto"
>Die Zahlen beschreiben im Lehrbeispiel das tatsächliche Seitenverhältnis der verwendeten Testgrafik. Sie sind keine willkürlich gewählte feste Darstellungsgröße. Bei einer anderen Datei müssen die Angaben entsprechend passen.
Der dazugehörige Browserversuch verzögert die Grafik absichtlich und prüft die Position des nachfolgenden Inhalts vor und nach dem Laden. Er verifiziert diesen begrenzten Layoutmechanismus und misst keine reale Unternehmensseite.
Bei wechselnden Zuschnitten, eingebetteten Medien und responsiven Sonderfällen ist die vollständige Gestaltung zu betrachten. Ein korrektes width-Attribut allein garantiert keine stabile Seite, wenn andere Regeln das Layout nachträglich verändern.
10. Einzelne Verschiebungen zur Diagnose beobachten
Die MDN-Referenz zu LayoutShift dokumentiert die zugrunde liegenden Einträge und ihre begrenzte Browserverfügbarkeit. Das folgende Beispiel prüft die Unterstützung und protokolliert einzelne Ereignisse. Es berechnet ausdrücklich keinen vollständigen CLS-Wert.
if ("PerformanceObserver" in window &&
PerformanceObserver.supportedEntryTypes.includes("layout-shift")) {
const observer = new PerformanceObserver(list => {
for (const entry of list.getEntries()) {
if (entry.hadRecentInput) continue;
console.info("Layout-Verschiebung", {
value: entry.value,
startTime: entry.startTime
});
}
});
observer.observe({ type: "layout-shift", buffered: true });
}Ein ausbleibender Eintrag kann mehrere Ursachen haben. Vielleicht trat keine passende Verschiebung auf oder die Funktion wird in der Umgebung nicht unterstützt. Daraus darf keine allgemeine Bestätigung stabilen Verhaltens entstehen.
Für reguläre Metrikberichte sollte eine dafür geeignete, gepflegte Messlösung verwendet werden. Ein kleiner Diagnoseausschnitt ist hilfreich, wenn sein Zweck und seine Grenzen klar bleiben.
11. Den Zeitraum eines Feldberichts berücksichtigen
Die PageSpeed-Insights-Dokumentation beschreibt einen zurückliegenden Erfassungszeitraum von 28 Tagen für die dort angezeigten CrUX-Erfahrungen. Eine heutige Änderung ersetzt diese historische Mischung nicht sofort vollständig.
Dokumentieren Sie den Veröffentlichungszeitpunkt der Änderung. Betrachten Sie anschließend Laborbefunde und die Entwicklung der passenden Felddaten gemeinsam. Ein gleichbleibender früher Feldwert widerlegt nicht automatisch eine technisch bestätigte Korrektur.
Umgekehrt kann eine bessere Verteilung andere Ursachen haben. Gerätetypen, besuchte Seiten oder erfasste Nutzungen können sich verändern. Eine zeitliche Nähe allein ist noch kein belastbarer Wirkungsnachweis.
Die offizielle PSI-Bewertung enthält außerdem Regeln für unvollständige Metrikdaten. Fehlt nur ausreichendes INP-Material, kann die Bewertung nach den dokumentierten Bedingungen auf LCP und CLS beruhen. Lesen Sie deshalb die tatsächlich ausgewiesene Bewertung, statt eine eigene vereinfachte Bestehensregel zu erfinden.
12. Erst eine Ursache, dann eine gezielte Änderung
| Beobachtung | Zu untersuchende Frage | Mögliche begrenzte Maßnahme |
|---|---|---|
| Einstiegsbild erscheint spät | Wann wird die richtige Ressource angefordert und dargestellt? | Den nachgewiesenen Ladeengpass beheben |
| Terminwahl reagiert verzögert | Welche Arbeit blockiert vor der nächsten Darstellung? | Den konkreten blockierenden Ablauf verkleinern |
| Formular springt nach unten | Welcher Bereich verändert nachträglich seine Höhe? | Passenden Platz vorsehen |
| Labor und Feld weichen ab | Sind Bedingungen, Zeitraum und Bezug vergleichbar? | Geeignete Vergleichsgrundlage herstellen |
Die Tabelle nennt Untersuchungsrichtungen und keine Garantie für einen bestimmten Gewinn. Verändern Sie nicht gleichzeitig alle Medien, Schriftregeln und Skripte, wenn Sie die Wirkung einer einzelnen Ursache verstehen wollen.
Halten Sie den erwarteten Effekt vorher fest. Nach der Änderung wird geprüft, ob dieser Effekt unter denselben sinnvollen Bedingungen eintritt und ob vorhandene Funktionen erhalten bleiben.
13. Funktionsqualität bei der Optimierung erhalten
Eine schnellere Seite darf den eigentlichen Vorgang nicht verschlechtern. Wenn aus einer funktionierenden Terminwahl eine statische Attrappe wird, wurde die Aufgabe nicht erfolgreich optimiert. Prüfen Sie daher das Verhalten zusätzlich zu den Metriken.
Dasselbe gilt für die Gestaltung. Reservierter Platz muss zum tatsächlichen Inhalt passen und auf kleinen Bildschirmen funktionieren. Ein großer leerer Block kann eine Verschiebung vermeiden und trotzdem die Orientierung unnötig erschweren.
Bei Fehlerzuständen sollten Rückmeldungen sachlich stimmen. Eine sofortige optische Bestätigung darf keinen erfolgreichen Versand behaupten, solange die fachliche Bestätigung noch aussteht. Reaktionsfähigkeit und wahrheitsgemäßer Status gehören zusammen.
Bewahren Sie die notwendigen Inhalte. Eine entfernte Einschränkung kann den Text kürzer machen, verbessert aber nicht die fachliche Qualität der Seite. Metrikarbeit ersetzt keine verantwortliche Redaktion.
14. Einen nachvollziehbaren Messnachweis führen
Ein guter Nachweis enthält Adresse, Datum, Messwerkzeug, Gerät beziehungsweise Simulation und den untersuchten Ablauf. Notieren Sie auch relevante Cache- und Netzwerkbedingungen. So wird ein späterer Vergleich überhaupt erst sinnvoll.
Speichern Sie neben dem Ergebnis die zugehörige Diagnose. Ein einzelner Gesamtpunktwert erklärt selten, warum sich ein Verhalten verändert hat. Die betroffene Ressource oder der blockierende Ablauf ist für die Umsetzung wichtiger.
Wiederholen Sie eine Messung, wenn die Umgebung deutlich schwankt oder die Änderung den beobachteten Effekt noch nicht nachvollziehbar erklärt. Viele Wiederholungen ohne klare Frage erzeugen dagegen leicht nur eine Auswahl besonders günstiger Läufe.
Berichten Sie Grenzen ausdrücklich. Ein bestandener Test des Bildbereichs ist kein vollständiger Core-Web-Vitals-Nachweis. Ein Laborergebnis gilt für seine Bedingungen und ersetzt keine nie erhobene Feldmessung.
15. Core Web Vitals und Suchsichtbarkeit einordnen
Google Search Central ordnet die Metriken der Nutzererfahrung und den Bewertungssystemen der Suche zu. Eine Verbesserung ist deshalb sinnvoll, wenn sie die tatsächliche Nutzung verbessert.
Daraus folgt keine garantierte Position für eine konkrete Suchanfrage. Inhalt, Fragestellung und weitere Eigenschaften bleiben relevant. Eine Behauptung wie „200 Millisekunden schneller bringt sicher Platz eins“ wäre durch den gezeigten Prüfablauf nicht belegt.
Formulieren Sie Ziele deshalb zuerst als überprüfbare Nutzererfahrung. Besucher sollen das Angebot sehen, die Terminwahl zuverlässig bedienen und ohne unerwartetes Verrutschen weiterarbeiten können. Diese Ziele bleiben nützlich, auch wenn Suchpositionen schwanken.
16. Eine Gesamtzeit in verständliche Abschnitte zerlegen
Die offizielle Anleitung zur LCP-Optimierung betrachtet den gesamten Weg bis zur Darstellung. Dazu gehören Wartezeit auf die erste Antwort, Verzögerung vor dem Ressourcenabruf, Abrufdauer und anschließende Darstellungsverzögerung. Diese Aufteilung hilft, die richtige Ursache zu bearbeiten.
Ist das Bild bereits vollständig übertragen, aber noch nicht sichtbar, reicht eine weitere Kompression möglicherweise nicht aus. Umgekehrt sollte eine auffällig späte Anfrage nicht nur durch eine kleinere Datei kaschiert werden. Der konkrete Ablauf entscheidet, welcher Schritt überhaupt verbessert werden kann.
Bei INP unterscheidet die Optimierungsanleitung Eingabeverzögerung, Verarbeitungsdauer und Verzögerung bis zur nächsten Darstellung. Eine lange Wartezeit vor dem eigentlichen Handler kann deshalb wichtiger sein als dessen eigene Laufzeit.
Für die Schulungsseite lässt sich daraus eine genaue Frage formulieren: Wartet der Klick auf den Termin zunächst hinter anderer Arbeit oder braucht erst die anschließende Darstellung lange? Halten Sie den beobachteten Abschnitt fest. Dann kann eine Änderung gezielt auf diesen Abschnitt wirken.
Vermeiden Sie dennoch die Annahme, jede Verkürzung eines Teilabschnitts erzeuge denselben Gewinn im Gesamtwert. Abläufe können sich überlagern und Ressourcen können an anderer Stelle warten. Der vollständige erneute Test bleibt erforderlich.
17. Unterschiedliche Seitentypen und Zustände abdecken
Eine Startseite, eine lange Kursbeschreibung und ein Formular können gemeinsame Ressourcen verwenden und trotzdem unterschiedliche Engpässe besitzen. Wählen Sie deshalb repräsentative Seiten für die tatsächlichen Vorlagen. Ein guter Wert auf der Startseite ist kein automatischer Nachweis für die Anmeldung.
Notieren Sie zu jedem Test den Zustand der Oberfläche. Ist das Menü geschlossen? Liegt bereits eine Auswahl für optionale Dienste vor? Ist ein längerer Hinweis eingeblendet? Solche Unterschiede können verändern, welche Ressourcen und Bereiche überhaupt beteiligt sind.
Prüfen Sie nach einer gemeinsamen Vorlagenänderung die betroffenen Seitentypen erneut. Eine Korrektur an einer geteilten Bildregel kann mehr als die ursprünglich untersuchte Seite verändern. Die zusätzliche Prüfung hat dann einen konkreten Anlass.
Berücksichtigen Sie auch den Datenumfang. Eine Terminliste mit einem Eintrag kann anders reagieren als dieselbe Oberfläche mit vielen tatsächlichen Angeboten. Der Testbestand sollte die erwartete Nutzung sinnvoll abbilden. Eine unrealistisch kleine Demonstration darf nicht als Beleg für sämtliche späteren Datenmengen ausgegeben werden.
Die Auswahl der Prüffälle wird damit zu einem Teil der Qualitätsarbeit. Halten Sie fest, welche Fälle vertreten sind und welche Fragen offenbleiben. Das ist aussagekräftiger als eine Sammlung nicht vergleichbarer Einzelberichte.
18. Checkliste für den nächsten Bericht
- Ist die betrachtete Besucheraufgabe beschrieben?
- Sind LCP, INP und CLS richtig zugeordnet?
- Ist Labor oder Feld als Datenquelle erkennbar?
- Stehen Gerätetyp und Datenzeitraum fest?
- Bezieht sich der Wert auf die konkrete URL oder den Ursprung?
- Ist das tatsächliche LCP-Element identifiziert?
- Wurden wichtige Interaktionen praktisch untersucht?
- Sind spätere Layoutverschiebungen berücksichtigt?
- Hat eine Änderung eine nachvollziehbare Ursache?
- Bleiben Funktionen und korrekte Rückmeldungen erhalten?
19. Häufige Fragen
Warum zeigt mein Test etwas anderes als PageSpeed?
Prüfen Sie zuerst Datenquelle, Zeitraum, Gerätebedingungen und URL-Bezug. Eine kontrollierte Einzelmessung und eine Verteilung tatsächlicher Besuche sind unterschiedliche Beobachtungen.
Ist CLS eine Zeitangabe?
Nein. CLS ist ein dimensionsloser Wert für bewertete Layoutverschiebungen. Er darf nicht als Sekunden oder Millisekunden beschriftet werden.
Kann eine neue Seite ohne Felddaten bewertet werden?
Sie kann technisch im Labor untersucht werden. Das ersetzt keine nicht vorhandene Verteilung tatsächlicher Nutzungen. Die Aussage über den jeweiligen Prüfstand muss entsprechend begrenzt bleiben.
Reicht ein hoher Gesamtwert?
Nein. Betrachten Sie die einzelnen Metriken und die funktionierende Aufgabe. Ein Gesamtwert kann bei der Orientierung helfen, erklärt aber weder jede Ursache noch die gesamte Qualität einer Webseite.
