Core Web Vitals: LCP, INP und CLS verstehen und verbessern
Core Web Vitals erklärt: Grenzwerte für LCP, INP und CLS, Felddaten vs. Labordaten, typische Ursachen schlechter Werte und was wirklich hilft – mit Prüfreihenfolge.
Core Web Vitals sind drei Messwerte, mit denen Google die Nutzererfahrung einer Seite bewertet: wie schnell der Hauptinhalt erscheint (LCP), wie schnell die Seite auf Eingaben reagiert (INP) und wie stabil das Layout beim Laden bleibt (CLS). Gut ist eine Seite, wenn mindestens 75 Prozent der echten Seitenaufrufe die Grenzwerte einhalten, getrennt nach Mobil und Desktop.
Google empfiehlt, gute Werte anzustreben, und schreibt, dass Core Web Vitals und andere Aspekte der Nutzerfreundlichkeit den Anforderungen seiner Ranking-Systeme entsprechen (Google Search Central). Sie sind aber kein Ersatz für relevante Inhalte. Eine schnelle Seite, die die Suchanfrage nicht beantwortet, rankt trotzdem nicht.
Die drei Werte und ihre Grenzwerte
| Wert | Misst | Gut | Verbesserungswürdig | Schlecht |
|---|---|---|---|---|
| LCP (Largest Contentful Paint) | Zeit, bis das größte sichtbare Element geladen ist | bis 2,5 s | 2,5 bis 4,0 s | über 4,0 s |
| INP (Interaction to Next Paint) | Verzögerung zwischen Klick, Tippen oder Tastendruck und der sichtbaren Reaktion | bis 200 ms | 200 bis 500 ms | über 500 ms |
| CLS (Cumulative Layout Shift) | wie stark Inhalte beim Laden verrutschen | bis 0,1 | 0,1 bis 0,25 | über 0,25 |
Quellen: web.dev zu LCP, INP und CLS. INP hat im März 2024 den früheren Wert First Input Delay (FID) abgelöst. Ältere Anleitungen, die noch FID nennen, sind in diesem Punkt veraltet.
Felddaten und Labordaten: die häufigste Verwechslung
Viele schauen auf den Lighthouse-Wert in PageSpeed Insights und halten ihn für die Core Web Vitals. Das stimmt nicht ganz. Es gibt zwei Arten von Daten:
| Felddaten | Labordaten | |
|---|---|---|
| Herkunft | echte Chrome-Nutzer (Chrome UX Report) | eine simulierte Messung mit festem Gerät und Netz |
| Zeitraum | die letzten 28 Tage | ein einzelner Testlauf |
| Wo zu sehen | Search Console (Bericht „Core Web Vitals“), oberer Teil von PageSpeed Insights | Lighthouse, unterer Teil von PageSpeed Insights, Chrome DevTools |
| Zählt für Google | ja | nein, dient der Fehlersuche |
| INP messbar | ja | nein, Lighthouse misst stattdessen Total Blocking Time |
Für die Bewertung zählen die Felddaten. Labordaten helfen, Ursachen zu finden und Änderungen sofort zu testen, bevor sie sich nach Wochen in den Felddaten zeigen.
Kleine Websites haben oft keine Felddaten. Wenn zu wenige Chrome-Nutzer eine Seite aufrufen, zeigt die Search Console „Nicht genügend Nutzungsdaten“ und PageSpeed Insights nur Labordaten. Dann ist der Lighthouse-Test die einzige Orientierung. Für die Bewertung durch Google gibt es in diesem Fall schlicht keine Werte.
LCP verbessern: der größte Inhalt kommt zu spät
Das LCP-Element ist meist ein großes Bild im oberen Bereich, ein Hintergrundbild oder ein Textblock wie die Hauptüberschrift. Welches Element es ist, zeigt PageSpeed Insights unter „Largest Contentful Paint element“.
Typische Ursachen und Lösungen:
- Das Titelbild ist zu groß. Bilder in WebP oder AVIF ausliefern, in der passenden Größe für das Gerät (
srcset), und nicht breiter als angezeigt. - Das Titelbild wird verzögert geladen.
loading="lazy"gehört nicht an das LCP-Bild. Stattdessenfetchpriority="high", damit der Browser es früh anfordert. - Der Server antwortet langsam. Eine hohe Time to First Byte verschiebt alles nach hinten. Caching, ein CDN oder statisch erzeugte Seiten helfen.
- Schriften und CSS blockieren die Darstellung. Kritisches CSS früh laden, große Stylesheets aufteilen, Schriften mit
font-display: swapeinbinden. - Der Inhalt wird erst per JavaScript erzeugt. Wenn die Überschrift erst nach einem Script erscheint, wartet der LCP auf dieses Script. Inhalte, die schon im HTML stehen, sind schneller da.
INP verbessern: die Seite reagiert träge
INP betrachtet alle Interaktionen während eines Besuchs und meldet einen der langsamsten Werte. Schlechte Werte entstehen fast immer durch JavaScript, das den Hauptthread blockiert.
- Zu viele Drittanbieter-Scripts. Chat-Widgets, Tag-Manager mit vielen Tags, Werbe- und Tracking-Scripts laufen im selben Thread wie die Seite. Jedes Script prüfen: Wird es gebraucht, kann es später geladen werden?
- Lange Aufgaben. JavaScript, das länger als 50 Millisekunden am Stück läuft, verzögert jede Eingabe. Große Aufgaben in kleinere Schritte teilen.
- Aufwendige Reaktionen auf Klicks. Wenn ein Klick große Teile der Seite neu aufbaut, sieht der Nutzer lange nichts. Zuerst sichtbares Feedback geben, schwere Arbeit danach erledigen.
- Große DOM-Strukturen. Seiten mit tausenden Elementen brauchen bei jeder Änderung länger. Lange Listen oder Tabellen nur teilweise rendern.
Für die Fehlersuche hilft der Bereich „Performance“ in den Chrome DevTools. Dort zeigt eine Aufzeichnung, welches Script bei einem Klick wie lange läuft.
CLS verbessern: Inhalte springen
Layoutverschiebungen ärgern Nutzer besonders, wenn sie danebentippen, weil ein Button nach unten rutscht. Die häufigsten Ursachen laut web.dev:
- Bilder und Videos ohne Maße.
widthundheightim HTML angeben oderaspect-ratioper CSS setzen, damit der Platz vorher reserviert ist. - Werbung, Banner und eingebettete Inhalte, die sich nach dem Laden vergrößern. Feste Platzhalter mit Mindesthöhe einplanen.
- Nachgeladene Inhalte oberhalb des sichtbaren Bereichs, etwa ein Cookie-Hinweis, der den Inhalt nach unten schiebt, statt darüber zu liegen.
- Webfonts, die deutlich größer oder kleiner sind als die Ersatzschrift. Passende Ersatzschriften wählen oder Schriften vorladen.
Prüfreihenfolge in der Praxis
- Search Console öffnen, Bericht „Core Web Vitals“. Getrennt nach Mobil und Desktop zeigt er, welche URL-Gruppen schlecht oder verbesserungswürdig sind. Mobil zuerst ansehen.
- Eine Beispiel-URL je Gruppe in PageSpeed Insights prüfen. Oben stehen die Felddaten, unten die Lighthouse-Diagnose mit konkreten Hinweisen.
- Die Ursache am Template beheben, nicht an einzelnen Seiten. Schlechte Werte betreffen meist alle Seiten, die dieselbe Vorlage nutzen, etwa alle Blogartikel oder alle Produktseiten.
- Im Labor testen, ob die Änderung wirkt, und erst dann veröffentlichen.
- In der Search Console „Fehlerbehebung überprüfen“ starten. Weil die Felddaten 28 Tage umfassen, dauert es mehrere Wochen, bis sich die Werte vollständig ändern.
Nicht jede Warnung aus Lighthouse ist gleich wichtig. Wer zuerst das LCP-Bild, die größten Drittanbieter-Scripts und fehlende Bildmaße behebt, löst bei den meisten Websites den größten Teil der Probleme.
Wie wichtig sind Core Web Vitals für das Ranking?
Core Web Vitals sind ein Signal unter vielen. Google beschreibt sie als Teil der Nutzerfreundlichkeit, die seine Ranking-Systeme belohnen, betont aber an anderer Stelle, dass relevante Inhalte wichtiger sind. In der Praxis heißt das: Wer bei Inhalt und Suchintention gleichauf mit der Konkurrenz liegt, kann über eine bessere Nutzererfahrung den Unterschied machen. Wer die Suchintention verfehlt, gewinnt mit schnellen Ladezeiten nichts.
Unabhängig vom Ranking haben langsame und springende Seiten einen direkten Preis: Besucher brechen ab, bevor sie das Angebot sehen. Das gilt vor allem mobil.
Wenn Ihre Website nach einem Relaunch oder einem Update langsamer geworden ist, lohnt der Blick in die Ursachen für einen Sichtbarkeitsverlust. Technische Probleme kommen dort selten allein. Bei tieferen Problemen mit Server, Rendering oder Indexierung hilft eine Analyse im Rahmen von technischem SEO.
FAQ: Core Web Vitals
Was sind gute Core Web Vitals-Werte?
LCP bis 2,5 Sekunden, INP bis 200 Millisekunden und CLS bis 0,1. Gemessen wird am 75. Perzentil der echten Seitenaufrufe, getrennt nach Mobil und Desktop.
Warum zeigt die Search Console keine Core Web Vitals für meine Website?
Die Daten stammen von echten Chrome-Nutzern. Hat eine Seite oder Website zu wenige Aufrufe, gibt es keine Felddaten. Dann helfen nur Labortests in PageSpeed Insights oder Lighthouse.
Ist ein Lighthouse-Wert von 100 nötig?
Nein. Der Lighthouse-Wert ist eine Laborbewertung und fließt nicht direkt in das Ranking ein. Entscheidend ist, dass die Felddaten die drei Grenzwerte einhalten.
Wie lange dauert es, bis Verbesserungen sichtbar werden?
Labortests zeigen Änderungen sofort. Die Felddaten fassen 28 Tage zusammen, deshalb dauert es mehrere Wochen, bis die Search Console die neuen Werte vollständig zeigt.
Was hat FID mit INP zu tun?
First Input Delay (FID) war bis März 2024 der Wert für die Reaktionsfähigkeit. Er maß nur die erste Interaktion. INP hat ihn abgelöst und betrachtet alle Interaktionen eines Besuchs.