- 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 (FID) abgelöst. FID-Werte sind damit überholt.
- Die offiziellen Messwerte kommen aus echten Chrome-Nutzerdaten, nicht aus einem Labortest. Schlechte Labortests sind ein Hinweis, aber Felddaten aus der Search Console entscheiden.
Eine Website kann im Geschwindigkeitstest 100 von 100 Punkten holen und sich für echte Besucher trotzdem zäh anfühlen. Genau diese Lücke zwischen Testergebnis und echtem Erleben schließen die Core Web Vitals. Sie messen nicht den Idealzustand im Labor, sondern was ein Mensch auf seinem Smartphone wirklich erlebt: wann der Inhalt erscheint, wie schnell die Seite auf eine Eingabe reagiert und ob das Layout dabei ruhig bleibt. Dieser Artikel erklärt die drei Werte, ihre Schwellen, wie Sie sie messen, und an welchem Punkt weitere Optimierung nichts mehr bringt.
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 die gesamte Zeitspanne bis zum nächsten sichtbaren Bildschirmaufbau, nicht bloß deren Beginn.
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. Gezählt wird nicht nur das Laden, auch spätere Sprünge beim Scrollen oder durch nachladende Inhalte fließen ein. 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 ordnet die Core Web Vitals dem Page Experience Signal zu und formuliert ihre Rolle bewusst zurückhaltend. Gute Werte decken sich mit dem, was Googles Kernsysteme belohnen wollen. Das ist kein Versprechen auf einen Ranking-Bonus, sondern die Einordnung als ein Signal unter mehreren. Zu Page Experience zählen außerdem HTTPS, Mobiltauglichkeit und das Vermeiden aufdringlicher Einblendungen.
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.
Wie viel Optimierung sich wirklich lohnt
Der teuerste Denkfehler beim Thema Core Web Vitals ist, dem perfekten Wert hinterherzujagen. Zwei sehr verschiedene Blickwinkel führen zum selben Rat, und genau das macht ihn belastbar.
Die SEO-Sicht. Geschwindigkeit ist ein schwacher direkter Rankingfaktor. Eine vielzitierte Analyse von Backlinko beschleunigte eine ohnehin sehr langsame Seite von rund 40 Sekunden auf 1,6 Sekunden Ladezeit. Ranking und Traffic änderten sich dadurch nicht. Das deckt sich mit Googles eigener, zurückhaltender Formulierung: Eine sehr langsame Seite wird zum Problem, für eine sehr schnelle gibt es keinen Bonus. Ist die Schwelle erreicht, bringt jede weitere Millisekunde keinen Suchvorteil mehr. Die Wirkung läuft dann nur noch indirekt, über zufriedene Besucher, die länger bleiben.
Die Technik-Praxis-Sicht. Aus meiner Sicht wiegt der zweite Blickwinkel schwerer. Wer den 100-Punkte-Score zum Ziel macht, opfert oft das Falsche: ein verkaufsstarkes Hero-Video, einen Vergleichsrechner, einen Live-Chat. Diese Elemente kosten Punkte, bringen aber Kunden. Manche Werkzeuge erzeugen grüne Ampeln durch Tricks, etwa indem sie für einen Sekundenbruchteil eine leere Seite ausliefern. Das hübscht den Test auf, ohne dass ein echter Besucher schneller bedient wird. Und jedes Drittanbieter-Skript, ob Analyse, Tracking-Pixel oder Chat, drückt die Werte unweigerlich. Sie alle gleichzeitig grün zu bekommen, ist teuer.
Zwei Welten, derselbe Schluss aus verschiedenen Gründen: Die SEO-Seite sagt, der Score bringt oben heraus nichts mehr. Die Technik-Seite sagt, er kostet oben heraus die Conversion. Der lohnende Bereich liegt unten, beim Heben roter Werte in den grünen oder wenigstens gelben Bereich. Dort sitzen die billigen Hebel, die sich fast immer lohnen, weil sie die Seite spürbar schneller machen, ohne das Design zu beschneiden: ein komprimiertes Hero-Bild als WebP statt PNG, Lazy Loading für Medien unterhalb des sichtbaren Bereichs, eine feste Höhe für nachladende Banner, Caching.
Ein verbreitetes Muster zeigt, warum die Felddaten dabei das letzte Wort haben: Eine Seite mit gutem Labor-Score steht in der Search Console trotzdem oft auf „schlecht“. Der Grund ist meist ein großes, unkomprimiertes Hero-Bild, das im schnellen Testnetz kaum auffällt, einen echten Mobilbesucher mit LTE aber Sekunden kostet. Das Labor liefert nur den Hinweis. Das wahre Ausmaß zeigen die Felddaten, und ein kurzer Test auf einem echten Gerät macht das konkrete Problem greifbar. Wer mit WooCommerce arbeitet, findet die spezifischen Hebel im Artikel WooCommerce beschleunigen.
Für Entwickler · überspringbar
Profi-Block: Warum INP der härteste der drei ist
LCP und CLS löst man meist mit wenigen gezielten Eingriffen: das Hauptbild vorladen, für Bilder und Banner feste Größen reservieren. INP ist hartnäckiger, weil er nicht an einer Stelle hängt, sondern am gesamten JavaScript der Seite. Jede Interaktion, die länger als 200 Millisekunden bis zur sichtbaren Reaktion braucht, zählt, und das über den ganzen Besuch.
Die Ursache ist fast immer der Hauptthread. Der Browser verarbeitet JavaScript in einer einzigen Schlange. Läuft dort eine lange Aufgabe (eine „Long Task“ über 50 Millisekunden), muss eine Nutzereingabe warten, bis sie fertig ist. Genau diese Wartezeit misst INP. Page-Builder, schwere Event-Handler und vor allem Drittanbieter-Skripte sind die typischen Blockierer. Ein Tag-Manager, der bei jedem Klick Listener auslöst, kann den INP-Wert allein nach unten ziehen.
Der wirksamste Hebel ist, lange Aufgaben aufzuteilen und dem Browser zwischendurch die Kontrolle zurückzugeben, damit er auf eine wartende Eingabe reagieren kann. In modernen Browsern geht das mit der Scheduler-API:
async function verarbeiteGrosseListe(items) {
for (const item of items) {
bearbeite(item);
// Kontrolle zurueckgeben, falls eine Eingabe wartet
if (navigator.scheduling?.isInputPending?.()) {
await scheduler.yield();
}
}
}Wo die Scheduler-API fehlt, dient ein await new Promise(r => setTimeout(r)) als Bruchstelle. Wichtiger als die Technik ist die Haltung: Auf einer WordPress-Seite bringt es oft mehr, ein überflüssiges Tracking-Skript ganz zu entfernen, als das vorhandene zu optimieren. Was nicht lädt, blockiert auch nichts.
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.
- Optimieren Sie bis zur Schwelle, nicht bis zur Perfektion. Google belohnt keine Extra-Geschwindigkeit, und die Jagd nach dem 100-Punkte-Score kostet oft Conversion.
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.
Muss ich einen perfekten Score von 100 Punkten anstreben?
Nein. Google bestraft sehr langsame Seiten, vergibt aber keinen Bonus für extreme Geschwindigkeit. Sobald Ihre Werte im grünen Bereich liegen (LCP unter 2,5 Sekunden, INP unter 200 Millisekunden, CLS unter 0,1), bringt weitere Optimierung am Ranking kaum noch etwas. Die verbleibende Zeit investieren Sie meist besser in Inhalt und Conversion. Entscheidend ist, rote Werte über die Schwelle zu heben, nicht die letzte Zehntelsekunde herauszuholen.
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);
Google Search Central: Core Web Vitals und die Google-Suche.
Stand: Juni 2026. Dieser Artikel gibt einen fachlichen Überblick und ersetzt keine individuelle technische Analyse Ihrer Website.