Core Web Vitals prüfen und verbessern: LCP, INP, CLS für kleine Seiten

Core Web Vitals sind drei Messwerte, mit denen Google die Erfahrung echter Besucher beschreibt: wie schnell der Hauptinhalt erscheint (LCP), wie schnell die Seite auf einen Klick reagiert (INP) und wie ruhig das Layout beim Laden bleibt (CLS). Gemessen werden sie in Chrome, bei Besuchern, die das zulassen, über die letzten 28 Tage. Ein „Optimierung erforderlich“ in der Search Console und eine rote Zahl in PageSpeed Insights sind zwei verschiedene Befunde.

Die rote Lighthouse-Note ist nicht die Bewertung, die Google für die Suche heranzieht. Die Search Console wertet nur echte Nutzerdaten aus. Die Note von 0 bis 100 stammt aus einer Simulation auf einem Rechner im Rechenzentrum und ist ein Werkzeug zur Fehlersuche.

Die drei Werte und ihre Grenzen#

Google nennt für jeden Wert eine Grenze für „gut“ und eine für „schlecht“. Dazwischen liegt „Optimierung erforderlich“.

Maßgeblich ist laut web.dev das 75. Perzentil, getrennt nach Handy und Computer. Eine Seite besteht, wenn drei von vier Aufrufen bei allen drei Werten im grünen Bereich liegen. INP hat am 12. März 2024 den älteren Wert FID abgelöst. Wer noch Anleitungen zu „First Input Delay“ findet, liest einen veralteten Stand.

Felddaten, Labordaten und warum deine Seite vielleicht keine hat#

Felddaten stammen aus dem Chrome User Experience Report, kurz CrUX. Hinein kommen nur Besuche, bei denen der Nutzer die Nutzungsstatistik eingeschaltet und den Browserverlauf synchronisiert hat, und zwar mit Chrome am Computer oder unter Android. Chrome auf dem iPhone, Edge und andere Chromium-Browser liefern keine Daten, Safari und Firefox ohnehin nicht. Für eine Website, deren Kundschaft viel am iPhone surft, ist das ein kleiner Ausschnitt.

Dazu kommt eine Mindestmenge. Eine Seite oder ganze Website muss laut Chrome-Dokumentation „ausreichend beliebt“ sein, also eine Mindestzahl an Besuchern haben. Die genaue Zahl veröffentlicht Google nicht. Außerdem muss die Seite mit Status 200 antworten und darf kein noindex tragen. Anmelden lässt sich eine Website für CrUX nicht.

Was das praktisch heißt:

• PageSpeed Insights zeigt oben echte Nutzerdaten für die einzelne Adresse. Reichen sie nicht, fällt es auf die ganze Website zurück („Origin“). Reicht auch das nicht, steht dort nichts.
• Die Search Console zeigt dann „Keine Daten verfügbar“. Das ist kein Fehler und kein schlechtes Zeichen, es fehlt schlicht die Stichprobe.
• Labordaten gibt es immer. Lighthouse lädt die Seite einmal unter festen Bedingungen, mobil auf einem simulierten Mittelklasse-Handy (Moto G4) mit Mobilfunknetz. Das ist gut zum Nachstellen, sagt aber nichts darüber, wie es bei deinen Besuchern läuft.

INP gibt es im Labor gar nicht, weil beim Laden niemand klickt. Lighthouse nimmt ersatzweise die Total Blocking Time (TBT). web.dev nennt sie einen brauchbaren Hinweis, aber keinen Ersatz.

Wer keine Felddaten hat, wartet vergeblich auf sie. Dann ist der Labortest die Arbeitsgrundlage, seine Zahlen sind Richtung, nicht Urteil.

Wo du es prüfst, in drei Schritten#

1. Search Console, Bericht „Core Web Vitals“. Er teilt die Adressen nach Handy und Computer in „Langsam“, „Optimierung erforderlich“ und „Gut“. Die Adressen sind in Gruppen ähnlicher Seiten zusammengefasst, und eine Gruppe bekommt den Status ihres schlechtesten Werts. Aufgeführt werden nur indexierte Adressen. Fehlt der Zugang noch, steht in Google Search Console einrichten, wie die Property angelegt wird. Fehlen dir dort ganze Seiten, liegt das Problem woanders: Warum Google deine Seiten nicht indexiert.
2. PageSpeed Insights für eine Beispieladresse. Aus der schlechtesten Gruppe eine Adresse nehmen und testen, Ansicht „Mobil“. Der obere Teil (in der englischen Oberfläche „Discover what your real users are experiencing“) sind die Felddaten, der untere („Diagnose performance issues“) der Lighthouse-Test mit den konkreten Hinweisen. Weichen beide stark voneinander ab, gilt für die Suche der obere. Dasselbe Prüfprinzip steckt im PageSpeed-Test von cyberscale, der Gesamtnote, LCP, CLS und INP für Mobilgeräte zusammen mit den echten Nutzerdaten von Google zeigt. Das Werkzeug ist von mir, gratis und ohne Anmeldung.
3. Chrome DevTools, Bereich „Performance“. Die Entwicklerwerkzeuge öffnen, Bereich „Performance“ wählen, oder über das Befehlsmenü (Strg+Umschalt+P) „Show Performance panel“. Das Panel zeigt sofort LCP und CLS deines eigenen Aufrufs, und sobald du klickst, auch INP. Unter „Interactions“ und „Layout shifts“ stehen die betroffenen Elemente. Damit es eher nach Handy aussieht, CPU und Netz drosseln. Über „Field data“, „Set up“ holt das Panel zum Vergleich die CrUX-Werte dazu.

PageSpeed Insights und DevTools zeigen auch, welches Element das LCP-Element ist. Das ist die wichtigste Auskunft des ganzen Tests, denn an diesem einen Element hängt der LCP.

Was Google über die Rankingwirkung sagt#

In der Dokumentation zur Seitenerfahrung schreibt Google: „Core Web Vitals are used by our ranking systems.“ Gute Werte im Search-Console-Bericht oder in fremden Werkzeugen garantieren aber keine vorderen Plätze, und eine perfekte Punktzahl nur wegen SEO anzustreben, sei womöglich nicht die beste Verwendung der Zeit. Andere Aspekte der Seitenerfahrung helfen laut derselben Seite nicht direkt beim Ranking.

Entscheidend ist der Satz zur Gewichtung: Google zeigt immer den relevantesten Inhalt, auch wenn dessen Seitenerfahrung schwach ist. Bei Suchanfragen mit vielen guten Antworten kann eine gute Seitenerfahrung den Ausschlag geben. Für eine kleine Firmenwebsite folgt daraus: Passt der Inhalt nicht zur Suchanfrage, retten ihn auch grüne Werte nicht. Passt er, sind gute Werte ein Vorteil unter ähnlich guten Antworten.

LCP: wenn der Hauptinhalt zu spät kommt#

Als LCP-Element kommen laut web.dev Bilder, Video-Vorschaubilder, Hintergrundbilder aus CSS und Textblöcke in Frage, auf Firmenwebsites ist es oft das große Bild oben. web.dev teilt den LCP in vier Teile: Antwortzeit des Servers (TTFB), Verzögerung bis das Bild angefordert wird, Ladedauer des Bildes, Verzögerung bis zur Darstellung. Die zwei Verzögerungen sollen nahe null liegen.

Die häufigsten Ursachen und was dagegen hilft:

• Das Heldenbild ist lazy geladen. Mit loading="lazy" lädt der Browser das Bild erst, wenn das Layout steht. web.dev schreibt dazu ausdrücklich: das LCP-Bild nie lazy laden.
• Das Bild bekommt keine Priorität. Bilder lädt der Browser zunächst nicht mit höchster Priorität. Das Attribut fetchpriority="high" am LCP-Bild ändert das.
• Das Bild ist ein CSS-Hintergrund oder wird per JavaScript eingesetzt, etwa von einem Slider. Dann findet der Browser es erst spät. Ein normales <img> im HTML ist besser, sonst ein <link rel="preload">.
• Das Bild ist zu groß. Ein kleineres Bild in AVIF oder WebP verkürzt die Ladedauer. Hilft aber nur, wenn das Bild nicht ohnehin auf etwas anderes wartet.
• Der Server antwortet langsam. web.dev nennt als grobe Richtung eine TTFB bis 0,8 s. Ist sie hoch, sind 2,5 s für den LCP schwer oder gar nicht erreichbar. Das Hosting ist laut web.dev das Erste, was man prüfen sollte, Shared Hosting sei in der Regel langsamer. Seiten-Caching nimmt dem Server Arbeit ab, dazu unten bei WordPress mehr.

So sieht das Heldenbild aus, wenn es richtig ausgezeichnet ist:

<img src="/bilder/werkstatt-1200.avif"
     width="1200" height="675"
     fetchpriority="high"
     alt="Werkstatt der Tischlerei, Blick auf die Hobelbank">

Kein loading="lazy", dafür Breite und Höhe, die zugleich den CLS schützen. Bilder weiter unten dürfen lazy laden.

INP: wenn die Seite auf Klicks träge reagiert#

Der Browser erledigt fast alles auf einem einzigen Hauptstrang, eine Aufgabe nach der anderen. Jede Aufgabe über 50 ms gilt als lange Aufgabe, und solange sie läuft, wartet ein Klick. Daraus ergeben sich die üblichen Verdächtigen:

• Drittanbieter-Skripte. Chat-Fenster, Werbe- und Analyse-Tags, eingebettete Karten und Videos. web.dev schreibt, wer seinen eigenen Code optimiert hat und trotzdem langsam ist, findet die Ursache wahrscheinlich bei Drittanbieter-Skripten.
• Der Cookie-Banner. Laut web.dev ein häufiger Grund für hohe INP-Werte, weil beim Klick auf „Akzeptieren“ viele Drittanbieter-Skripte auf einmal starten.
• Page-Builder und schwere Themes. Viel JavaScript für Animationen und ein sehr großes DOM. Wie viel Arbeit das Darstellen macht, wächst laut web.dev mit der Größe des DOM.

Einen Schalter für INP gibt es nicht. In DevTools unter „Interactions“ die langsame Interaktion suchen, nachsehen, welches Skript in der Zeit lief, und es entfernen, verzögern oder ersetzen. Ein Analyse-Skript, das niemand mehr auswertet, ist der einfachste Gewinn.

CLS: wenn Inhalte verrutschen#

web.dev nennt vier häufige Ursachen: Bilder ohne Maße, Werbung, Einbettungen und iframes ohne Maße, nachträglich eingefügte Inhalte und Webschriften. Verschiebungen innerhalb von 500 ms nach einem Klick oder Tastendruck zählen nicht, die sind erwartet.

• Bilder ohne width und height. Mit beiden Attributen berechnet der Browser das Seitenverhältnis vor dem Laden und hält den Platz frei. Alternativ hilft CSS aspect-ratio.
• Banner, die oben hereinrutschen. Cookie-Hinweise sind laut web.dev eine sehr häufige Quelle für Layoutverschiebungen. Platz vorab reservieren oder den Hinweis über den Inhalt legen statt ihn hineinzuschieben.
• Webschriften. Wird die Ersatzschrift nach dem Laden gegen die Webschrift getauscht, verschiebt sich der Text. font-display: optional verwendet die Webschrift nur, wenn sie beim ersten Layout schon da ist. Wichtige Schriften früh per preload laden.

@font-face {
  font-family: "Hausschrift";
  src: url("/schriften/hausschrift.woff2") format("woff2");
  font-display: optional;
}

Wie die Schriften auf den eigenen Server kommen, steht in Google Fonts lokal einbinden. Der Umzug spart zugleich die Verbindung zu einem fremden Server.

WordPress: was der Kern schon macht#

WordPress nimmt einen Teil der Arbeit selbst ab, sofern es aktuell ist:

• Lazy Loading seit 5.5. WordPress setzt loading="lazy" an Bilder mit Breite und Höhe. Seit 6.3 lässt es das Attribut bei Bildern im sichtbaren Bereich zuverlässiger weg.
• fetchpriority="high" seit 6.3. WordPress setzt es automatisch an das Bild, das es für das LCP-Bild hält.
• WebP seit 5.8, AVIF seit 6.5, beide nur, wenn die Bildbibliothek des Servers (Imagick oder GD) das Format kann. Ob sie es kann, steht unter Werkzeuge → Website-Zustand → Info → Medienverarbeitung.

Das gilt für Bilder, die WordPress selbst ausgibt. Baut ein Page-Builder das Heldenbild als Hintergrund oder Slider, greift nichts davon, und der LCP bleibt Handarbeit.

Für die Serverseite schreibt das WordPress-Handbuch, Caching sei der schnellste Weg zu besserer Leistung. Ein Caching-Plugin legt Beiträge und Seiten als statische Dateien ab und spart dem Server damit Rechenarbeit bei jedem Aufruf. Die übrigen Stellschrauben stehen in eigenen Beiträgen: welche Erweiterungen wirklich nötig sind in WordPress-Plugins: welche du brauchst, und warum eine alte PHP-Version nicht nur ein Sicherheitsthema ist in WordPress PHP-Version prüfen und umstellen.

Die Reihenfolge der Arbeit#

1. Messen. Search Console und PageSpeed Insights, mobil zuerst. Google empfiehlt, zuerst die Adressen mit „Langsam“ anzugehen.
2. Den größten Hebel nehmen. Welcher Wert ist rot, welches Element ist schuld? Oft steckt eine Vorlage dahinter, etwa die Startseite oder alle Leistungsseiten, und eine Änderung an der Vorlage behebt die ganze Gruppe.
3. Im Labor nachmessen. PageSpeed oder DevTools zeigen sofort, ob die Änderung wirkt.
4. In der Search Console „Tracking starten“. Google beobachtet dann 28 Tage lang, ob das Problem noch irgendwo auftritt. Taucht es bei keiner Adresse mehr auf, gilt es als behoben.

Die Felddaten sind ein rollendes Fenster über 28 Tage. Eine Verbesserung von heute schlägt deshalb erst nach und nach durch. Wer nach drei Tagen wieder umbaut, misst den eigenen Umbau.

Was nicht hilft#

Die 100 im Lighthouse jagen. Die Note ist ein gewichteter Mittelwert, zu 30 % aus der Total Blocking Time, zu je 25 % aus LCP und CLS. Die Note schwankt von Lauf zu Lauf, und ab 90 ist sie grün. Google selbst rät davon ab, für SEO eine perfekte Punktzahl anzustreben.

Drei Speed-Plugins übereinander. Zwei Plugins, die beide Seiten zwischenspeichern oder beide Skripte zusammenfassen, erledigen dieselbe Arbeit doppelt und machen die Fehlersuche schwer, weil keiner mehr weiß, welches gerade wirkt. Jedes zusätzliche Plugin ist auch Code, der läuft.

Alle Bilder lazy laden, auch das oberste. Spart Bytes und verschlechtert genau den Wert, um den es geht.

Ein neues Design als Lösung. Ein Relaunch mit einem schwereren Theme kann dieselben Probleme in neuer Farbe bringen. Was vor einem Umbau zu prüfen ist, steht in Website überarbeiten lassen.

Prüfliste#

• [ ] Search Console: Bericht „Core Web Vitals“ für Handy und Computer angesehen
• [ ] Felddaten vorhanden oder „Keine Daten verfügbar“ notiert
• [ ] LCP-Element der wichtigsten Vorlage bestimmt (DevTools oder PageSpeed)
• [ ] LCP-Bild ohne loading="lazy", mit fetchpriority="high"
• [ ] Heldenbild in passender Größe, als AVIF oder WebP
• [ ] Antwortzeit des Servers geprüft, Seiten-Caching aktiv, nur ein Caching-Plugin
• [ ] Alle Bilder und iframes mit width und height
• [ ] Cookie-Banner überlagert den Inhalt statt ihn zu verschieben
• [ ] Schriften lokal, mit font-display
• [ ] Drittanbieter-Skripte gelistet, ungenutzte entfernt
• [ ] Nach der Änderung im Labor nachgemessen, dann „Tracking starten“

Häufige Fragen#

Wenn du es nicht selbst machen willst#

cyberscale bin ich, Stefan Haun aus Tirol. Der SEO-Check für 390 € prüft Ladezeit und Core Web Vitals zusammen mit Indexierung und Technik und sagt, welcher Hebel bei deiner Website der größte ist. Für WordPress-Seiten, bei denen Updates, Caching und Plugin-Last laufend im Blick bleiben sollen, gibt es die WordPress-Wartung für 49 € im Monat.

Stand 26.10.2026. Alle Quellen an diesem Tag abgerufen. Eine eigene Messung der cyberscale-Startseite über die PageSpeed-Insights-API war an diesem Tag nicht möglich (Tageskontingent ohne Schlüssel erschöpft) und fehlt deshalb.