Core Web Vitals nicht bestanden? LCP, INP und CLS verbessern

Kurzantwort: „Core Web Vitals nicht bestanden“ heißt: Mindestens einer von drei Werten liegt bei echten Besuchern über der Grenze. Der LCP (Laden) soll höchstens 2,5 Sekunden betragen, der INP (Reaktion) höchstens 200 Millisekunden und der CLS (Stabilität des Layouts) höchstens 0,1, jeweils am 75. Perzentil. Suche den schwachen Wert in den Daten echter Besucher, nicht in der Laborwertung, und behebe zuerst diesen einen. Google sagt, dass seine Ranking-Systeme die Core Web Vitals nutzen, aber gute Werte sichern keinen Spitzenplatz.

Was bedeutet „Core Web Vitals nicht bestanden“?

Die Core Web Vitals sind der Teil von Googles Web-Vitals-Initiative, der für jede Webseite gilt. web.dev nennt drei Messwerte, je einen für einen Teil des Nutzererlebnisses:

Bewertet wird am 75. Perzentil der Seitenaufrufe, getrennt nach Handy und Computer. Auf Deutsch: Bei drei von vier Besuchen muss der Wert gut sein, und Handy und Computer bekommen je ein eigenes Urteil. Nach web.dev gilt eine Seite in Werkzeugen als bestanden, wenn sie am 75. Perzentil alle drei Ziele erreicht. Ein einziger roter Wert reicht also zum Durchfallen.

Ein Detail an der Grenze: web.dev schreibt für INP und CLS „oder weniger“, Googles Dokumentation zur Suche schreibt „weniger als 200 Millisekunden“ und „weniger als 0,1“. Plane deshalb deutlich unter der Grenze, dann spielt der Unterschied keine Rolle.

Eine Änderung solltest du kennen: Der INP hat im März 2024 den First Input Delay (FID) als Core Web Vital abgelöst, wie die Ankündigung auf web.dev sagt. Eine Anleitung, die noch den FID nennt, ist veraltet. Alle in diesem Artikel genannten Seiten haben wir am 4. November 2026 gelesen; die Übersicht auf web.dev wurde zuletzt am 31. Oktober 2024 aktualisiert.

Beeinflussen die Core Web Vitals das Google-Ranking?

Laut Google ja, aber ohne Gewichtung. Googles Seite zur Seitenerfahrung sagt: „Core Web Vitals are used by our ranking systems.“ Google empfiehlt gute Werte für den Erfolg in der Suche und betont, dass es kein einzelnes Signal für die Seitenerfahrung gibt.

Genauso deutlich nennt die Seite die Grenzen. Gute Ergebnisse im Bericht zu den Core Web Vitals in der Search Console oder in Werkzeugen von Dritten „doesn't guarantee that your pages will rank at the top of Google Search results“. Außerdem steht dort, ein perfekter Wert nur aus SEO-Gründen sei womöglich nicht der beste Einsatz deiner Zeit. Google will immer die relevantesten Inhalte zeigen, auch wenn die Seitenerfahrung schwach ist.

Wie schwer die Werte wiegen, veröffentlicht Google nicht, deshalb nennen wir ebenfalls keine Zahl. Unsere Einschätzung, keine Aussage von Google: Sieh die Grenzwerte als Qualitätsmaßstab für deine Besucher, bring alle drei in den grünen Bereich und stecke die Zeit danach wieder in Inhalte. Googles Ranking-Systeme bewerten Inhalte meist seitenweise, prüfe also jede wichtige Seitenart und nicht nur die Startseite.

Labor- oder Felddaten: Welche zählen bei den Core Web Vitals?

Die Bewertung beruht auf Felddaten, also Messungen echter Besuche. Sie stammen aus dem Chrome User Experience Report (CrUX), der Daten echter Chrome-Nutzer sammelt; PageSpeed Insights und der Bericht zu den Core Web Vitals in der Search Console zeigen sie an. Ein CrUX-Bericht deckt laut web.dev einen Zeitraum von 28 Tagen ab.

Labordaten entstehen, wenn die Seite einmal unter festen Bedingungen geladen wird: ein Gerät, ein Netz, ein Standort. Das eignet sich bestens, um Ursachen zu finden und eine Korrektur vor der Veröffentlichung zu testen, warnt aber laut Anleitung zum LCP: „lab tests alone may not be entirely representative“, also nicht unbedingt repräsentativ. Widersprechen sich beide, rät die Anleitung zum LCP, zuerst die Daten echter Nutzer anzusehen. Die Unterschiede haben handfeste Gründe:

• Das LCP-Element kann abweichen. Ein Laborlauf findet immer dasselbe Element. Echte Besucher haben andere Bildschirmgrößen, eingeloggte Inhalte oder A/B-Tests.
• Der INP braucht echte Menschen. Lighthouse und andere Laborwerkzeuge laden eine Seite, ohne dass jemand klickt, und können den INP deshalb nicht messen. Die Total Blocking Time (TBT) ist der Ersatz im Labor; was sie verbessert, kann auch den INP verbessern.
• Der CLS zählt nach dem Laden weiter. Laborläufe sehen meist nur den Ladevorgang. Im Feld kann auch Inhalt, der beim Scrollen nachgeladen wird, das Layout verschieben.
• Zwischenspeicher helfen echten Besuchern. Labortests starten meist mit leerem Cache, wiederkehrende Besucher und der Vor-/Zurück-Cache (bfcache) laden Seiten schneller.

So liest du deine Zahlen in vier Schritten:

1. Rufe deine Adresse in PageSpeed Insights ab. Der Bereich „Discover what your real users are experiencing“ enthält Felddaten, „Diagnose performance issues“ den Laborlauf.
2. Prüfe, was du siehst. Wechsle zwischen Handy und Computer und zwischen der einzelnen Adresse und der ganzen Website („Origin“). Hat eine Adresse zu wenig Daten, zeigt PageSpeed Insights stattdessen die der ganzen Website.
3. Finde den Wert, der am 75. Perzentil über der Grenze liegt. Das ist dein schwacher Wert. Bei zu wenig Besuchern gibt es keine Felddaten; nimm dann die Laborwerte und miss deine Besucher selbst mit der kleinen Bibliothek web-vitals von web.dev.
4. Öffne die Labordiagnose zu diesem Wert, sieh die Ursache und behebe zuerst diese eine Sache.

LCP verbessern: Das größte Element erscheint zu spät

Der LCP meldet, wann das größte Bild, der größte Textblock oder das größte Video im sichtbaren Bereich gezeichnet ist. Die Anleitung von web.dev teilt die Zeit in vier Teile, die zusammen den LCP ergeben: die Serverantwort (TTFB), die Wartezeit, bis der Browser die LCP-Ressource zu laden beginnt, die Ladedauer dieser Ressource und die Zeit, bis das Element gezeichnet ist. Suche zuerst den größten Teil, bevor du etwas änderst: Wer einen Teil verkürzt, verschiebt die Zeit unter Umständen nur in einen anderen. Ein stärker komprimiertes Bild hilft nicht, wenn das Element ohnehin versteckt bleibt, bis ein Skript geladen ist.

Die Liste der wirksamsten Maßnahmen vom Chrome-Team enthält unter anderem diese Punkte:

1. Mach das LCP-Bild leicht auffindbar und gib ihm Vorrang. Nimm ein normales <img> mit src oder srcset, kein data-src, das JavaScript braucht. Lass die Seite lieber auf dem Server aufbauen, statt sie erst im Browser zusammenzusetzen. Ergänze fetchpriority="high" und entferne loading="lazy" bei genau diesem Bild.
2. Verkürze die Serverantwort. Liefere und speichere Inhalte nah bei deinen Besuchern, meist mit einem CDN.

Dasselbe Tag erledigt den LCP und über die Größenangabe auch den CLS:

<!-- Hauptbild: im HTML, hohe Priorität, nicht lazy, mit Größe -->
<img src="/img/titel.webp" width="1200" height="630" alt="Kurze Beschreibung" fetchpriority="high">

<!-- Bilder weiter unten: Lazy Loading ist hier in Ordnung -->
<img src="/img/team.webp" width="600" height="400" alt="Kurze Beschreibung" loading="lazy">

INP verbessern: Die Seite reagiert zu langsam

Der INP beobachtet jeden Klick, jedes Tippen und jeden Tastendruck während eines Besuchs und meldet ungefähr den langsamsten; bei Seiten mit sehr vielen Interaktionen bleiben Ausreißer außen vor. Mit der Maus nur darüberfahren und Scrollen zählt nicht. Laut Anleitung zum INP besteht jede Interaktion aus drei Teilen: der Verzögerung bis zum Start, der Laufzeit der Ereignis-Handler und der Wartezeit bis zum nächsten gezeichneten Bild. Meist ist JavaScript schuld, das den Hauptthread blockiert. Die wichtigsten Maßnahmen des Chrome-Teams:

1. Teile lange Aufgaben auf. Eine Aufgabe über 50 Millisekunden blockiert den Hauptthread. Gib die Kontrolle oft zurück: mit scheduler.yield(), wo der Browser es kann, sonst mit setTimeout.
2. Liefere weniger JavaScript aus. Finde ungenutzten Code mit dem Coverage-Werkzeug der Chrome-DevTools, teile Code auf, der anfangs nicht gebraucht wird, und räume alte Tags im Tag-Manager auf.
3. Vermeide große Darstellungsänderungen. Halte das DOM klein, vermeide erzwungenes Layout und nutze CSS-Containment für Inhalte außerhalb des Bildschirms.

CLS verbessern: Das Layout springt

Der CLS hat keine Einheit. Er verbindet, wie viel sichtbarer Inhalt sich verschoben hat und wie weit. Im Feld zählt er über den ganzen Besuch, Verschiebungen innerhalb von 500 Millisekunden nach einer Eingabe bleiben aber außen vor. Die Anleitung zum CLS nennt die häufigsten Ursachen: Bilder ohne Maße, Werbung, Einbettungen und iframes ohne Maße, nachträglich eingefügte Inhalte und Webfonts. Das hilft:

• Platz reservieren. Gib Bildern und Videos width und height oder nutze die CSS-Eigenschaft aspect-ratio. Bei Inhalten unbekannter Größe ist eine sinnvolle min-height besser als der Standardwert null.
• Mit transform animieren. Wer top, left oder margin animiert, verschiebt das Layout. Typisch sind Cookie-Banner, die hereingleiten.
• Den Vor-/Zurück-Cache arbeiten lassen. Er stellt fertig gezeichnete Seiten wieder her. Häufige Blocker sind no-store-Cache-Anweisungen und unload-Ereignisse.
• Webfonts im Griff haben. font-display: optional, passende Ersatzschriften mit size-adjust und das Vorladen wichtiger Schriften verringern schriftbedingte Sprünge.

So prüft SEOgrinder die Core Web Vitals

SEOgrinder ist unser Werkzeug, wir bauen es. Gibst du bei SEOgrinder die Adresse einer öffentlichen Seite ein, kommen die Geschwindigkeitswerte von Google PageSpeed Insights, für Handy und Computer. Die Karte „Core Web Vitals“ zeigt LCP und CLS aus dem Lighthouse-Laborlauf und den INP von echten Besuchern; in einem eigenen Feld stehen die echten Nutzerdaten der letzten 28 Tage. Hat Google zu wenig Daten für die Seite, sagt der Bericht das, statt zu raten. Aufgaben wie „Echte Besucher am Handy warten … auf den Inhalt“ nennen Messwert, Zahl und Lösung. Eine langsame Serverantwort, die in den LCP einfließt, bekommt eine eigene Aufgabe.

Die Grenzen: SEOgrinder liest Googles Zahlen und ersetzt keine eigene Messung bei echten Besuchern. Rankings misst es nicht. Ist Googles Tageskontingent für die Geschwindigkeitsmessung aufgebraucht, kommt der Bericht ohne sie.

Häufige Fehler

• Nur auf die Laborwertung vertrauen. Sie kann den INP nicht messen und kann anders aussehen als das, was Besucher erleben. Fang mit den Werten echter Besucher an.
• Nur ein Gerät prüfen. Handy und Computer werden getrennt bewertet.
• Das Hauptbild lazy laden. loading="lazy" am LCP-Bild fügt Wartezeit hinzu.
• Bildmaße weglassen. Ohne width und height kann der Browser keinen Platz reservieren.
• Am falschen Teil des LCP drehen. Komprimiere Bilder erst, wenn die Aufteilung zeigt, dass die Ladedauer das Problem ist.
• Sofort ein Ergebnis erwarten. Felddaten umfassen 28 Tage und ändern sich nur allmählich. Prüfe nach einer Korrektur gleich den Laborlauf und die Werte echter Besucher in den Wochen danach.

Häufige Fragen

Was ist ein guter Wert bei den Core Web Vitals?

Eine einzelne Note gibt es nicht. Eine Seite besteht, wenn der LCP am 75. Perzentil höchstens 2,5 Sekunden, der INP höchstens 200 Millisekunden und der CLS höchstens 0,1 beträgt. Die Zahl von 0 bis 100, die du von Lighthouse kennst, ist ein Laborwert und etwas anderes.

Warum zeigt PageSpeed Insights für meine Website keine Daten echter Besucher?

Meist gibt es zu wenige Besuche, als dass CrUX etwas melden könnte. web.dev rät dann, die echten Besucher zusätzlich selbst zu messen. Bis dahin arbeitest du mit den Laborwerten.

Brauche ich einen perfekten Wert?

Nein. Das Ziel ist, zu bestehen. Google selbst schreibt, ein perfekter Wert nur aus SEO-Gründen sei womöglich nicht der beste Einsatz deiner Zeit.

Dein nächster Schritt

Lass deine wichtigste Seite durch SEOgrinder laufen, öffne die Karte „Core Web Vitals“ und sieh zuerst auf die Werte echter Besucher. Behebe den einen Wert, der durchfällt, klicke auf Neu prüfen und lies danach die Laborwerte. Das größere Bild findest du in unserer SEO-Audit-Checkliste.

Weiterlesen

• Bei Google besser ranken: 3 Dinge, die Google selbst empfiehlt
• Interne Verlinkung: verwaiste Seiten finden, Klicktiefe senken
• Strukturierte Daten mit JSON-LD: Beispiele zum Kopieren und Testen