- Google misst mit drei Kennzahlen, was Besucher wirklich erleben: LCP für Ladegeschwindigkeit, INP für Reaktionsfähigkeit und CLS für visuelle Stabilität.
- Gut bedeutet konkret: LCP unter 2,5 Sekunden, INP unter 200 Millisekunden, CLS unter 0,1.
- Seit März 2024 hat Interaction to Next Paint (INP) die ältere Metrik First Input Delay abgelöst. Wer sich auf FID-Werte verlässt, schaut auf eine veraltete Zahl.
- Die offiziellen Messwerte kommen aus echten Chrome-Nutzerdaten, nicht aus einem Labortest. Schlechte Labortests sind ein Hinweis, aber Felddaten aus der Search Console entscheiden.
Ladezeit in Sekunden war lange die einzige Zahl, die zählte. Das Problem: Sie sagt wenig darüber aus, was ein Besucher auf seinem Smartphone wirklich erlebt. Eine Seite kann nach drei Sekunden technisch fertig geladen sein und dabei trotzdem ruckeln, springen und auf Klicks nicht reagieren. Genau das wollte Google messen. Das Ergebnis sind die Core Web Vitals: drei Kennzahlen, die konkrete Nutzererfahrungen abbilden, nicht den Idealzustand im Testlabor.
Was Core Web Vitals wirklich messen
Der Kern der Sache: Die Werte stammen nicht aus einem synthetischen Test, sondern aus dem Chrome User Experience Report (CrUX). Das ist eine Sammlung anonymisierter Messdaten echter Chrome-Nutzer. Jedes Mal, wenn jemand Ihre Seite mit Chrome besucht und dem Datenteilen zugestimmt hat, fließt sein Erlebnis in diese Daten ein. Was die Search Console anzeigt, ist also der Durchschnitt echter Besucher auf echten Geräten mit echten Verbindungen.
Die drei stabilen Metriken heißen Largest Contentful Paint (LCP), Interaction to Next Paint (INP) und Cumulative Layout Shift (CLS). Daneben gibt es weitere Signale wie Time to First Byte und First Contentful Paint. Diese helfen bei der Fehlerdiagnose, fließen aber nicht direkt als Core Web Vitals in die Bewertung ein.
Alle Schwellenwerte gelten am 75. Perzentil der Seitenaufrufe. Das bedeutet: 75 Prozent Ihrer Besucher müssen den guten Wert erreichen, damit eine Seite als gut eingestuft wird. Die schlechtesten 25 Prozent der Besuche zählen nicht als Ausreißer weg, sondern beeinflussen die Einstufung mit.
LCP: Wann erscheint der Hauptinhalt?
Konkret erfasst LCP, zu welchem Zeitpunkt das dominante Element der Seite erscheint. Das ist meistens ein großes Bild im Hero-Bereich, ein Hintergrundbild oder eine große Überschrift. Welche Elemente als LCP-Kandidaten zählen, hat Google klar definiert: <img>-Elemente, <video>-Poster, Elemente mit CSS-Hintergrundbildern und Block-Elemente mit Text kommen infrage. Vollständig transparente Elemente oder Platzhalter mit wenig Inhalt bleiben außen vor.
Der häufigste Grund für einen schlechten LCP-Wert bei WordPress-Seiten ist ein großes Hero-Bild ohne Vorladen. Lädt der Browser erst die gesamte CSS-Datei und alle Skripte, bevor er das Hauptbild anfordert, vergehen schnell 3 bis 4 Sekunden, bevor der Besucher überhaupt etwas Relevantes sieht. Welche konkreten Schritte das beheben, zeigt der Artikel LCP verbessern: konkrete Schritte.
INP: Wie schnell reagiert die Seite?
Was INP von seinem Vorgänger First Input Delay (FID) unterscheidet, ist wichtig: FID maß nur die Verzögerung der allerersten Eingabe auf einer Seite, also den Moment vom Klick bis zu dem Punkt, an dem der Browser überhaupt anfängt, die Eingabe zu verarbeiten. INP geht weiter. Es beobachtet praktisch alle Klicks, Tipp-Eingaben und Tastaturinteraktionen während des gesamten Besuchs und misst nicht nur den Anfang der Verarbeitung, sondern die gesamte Zeitspanne bis zum nächsten sichtbaren Bildschirmaufbau.
Bei mehr als 50 Interaktionen pro Seitenbesuch ignoriert INP die schlechteste pro angefangene 50 Interaktionen, um vereinzelte Ausreißer nicht zu stark zu gewichten. Entscheidend bleibt aber die generelle Reaktionsfähigkeit über den gesamten Besuch hinweg.
Schlechte INP-Werte entstehen fast immer, wenn JavaScript den Hauptprozess des Browsers blockiert. Umfangreiche Tracking-Skripte von Drittanbietern, schwere Page-Builder-Skripte und schlecht optimierte Event-Handler sind die typischen Verursacher. Eine Seite kann einen guten LCP haben und trotzdem auf Formularklicks träge reagieren, wenn im Hintergrund zu viel JavaScript läuft.
CLS: Springt das Layout beim Laden?
Wer auf einem Mobilgerät eine Seite aufruft, einen Text liest und plötzlich alles nach unten springt weil ein Werbebanner nachgeladen hat, kennt das Problem. Genau diese unerwarteten Verschiebungen summiert CLS. Der Score berechnet sich aus dem Anteil des Viewports, der von der Verschiebung betroffen ist (Impact Fraction), multipliziert mit der Distanz, die ein Element zurücklegt (Distance Fraction). Eine Schaltfläche, die sich kurz vor dem Antippen um 200 Pixel nach unten bewegt, kann einen Klick auf das falsche Element auslösen, das ist kein theoretisches Problem.
Die häufigsten Ursachen sind gut greifbar: Bilder ohne feste Höhen- und Breitenangabe im HTML, Schriften die spät nachladen und den umliegenden Text neu anordnen, und Anzeigen oder Cookie-Banner, die nachträglich Platz beanspruchen. CLS ist oft die Metrik, die sich am direktesten beheben lässt, sobald die betroffenen Elemente identifiziert sind. Wer tiefer einsteigen will, findet eine vollständige Anleitung im Artikel CLS vermeiden: stabiles Layout statt Springen.
Alle drei Metriken auf einen Blick
| Metrik | Was sie misst | Gut | Verbesserungswürdig | Schlecht |
|---|---|---|---|---|
| LCP (Largest Contentful Paint) | Wann das größte sichtbare Element erscheint | unter 2,5 s | 2,5 bis 4,0 s | über 4,0 s |
| INP (Interaction to Next Paint) | Wie lange der Browser nach einer Eingabe braucht, bis etwas sichtbar passiert | unter 200 ms | 200 bis 500 ms | über 500 ms |
| CLS (Cumulative Layout Shift) | Wie stark Elemente während des Ladens unerwartet springen | unter 0,1 | 0,1 bis 0,25 | über 0,25 |
Alle Schwellenwerte stammen direkt aus der offiziellen Core Web Vitals Dokumentation auf web.dev und gelten am 75. Perzentil der Seitenaufrufe.
Felddaten gegen Labordaten
Hier liegt einer der häufigsten Denkfehler bei der CWV-Analyse. Es gibt zwei grundlegend verschiedene Arten zu messen, und sie liefern oft sehr unterschiedliche Ergebnisse.
Felddaten (Real User Monitoring) stammen aus echten Besuchen echter Nutzer. Google sammelt sie über den Chrome User Experience Report und zeigt sie in der Search Console und in PageSpeed Insights an. Diese Zahlen sind das, was Google für das Ranking verwendet. Ein Nachteil: Felddaten brauchen ausreichend Traffic. Seiten mit wenigen Besuchern sehen in der Search Console oft keine Bewertung, weil die Datenpunkte für eine statistische Aussage fehlen.
Labordaten entstehen in einer kontrollierten Testumgebung. PageSpeed Insights, Lighthouse und WebPageTest simulieren einen Seitenaufruf unter definierten Bedingungen: feste Verbindungsgeschwindigkeit, bestimmte Geräteklasse, kein laufendes JavaScript im Hintergrund. Das macht den Labortest reproduzierbar und gut für Entwicklungsarbeit. Für die Ranking-Bewertung zählt er aber nicht direkt.
Die Konsequenz für die Praxis: Ein glänzender Lighthouse-Score von 95 bedeutet nicht automatisch gute Felddaten. Echte Besucher nutzen ältere Android-Geräte, schwankende LTE-Verbindungen und haben mehrere Tabs gleichzeitig offen. Was im Labor drei Sekunden lädt, kann beim Durchschnittsbesucher fünf Sekunden brauchen. Deshalb sind die Search Console Berichte die erste Anlaufstelle, nicht der Labortest.
Was zum Debuggen bleibt: Labortests sind unverzichtbar, weil sie zeigen, warum die Werte schlecht sind. Welche Ressource blockiert den Aufbau, welches Skript verzögert die Interaktivität. Die Ursache findet man im Labor, den Beweis fürs Ranking liefern die Felddaten.
Warum Google sie als Rankingfaktor nutzt
Google hat bestätigt, dass Core Web Vitals als Teil des Page Experience Signals in das Ranking einfließen: „Core Web Vitals are used by our ranking systems.“ Daneben gehören zu Page Experience auch HTTPS, Mobile-Freundlichkeit und das Vermeiden aufdringlicher Interstitials.
Das Gewicht der Core Web Vitals ist geringer als das von Inhalt und eingehenden Links. Bei mehreren inhaltlich ähnlichen Seiten zu einem Suchbegriff können sie aber den Ausschlag geben. Mindestens ebenso relevant ist der mittelbare Effekt: eine langsame, springende Seite erhöht die Absprungrate und verkürzt die Verweildauer, was sich mittelbar auf das Nutzerverhalten auswirkt, das Google in aggregierter Form beobachtet.
Für kleine und mittelständische Unternehmen mit regionalen Suchbegriffen ist das Bild oft direkter: Wer die drei oder vier lokalen Wettbewerber um denselben Begriff hat, gewinnt mit klar besseren CWV-Werten einen spürbaren Vorsprung. Umgekehrt verliert, wer technisch deutlich schlechter dasteht als ein Konkurrent mit vergleichbarem Inhalt.
Praxisbeispiel: Was wir in Projekten sehen
In einem Projekt mit einem mittelgroßen WooCommerce-Shop sahen wir folgendes Bild: Lighthouse meldete einen Score von 72, der LCP-Wert im Labor lag bei 2,8 Sekunden. Die Search Console zeigte aber, dass 68 Prozent der Seiten als schlecht eingestuft waren, mit einem tatsächlichen LCP-Median von 4,6 Sekunden auf Mobilgeräten. Die Diskrepanz entstand durch ein unkomprimiertes Hero-Bild (380 kB PNG), das im Labor durch schnelle Testverbindung kaum auffiel, für einen typischen Mobilbesucher mit LTE aber über drei Sekunden allein für dieses Bild beanspruchte.
Der CLS-Wert von 0,18 fiel erst auf, als wir mit einem Mobilgerät auf der Produktseite scrollten: Ein Hinweisbanner mit Versandkosten lud nach und schob den kompletten Produktblock nach unten. Technisch verursacht durch einen fehlenden min-height-Wert auf dem Banner-Container. Die Korrektur war klein, der Effekt im Nutzertest sofort spürbar.
Das zeigt beide Seiten der Metrik: Labordaten liefern den Hinweis, Felddaten belegen das Ausmaß, und eine schnelle manuelle Überprüfung auf echten Geräten macht das konkrete Problem sichtbar. Wer mit WooCommerce arbeitet und nach spezifischen Hebeln sucht, findet sie im Artikel WooCommerce beschleunigen.
Wo und wie messen?
Der praktische Einstieg geht über drei Werkzeuge, die alle kostenlos sind:
Google Search Console zeigt die echten Felddaten geordnet nach Status und gruppiert nach URL-Typen. Das ist die wichtigste Quelle für die Ranking-relevanten Werte. Unter „Nutzererfahrung“ findet man sowohl die Mobilansicht als auch die Desktop-Auswertung.
PageSpeed Insights liefert für einzelne URLs sowohl Felddaten (sofern vorhanden) als auch Laborwerte aus Lighthouse. Besonders nützlich: es nennt konkrete Optimierungsvorschläge mit Einsparpotenzial in Sekunden.
Chrome DevTools Lighthouse erlaubt die lokale Analyse und ist unverzichtbar während der Entwicklung. Beim Einsatz im normalen Browserbetrieb laufen aber häufig Erweiterungen mit, die das Ergebnis verfälschen. Für reproduzierbare Ergebnisse entweder ein Inkognito-Fenster ohne Erweiterungen nutzen oder den DevTools-Lighthouse direkt starten.
Was oft übersehen wird: CWV-Werte gelten pro URL, nicht für die gesamte Domain. Die Startseite kann gut abschneiden, während Produktseiten mit großen Bildgalerien schlechte Werte haben. Die Search Console zeigt diese Verteilung nach URL-Gruppen und hilft, die Seiten mit dem größten Handlungsbedarf zu identifizieren.
Die häufigsten Ursachen für schlechte Werte, unabhängig von der Metrik, sind in der Regel dieselben. Eine strukturierte Übersicht bietet der Artikel Warum Ihre Website langsam ist: die fünf häufigsten Ursachen. Wer danach gezielt ans Thema Caching heran will, findet eine verständliche Einführung im Artikel Caching verständlich erklärt.
Wenn Sie wissen wollen, wo Ihre Website konkret steht und welche Hebel am meisten bringen, liefert der Website-Performance-Check von ihp media eine strukturierte Analyse mit priorisierten Empfehlungen.
Sofort-Checkliste
- Search Console aufgerufen und den Bericht „Core Web Vitals“ für Mobilgeräte geprüft?
- Gibt es Seiten, die als schlecht eingestuft sind? Diese Seiten zuerst angehen.
- Größtes sichtbares Element identifiziert und LCP-Wert im Feld geprüft (Ziel: unter 2,5 s)?
- Hero-Bild als JPEG oder WebP gespeichert, nicht als PNG, und mit
width/height-Attribut versehen? - INP-Wert bekannt? Liegen Drittanbieter-Tracking-Skripte im Verdacht?
- CLS-Wert bekannt? Alle Bilder und Anzeigencontainer mit fester Höhe versehen?
- Schriften über
font-display: swapeingebunden, um Text-Shift beim Laden zu reduzieren? - Laborwerte (Lighthouse) und Feldwerte (Search Console) verglichen? Große Abweichungen untersucht?
- Nach jeder größeren Änderung (neues Plugin, neues Theme) die CWV-Werte neu geprüft?
- Drei Metriken, drei konkrete Schwellenwerte: LCP unter 2,5 Sekunden, INP unter 200 Millisekunden, CLS unter 0,1.
- INP hat FID im März 2024 abgelöst und bewertet die Reaktionsfähigkeit über den gesamten Seitenbesuch, nicht nur den ersten Klick.
- Felddaten aus der Search Console entscheiden über das Ranking, nicht der Labortest. Beide haben ihren Nutzen: Felddaten zeigen das Ausmaß, Labortests die Ursache.
- CWV-Werte sind kein einmaliges Projekt. Jedes neue Plugin, jedes größere Bild und jedes neue Tracking-Skript kann die Werte verändern.
Häufige Fragen
Was genau hat INP ersetzt, und warum?
INP hat First Input Delay (FID) im März 2024 als stabilen Core Web Vital abgelöst. FID maß nur die Verzögerung der allerersten Nutzereingabe auf einer Seite, und nur bis zu dem Punkt, an dem der Browser anfängt, die Eingabe zu verarbeiten. INP beobachtet praktisch alle Interaktionen während des gesamten Besuchs und misst die vollständige Zeitspanne bis zum nächsten sichtbaren Bildschirmaufbau. Das gibt ein deutlich vollständigeres Bild der Reaktionsfähigkeit einer Seite.
Zählen Core Web Vitals wirklich für das Google-Ranking?
Ja. Google hat bestätigt, dass Core Web Vitals als Teil des Page Experience Signals in die Rankingsysteme einfließen. Ihr Gewicht ist geringer als das von Inhalt und Verlinkung. Bei ähnlich positionierten Seiten um denselben Suchbegriff können sie den Unterschied machen. Hinzu kommt die mittelbare Wirkung auf Absprungrate und Verweildauer.
Meine Search Console zeigt keine Daten. Was bedeutet das?
Felddaten aus dem Chrome User Experience Report entstehen nur bei ausreichend Traffic auf einer URL. Seiten mit wenig Besuchern haben schlicht nicht genug Messpunkte für eine statistische Aussage. In diesem Fall bleibt der Labortest über PageSpeed Insights oder Lighthouse als Orientierung. Sobald mehr Besucher kommen, füllt die Search Console sich automatisch.
Kann ich einen guten Lighthouse-Score haben und trotzdem schlechte CWV-Felddaten?
Ja, das ist häufig. Der Labortest läuft unter idealen Bedingungen mit einer definierten schnellen Verbindung. Echte Besucher nutzen ältere Mobilgeräte mit schwankender LTE-Verbindung. Was im Labor zwei Sekunden braucht, kann beim Median-Besucher vier Sekunden dauern. Deshalb sind Felddaten die relevante Größe für das Ranking, der Labortest das Diagnosewerkzeug dahinter.
Wie oft sollte ich die Werte überprüfen?
Nach jeder größeren Änderung an der Website: neues Plugin, neues Theme, neue eingebundene Skripte, neue Bildgalerien. Im laufenden Betrieb ohne große Änderungen genügt ein monatlicher Blick in die Search Console. Die Werte verschlechtern sich selten über Nacht, aber ein neues Tracking-Skript oder ein schlecht optimiertes Bild auf der Startseite kann in wenigen Tagen messbare Auswirkungen haben.
Was ist der Unterschied zwischen LCP und Time to First Byte (TTFB)?
TTFB misst, wie schnell der Server mit den ersten Datenbytes antwortet, bevor der Browser überhaupt anfängt, die Seite aufzubauen. LCP misst, wann der Besucher das dominante Element tatsächlich sieht. TTFB ist eine Ursache, LCP ist das Ergebnis. Ein schlechter TTFB-Wert zieht fast immer auch den LCP nach unten, aber ein guter TTFB allein reicht nicht für einen guten LCP aus.
Google / web.dev: Core Web Vitals (Schwellenwerte, Metriken-Übersicht);
Google / web.dev: Largest Contentful Paint (LCP);
Google / web.dev: Interaction to Next Paint (INP);
Google / web.dev: Cumulative Layout Shift (CLS);
Google Search Central: Page Experience Ranking Signal;
Chrome User Experience Report (CrUX).
Stand: Juni 2026. Dieser Artikel gibt einen fachlichen Überblick und ersetzt keine individuelle technische Analyse Ihrer Website.