Core Web Vitals verstehen & verbessern

Die Core Web Vitals sind Googles Antwort auf eine alte Frage: Wie misst man, ob sich eine Website gut anfühlt? Drei Kennzahlen fassen die gefühlte Qualität in Zahlen – lädt die Seite zügig (LCP), reagiert sie flüssig (INP), bleibt das Layout stabil (CLS)? Gemessen wird nicht im Testlabor, sondern an echten Besuchen; die Werte fließen als Teil der „Page Experience“ ins Ranking ein.

Das Wichtigste in Kürze

• Drei Kennzahlen, drei Fragen: LCP misst das Ladegefühl (gut: ≤ 2,5 s), INP die Reaktionsfreude (gut: ≤ 200 ms), CLS die visuelle Stabilität (gut: ≤ 0,1).
• Gemessen wird an echten Besuchern: Grundlage sind anonymisierte Chrome-Daten (CrUX) der letzten 28 Tage – nicht dein Testlauf am Rechner.
• Das 75. Perzentil zählt: Eine Seite besteht, wenn mindestens drei von vier Besuchen den Zielwert erreichen – für Mobil und Desktop getrennt.
• Fürs Ranking ein moderates Signal: eher Zünglein an der Waage als Hebel. Der eigentliche Gewinn sind weniger Abbrüche und zufriedenere Besucher.
• Die größten Hebel: optimierte Bilder mit festen Maßen, so wenig JavaScript wie möglich, schnelle Auslieferung. Eine statische, semantische Seite bringt das meiste davon von Hause aus mit.

Wie Google misst: Feld, Perzentil, 28 Tage

Um die Funktionsweise zu verstehen, muss man eine Unterscheidung kennen, die in der Praxis für die meiste Verwirrung sorgt: Felddaten gegen Labordaten.

Felddaten stammen aus dem Chrome User Experience Report (CrUX): Chrome sammelt anonymisiert die Messwerte echter Besuche und aggregiert sie über ein rollierendes Fenster von 28 Tagen. Nur diese Werte zählen für die Bewertung – sie bilden ab, was Menschen mit langsamen Handys in schlechten Netzen wirklich erleben. Bewertet wird das 75. Perzentil: Der Wert, den drei Viertel aller Besuche erreichen oder unterbieten, muss im grünen Bereich liegen. Ein schneller Durchschnitt genügt nicht, wenn jeder vierte Besuch zäh ist. Mobil und Desktop werden getrennt bewertet.

Labordaten liefern Werkzeuge wie Lighthouse oder die Chrome-DevTools: ein simulierter Besuch unter kontrollierten Bedingungen, typischerweise ein gedrosseltes Mittelklasse-Smartphone. Das ist reproduzierbar und ideal, um Ursachen zu finden – aber es bleibt eine Simulation. Ich nutze beides: das Labor zum Debuggen, das Feld als Wahrheit.

Zwei praktische Folgen: Verbesserungen werden wegen des 28-Tage-Fensters erst mit Verzögerung sichtbar. Und kleine Websites mit wenig Traffic erreichen die CrUX-Mindestdatenmenge oft nicht – dann zeigen die Tools schlicht „keine Daten“, und der Labortest ist die beste verfügbare Näherung. Dazu unten mehr.

Die drei Kennzahlen im Detail

LCP – das Ladegefühl

Der Largest Contentful Paint ist der Zeitpunkt, zu dem das größte Inhaltselement im sichtbaren Bereich fertig gerendert ist – meist das Heldenbild oder die große Überschrift. Kandidaten sind Bilder, Video-Vorschaubilder, CSS-Hintergrundbilder und Textblöcke; gezählt wird nur, was tatsächlich im Viewport sichtbar ist. Während des Ladens kann das „größte Element“ mehrfach wechseln; die Messung endet mit der ersten Interaktion.

Warum ausgerechnet dieser Moment? Ältere Ereignisse wie load oder DOMContentLoaded sagen nichts darüber, was Besucher sehen. Der First Contentful Paint (FCP) feuert schon beim ersten Pixel – oft nur ein Ladeindikator. Der LCP trifft ziemlich genau das Gefühl „jetzt ist das Wesentliche da“.

Technisch zerfällt der LCP in vier Phasen, und jede ist ein eigener Hebel: die Server-Antwortzeit (TTFB), die Verzögerung, bis die Ressource überhaupt angefordert wird, deren Ladezeit und schließlich die Renderzeit im Browser.

INP – die Reaktionsfreude

Interaction to Next Paint beantwortet die Frage: Wenn ich klicke, tippe oder eine Taste drücke – wie lange dauert es, bis die Seite sichtbar reagiert? Gemessen werden alle Klicks, Taps und Tastatureingaben über den gesamten Besuch (Scrollen und Hover zählen nicht). Gemeldet wird am Ende die langsamste Interaktion; bei sehr vielen Interaktionen wird pro fünfzig eine als Ausreißer verworfen.

Jede Interaktion durchläuft drei Phasen: die Eingabeverzögerung (der Hauptthread ist noch mit anderem beschäftigt), die Verarbeitung der Event-Handler und die Darstellungsverzögerung bis zum nächsten gezeichneten Frame. In allen drei Phasen ist der übliche Bremsklotz derselbe: zu viel JavaScript am Stück.

INP hat im März 2024 den älteren First Input Delay (FID) abgelöst und ist deutlich strenger: FID betrachtete nur die erste Interaktion und davon nur die Eingabeverzögerung. Eine Randnotiz mit Praxisfolge: Im Labor lässt sich INP nicht messen, weil niemand interagiert – Lighthouse nutzt die Total Blocking Time (TBT) als Näherung dafür, wie stark Skripte den Hauptthread blockieren.

CLS – die Stabilität

Der Cumulative Layout Shift misst, wie stark Inhalte unerwartet springen – der Moment, in dem der Daumen auf „Abbrechen“ zielt und „Kaufen“ trifft, weil oben noch ein Banner hineingerutscht ist. CLS ist keine Zeitangabe, sondern ein Wert ohne Einheit: Vereinfacht wird für jeden Sprung gerechnet, wie viel Fläche des Viewports sich bewegt und wie weit. Schnell aufeinanderfolgende Sprünge werden zu Gruppen zusammengefasst (maximal fünf Sekunden, Lücke unter einer Sekunde); die schlechteste Gruppe ergibt den Wert.

Fair bleibt die Metrik durch zwei Ausnahmen: Verschiebungen innerhalb von 500 ms nach einer Eingabe gelten als erwartet (die Seite darf auf Klicks reagieren), und Animationen per CSS-transform zählen nicht als Layout-Verschiebung. Die üblichen Verdächtigen sind Bilder ohne Größenangaben, Webfonts mit stark abweichender Fallback-Schrift und nachträglich eingefügte Banner, Anzeigen oder Einbettungen.

Womit du misst: die Werkzeuge

• PageSpeed Insights ist die erste Adresse: oben die Felddaten aus CrUX (sofern vorhanden), darunter ein frischer Lighthouse-Labortest mit konkreten Diagnosen – kostenlos, ohne Anmeldung.
• Der Core-Web-Vitals-Bericht der Search Console zeigt die Felddaten deiner ganzen Website, gebündelt in Gruppen ähnlicher Seiten. Der schlechteste Messwert bestimmt den Status der Gruppe – ein Fehler im Seitentemplate zieht so hunderte URLs auf einmal nach unten (und eine Korrektur hebt sie gemeinsam). Nach einem Fix lässt sich die Behebung dort starten; Google beobachtet die Gruppe dann 28 Tage.
• Lighthouse und die Chrome-DevTools sind das Labor für die Ursachenforschung, inklusive Aufschlüsselung der LCP-Phasen und der Verursacher von Layout-Shifts.
• Eigenes Monitoring: Mit der JavaScript-Bibliothek web-vitals sammelst du Felddaten selbst; Dienste wie Uptrends messen zusätzlich von wählbaren Standorten, Geräten und Netzgeschwindigkeiten aus.

Was die Core Web Vitals fürs Ranking bedeuten

Seit Mitte 2021 (Desktop seit Anfang 2022) gehören die Core Web Vitals zu Googles Page-Experience-Signalen. Die ehrliche Einordnung: Sie sind ein moderates Rankingsignal. Relevanz schlägt Tempo – eine inhaltlich bessere Seite überholt keine schnellere mit schwächerem Inhalt. In umkämpften Ergebnissen wirken sie eher als Zünglein an der Waage zwischen ähnlich guten Treffern, oder nüchtern formuliert: als technisches Eintrittsticket, das man gelöst haben sollte.

Unterschätzen sollte man sie deshalb nicht. Eine Google-Auswertung bezifferte den Effekt aufs Verhalten: Erreichen alle drei Werte den grünen Bereich, brechen Besucher das Laden um rund ein Viertel seltener ab. Schnelle, stabile Seiten konvertieren besser – das Ranking ist fast das kleinste Argument.

LCP optimieren

• Das wichtigste Bild klein machen: modernes Format (AVIF/WebP), passende Größen per srcset – die Details stehen im Artikel zur Bild-SEO.
• Früh laden statt spät: Das LCP-Bild gehört nie auf loading="lazy". Stattdessen priorisieren: fetchpriority="high", bei Bedarf per preload vorladen.
• Schnell ausliefern: statisches HTML, Kompression, Caching. Ein guter TTFB ist die Basis, auf der alle anderen Phasen aufbauen.
• Render-Blocker beseitigen: schlankes CSS, kein blockierendes JavaScript im <head>, Schriften selbst hosten.

Die Feinarbeit an den vier LCP-Phasen habe ich in einem eigenen Artikel aufgeschrieben: LCP & INP gezielt optimieren.

INP optimieren

• Weniger JavaScript ausliefern – der mit Abstand wirksamste Hebel. Wer Verhalten nativ löst statt es nachzubauen (die erste Regel von ARIA lässt grüßen, ebenso details/summary), hat weniger Code, der den Hauptthread blockieren kann.
• Lange Aufgaben zerteilen: Arbeit am Stück über 50 ms blockiert spürbar. In Häppchen aufteilen und dem Browser zwischendurch Luft zum Zeichnen geben.
• Nicht-Dringendes verschieben: Analytics und Nebensächliches erst nach der Reaktion auf die Eingabe ausführen.
• Schwergewichte hinterfragen: Ein aufwendiges Karussell oder ein Framework-Bündel für eine Inhaltsseite ist ein Klassiker für schlechte Werte.

CLS optimieren

• Bildern und Videos feste Maße geben. Mit width und height kennt der Browser das Seitenverhältnis und reserviert den Platz, bevor die Datei geladen ist:

  <img src="/img/produkt.webp" width="800" height="450" alt="Produktfoto: …" />

• Platz für Nachzügler reservieren: Anzeigen, Einbettungen und iframes bekommen einen Container mit fester Größe oder aspect-ratio, statt sich ihren Platz beim Laden zu nehmen.

• Nichts oberhalb von Sichtbarem einfügen. Banner und Hinweise gehören von Anfang an ins Layout – oder überlagern es, statt es zu verschieben.

• Schriften zähmen: Beim Wechsel von der Fallback- zur Webschrift springt der Text. font-display: swap zeigt sofort Text an, selbst gehostete, vorgeladene Schriften halten den Wechsel kurz und klein:

  @font-face {
    font-family: "Plus Jakarta Sans";
    src: url("/fonts/plus-jakarta-sans.woff2") format("woff2");
    font-display: swap;
  }

Best Practice: 100 Punkte, ohne dafür zu kämpfen

Wie sieht das Ergebnis aus, wenn eine Seite konsequent schlank gebaut ist? So:

Der Bericht ist ein Lighthouse-Labortest unter bewusst harten Bedingungen – emuliert wird ein Mittelklasse-Smartphone im langsamen 4G-Netz. Trotzdem: LCP nach 1,4 Sekunden, Total Blocking Time 0 ms, CLS praktisch null, 100 Punkte in Leistung, Barrierefreiheit, Best Practices und SEO – dazu drei von drei Prüfungen in der neuen, noch experimentellen Kategorie „Agentisches Browsing“, die testet, wie gut KI-Agenten mit der Seite zurechtkommen.

Die Pointe: Diese Werte sind keine nachträgliche Optimierung, sondern das Nebenprodukt der Bauweise – und genau deshalb taugen sie als Best Practice:

• Statisches HTML ohne Framework-Bündel. Die Seite liefert fertiges Markup aus, „Zero JS by default“. Wo nichts blockiert, ist die Total Blocking Time 0 ms – LCP und INP gewinnen praktisch von allein.
• Bilder mit festen Maßen, modern komprimiert. Der Screenshot oben kommt als WebP mit width/height, srcset und loading="lazy": 25 KB statt der 396 KB des Original-PNGs – und kein Pixel springt beim Laden.
• Schriften selbst gehostet als variable WOFF2 mit font-display: swap – kein Warten auf ein fremdes CDN, kaum Textsprung.
• Keine Drittanfragen vor der Einwilligung: Die Webanalyse lädt erst nach dem Klick auf „Akzeptieren“ – bis dahin konkurriert nichts Fremdes um die Bandbreite.
• Und die 100 in Barrierefreiheit und SEO? Semantisches HTML zahlt auf alle Ziele gleichzeitig ein – Struktur, die Screenreader versteht, versteht auch der Crawler.

Ein ehrlicher Hinweis gehört dazu: Oben im Bericht steht bei den Felddaten „keine Daten“ – diese Website hat schlicht noch zu wenig Chrome-Traffic für die CrUX-Mindestmenge. Genau so sieht das Bild bei den meisten kleinen Websites aus, und dann gilt: Der Labortest ist die beste verfügbare Näherung. Wer dort unter harten Bedingungen mit großem Puffer besteht, hat von den Feld-Schwellenwerten wenig zu befürchten.

Häufige Fragen

Sind die Core Web Vitals ein starkes Rankingsignal?

Eher ein moderates – ein Faktor unter vielen, und Relevanz schlägt Geschwindigkeit. In engen Rennen können sie den Ausschlag geben. Der größere Gewinn liegt in weniger Abbrüchen und besserer Nutzung, was wiederum indirekt hilft.

Reicht ein guter Lighthouse-Wert?

Als Diagnose ja, als Nachweis nein: Für die Bewertung zählen die Felddaten echter Besucher. Hat deine Website dafür zu wenig Traffic, ist ein guter Labortest unter gedrosselten Bedingungen aber die beste Näherung, die du bekommen kannst.

Wie schnell wirken sich Verbesserungen aus?

Mit Verzögerung: Die Felddaten sind ein rollierendes 28-Tage-Fenster. Nach einer Korrektur kannst du in der Search Console die Behebung anstoßen – Google beobachtet die betroffenen Seiten dann 28 Tage lang.

Was bringt am meisten?

Meist die Bilder (modernes Format, passende Größe, feste Maße) und der Verzicht auf unnötiges JavaScript. Beides zusammen verbessert LCP, CLS und INP auf einen Schlag.

Muss ich den First Input Delay (FID) noch beachten?

Nein. FID ist seit März 2024 ausgemustert; sein Nachfolger INP misst strenger, weil er alle Interaktionen des Besuchs betrachtet statt nur der ersten.

Fazit

Die Core Web Vitals übersetzen gefühlte Qualität in drei messbare Werte: Ladegefühl (LCP ≤ 2,5 s), Reaktionsfreude (INP ≤ 200 ms) und Stabilität (CLS ≤ 0,1), gemessen am 75. Perzentil echter Besuche. Die größten Hebel sind optimierte Bilder mit festen Maßen, gezähmte Schriften, schnelle Auslieferung und so wenig JavaScript wie möglich. Eine statische, semantische Seite bringt das meiste davon mit – die 100 Punkte oben sind kein Kunststück, sondern die Folge.