Was sind die Core Web Vitals? LCP, INP & CLS erklärt (2026)

Was sind die Core Web Vitals?

Jeder Core Web Vital deckt einen Moment eines Besuchs ab. Die Daten stammen von echten Chrome-Nutzern:

• Laden (LCP): Wie lange es dauert, bis der Hauptinhalt auf dem Bildschirm erscheint
• Reaktionsfähigkeit (INP): Wie lange die Seite braucht, um auf einen Klick, ein Tippen oder einen Tastendruck zu reagieren
• Stabilität (CLS): Wie stark sich der Inhalt bewegt, während er lädt

Das Set ändert sich. Im März 2024 hat INP First Input Delay (FID) ersetzt. FID maß nur die Wartezeit, bevor die erste Interaktion verarbeitet wurde. INP misst jede Interaktion von Anfang bis Ende. Viele weitere Websites fallen dabei durch.

Wann bestehst du die Core Web Vitals?

Google bewertet jede Metrik als Gut, Verbesserungsbedürftig oder Schlecht. Du bestehst, wenn mindestens 75 % der Seitenbesuche in CrUX einen guten LCP-Wert, einen guten INP-Wert und einen guten CLS-Wert aufweisen. Google betrachtet zuerst die URL. Hat diese URL zu wenig Traffic, weicht Google auf eine Gruppe ähnlicher URLs oder auf die gesamte Origin aus. PageSpeed Insights zeigt das Ergebnis ganz oben auf der Seite an: „Core Web Vitals-Bewertung: Bestanden“ oder „Nicht bestanden“.

Warum das 75. Perzentil?

Der Median sagt dir nur etwas über die schnellere Hälfte deiner Besucher. Ein strengeres Perzentil würde die Seite durch wenige Besuche aus einem Zug mit einem Balken Empfang durchfallen lassen. p75 liegt dazwischen: Drei von vier Besuchen müssen gut sein.

Dein eigener Laptop im Büro-WLAN sagt dir sehr wenig. Die Besuche, die p75 entscheiden, sind die langsameren Handys in Mobilfunknetzen.

Die drei Core Web Vitals-Metriken

Largest Contentful Paint (LCP): Laden

Der Largest Contentful Paint misst das Laden: die Zeit vom Start der Navigation, bis das größte Element im Viewport gerendert wird.

Dieses Element muss Inhalt haben: ein Bild (Hintergrundbilder und Video-Poster zählen auch) oder ein Textblock. Auf den meisten Seiten ist das LCP-Element das Hero-Bild oder die Hauptüberschrift.

Gut ist unter 2,5 Sekunden. Im CrUX-Release für August 2026 schafften das 68,1 % der Origins. Das ist der niedrigste Wert der drei.

LCP folgt dem, was der Besucher sieht. Sobald das größte Element auf dem Bildschirm ist, denken die meisten Leute, die Seite ist fertig. Auch wenn noch Skripte laden. Die Metrik wurde entwickelt, um eine Frage zu beantworten: „Wann ist der Inhalt einer Seite sichtbar?“.

Wenn das LCP-Element spät dran ist, ist der Grund meist langweilig. loading="lazy" auf dem Hero-Bild. Ein Hero als CSS-Hintergrund, sodass der Browser es erst nach dem Stylesheet findet. Ein Slider-Skript, das laufen muss, bevor das erste Slide erscheint. Behebe zuerst die Erkennung. Lade dann das Bild per Preload, falls das HTML es noch versteckt. Gib ihm fetchpriority="high" und mache die Datei kleiner. Der Largest Contentful Paint Guide geht alle vier LCP-Phasen durch.

Interaction to Next Paint (INP): Interaktivität

Der Interaction to Next Paint misst die Interaktivität: Wie lange es dauert, bis sich der Bildschirm aktualisiert, nachdem ein Besucher klickt, tippt oder eine Taste drückt. Scrollen und Hovern zählen nicht.

Jede Interaktion wird von der Eingabe über das ausgelöste JavaScript bis zum nächsten Frame auf dem Bildschirm gemessen. Die Seite erhält die Zeit ihrer langsamsten Interaktion. Auf Seiten mit vielen Interaktionen überspringt Google einen Ausreißer pro 50 Interaktionen. Das entspricht ungefähr dem 98. Perzentil.

Ein normaler Lighthouse-Durchlauf kann INP nicht messen. Er lädt die Seite und klickt nie auf etwas. Die nächste Metrik aus Lab Data ist die Total Blocking Time. INP ist meist viel niedriger als TBT. Wenn TBT sinkt, folgt INP aber oft.

Oft ist der Click-Handler selbst schnell. Der Main Thread ist mit etwas anderem beschäftigt, wenn der Klick reinkommt: ein Tag-Manager, ein Chat-Widget, ein Framework, das noch hydriert. Ein Großteil dieses JavaScript kann aufgeschoben oder eingeplant werden. 85,3 % der Origins hatten im August 2026 einen guten INP-Wert. Im März waren es noch 87,2 % (CrUX Release Notes). Es ist der einzige Core Web Vital, der im letzten Jahr schlechter wurde. Der Interaction to Next Paint Guide zeigt, wie du langsame Interaktionen findest.

Cumulative Layout Shift (CLS): Visuelle Stabilität

Der Cumulative Layout Shift misst die visuelle Stabilität: Wie stark sich sichtbarer Inhalt bewegt, ohne dass der Besucher darum bittet. Du willst auf einen Link tippen und die Seite springt.

Jeder Shift bekommt eine Punktzahl: die Impact Fraction (wie viel vom Viewport betroffen ist) mal der Distanz-Fraktion (wie weit sich der Inhalt relativ zum Viewport bewegt hat). Shifts, die kurz nacheinander passieren, werden in einem Session Window addiert. Der CLS der Seite ist ihr schlechtestes Session Window.

Die üblichen Ursachen: Bilder ohne Breite und Höhe. Anzeigen, Cookie-Banner und Embeds, die Inhalte beim Laden nach unten schieben. Und ein Webfont, der breiter oder höher als sein Fallback ist. Hoste Fonts selbst und wähle die richtige font-display-Einstellung. CLS ist die Metrik, die die meisten Seiten richtig machen: 81,5 % der Origins hatten im August 2026 einen guten CLS. Mehr dazu im Cumulative Layout Shift Guide.

Warum sind die Core Web Vitals wichtig?

• Besucher gehen. Ein Button, der eine halbe Sekunde lang nichts tut, wird zweimal geklickt und dann verlassen. Google hat Fallstudien von Seiten gesammelt, die ihre Core Web Vitals verbessert haben. Sie erzielten niedrigere Absprungraten und mehr Conversions.
• Rankings. Die Core Web Vitals sind ein Google-Rankingfaktor. Ein kleiner. Wenn zwei Seiten in etwa gleich gut sind, hat die schnellere den Vorteil.
• Mobil. Der meiste Traffic kommt wahrscheinlich von Handys. Genau dort fallen Seiten durch. Der Web Almanac 2025 (die neueste Ausgabe) ergab, dass 48 % der mobilen Seiten bestanden. Auf dem Desktop waren es 56 %.
• Google Ads. Die Nutzererfahrung der Landingpage ist Teil deines Qualitätsfaktors. Eine langsame Landingpage zieht ihn nach unten. Jeder Klick kostet dann mehr.

Google dokumentiert außerdem exakt, wie jede Metrik gemessen wird, bis hin zum Browser-Code. Für einen Rankingfaktor passiert das fast nie.

Vodafone Fallstudie

Vodafone Italien verbesserte seinen Largest Contentful Paint um 31 %. Sie erzielten 8 % mehr Umsatz, 15 % mehr Leads und eine um 11 % bessere Cart-to-Visit-Rate (Quelle: web.dev Fallstudie).

Field Data vs. Lab Data

Field Data (auch Real User Monitoring oder RUM-Daten genannt) stammt von deinen echten Besuchern. Auf ihren eigenen Geräten und in ihren eigenen Netzwerken. Googles CrUX-Datensatz besteht aus Field Data von Chrome-Nutzern, die zugestimmt haben. Die Core Web Vitals basieren nur auf Field Data.

Lab Data stammt aus einem Test auf einem simulierten Gerät in einem festen Setup. Lighthouse und WebPageTest produzieren Lab Data. Ein Lab-Test liefert bei jedem Durchlauf ungefähr das gleiche Ergebnis. Das macht ihn gut fürs Debugging. Er sagt dir nicht, was deine Besucher erleben.

Lighthouse sagt 100, warum falle ich durch?

Weil Google basierend auf CrUX rankt. Lighthouse testet einen simulierten Besuch. Deine Besucher nutzen billige Android-Handys und schlechtes Hotel-WLAN. Sie klicken auf Dinge, die Lighthouse nie berührt. INP existiert in einem Lighthouse-Durchlauf nicht einmal.

CrUX liefert dir ein Bestanden oder Nicht bestanden pro URL-Gruppe. Um herauszufinden, welche Seite, welches Gerät und welches Element hinter dem Fehler stecken, nutze ich Real User Monitoring: CoreDash. Ich habe es genau dafür gebaut. Es teilt die Daten nach Gerät, Land und Seitentemplate auf. Es zeigt direkt auf das langsame LCP-Element oder die langsame Interaktion.

Wie man die Core Web Vitals misst

Messwerkzeuge im Vergleich

CrUX-Daten

Der CrUX-Datensatz enthält die Core Web Vitals jeder Seite mit genug Chrome-Traffic. Es ist der offizielle Datensatz des Web Vitals-Programms. Du erreichst ihn auf verschiedene Arten:

1. CrUX Vis zeigt, wie eine Origin oder URL in den letzten Monaten abgeschnitten hat. Es ersetzte das alte CrUX-Dashboard in Looker Studio, das Google Ende 2025 abgeschaltet hat.
2. CrUX in BigQuery bietet die Daten auf Origin-Ebene für jede Seite in CrUX. Mit vollständigen Histogrammen pro Metrik, monatlich aktualisiert. Gut, um eine Seite mit Konkurrenten zu vergleichen.
3. Die CrUX-API liefert dir die Daten pro Seite oder Origin. Gefiltert nach Gerätetyp und Metrik. Nützlich, wenn du die Zahlen in deinen eigenen Tools brauchst.
4. PageSpeed Insights zeigt die CrUX-Daten einer URL über einem Lighthouse-Report an. Es öffnet sich im Mobil-Tab. Bleib dort: Der Desktop-Tab ist oft grün. Das lässt Leute fälschlicherweise glauben, sie hätten bestanden.

Monitoring mit RUM

RUM-Daten stammen von einem kleinen Skript auf deiner eigenen Seite, das jeden Besuch misst. Es misst dieselben Core Web Vitals wie CrUX, aber mit den Details, die CrUX auslässt. CrUX ist anonymisiert, stoppt auf URL-Ebene und betrachtet immer die letzten 28 Tage. RUM zeigt dir gestern, pro Seite, Gerät, Land und Browser. Es sagt dir, welches Element den langsamen LCP oder den Layout Shift verursacht hat. Darum nutzen die meisten Leute, die beruflich Core Web Vitals beheben, RUM neben CrUX.

Lighthouse

Lighthouse misst die Core Web Vitals nicht. Es lädt eine Seite, ein Mal, auf einem simulierten Handy mit gedrosselter Verbindung. Es startet mit leerem Cache, navigiert nie zu einer zweiten Seite und klickt nie.

Es ist dennoch der schnellste Weg zu sehen, was das Rendern blockiert. Es zeigt, welches Bild das LCP-Element ist und welche Skripte den Main Thread beschäftigen. Ignoriere allerdings die Hälfte der Liste. CSS zu minimieren spart ein paar Kilobyte, und keiner deiner Besucher wird es merken.

Führe es in PageSpeed Insights, in den Chrome DevTools oder mit dem Lighthouse Kommandozeilen-Tool aus.

Wie viele Seiten bestehen?

Das Chrome-Team veröffentlicht die CrUX-Zahlen jeden Monat, am zweiten Dienstag, in den CrUX Release Notes. Das sind die Anteile von Origins mit einem guten Score, alle Geräte zusammen:

Vergleiche denselben Monat im Jahresvergleich. Der Dezember schwankt jedes Jahr (das Chrome-Team sieht das seit dem Start von CrUX). Ein schlechter Monat sagt also wenig aus. Für TTFB und FCP, die nicht in den Release Notes stehen, siehe den Time to First Byte Guide und den First Contentful Paint Guide.

Wie man die Core Web Vitals verbessert

Wo ich anfange: p75 pro Metrik auf Mobilgeräten, dann die URL-Gruppe aus der Search Console, dann der Trend. Ein plötzlicher Einbruch deutet meist auf ein Deploy hin. Ein langsames Abrutschen bedeutet, dass sich Skripte von Drittanbietern ansammeln, ein Tag nach dem anderen.

Jedes Release kann wieder etwas kaputt machen. Beobachte also deine Field Data weiter, nachdem der Fix live ist. Und die Metriken beeinflussen sich gegenseitig. font-display: swap bringt deinen Text schneller auf den Bildschirm. Das kann dem LCP-Wert helfen. Wenn der Webfont jedoch eine andere Größe als der Fallback hat, verursacht der Tausch einen Layout Shift. Ein Guide pro Metrik:

• Den Largest Contentful Paint verbessern
• Den Interaction to Next Paint verbessern
• Den Cumulative Layout Shift verbessern

Zwei Diagnose-Metriken bremsen LCP aus:

• Time to First Byte (TTFB): Der Browser kann nicht mit der Seite beginnen, bevor das HTML ankommt. Mit einem langsamen TTFB ist ein guter LCP-Wert fast unmöglich. Das Cachen des HTMLs in deinem CDN ist meist der schnellste Gewinn.
• First Contentful Paint (FCP): Der erste Paint von jeglichem Inhalt. Bis dahin starrt der Besucher auf einen weißen Bildschirm.

Für eine Schritt-für-Schritt-Liste nutze die Core Web Vitals Checkliste.

Core Web Vitals in der Search Console

Früher hat Google die Core Web Vitals mit HTTPS, Mobilfreundlichkeit und aufdringlichen Interstitials als "Page Experience" zusammengefasst. Google hat den Page Experience-Report im November 2024 aus der Search Console entfernt. Der Core Web Vitals-Report ist noch da, unter „Nutzererfahrung“.

Dieser Report gruppiert deine URLs nach Template und zeigt, welche Gruppen bestehen. Er deckt die letzten 28 Tage ab. Zwei Wochen nachdem ein Fix live geht, ist also die Hälfte der angezeigten Daten noch die alte Seite.