Core Web Vitals erklärt: LCP, INP & CLS im Klartext
Was Core Web Vitals sind, was LCP, INP und CLS messen und wie du die drei Werte konkret verbesserst. Klartext-Leitfaden aus 20 Jahren Praxis.
Inhaltsverzeichnis anzeigen
Du öffnest PageSpeed Insights, gibst deine Adresse ein, und plötzlich starren dich drei rote Kästchen an: LCP, INP, CLS. Klingt nach Geheimsprache, fühlt sich an wie ein schlechtes Zeugnis. Genau hier setzen die Core Web Vitals an: drei Messwerte, mit denen Google bewertet, wie schnell, wie reaktiv und wie stabil sich deine Website für echte Besucher anfühlt. Sie sind kein Tech-Nerd-Thema, sondern eine Übersetzung von „fühlt sich gut an" in Zahlen, die Google in die Suche einrechnet.
Ich baue seit über zwanzig Jahren Websites für KMU in Münster und NRW, und ich sehe diese drei Buchstaben-Kürzel in jedem zweiten Erstgespräch über einen Relaunch. Meist verbunden mit der Frage: „Ist das schlimm?" Dieser Artikel beantwortet sie. Ohne Marketing-Nebel, dafür mit den Schwellenwerten, den Messwegen und den Hebeln, die wirklich etwas bewegen.
- Core Web Vitals sind drei Messwerte für die Nutzererfahrung: LCP (Ladezeit), INP (Reaktionsfähigkeit) und CLS (visuelle Stabilität).
- Die Zielwerte: LCP unter 2,5 Sekunden, INP unter 200 Millisekunden, CLS unter 0,1. Alles darüber ist verbesserungswürdig oder schlecht.
- INP hat im März 2024 FID abgelöst. Viele ältere Anleitungen sind dadurch überholt: Wer noch „First Input Delay" optimiert, misst die falsche Größe.
- Google bewertet Felddaten echter Besucher (75. Perzentil), nicht den einen Laborwert auf deinem Rechner. Deshalb können PageSpeed Insights und Search Console abweichen.
- Core Web Vitals sind ein Ranking-Faktor, aber ein nachrangiger. Sie entscheiden bei sonst gleichwertigem Content, ersetzen aber keine guten Inhalte.
Was Core Web Vitals sind und warum Google sie misst
Core Web Vitals sind ein Satz von drei Kennzahlen, mit denen Google die tatsächliche Nutzererfahrung einer Seite quantifiziert. Eingeführt wurden sie 2020, seit dem sogenannten Page-Experience-Update im Sommer 2021 fließen sie als Signal in das Ranking ein. Der Gedanke dahinter ist simpel: Eine Seite kann inhaltlich top sein und trotzdem nerven, wenn sie ewig lädt, auf Klicks träge reagiert oder beim Scrollen herumspringt.
Entscheidend ist, dass Google nicht misst, wie schnell die Seite auf einem Hochleistungs-Laptop mit Glasfaser lädt, sondern wie sie sich für echte Menschen anfühlt: auf einem drei Jahre alten Smartphone im Zugnetz. Diese realen Messwerte sammelt Google anonymisiert über den Chrome User Experience Report, kurz CrUX. Genau deshalb ist „Bei mir lädt das doch sofort" kein Argument. Es zählt das 75. Perzentil aller Seitenaufrufe, also der Wert, den drei von vier Besuchern mindestens erleben.
Felddaten gegen Labordaten
Diese Unterscheidung ist der häufigste Stolperstein. Labordaten entstehen, wenn ein Tool wie Lighthouse deine Seite einmal unter standardisierten Bedingungen lädt. Sie sind gut zum Debuggen, weil reproduzierbar. Felddaten stammen von echten Besuchern über Wochen. Nur die Felddaten zählen fürs Ranking. Wenn dein Lighthouse-Wert grün ist, die Search Console aber rot meldet, hast du ein Feld-Problem, das im Labor nicht auftaucht, etwa eine langsame Datenbank unter Last.
Die drei Metriken im Klartext
Jede der drei Kennzahlen steht für eine andere Phase des Besuchs: Ankommen, Bedienen, Vertrauen. Hier ist, was jede einzelne wirklich misst, ohne Fachjargon.
LCP — Largest Contentful Paint: das Ankommen
LCP misst, wie lange es dauert, bis das größte sichtbare Element im ersten Bildschirmausschnitt geladen ist. Meistens ist das ein Hero-Bild oder ein großer Textblock. LCP beantwortet die Frage: „Wann sieht der Besucher, dass hier etwas Substanzielles ist?" Ein guter Wert liegt unter 2,5 Sekunden. Bremsen sind fast immer dieselben: eine langsame Serverantwort, ein riesiges unkomprimiertes Bild oder render-blockierendes CSS und JavaScript, das vor dem Bild geladen wird.
INP — Interaction to Next Paint: das Bedienen
INP misst die Reaktionsfähigkeit. Wenn du auf einen Button tippst, ein Menü öffnest oder in ein Formularfeld klickst, wie lange dauert es, bis die Seite sichtbar reagiert? Hier liegt die wichtigste Neuerung: INP hat im März 2024 die alte Metrik FID, First Input Delay, abgelöst. FID maß nur die Verzögerung der allerersten Interaktion und war damit fast immer optimistisch grün. INP betrachtet alle Interaktionen über den gesamten Besuch und nimmt den schlechtesten relevanten Wert. Das ist ehrlicher und für viele Seiten unbequemer. Ziel ist unter 200 Millisekunden. Der typische Übeltäter ist zu viel JavaScript, das den Hauptthread blockiert, oft eingeschleppt durch schwere Plugins oder Tracking-Tools.
CLS — Cumulative Layout Shift: das Vertrauen
CLS misst, wie sehr das Layout während des Ladens herumspringt. Du kennst das: Du willst auf einen Link tippen, im selben Moment lädt eine Anzeige nach, alles rutscht nach unten, und du klickst auf etwas anderes. CLS ist kein Zeitwert, sondern eine dimensionslose Zahl, die unter 0,1 liegen sollte. Die Hauptursachen sind Bilder und Einbettungen ohne feste Größenangabe, nachladende Werbung und Schriften, die einen sichtbaren Umbruch verursachen.
Die Schwellenwerte auf einen Blick
Google teilt jede Metrik in drei Zonen: gut, verbesserungswürdig, schlecht. Erst wenn alle drei im grünen Bereich liegen, gilt eine Seite als „besteht". Diese Tabelle ist dein Maßstab beim nächsten PageSpeed-Test.
| Metrik | Misst | Gut | Verbesserungswürdig | Schlecht |
|---|---|---|---|---|
| LCP | Ladezeit | ≤ 2,5 s | ≤ 4,0 s | > 4,0 s |
| INP | Reaktionsfähigkeit | ≤ 200 ms | ≤ 500 ms | > 500 ms |
| CLS | Visuelle Stabilität | ≤ 0,1 | ≤ 0,25 | > 0,25 |
Schau dir Mobil- und Desktop-Werte immer getrennt an. Google bewertet beide separat, und in den allermeisten Fällen ist Mobil der Engpass. Wenn deine Desktop-Werte grün, die mobilen aber rot sind, optimierst du am besten zuerst für das Smartphone, denn dort entscheidet sich auch der Großteil deiner Besuche.
Womit du Core Web Vitals misst
Es gibt mehr Tools als nötig. Diese drei reichen für fast jeden Fall, und sie greifen ineinander.
PageSpeed Insights ist der schnellste Einstieg. Adresse eingeben, fertig. Das Tool zeigt oben die Felddaten echter Nutzer (sofern Google genug Daten gesammelt hat) und darunter die Labordaten aus Lighthouse mit konkreten Verbesserungsvorschlägen. Der grüne Wert oben zählt fürs Ranking, die Diagnose unten ist deine To-do-Liste.
Der Core-Web-Vitals-Bericht in der Google Search Console ist die strategische Sicht. Statt einer Einzelseite zeigt er, wie viele deiner URLs in welcher Zone liegen, gruppiert nach Problem. Wenn fünfzig Produktseiten denselben CLS-Fehler haben, siehst du das hier, nicht im Einzeltest. Das ist der Bericht, in den ich bei einem Audit zuerst schaue.
Lighthouse, direkt in den Chrome-DevTools unter dem Reiter „Lighthouse", ist das Debugging-Werkzeug. Reproduzierbar, lokal, mit Wasserfalldiagramm. Damit findest du heraus, welches konkrete Skript oder Bild den LCP nach hinten zieht. Wichtig bleibt: Lighthouse misst Labor, nicht Feld. Es ist die Werkstatt, nicht das amtliche Gutachten.
Wie du die drei Werte konkret verbesserst
Optimierung folgt fast immer derselben Reihenfolge, weil der größte Hebel meistens beim LCP liegt. Diese Schritte deckst du in dieser Abfolge ab.
- Serverantwort und Hosting prüfen. Eine träge Serverantwort verschiebt jeden anderen Wert nach hinten. Günstiges Shared-Hosting ist hier oft der erste Bremsklotz. Ein Blick auf die laufenden Kosten und Leistungen deines Hostings lohnt sich, bevor du an Details schraubst.
- Das LCP-Bild gezielt beschleunigen. Das größte Bild über dem Seitenfalz bekommt ein modernes Format (AVIF oder WebP), wird per Preload-Hinweis früh angefordert und früh geladen statt verzögert. Das ist der wirkungsvollste Einzelschritt für die Ladezeit.
- Render-blockierende Ressourcen entschärfen. CSS und JavaScript, die vor dem ersten Inhalt geladen werden müssen, halten die Seite auf. Nicht kritisches JavaScript wird verzögert oder asynchron geladen.
- JavaScript-Last für INP reduzieren. Lange Skript-Aufgaben blockieren den Hauptthread und damit jede Reaktion. Schwere Plugins und Drittanbieter-Skripte (Tracking, Chat, Karten) kritisch durchgehen und ausmisten.
- Layout-Sprünge gegen CLS eliminieren. Jedem Bild und Video feste Breite und Höhe geben, Platz für nachladende Elemente reservieren, Schriften vorladen. Damit steht das Layout, bevor der Inhalt eintrudelt.
- Erneut messen, im Feld. Nach dem Deploy in der Search Console beobachten, nicht nur einmal in PageSpeed Insights. Felddaten brauchen einige Tage, bis sie die Änderung abbilden.
Mein Workflow, wenn der LCP der Engpass ist
In meiner Praxis ist der LCP-Wert der häufigste rote Punkt, und das Bild über dem Falz ist fast immer die Ursache. Mein Standardvorgehen sieht so aus: Das zentrale Hero-Bild bekommt eine AVIF-Variante, einen Preload-Eintrag im Seitenkopf und wird mit hoher Priorität sofort geladen, nicht lazy. Was viele übersehen: Ich verzichte beim LCP-Element bewusst auf eine Einblend-Animation, die von durchsichtig auf sichtbar fadet. Denn Google misst den LCP erst, wenn das Element seine endgültige Sichtbarkeit erreicht hat. Eine schicke Fade-in-Animation auf genau diesem Bild schiebt den gemessenen Wert um die Animationsdauer nach hinten, obwohl das Bild technisch längst da ist. Sekundäre Elemente dürfen gern reinfaden, das Hauptbild nicht.
Bei den meisten KMU-Websites bringt ein einziger sauberer Eingriff am LCP-Bild mehr als zehn Mikro-Optimierungen verstreut über die ganze Seite. Erst den größten Brocken bewegen, dann verfeinern.
Was Core Web Vitals fürs Ranking wirklich bedeuten
Hier ist die ehrliche Einordnung, die in vielen Anleitungen fehlt. Core Web Vitals sind ein bestätigter Ranking-Faktor, aber ein nachrangiger. Google hat mehrfach klargestellt, dass relevanter, hilfreicher Content schwerer wiegt. Die Vitals wirken eher als Tiebreaker: Wenn zwei Seiten inhaltlich gleichauf liegen, gewinnt die mit der besseren Nutzererfahrung. Wer hofft, mit grünen Werten dünnen Content nach oben zu drücken, optimiert am falschen Ende.
Der eigentliche Gewinn liegt ohnehin abseits des Rankings. Eine schnelle, stabile Seite hält Besucher, senkt die Absprungrate und führt mehr Anfragen zum Ziel. Die Ladezeit ist ein direkter Conversion-Hebel, und das gilt unabhängig davon, was Google damit macht. Wenn du tiefer in den reinen Geschwindigkeits-Teil einsteigen willst, lohnt der ergänzende Blick darauf, wie du die Ladezeit deiner Website systematisch optimierst. Und weil CLS und mobile Performance eng mit dem Aufbau zusammenhängen, ist gutes responsives Webdesign die halbe Miete.
Der pragmatischste Zeitpunkt, die Vitals grundlegend in den Griff zu bekommen, ist ein Website-Relaunch. Auf einer bestehenden, gewachsenen Seite ist Performance oft Flickwerk. Wer neu baut, kann Bildstrategie, Skript-Last und Layout-Stabilität von Anfang an richtig anlegen, statt später nachzubessern. Welche Punkte dabei sonst noch auf die Liste gehören, fasst die Website-Relaunch-Checkliste zusammen.
Häufige Fragen zu Core Web Vitals
Was ist der Unterschied zwischen INP und FID?
FID, First Input Delay, maß nur die Verzögerung der ersten Interaktion auf einer Seite und ignorierte alles danach. INP, Interaction to Next Paint, betrachtet alle Interaktionen über den gesamten Besuch und nimmt den schlechtesten relevanten Wert. INP hat FID im März 2024 offiziell als Core Web Vital abgelöst. Es ist die strengere und realistischere Metrik, weshalb manche Seiten beim Wechsel von grün auf gelb gerutscht sind.
Wie oft aktualisieren sich die Core-Web-Vitals-Werte?
Die Felddaten, die Google fürs Ranking nutzt, basieren auf einem rollierenden 28-Tage-Fenster. Eine Änderung an deiner Seite schlägt sich also nicht sofort nieder, sondern wird über mehrere Tage hinweg sichtbar, je mehr neue Besucherdaten einfließen. Labordaten in Lighthouse dagegen ändern sich sofort bei jedem Test.
Brauche ich für gute Core Web Vitals ein teures Hosting?
Nicht zwingend teuer, aber solide. Eine schnelle Serverantwort ist die Grundlage, auf der alles andere aufbaut, und billiges, überbuchtes Shared-Hosting ist häufig der erste Engpass. Du brauchst keinen dedizierten Server, aber ein performantes, gut konfiguriertes Hosting mit aktueller Technik macht einen messbaren Unterschied, besonders beim LCP.
Sind Core Web Vitals auf jeder Unterseite gleich wichtig?
Google bewertet sie pro URL, gruppiert aber ähnliche Seiten zu Gruppen mit vergleichbarem Verhalten. Praktisch heißt das: Deine wichtigen Landing- und Geldseiten sollten zuerst grün sein. Ein selten besuchtes Impressum mit schlechtem Wert ist weniger kritisch als die Startseite oder eine zentrale Leistungsseite, über die deine Anfragen laufen.
Kann ich Core Web Vitals in WordPress mit einem Plugin lösen?
Teilweise. In WordPress helfen Caching- und Optimierungs-Plugins spürbar bei LCP und render-blockierenden Ressourcen. Bei INP und CLS stoßen sie aber an Grenzen, weil die Ursachen oft im Theme, in der Skript-Last oder im Seitenaufbau liegen. Ein Plugin ist ein guter erster Hebel, ersetzt aber keine saubere technische Grundlage.
Was bedeutet das 75. Perzentil bei Core Web Vitals?
Google sortiert alle Seitenaufrufe nach ihrem Messwert und nimmt den Wert, den 75 Prozent der Besucher erreichen oder unterbieten. Damit fallen einzelne Ausreißer mit sehr schneller oder sehr langsamer Verbindung weniger ins Gewicht, und die Bewertung spiegelt das, was die breite Mehrheit deiner Besucher tatsächlich erlebt.
Wenn du die drei Buchstaben-Kürzel einmal verstanden hast, verlieren sie ihren Schrecken. LCP, INP und CLS sind keine Schikane, sondern eine ziemlich präzise Übersetzung dessen, was eine Website angenehm macht: Sie ist schnell da, sie reagiert sofort, und sie steht still, während du sie bedienst. Wer das von Anfang an mitdenkt, statt es nachträglich zu reparieren, baut Seiten, die nicht nur bei Google bestehen, sondern bei den Menschen, die sie benutzen. Und das war ohnehin immer der eigentliche Punkt.
