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:

• Ladezeit (LCP): wie lange es dauert, bis der Hauptinhalt auf dem Bildschirm zu sehen ist
• Interaktivität (INP): wie lange die Seite braucht, um auf einen Klick, ein Tippen oder einen Tastendruck zu reagieren
• Stabilität (CLS): wie sehr sich der Inhalt beim Laden verschiebt

Die Messwerte ändern sich. Im März 2024 hat INP den First Input Delay (FID) abgelöst. FID hat nur die Wartezeit gemessen, bis die erste Interaktion verarbeitet wurde. INP misst jede Interaktion von Anfang bis Ende – und deutlich mehr Seiten fallen durch.

Wann bestehst du die Core Web Vitals?

Google stuft jeden Messwert als Gut, Optimierungsbedarf oder Schlecht ein. Du bestehst, wenn mindestens 75 % der Seitenbesuche in CrUX einen guten LCP, einen guten INP und einen guten CLS aufweisen. Google prüft zuerst die URL. Hat diese URL zu wenig Traffic, greift Google auf eine Gruppe ähnlicher URLs zurück – oder auf den gesamten Origin. PageSpeed Insights zeigt das Ergebnis ganz oben auf der Seite: „Core Web Vitals Assessment: Passed“ oder „Failed“.

Warum das 75. Perzentil?

Der Median zeigt dir nur die schnellere Hälfte deiner Besucher. Ein strengeres Perzentil würde dazu führen, dass ein paar Besuche aus dem Zug mit einem Balken Empfang die gesamte Seite durchfallen lassen. p75 liegt dazwischen: Drei von vier Besuchen müssen gut sein.

Dein eigener Laptop im Büro-WLAN sagt dir wenig. Für p75 zählen die langsameren Smartphones im Mobilfunknetz.

Die drei Core-Web-Vitals-Messwerte

Largest Contentful Paint (LCP): Ladezeit

Der Largest Contentful Paint misst die Ladezeit: die Zeitspanne vom Start der Navigation bis das größte Element im Viewport gerendert ist.

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 bedeutet unter 2,5 Sekunden. Im CrUX-Release vom August 2026 schafften das 68,1 % der Origins – der niedrigste Wert unter den dreien.

Der LCP richtet sich nach dem, was der Besucher sieht. Sobald das größte Element auf dem Bildschirm zu sehen ist, halten die meisten Nutzer die Seite für fertig – selbst wenn Skripte noch laden. Der Messwert wurde entwickelt, um eine Frage zu beantworten: „Wann ist der Inhalt einer Seite sichtbar?“.

Wenn das LCP-Element zu spät kommt, ist der Grund meist banal: loading="lazy" auf dem Hero-Bild. Ein Hero-Bild als CSS-Hintergrund, sodass der Browser es erst findet, nachdem das Stylesheet geladen ist. Ein Slider-Skript, das erst laufen muss, bevor der erste Slide sichtbar ist. Behebe zuerst die Erkennung, preloade das Bild, falls das HTML es noch verbirgt, gib ihm fetchpriority="high" und mach die Datei kleiner. Der Guide zum Largest Contentful Paint 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 nach einem Klick, Tippen oder Tastendruck aktualisiert. 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. Gewertet wird die langsamste Interaktion der Seite. Bei Seiten mit vielen Interaktionen ignoriert Google pro 50 Interaktionen einen Ausreißer – das entspricht ungefähr dem 98. Perzentil.

Ein normaler Lighthouse-Lauf kann den INP nicht messen. Er lädt die Seite und klickt nie etwas an. Der am nächsten liegende Lab-Wert ist die Total Blocking Time. Der INP ist meist deutlich niedriger als die TBT – sinkt die TBT, zieht der INP aber meist nach.

Oft ist der Click-Handler selbst schnell. Der Main-Thread ist bloß mit etwas anderem beschäftigt, wenn der Klick erfolgt: ein Tag Manager, ein Chat-Widget oder ein Framework, das noch hydriert. Der Großteil dieses JavaScripts lässt sich aufschieben oder einteilen. Im August 2026 hatten 85,3 % der Origins einen guten INP – ein Rückgang von 87,2 % im März (CrUX-Release-Notes). Es ist der einzige Core Web Vital, der sich im letzten Jahr verschlechtert hat. Der Guide zum Interaction to Next Paint zeigt, wie du die langsamen Interaktionen aufspürst.

Cumulative Layout Shift (CLS): visuelle Stabilität

Der Cumulative Layout Shift misst die visuelle Stabilität: wie stark sich sichtbarer Inhalt verschiebt, ohne dass der Besucher das veranlasst hat. Du willst auf einen Link tippen – und die Seite springt weg.

Jeder Shift erhält einen Wert: Impact Fraction (wie viel des Viewports betroffen ist) mal Distance Fraction (wie weit sich der Inhalt relativ zum Viewport bewegt hat). Shifts, die kurz hintereinander auftreten, werden in einem Session Window zusammengefasst. Der CLS der Seite entspricht dem schlechtesten Session Window.

Die typischen Ursachen: Bilder ohne Breiten- und Höhenangaben; Ads, Cookie-Banner und Embeds, die Inhalte beim Nachladen nach unten schieben; und Web-Fonts, die breiter oder höher als ihr Fallback sind. Bei Fonts gilt: Hoste sie selbst und wähle die passende Einstellung für font-display. Den CLS haben die meisten Websites im Griff: Im August 2026 wiesen 81,5 % der Origins einen guten CLS auf. Mehr dazu im Guide zum Cumulative Layout Shift.

Warum sind die Core Web Vitals wichtig?

• Besucher springen ab. Ein Button, der eine halbe Sekunde lang nicht reagiert, wird zweimal geklickt – und dann verlassen Besucher die Seite. Google hat Case Studies von Websites gesammelt, die ihre Core Web Vitals optimiert haben: Das Ergebnis waren niedrigere Absprungraten und mehr Conversions.
• Rankings. Die Core Web Vitals sind ein Google-Ranking-Faktor. Ein kleiner. Sind zwei Seiten in etwa gleich gut, ist die schnellere im Vorteil.
• Mobile. Der Großteil deines Traffics kommt wahrscheinlich über Smartphones – und genau dort fallen Seiten durch. Laut dem Web Almanac 2025 (der aktuellen Ausgabe) bestehen nur 48 % der mobilen Seiten, verglichen mit 56 % auf dem Desktop.
• Google Ads. Die Nutzererfahrung mit der Landingpage fließt in deinen Qualitätsfaktor ein. Eine langsame Landingpage zieht ihn nach unten und jeder Klick wird teurer.

Zudem dokumentiert Google exakt, wie jeder Messwert erfasst wird – bis hinunter zum Browser-Code. Bei einem Ranking-Faktor kommt das so gut wie nie vor.

Vodafone-Fallstudie

Vodafone Italien verbesserte seinen Largest Contentful Paint um 31 % und erzielte 8 % mehr Verkäufe, 15 % mehr Leads und eine um 11 % bessere Cart-to-Visit-Rate (Quelle: web.dev Case Study).

Field Data vs. Lab Data

Field Data (auch als Real User Monitoring oder RUM-Daten bezeichnet) 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 dem zugestimmt haben. Die Core Web Vitals basieren ausschließlich auf Field Data.

Lab Data stammt aus Tests auf einem simulierten Gerät in einer festen Testumgebung. Lighthouse und WebPageTest liefern Lab Data. Ein Lab-Test liefert bei jedem Durchlauf in etwa dasselbe Ergebnis – das macht ihn ideal zum Debuggen. Was deine echten Besucher erleben, erfährst du so allerdings nicht.

Lighthouse zeigt 100 – warum falle ich trotzdem durch?

Weil Google auf Basis von CrUX bewertet und Lighthouse nur einen einzigen simulierten Besuch testet. Deine Besucher nutzen günstige Android-Smartphones und schlechtes Hotel-WLAN. Und sie klicken auf Elemente, die Lighthouse niemals anfasst. Den INP gibt es in einem Lighthouse-Lauf nicht einmal.

CrUX liefert dir pro URL-Gruppe nur ein „Bestanden“ oder „Nicht bestanden“. Um herauszufinden, welche Seite, welches Gerät und welches Element hinter dem Fehler steckt, nutze ich Real User Monitoring: CoreDash, das ich genau dafür gebaut habe. Es schlüsselt die Daten nach Gerät, Land und Seiten-Template auf und zeigt direkt auf das LCP-Element oder die Interaktion, die langsam ist.

So misst du die Core Web Vitals

Mess-Tools im Vergleich

CrUX-Daten

Der CrUX-Datensatz enthält die Core Web Vitals jeder Website mit genügend Chrome-Traffic. Er ist der offizielle Datensatz des Web Vitals-Programms. Du hast mehrere Wege, um an die Daten zu kommen:

1. CrUX Vis zeigt, wie ein Origin oder eine URL in den letzten Monaten abgeschnitten hat. Es ersetzt das alte CrUX Dashboard in Looker Studio, das Google Ende 2025 eingestellt hat.
2. CrUX auf BigQuery enthält die Origin-Daten aller Websites in CrUX – mit vollständigen Histogrammen pro Messwert, monatlich aktualisiert. Ideal, um eine Website mit Mitbewerbern zu vergleichen.
3. Die CrUX API liefert Daten pro Seite oder Origin, filterbar nach Gerätetyp und Messwert – perfekt, wenn du die Zahlen in eigenen Tools brauchst.
4. PageSpeed Insights zeigt die CrUX-Daten einer URL über einem Lighthouse-Bericht an. Es öffnet standardmäßig im Mobile-Tab. Bleib dort: Der Desktop-Tab ist oft grün und lässt viele glauben, sie hätten bestanden.

Monitoring mit RUM

RUM-Daten stammen aus einem kleinen Skript auf deiner eigenen Website, das jeden Besuch misst. Es misst dieselben Core Web Vitals wie CrUX – liefert aber genau die Details, die CrUX weglässt. CrUX ist anonymisiert, endet auf URL-Ebene und blickt immer auf die letzten 28 Tage zurück. RUM zeigt dir den gestrigen Tag: nach Seite, Gerät, Land und Browser. Und es sagt dir, welches Element für den langsamen LCP oder den Layout Shift verantwortlich war. Genau deshalb setzt fast jeder, der beruflich Core Web Vitals optimiert, RUM neben CrUX ein.

Lighthouse

Lighthouse misst die Core Web Vitals nicht. Es lädt eine Seite, genau einmal, auf einem simulierten Smartphone mit gedrosselter Verbindung. Es startet mit leerem Cache, navigiert nie zu einer zweiten Seite und klickt nirgendwo hin.

Trotzdem ist es der schnellste Weg, um herauszufinden, was das Rendering blockiert, welches Bild das LCP-Element ist und welche Skripte den Main-Thread beschäftigen. Ignoriere allerdings die halbe Liste: CSS zu minifizieren spart ein paar Kilobyte – kein einziger deiner Besucher wird das merken.

Starte es in PageSpeed Insights, in den Chrome DevTools oder über das Lighthouse-Command-Line-Tool.

Wie viele Websites bestehen?

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

Vergleiche denselben Monat immer im Jahresvergleich. Der Dezember schwankt jedes Jahr (das beobachtet das Chrome-Team seit dem Start von CrUX) – ein einzelner schlechter Monat sagt also wenig aus. Zu TTFB und FCP, die nicht in den Release Notes stehen, findest du mehr im Guide zur Time to First Byte und im Guide zum First Contentful Paint.

So verbesserst du die Core Web Vitals

Wo ich ansetze: p75 pro Messwert auf Mobile, dann die von der Search Console markierte URL-Gruppe, danach der Trend. Ein plötzlicher Einbruch deutet meist auf ein Deploy hin. Ein schleichender Abfall entsteht, wenn sich Third-Party-Skripte anhäufen – ein Tag nach dem anderen.

Jedes Release kann wieder etwas kaputtmachen – behalte deine Field Data also auch nach dem Livegang im Auge. Zudem beeinflussen sich die Messwerte gegenseitig: font-display: swap bringt deinen Text schneller auf den Bildschirm und kann dem LCP helfen. Weicht der Web-Font in seinen Maßen aber vom Fallback ab, führt der Austausch zu einem Layout Shift. Ein Guide pro Messwert:

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

Zwei Diagnose-Messwerte bremsen den LCP oft aus:

• Time to First Byte (TTFB): Der Browser kann nicht mit dem Aufbau der Seite beginnen, bevor das HTML da ist. Bei einer langsamen TTFB ist ein guter LCP fast unmöglich. Das HTML auf deinem CDN zu cachen ist meist der schnellste Hebel.
• First Contentful Paint (FCP): Der erste sichtbare Inhalt wird gerendert. 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 fasste Google die Core Web Vitals zusammen mit HTTPS, Mobilfreundlichkeit und störenden Interstitials unter „Page Experience“ zusammen. Im November 2024 hat Google den Page-Experience-Bericht aus der Search Console entfernt. Der Core-Web-Vitals-Bericht ist nach wie vor da – unter „Experience“.

Dieser Bericht fasst deine URLs nach Vorlage zusammen und zeigt, welche Gruppen bestehen. Er deckt die letzten 28 Tage ab: Zwei Wochen nach einem Fix spiegelt die Hälfte der Daten also immer noch den alten Stand wider.