Core Web Vitals

Was sind Core Web Vitals? Definition und Abgrenzung

Die Core Web Vitals sind die drei Kernmetriken der Web-Vitals-Initiative von Google. Largest Contentful Paint (LCP) misst, wie schnell der Hauptinhalt erscheint, Interaction to Next Paint (INP), wie schnell die Seite auf Klicks, Tippen und Tastatureingaben reagiert, und Cumulative Layout Shift (CLS), wie stabil das Layout bleibt. Gemessen werden sie an echten Seitenaufrufen, den Felddaten, getrennt für Mobilgeräte und Desktop. Die Schreibweisen „Core Website Vitals“ und „CoreWebVitals“ meinen dasselbe.

Web Vitals und Core Web Vitals

Web Vitals ist der Oberbegriff. Unter diesem Namen bündelt Google laut web.dev Messwerte für eine gute Nutzererfahrung im Web. Die Core Web Vitals sind die Teilmenge, die für alle Seiten gilt, von allen Website-Betreibern gemessen werden soll und in allen Google-Tools erscheint. Weitere Web Vitals wie Time to First Byte (TTFB) und First Contentful Paint (FCP) beschreiben frühere Abschnitte des Ladevorgangs. Sie helfen bei der Ursachensuche, etwa wenn der LCP zu spät kommt, zählen aber nicht zur Bewertung.

Largest Contentful Paint (LCP): Ladezeit des Hauptinhalts

Der Largest Contentful Paint (LCP) gibt an, wie lange es nach dem Aufruf einer Seite dauert, bis das größte Bild, der größte Textblock oder das größte Video im sichtbaren Bereich dargestellt ist. Gut ist ein LCP bis 2,5 Sekunden, schlecht einer über 4 Sekunden, dazwischen gilt er als verbesserungswürdig (in PageSpeed Insights und der Search Console „Optimierung erforderlich“). Infrage kommen laut web.dev Bilder, auch innerhalb einer SVG-Grafik, Videos, Elemente mit einem Hintergrundbild aus dem CSS und Blockelemente mit Text. Weil nur der sichtbare Bereich zählt, liegt das LCP-Element beim normalen Aufruf im ersten Bildschirm, also Above the Fold.

Ob ein LCP unter 2,5 Sekunden bleibt, hängt laut web.dev an vier Teilzeiten, die nacheinander ablaufen.

1. Serverantwort (TTFB), bis das erste Byte des HTML-Dokuments ankommt.
2. Ladeverzögerung, bis der Browser die LCP-Ressource, meist ein Bild, überhaupt anfordert.
3. Ladedauer, bis diese Ressource vollständig übertragen ist.
4. Renderverzögerung, bis das Element tatsächlich auf dem Bildschirm erscheint.

Als Richtwert nennt web.dev jeweils rund 40 % des LCP für Serverantwort und Ladedauer und jeweils unter 10 % für die beiden Verzögerungen. Häufig verzögert sich der LCP, weil das Bild erst über CSS oder JavaScript eingebunden oder per Lazy Loading zurückgehalten wird. Laut dem Web Almanac 2024 ist auf 73 % der mobilen Seiten ein Bild das LCP-Element. Bei 35 % dieser Bilder steht die Bildadresse nicht im ursprünglichen HTML, sodass der Browser sie erst spät entdeckt.

Interaction to Next Paint (INP): Reaktion auf Eingaben

Interaction to Next Paint (INP) misst, wie schnell eine Seite sichtbar auf Eingaben reagiert, und zwar über alle Klicks, Tipp-Gesten und Tastatureingaben eines Besuchs. Gemessen wird je Interaktion die Zeit von der Eingabe bis zur nächsten Darstellung im Browser. Diese Zeit besteht aus drei Teilen, der Eingabeverzögerung, der Verarbeitungsdauer der Event-Handler und der Darstellungsverzögerung. Als INP-Wert zählt meist die langsamste Interaktion, auf Seiten mit vielen Eingaben bleibt je 50 Interaktionen die langsamste als Ausreißer außen vor. Gut ist ein INP bis 200 Millisekunden, schlecht einer über 500 Millisekunden. Scrollen, Hovern und Zoomen zählen nicht. Ohne Klick, Tippen oder Tastendruck entsteht für einen Besuch kein INP-Wert.

Seit dem 12. März 2024 ist INP ein Core Web Vital und hat den First Input Delay (FID) ersetzt. FID maß nur die Eingabeverzögerung der ersten Interaktion, also weder die Verarbeitung noch spätere Eingaben. Ein Tarifrechner, der auf den ersten Klick sofort reagiert, bei der fünften Eingabe aber hängt, fiel mit FID nicht auf, mit INP schon. Hohe INP-Werte entstehen meist durch lange JavaScript-Aufgaben, die den Hauptthread des Browsers blockieren.

Cumulative Layout Shift (CLS): visuelle Stabilität

Cumulative Layout Shift (CLS) misst, wie stark sich sichtbare Inhalte unerwartet verschieben, etwa wenn ein nachgeladenes Banner den Text nach unten drückt. Jede Verschiebung erhält einen Score. Er ergibt sich aus dem Anteil des Bildschirms, den die verschobenen Elemente vor und nach der Verschiebung einnehmen (Impact Fraction), mal der Strecke der Verschiebung im Verhältnis zum Bildschirm (Distance Fraction). Verschiebungen mit weniger als einer Sekunde Abstand bilden zusammen ein Sitzungsfenster von höchstens fünf Sekunden. Der CLS ist die Summe der Scores im größten solchen Fenster während der gesamten Lebensdauer der Seite. Gut ist ein CLS bis 0,1, schlecht einer über 0,25.

Verschiebungen innerhalb von 500 Millisekunden nach einer Eingabe gelten als erwartet und zählen nicht, etwa wenn ein Klick ein Akkordeon öffnet. Typische Ursachen sind laut web.dev Bilder und Videos ohne Größenangabe, Webfonts, die mehr oder weniger Platz brauchen als die Ersatzschrift, Anzeigen und Widgets, die ihre Größe ändern, sowie Elemente, die nachträglich ins Layout eingefügt werden. Laut dem Web Almanac 2024 enthalten 66 % der Seiten mindestens ein Bild ohne feste Größe.

Grenzwerte und Bewertung: wann die Core Web Vitals bestanden sind

Die Bewertung der Core Web Vitals gilt als bestanden, wenn LCP, INP und CLS am 75. Perzentil der Seitenaufrufe im guten Bereich liegen. Das 75. Perzentil bedeutet, dass mindestens drei von vier Aufrufen den Grenzwert einhalten. Mobilgeräte und Desktop werden getrennt bewertet, in PageSpeed Insights jeweils über die vergangenen 28 Tage. Liegen dort für den INP nicht genug Daten vor, reichen gute Werte für LCP und CLS.

Die Bewertung ist also kein Durchschnitt und kein Punktwert von 0 bis 100. Ein einziger Messwert außerhalb des guten Bereichs lässt die gesamte Bewertung scheitern. Die Search Console wendet dieselbe Logik auf Gruppen ähnlicher Seiten an und gibt jeder Gruppe den Status ihres schlechtesten Messwerts.

Core Web Vitals messen und testen

Gemessen werden die Core Web Vitals mit Felddaten, also an echten Seitenaufrufen. Die wichtigste Quelle ist der Chrome User Experience Report (CrUX). Er sammelt Messwerte von Chrome-Nutzern am Desktop und unter Android, die die Synchronisierung ihres Browserverlaufs und die Übermittlung von Nutzungsstatistiken aktiviert haben. Chrome auf dem iPhone fehlt. Eine Seite oder eine Origin erscheint nur, wenn sie öffentlich auffindbar ist und genug Besucher hat. Origin meint alle Seiten unter einem Protokoll und Hostnamen, etwa https://www.example.com.

• Search Console, Core-Web-Vitals-Bericht. Er zeigt CrUX-Daten der eigenen Website getrennt nach Mobil und Desktop und fasst ähnliche URLs zu Gruppen zusammen. Haben Gruppen zu wenige Daten, bildet die Search Console eine übergeordnete Gruppe auf Ebene der Origin. Nach einer Korrektur beobachtet eine Validierung 28 Tage lang, ob das Problem noch auftritt.
• PageSpeed Insights. Der kostenlose Core-Web-Vitals-Test für einzelne URLs zeigt die Felddaten der vergangenen 28 Tage für die URL oder, wenn sie zu wenige Aufrufe hat, für die ganze Origin. Darunter folgt ein Labortest mit Lighthouse.
• web-vitals-Bibliothek. Die JavaScript-Bibliothek von Google misst LCP, INP und CLS bei echten Besuchern so, wie Chrome sie misst, und übergibt die Werte an ein eigenes Analysetool. Damit lassen sich auch Seiten auswerten, für die CrUX zu wenige Aufrufe hat.

Wie sich Labor- und Felddaten in PageSpeed Insights unterscheiden und welche Werkzeuge den Ladevorgang im Detail zeigen, erklärt der Artikel zum Pagespeed-Test.

Warum Lighthouse keinen INP misst

Lighthouse und andere Labortests laden eine Seite in einer simulierten Umgebung ohne Nutzer. Weil niemand klickt oder tippt, können sie laut web.dev keinen INP messen. Als Näherung dient im Labor die Total Blocking Time (TBT), also die Zeit, in der lange Aufgaben den Browser während des Ladens blockieren. LCP und CLS misst Lighthouse nur für einen einzelnen Ladevorgang, spätere Verschiebungen beim Scrollen fehlen im Labor-CLS. Für die Bewertung zählen allein die Felddaten.

Single-Page-Apps tauschen Inhalte oft aus, ohne die Seite neu zu laden. Solche Seitenwechsel führt CrUX laut web.dev nicht als eigene Aufrufe, CLS und INP umfassen dann oft den ganzen Besuch. Seit Chrome 151 lassen sich die Core Web Vitals über neue Schnittstellen je Seitenwechsel messen, Bibliotheken wie web-vitals übernehmen diese gerade (Stand 08/2026). Wie solche Web-Apps aufgebaut sind, erklärt der Artikel zu Progressive Web Apps.

Core Web Vitals und SEO: Rolle im Google-Ranking

Googles Ranking-Systeme nutzen die Core Web Vitals als einen von mehreren Aspekten der Nutzerfreundlichkeit von Seiten (Page Experience), nachrangig zur Relevanz. Ein Rankingfaktor sind sie in dem Sinn, dass sie in die Bewertung einfließen. Ein einzelnes Signal für die Page Experience gibt es laut Google aber nicht, und gute Werte im Core-Web-Vitals-Bericht garantieren keine Platzierung ganz oben. Die Google-Suche zeigt laut eigener Dokumentation die relevantesten Inhalte auch bei schwächerer Page Experience. Gibt es viele ähnlich hilfreiche Inhalte, kann eine gute Page Experience zum Erfolg beitragen. Eine sehr langsame Seite kann dagegen Rankings kosten.

Angekündigt hat Google die Page Experience als Ranking-Signal im Mai 2020. Sie verband die Core Web Vitals mit bestehenden Signalen wie der Mobilfreundlichkeit, der Auslieferung per HTTPS und dem Verzicht auf aufdringliche Interstitials. Für HTTPS braucht eine Website ein SSL-Zertifikat. Ab Mitte Juni 2021 floss die Page Experience in die mobile Suche ein, ab Februar 2022 auch in die Desktop-Suche. Im April 2023 stellte Google klar, dass sie kein eigenes Ranking-System ist und eine gute Page Experience die Relevanz eines Inhalts nicht aufwiegt. Bewertet wird laut Google meist je Seite, ergänzt um einige websiteweite Einschätzungen.

Den zusammenfassenden Bericht „Nutzerfreundlichkeit“ hat Google im November 2024 aus der Search Console entfernt, der Core-Web-Vitals-Bericht blieb erhalten. Für die Suchmaschinenoptimierung sind die Core Web Vitals ein technischer Baustein der Onpage-SEO.

Core Web Vitals optimieren: die wirksamsten Hebel je Metrik

Wer die Core Web Vitals optimieren will, beginnt mit der Metrik, die in den Felddaten durchfällt, und grenzt die Ursache mit den Teilzeiten und einem Labortest ein. Google nennt auf web.dev je Metrik drei Maßnahmen, die die Werte am stärksten verbessern. Allgemeine Hebel für die Ladezeit wie Hosting, Caching, moderne Bildformate und Komprimierung behandelt der Artikel zum Pagespeed, sie wirken vor allem auf den LCP.

LCP optimieren

• LCP-Ressource früh auffindbar machen. Die LCP-Optimierung beginnt meist beim Bild. Es gehört als <img> direkt ins HTML statt in CSS oder JavaScript und bekommt fetchpriority="high" statt loading="lazy". Laut dem Web Almanac 2024 nutzen erst 15 % der infrage kommenden Seiten fetchpriority.
• Serverantwort beschleunigen. Ein Content Delivery Network (CDN) verkürzt die TTFB, den ersten Teil jedes LCP. Laut dem Web Almanac 2024 kamen erst 33 % der HTML-Dokumente über ein CDN.
• Navigationen ohne Wartezeit. Mit Speculation Rules lädt der Browser wahrscheinliche nächste Seiten vorab, sodass sie beim Klick sofort erscheinen.

INP optimieren

• Lange Aufgaben aufteilen. JavaScript, das länger als 50 Millisekunden am Stück läuft, gilt als lange Aufgabe und blockiert den Hauptthread. In kleinere Schritte zerlegt, lässt es Eingaben dazwischen durch.
• Unnötiges JavaScript vermeiden. Ungenutzten Code entfernen, Code in kleinere Pakete aufteilen und Skripte von Drittanbietern auf das Nötige beschränken.
• Große Rendering-Updates vermeiden. Wenige und kleine Änderungen am Seitenaufbau nach einer Eingabe halten die Darstellungsverzögerung kurz.

Das Beispiel zeigt, wie ein Tarifrechner eine lange Berechnung in Schritte zerlegt. Nach jeder Zeile gibt er den Hauptthread mit scheduler.yield() frei, in Browsern ohne diese Funktion mit setTimeout, wie es web.dev empfiehlt.

function yieldToMain() {
  if (globalThis.scheduler?.yield) {
    return scheduler.yield();
  }
  return new Promise((resolve) =>
    setTimeout(resolve, 0));
}

async function rechne(tarife) {
  for (const tarif of tarife) {
    rechneZeile(tarif);
    // Eingaben dürfen dazwischen
    await yieldToMain();
  }
}

CLS optimieren

• Größen festlegen und Platz reservieren. Bilder, Videos und Iframes bekommen width und height oder ein aspect-ratio, damit der Browser ihren Platz vorab reserviert. Banner, Anzeigen und Ergebnisbereiche erhalten eine Mindesthöhe oder erscheinen als Overlay, statt Inhalte nach unten zu schieben.
• Back/Forward-Cache ermöglichen. Seiten, die der Browser beim Zurückgehen aus dem Speicher holt, erscheinen ohne neue Verschiebungen. Laut web.dev brachte die Einführung dieses Caches 2022 die größte Verbesserung des CLS in jenem Jahr.
• Layoutverschiebende Animationen vermeiden. Bewegung per transform statt über margin oder top verschiebt das Layout nicht.

Core Web Vitals auf Finanzseiten: Consent-Banner, Rechner und Tag-Manager

In einer KKP-Stichprobe bestanden 17 von 20 großen Banken und Versicherern die Bewertung der Core Web Vitals mobil. Abgerufen hat KKP die Felddaten der 20 Origins, je 10 von Banken und Versicherern, am 5. Oktober 2026. Zum Vergleich erreichten laut Web Almanac 2025 im Juli 2025 nur 48 % der mobilen Websites im CrUX-Datensatz gute Core Web Vitals. Bei den drei Origins, die scheiterten, lag jeweils genau ein Messwert außerhalb des guten Bereichs, einmal der LCP, einmal der INP und einmal der CLS.

Die Werte gelten je Origin, also für alle Seitenaufrufe unter einer Adresse zusammen. Bei zwei Origins, die bestanden, lag zudem ein Wert knapp an der Grenze, ein LCP von 2,5 Sekunden und ein CLS von 0,09. Typische Bausteine von Finanzseiten belasten vor allem INP und CLS, weil sie viel JavaScript nachladen oder erst spät erscheinen.

• Consent-Banner. Cookie-Hinweise sind laut web.dev eine sehr häufige Ursache von Layoutverschiebungen, vor allem wenn sie oben erscheinen und den Inhalt nach unten schieben. Als Overlay am unteren Rand oder als Dialog verschieben sie nichts. Der Klick auf „Akzeptieren“ lädt oft viele Drittanbieter-Skripte und kann so einen hohen INP verursachen. Auf Mobilgeräten kann ein textreicher Banner sogar selbst zum LCP-Element werden.
• Tag-Manager. Nach der Einwilligung starten Analyse- und Marketing-Tags. Laufen viele gleichzeitig an, belegen sie den Hauptthread genau dann, wenn Besucher die ersten Eingaben machen. Für das Consent-Skript selbst rät web.dev, es asynchron direkt im HTML zu laden statt über einen Tag-Manager.
• Zins- und Tarifrechner. Rechnen sie bei jeder Eingabe im Hauptthread neu, steigt der INP. Lädt das Ergebnis erst nach einer Serverabfrage und schiebt es später als 500 Millisekunden nach dem Klick Inhalte nach unten, zählt die Verschiebung zum CLS. Ein reservierter Ergebnisbereich verhindert das.
• Chat-Widgets. Sie laden eigenes JavaScript. Eine schlichte Schaltfläche, die das Widget erst beim Klick nachlädt, spart dieses JavaScript beim Seitenaufruf, und als Overlay verschiebt das Fenster keine Inhalte.

Gratis Download

AI Search Guide: Sichtbar in ChatGPT & Co.

Der Praxis-Guide zeigt auf 164 Seiten, wie eine Brand in ChatGPT, Google AI Overviews, Gemini und Perplexity sichtbar wird, von den Grundlagen über Messung und KPIs bis zu konkreten Maßnahmen.

Kostenlos herunterladen →