Core Web Vitals richtig optimieren
LCP, INP und CLS mit echten Nutzerdaten bewerten, Ursachen finden und gezielt verbessern
LCP, INP und CLS mit echten Nutzerdaten bewerten, Ursachen finden und gezielt verbessern
Core Web Vitals sind drei Kennzahlen für zentrale Aspekte der Seitennutzung: Largest Contentful Paint beschreibt die wahrgenommene Ladegeschwindigkeit, Interaction to Next Paint die Reaktionsfähigkeit auf Interaktionen und Cumulative Layout Shift die visuelle Stabilität. Gemeinsam beantworten sie nicht die Frage, ob eine Seite inhaltlich relevant oder technisch indexierbar ist. Sie zeigen, wie zuverlässig wichtige Inhalte erscheinen, Bedienelemente reagieren und das Layout an seinem Platz bleibt.
Google empfiehlt gute Core Web Vitals für eine insgesamt überzeugende Seitenerfahrung. Sie fließen zusammen mit weiteren Aspekten in die Bewertung der Seitenerfahrung ein, sind aber weder ein eigenständiger Erfolgsgarant noch ein Ersatz für hilfreiche Inhalte. Eine grüne Messung garantiert keine Spitzenposition, und ein einzelner schlechter Messwert erklärt keinen Rankingverlust ohne weitere Analyse.
Optimiert wird deshalb nicht auf eine abstrakte Punktzahl, sondern auf reale Engpässe. Ein zu spätes Hauptbild verlangt eine andere Maßnahme als ein langsamer Produktfilter oder ein Banner, das vorhandenen Inhalt nach unten schiebt. Erst die Zuordnung von Kennzahl, betroffenem Seitentyp und technischer Ursache führt zu einer belastbaren Lösung.
| Metrik | Gut | Verbesserungsbedarf | Schlecht |
|---|---|---|---|
| LCP | bis 2,5 s | über 2,5 bis 4,0 s | über 4,0 s |
| INP | bis 200 ms | über 200 bis 500 ms | über 500 ms |
| CLS | bis 0,1 | über 0,1 bis 0,25 | über 0,25 |
Für die Einstufung zählt das 75. Perzentil der Seitenaufrufe, getrennt nach Mobil- und Desktopgeräten. Ein mobiler LCP von 2,4 Sekunden am 75. Perzentil bedeutet vereinfacht: Mindestens 75 Prozent der gemessenen mobilen Aufrufe lagen bei 2,4 Sekunden oder darunter. Damit eine Auswertung die Core-Web-Vitals-Prüfung besteht, müssen die verfügbaren Kennzahlen im guten Bereich liegen.
CLS ist ein einheitenloser Wert, keine Zeitangabe. Die Grenzwerte gelten für alle Seitentypen, doch die Ursachen können sich stark unterscheiden. Auf redaktionellen Seiten dominiert vielleicht ein unreserviertes Titelbild, in Shops ein nachträglich eingefügter Preisblock und in Webanwendungen umfangreiche Interaktionslogik.
Felddaten stammen aus tatsächlichen Aufrufen mit unterschiedlichen Geräten, Verbindungen, Standorten und Nutzungsmustern. PageSpeed Insights verwendet dafür Daten des Chrome User Experience Report aus einem rollierenden Zeitraum von 28 Tagen. Je nach Datenmenge zeigt der Bericht Werte für die konkrete URL oder ersatzweise für den gesamten Origin. Fehlen ausreichende Stichproben, ist das keine bestandene Messung, sondern schlicht keine belastbare CrUX-Auswertung.
Der Core-Web-Vitals-Bericht der Search Console fasst URLs mit ähnlichem Nutzungserlebnis zu Gruppen zusammen. Das ist für die Priorisierung wiederkehrender Template-Probleme hilfreich, bedeutet aber auch: Eine Beispiel-URL steht stellvertretend für eine Gruppe und muss nicht bei jedem Aufruf exakt denselben Wert erzeugen. Mobil- und Desktopberichte werden getrennt untersucht.
Labordaten aus Lighthouse oder den Chrome DevTools entstehen dagegen unter kontrollierten Bedingungen. Sie sind reproduzierbarer und liefern Netzwerk-Wasserfälle, Main-Thread-Profile, Layout-Shift-Markierungen und konkrete Elemente. INP lässt sich ohne echte Interaktion während eines Ladetests nicht vollständig abbilden; Total Blocking Time kann Hinweise liefern, ersetzt INP aber nicht. Die praktische Reihenfolge lautet daher: Problem in Felddaten erkennen, in Labor und Real User Monitoring eingrenzen, Ursache beheben und anschließend beide Datenarten beobachten.
Die Leistungs- und Erfahrungsberichte der Search Console sollten dabei getrennt interpretiert werden: Suchklicks und Positionen beschreiben Sichtbarkeit, Core Web Vitals die technische Nutzungserfahrung einer URL-Gruppe.
LCP misst die Zeit vom Start der Navigation bis zur Darstellung des größten berücksichtigten Bild- oder Textbereichs im sichtbaren Viewport. Der Gesamtwert lässt sich in Time to First Byte, Verzögerung bis zum Start der LCP-Ressource, deren Ladezeit und Verzögerung bis zur Darstellung zerlegen. Diese Aufteilung verhindert pauschale Maßnahmen: Bildkompression hilft wenig, wenn das Bild erst nach JavaScript-Ausführung entdeckt wird.
src oder srcset in das initiale HTML und darf nicht lazy geladen werden.<link rel="preload" as="image"
href="/img/produkt-1280.webp"
imagesrcset="/img/produkt-640.webp 640w,
/img/produkt-1280.webp 1280w"
imagesizes="(max-width: 48rem) 100vw, 50vw">
<img src="/img/produkt-1280.webp"
srcset="/img/produkt-640.webp 640w,
/img/produkt-1280.webp 1280w"
sizes="(max-width: 48rem) 100vw, 50vw"
width="1280" height="960"
fetchpriority="high"
alt="Brauner Lederrucksack mit zwei Außentaschen">Ein Preload ist nur sinnvoll, wenn die Ressource wirklich früh benötigt wird und exakt zur später verwendeten URL beziehungsweise srcset-Auswahl passt. Zu viele Preloads konkurrieren um Bandbreite. Server Side Rendering oder statische Ausgabe kann die Entdeckung wichtiger Inhalte beschleunigen; die passende Rendering-Architektur behandelt die Anleitung zu JavaScript SEO bei dynamischen Websites.
INP bewertet die Reaktionsfähigkeit über die Lebensdauer eines Seitenbesuchs. Berücksichtigt werden Interaktionen per Klick, Tippen und Tastatur; der berichtete Wert orientiert sich an der langsamsten Interaktion und behandelt bei vielen Interaktionen Ausreißer nach der definierten Methodik. Gemessen wird bis zu dem Frame, der die visuelle Reaktion zeigt.
Jede Interaktionslatenz besteht aus Eingabeverzögerung, Ausführungszeit der Event-Callbacks und Darstellungsverzögerung. Lange Aufgaben auf dem Main Thread können schon vor dem Event-Handler warten lassen. Teure Handler verlängern die Verarbeitung; ein sehr großer DOM-Baum oder aufwendige Styles verzögern anschließend den nächsten Frame. Deshalb reicht es nicht, nur den angeklickten Handler zu betrachten.
saveButton.addEventListener('click', () => {
showSavingState(); // sichtbare Rückmeldung zuerst
requestAnimationFrame(() => {
setTimeout(() => {
validateDraft();
persistDraft();
}, 0);
});
});Das Beispiel verschiebt nicht sichtkritische Arbeit hinter die nächste Darstellung. In realen Anwendungen müssen Aufgaben zusätzlich verkleinert, unnötiges JavaScript entfernt, Drittanbieter-Skripte begrenzt und große DOM-Aktualisierungen vermieden werden. Für die Diagnose sind Interaktionsziel und die drei Latenzanteile wertvoller als eine globale Bundle-Größe ohne Bezug zum langsamen Bedienvorgang.
CLS summiert unerwartete Layout-Verschiebungen innerhalb definierter Sitzungsfenster. Häufige Ursachen sind Bilder, Anzeigen oder Iframes ohne reservierte Abmessungen, nachträglich oberhalb des vorhandenen Inhalts eingefügte Elemente und Webfonts mit stark abweichenden Ersatzmetriken. Eine Animation über transform kann visuell bewegen, ohne das umgebende Layout neu anzuordnen; Änderungen an top, Höhe oder Breite können dagegen Verschiebungen auslösen.
<img src="/img/diagramm.webp"
width="1200" height="675"
alt="Zeitlicher Verlauf der Ladephasen">
<div class="embed-slot" aria-label="Videoplayer"></div>
<style>
.embed-slot {
aspect-ratio: 16 / 9;
min-height: 12rem;
}
</style>Breiten- und Höhenattribute erlauben dem Browser, das Seitenverhältnis vor dem Download zu reservieren; responsive CSS darf das Bild trotzdem skalieren. Cookie-Hinweise oder Aktionsbanner sollten vorhandenen Inhalt nicht nachträglich nach unten drücken. Wenn eine Fläche erst später gefüllt wird, wird ihr Platz von Beginn an reserviert oder der Inhalt an einer Stelle ergänzt, die keine unerwartete Verschiebung im sichtbaren Bereich erzeugt.
| Befund | Erste technische Frage | Sinnvolle Prüfung |
|---|---|---|
| LCP nur mobil schlecht | Andere LCP-Ressource oder langsamere Entdeckung? | Mobile CrUX-Daten, Wasserfall und LCP-Teilzeiten |
| INP bei Filtern schlecht | Warten, Handler oder Rendering zu lang? | Interaktions-Trace und Main-Thread-Aufgaben |
| CLS nur bei Erstbesuch | Banner, Font oder Embed ohne Fläche? | Layout-Shift-Cluster mit Screenshots |
Begonnen wird mit URL-Gruppen, die viele wichtige Besuche und ein gemeinsames Template betreffen. Danach werden pro Gruppe repräsentative URLs, Geräteklasse und konkrete Elemente erfasst. Änderungen sollten eine messbare Hypothese haben, etwa: „Das Produktbild beginnt früher zu laden, weil es im initialen HTML auffindbar ist.“ So lässt sich nach dem Deployment prüfen, ob die erwartete Teilzeit tatsächlich sinkt.
Die 28-Tage-Felddaten reagieren verzögert, weil neue und ältere Aufrufe gemeinsam in das rollierende Fenster eingehen. Eine sofortige Labormessung bestätigt daher zunächst nur die technische Änderung. Eigene Real-User-Messungen können früher zeigen, ob die betroffenen Nutzer und Templates profitieren. Die endgültige Bewertung verbindet diese Signale mit Fehlerquoten, Conversion und visueller Kontrolle auf echten Geräten.
Performance ist dabei Teil einer funktionierenden mobilen Erfahrung. Viewport, Inhaltsparität und Bedienbarkeit bleiben eigene Anforderungen; der Beitrag zu Mobile SEO und Mobile-First Indexing ordnet diese Zusammenhänge ein.