Die Core Web Vitals sind drei Messwerte, mit denen Google bewertet, wie sich eine Seite für echte Besucher anfühlt: LCP misst, wann der Hauptinhalt sichtbar ist, INP, wie schnell die Seite auf Eingaben reagiert, und CLS, wie stark das Layout beim Laden springt. Gut sind ein LCP bis 2,5 Sekunden, ein INP bis 200 Millisekunden und ein CLS bis 0,1, jeweils für mindestens 75 Prozent der Seitenaufrufe. Die häufigsten Ursachen für schlechte Werte sind zu große Bilder im Seitenkopf, blockierendes CSS und JavaScript, Webfonts und Skripte von Drittanbietern. Wer verbessern will, misst zuerst die Felddaten und arbeitet dann in der Reihenfolge LCP, CLS, INP. So gehen wir in Jena bei Websites und Shops vor.
Was LCP, INP und CLS messen
| Wert | Was er misst | Gut | Schlecht |
|---|---|---|---|
| LCP, Largest Contentful Paint | Zeit, bis das größte sichtbare Element geladen ist, meist das Bild oder die Überschrift im Seitenkopf | bis 2,5 s | über 4 s |
| INP, Interaction to Next Paint | Wie lange es nach einem Klick, Tipp oder Tastendruck dauert, bis die Seite sichtbar reagiert, über den ganzen Besuch betrachtet | bis 200 ms | über 500 ms |
| CLS, Cumulative Layout Shift | Wie stark sich Inhalte unerwartet verschieben, etwa wenn ein Bild oder Banner nachlädt | bis 0,1 | über 0,25 |
INP hat im März 2024 den älteren Wert FID abgelöst. Der Unterschied ist wichtig: FID maß nur die Verzögerung der ersten Eingabe, INP betrachtet alle Interaktionen eines Besuchs. Viele Websites, die mit FID gut dastanden, haben mit INP plötzlich Probleme, vor allem solche mit viel JavaScript.
Richtig messen: Felddaten vor Labordaten
Es gibt zwei Arten von Messwerten, und sie werden ständig verwechselt. Felddaten stammen von echten Besuchern mit Chrome, gesammelt über 28 Tage. Sie stehen im Bericht „Core Web Vitals“ der Search Console und oben in PageSpeed Insights. Nur sie zählen für Google. Labordaten entstehen in einer simulierten Messung, etwa mit Lighthouse. Sie sind reproduzierbar und gut zur Fehlersuche, aber sie sind eine Momentaufnahme mit einem angenommenen Gerät und einer angenommenen Verbindung.
- Beginne in der Search Console: Welche URL-Gruppen sind „schlecht“ oder „verbesserungswürdig“, mobil oder am Desktop? Meist sind es wenige Seitentypen, etwa alle Produktseiten oder alle Blogartikel.
- Nimm je Gruppe eine Beispielseite und untersuche sie mit PageSpeed Insights und den Entwicklerwerkzeugen des Browsers. Dort siehst du, welches Element das LCP-Element ist und welche Skripte lange laufen.
- Miss mobil. Die meisten Probleme zeigen sich auf einem mittelklassigen Smartphone, nicht auf dem Entwicklerrechner.
- Hat eine Seite zu wenig Besucher für Felddaten, arbeitest du mit Labordaten, und prüfst nach dem Go-live, ob die Felddaten folgen.
Ein Beispiel für die Grenze von Labordaten ist unsere eigene Website: Lokal gemessen erreicht sie in Lighthouse 96 bis 98 Punkte für Performance. Das zeigt, was das Theme leistet. Was Besucher erleben, zeigen erst die Felddaten nach dem Go-live, die wir im Anwendungsfall zum Relaunch nachtragen.
LCP verbessern: Der Hauptinhalt muss schneller da sein
Der LCP setzt sich aus vier Teilen zusammen: der Antwortzeit des Servers, der Zeit, bis der Browser das LCP-Element entdeckt, der Ladezeit dieses Elements und der Zeit bis zur Darstellung. Jeder Teil hat eigene Stellschrauben.
- Server: Eine aktuelle PHP-Version, ein Seiten-Cache auf dem Server und eine Datenbank ohne Altlasten. Bei WordPress sind es oft Plugins, die bei jedem Aufruf Dutzende Datenbankabfragen auslösen.
- Das Bild im Seitenkopf: in passender Größe, als WebP oder AVIF, mit srcset für verschiedene Bildschirmbreiten. Dieses eine Bild darf nicht per Lazy Loading verzögert werden, das ist einer der häufigsten Fehler überhaupt. Mit fetchpriority=“high“ lädt der Browser es zuerst.
- Blockierendes CSS und JavaScript: Das CSS, das für den sichtbaren Bereich nötig ist, gehört in den Seitenkopf. Skripte, die für die erste Ansicht nicht gebraucht werden, laden mit defer oder erst bei Bedarf.
- Schriften: selbst gehostet statt von einem fremden Server, nur die Schnitte, die wirklich genutzt werden, und die wichtigste Schrift per preload.
- Slider im Seitenkopf: Sie laden mehrere große Bilder und viel JavaScript, bevor der Besucher überhaupt etwas sieht. Ein einzelnes Bild mit klarer Aussage ist fast immer schneller und meist auch besser.
CLS und INP: Nichts darf springen, alles muss reagieren
CLS: Platz reservieren
- Jedes Bild und jedes Video bekommt Breite und Höhe im HTML oder ein festes Seitenverhältnis im CSS, damit der Browser den Platz vorher kennt.
- Banner, Hinweisleisten und eingebettete Inhalte wie Karten oder Buchungswidgets bekommen einen reservierten Bereich, statt sich nachträglich über den Inhalt zu schieben.
- Webfonts mit passender Ersatzschrift: Wenn die eigentliche Schrift nachlädt und breiter läuft, verschiebt sich der ganze Text. Angepasste Ersatzschriften verhindern das.
- Animationen über transform und opacity statt über Höhe, Breite oder Abstände.
INP: JavaScript entlasten
Schlechte INP-Werte haben fast immer dieselbe Ursache: Der Browser ist mit JavaScript beschäftigt, wenn der Besucher klickt. Die Hauptverdächtigen sind Skripte von Drittanbietern, Chat-Widgets, Tag-Manager mit vielen Tags, Werbepixel, Consent-Werkzeuge, dazu Page-Builder mit eigenem Skript-Gerüst, alte jQuery-Erweiterungen und Filter in Shops, die bei jedem Klick die ganze Liste neu berechnen.
- Jedes externe Skript auf den Prüfstand: Wird es gebraucht, und muss es auf jeder Seite laden?
- Lange Aufgaben aufteilen, damit der Browser zwischendurch auf Eingaben reagieren kann.
- Erst sichtbar reagieren, dann rechnen: Ein Klick auf „In den Warenkorb“ zeigt sofort eine Rückmeldung, die Aktualisierung im Hintergrund folgt.
- Weniger Framework: Viele Websites brauchen für Menü, Akkordeon und Formular kein großes JavaScript-Gerüst.
Hier liegt auch der Grund, warum wir ohne Page-Builder arbeiten und im Frontend auf jQuery verzichten. Wie das konkret aussieht, beschreibt der Artikel WordPress ohne Page-Builder.
Die richtige Reihenfolge: und was ein Cache-Plugin nicht löst
Unsere Reihenfolge bei der Optimierung einer bestehenden Website ist immer dieselbe: zuerst messen und die betroffenen Seitentypen finden, dann LCP, weil er am häufigsten schlecht ist und sich meist am Seitenkopf-Bild und am Server entscheidet. Danach CLS, weil sich die Ursachen gut finden lassen. INP zuletzt, weil er am tiefsten in Theme und Skripte greift.
Ein Cache- oder Optimierungs-Plugin kann die Antwortzeit des Servers verbessern und Dateien zusammenfassen. Es ändert nichts daran, dass ein Slider fünf Bilder lädt, ein Chat-Widget den Browser blockiert oder ein Bild ohne Maße den Text verschiebt. Wer ein zweites und drittes Optimierungs-Plugin installiert, hat meist ein Problem im Theme, das kein Plugin lösen kann. Nach einer Verbesserung dauert es bis zu 28 Tage, bis die Felddaten den neuen Stand vollständig zeigen. Damit die Werte danach nicht wieder verfallen, gehört die regelmäßige Kontrolle in die Website-Wartung.
Fazit
LCP, INP und CLS sind keine abstrakten Kennzahlen, sondern beschreiben drei sehr konkrete Erlebnisse: Warten, Hängen, Springen. Die Ursachen sind meist bekannt, das Bild im Seitenkopf, blockierende Dateien, fehlende Maße, zu viel fremdes JavaScript. Miss mit Felddaten, arbeite dich von LCP über CLS zu INP vor und behandle Ursachen statt Symptome. Wenn das Theme selbst das Problem ist, hilft kein weiteres Plugin, sondern saubere Webentwicklung. Und weil Ladezeit auch für die Sichtbarkeit zählt, gehört sie bei uns zum technischen SEO.
Häufige Fragen
Sind die Core Web Vitals ein Rankingfaktor?
Ja, als Teil der Seitenerfahrung, die Google bewertet. Google sagt aber auch klar, dass relevante Inhalte wichtiger sind: Eine schnelle Seite ohne passende Antwort rankt nicht. Bei vergleichbaren Inhalten können gute Werte den Unterschied machen, und Besucher springen auf langsamen Seiten schlicht ab.
Warum ist mein PageSpeed-Wert schlecht, die Search Console aber grün?
Der Punktwert in PageSpeed Insights stammt aus einer simulierten Labormessung mit langsamer Verbindung. Die Search Console zeigt Felddaten echter Besucher. Für Google zählen die Felddaten; die Labormessung ist ein Werkzeug zur Fehlersuche.
Hilft ein Cache-Plugin bei den Core Web Vitals?
Beim LCP oft ja, weil der Server schneller antwortet. Bei CLS und INP kaum, weil deren Ursachen im Theme, in Bildern und in Skripten liegen. Mehrere Optimierungs-Plugins gleichzeitig verursachen häufiger Fehler, als sie lösen.
Wie lange dauert es, bis Verbesserungen sichtbar sind?
Labormessungen zeigen die Wirkung sofort. Die Felddaten in der Search Console beruhen auf den letzten 28 Tagen und brauchen entsprechend lange, bis sie den neuen Stand vollständig abbilden.
Muss ich in Lighthouse 100 Punkte erreichen?
Nein. Ziel ist, dass alle drei Werte in den Felddaten im grünen Bereich liegen. Ob Lighthouse dann 92 oder 100 zeigt, ist für Besucher und Google zweitrangig.
Stand: September 2026, wir aktualisieren diesen Artikel, wenn sich Rechtslage oder Technik ändern.
