Core Web Vitals: LCP, INP und CLS messen und verbessern

Kurz gesagt: Die Core Web Vitals sind drei Metriken, mit denen Google die Nutzererfahrung echter Besucher beschreibt: Largest Contentful Paint (LCP, Ladezeit, gut bei höchstens 2,5 s), Interaction to Next Paint (INP, Reaktionsfähigkeit, gut bei höchstens 200 ms) und Cumulative Layout Shift (CLS, visuelle Stabilität, gut bei höchstens 0,1). Jede Metrik wird am 75. Perzentil realer Chrome-Besuche über 28 Tage bewertet, getrennt für Mobilgeräte und Desktop. Google sagt, dass die Ranking-Systeme sie nutzen, doch Relevanz kommt zuerst. Zerlegen Sie zur Optimierung jede Metrik in ihre Bestandteile und beheben Sie zuerst den größten.

Die meisten Ratgeber zu Core Web Vitals sind eine Liste mit fünfzig Tipps. Deshalb investieren Teams einen Sprint in „Performance“ und sehen kaum Veränderungen bei ihren Werten. Die Metriken sind strukturierter: Jede lässt sich in wenige messbare Teile zerlegen, und meist verursacht ein Teil den Großteil des Problems.

Dieser Leitfaden erklärt, was die drei Metriken messen, welche Schwellenwerte im Oktober 2026 gelten, welcher Datenquelle Sie vertrauen sollten, was Google tatsächlich zum Ranking sagt und wie Sie jede Metrik mit einer diagnosebasierten Anleitung verbessern. Grundlage ist Googles eigene Dokumentation auf web.dev.

Was die Core Web Vitals messen

Laut web.dev-Überblick zu Web Vitals besteht das aktuelle, stabile Set aus drei Metriken:

Die Schwellenwerte entsprechen der Tabelle in About PageSpeed Insights.

Die 75.-Perzentil-Regel

Google beurteilt eine Seite weder nach dem Durchschnitt noch nach einem einzelnen Test. Web.dev nennt als sinnvollen Messwert „das 75. Perzentil der Seitenaufrufe, getrennt nach Mobilgeräten und Desktop“. Einfach gesagt: Mindestens drei von vier echten Besuchen müssen den Schwellenwert „gut“ erreichen. Um zu bestehen, braucht eine Seite bei allen drei Metriken ein gutes Ergebnis am 75. Perzentil.

Daraus folgen zwei Konsequenzen, die oft übersehen werden:

1. Mobil und Desktop sind getrennt. Eine Seite kann auf dem Desktop gut und mobil schlecht sein. Mobil ist meist schwieriger, weil Smartphones langsamere CPUs und Netzwerke haben.
2. Ihre langsamen Besucher entscheiden. Wenn ein Viertel Ihrer Besucher alte Android-Handys mit schwacher Verbindung nutzt, ist deren Erfahrung Ihr Wert. Ein Test auf einem neuen Laptop im Büro-WLAN sagt wenig aus.

INP hat 2024 FID abgelöst

Interaction to Next Paint hat First Input Delay (FID) am 12. März 2024 als Core Web Vital abgelöst. FID maß nur die Verzögerung, bevor der Browser die erste Interaktion verarbeitete. INP erfasst Klicks, Taps und Tastenanschläge während des gesamten Besuchs sowie die komplette Zeit bis zum nächsten gezeichneten Frame. Viele Seiten, die FID mühelos bestanden, fallen bei INP durch, weil der langsame Teil immer die Arbeit nach der ersten Eingabe war, die FID nie zählte. Wenn Sie FID noch in einem alten Bericht oder Plugin sehen, ignorieren Sie es.

Web.dev weist außerdem darauf hin, dass sich stabile Core Web Vitals „höchstens einmal pro Jahr ändern“ und neue Kandidaten mindestens sechs Monate lang im Wartestatus bleiben. Sie werden also vorab informiert, bevor sich die Regeln ändern.

Felddaten vs. Labordaten

Es gibt zwei Arten von Performance-Daten, und ihre Verwechslung ist der häufigste Grund, warum Teams das Falsche optimieren.

Einige Details aus Googles Dokumentation:

• CrUX ist ein gleitender 28-Tage-Durchschnitt, der laut CrUX-API-Dokumentation täglich aktualisiert wird. Er lässt sich für eine ganze Origin oder eine einzelne URL abfragen und nach Smartphone, Desktop oder Tablet filtern.
• PageSpeed Insights zeigt beides. Der Feldbereich nutzt die CrUX-Daten der vorherigen 28 Tage. Hat eine URL zu wenige Besuche, greift er auf die Daten der gesamten Origin zurück; ist die Origin zu klein, gibt es gar keine Felddaten (About PageSpeed Insights). Der Laborbereich und der Score von 0 bis 100 stammen von Lighthouse.
• Lighthouse kann INP nicht messen. Web.dev erklärt, dass Tools, die Seiten „in einer simulierten Umgebung ohne Nutzer“ laden, INP nicht messen können, und empfiehlt Total Blocking Time (TBT) als Labor-Näherung.
• Der Core-Web-Vitals-Bericht der Search Console fasst Seiten mit ähnlicher Nutzererfahrung zu Gruppen zusammen und gibt jeder Gruppe den Status ihrer langsamsten Metrik für den jeweiligen Gerätetyp. Er nutzt CrUX-Daten der letzten 28 Tage (Hilfe zum Core-Web-Vitals-Bericht).

Die Faustregel: Felddaten entscheiden, ob Sie ein Problem haben, Labordaten helfen bei der Ursachensuche. Ein Lighthouse-Score von 98 bei schlechtem Feld-LCP bedeutet, dass Ihre echten Nutzer eine schlechtere Erfahrung haben als in der Simulation, oft wegen langsamer Geräte, Werbung, Personalisierung oder Drittanbieter-Skripten, die der Labortest nicht auslöst.

Wie stark Core Web Vitals das Ranking beeinflussen

Googles Dokumentation zur Seitenerfahrung ist in beide Richtungen eindeutig:

• „Core Web Vitals werden von unseren Ranking-Systemen verwendet“, und Google empfiehlt gute Core Web Vitals „für den Erfolg in der Suche“.
• Für die Seitenerfahrung gibt es „kein einzelnes Signal“; die zentralen Ranking-Systeme betrachten eine Vielzahl von Signalen.
• „Die Google Suche versucht immer, die relevantesten Inhalte zu zeigen, auch wenn die Seitenerfahrung mangelhaft ist.“
• Gute Ergebnisse in der Search Console oder in Tools von Drittanbietern garantieren nicht, dass Ihre Seiten ganz oben ranken.
• „Einen perfekten Score nur aus SEO-Gründen anzustreben, ist möglicherweise nicht die beste Nutzung Ihrer Zeit.“

Unsere Einschätzung: Core Web Vitals heben eine irrelevante Seite nicht über eine relevante, können aber zwischen Seiten ähnlicher Qualität den Ausschlag geben, und für Nutzer sind sie unmittelbar wichtig. Eine Produktseite, die fünf Sekunden für ihr Foto braucht, oder ein „Kaufen“-Button, der eine halbe Sekunde einfriert, verliert Kunden, unabhängig vom Ranking. Streben Sie bei allen drei Metriken „gut“ an, jagen Sie dann keinen Punkten mehr hinterher und wenden Sie sich wieder dem Content zu.

Schritt 1: Herausfinden, welche Metrik wo durchfällt

Bevor Sie Code ändern:

1. Öffnen Sie den Core-Web-Vitals-Bericht der Search Console, zuerst mobil. Notieren Sie, welche Metrik durchfällt und welche URL-Gruppen betroffen sind (Produktseiten, Blogartikel, Startseite).
2. Wählen Sie pro betroffener Gruppe eine repräsentative URL und testen Sie sie in PageSpeed Insights. Prüfen Sie, ob die Felddaten für diese URL oder für die Origin gelten.
3. Beheben Sie immer ein Template nach dem anderen. Core-Web-Vitals-Probleme sind fast immer Template-Probleme: Alle Produktseiten teilen dieselbe Bildkomponente, dieselben Skripte und dasselbe Layout.

Unser kostenloser Core Web Vitals Checker liefert ohne Konto eine schnelle erste Einschätzung: Er ruft aus CrUX das 75. Perzentil von LCP, INP und CLS für Smartphone-Besucher ab (für die eingegebene Seite, wenn Chrome dafür genug Daten hat, sonst für Ihre gesamte Origin) und misst Serverantwortzeit, HTML-Größe, Komprimierung, renderblockierende Skripte im Seitenkopf und Bildformate auf dieser Seite, standardmäßig Ihrer Startseite.

Schritt 2: LCP über die vier Teilbereiche verbessern

LCP ist die Zeit, bis das größte Bild oder der größte Textblock im Viewport gerendert ist. Infrage kommen <img>, <video>, Elemente mit einem CSS-url()-Hintergrundbild und Textblöcke auf Blockebene (LCP auf web.dev). Auf den meisten Produkt- und Landingpages ist es das Hero-Bild.

Optimize LCP teilt den LCP in vier Teile, die sich zur Gesamtzeit addieren:

Web.dev nennt diese Anteile „Richtwerte, keine strikten Regeln“, für die Diagnose sind sie aber sehr nützlich. Das Performance-Panel der Chrome DevTools zeigt die Aufschlüsselung für einen aufgezeichneten Ladevorgang. Der Teil, der seinen Anteil deutlich überschreitet, ist Ihr Ansatzpunkt.

Hoher TTFB

Der TTFB umfasst Weiterleitungen, Verbindungsaufbau und Serververarbeitung. Der TTFB-Leitfaden von web.dev nennt 0,8 Sekunden oder weniger als groben Zielwert und weist darauf hin, dass TTFB selbst kein Core Web Vital ist.

• Liefern Sie HTML über ein CDN aus und cachen Sie es am Edge, auch nur kurz. The most effective ways to improve Core Web Vitals nennt ein CDN als besten Weg, den TTFB zu senken.
• Entfernen Sie Weiterleitungsketten, auch solche aus Werbe- und Kurzlinks.
• Achten Sie auf eindeutige URL-Parameter (aus Analytics oder Kampagnen), die jede Anfrage zum Cache-Miss machen.
• Analysieren Sie langsame Datenbankabfragen und serverseitiges Rendering im Seiten-Template.

Hohe Resource load delay

Das ist oft der größte Teilbereich und meist der günstigste zu beheben. Der Browser hätte den Bilddownload früher starten können, wusste aber nichts davon.

• Binden Sie das LCP-Bild im initialen HTML als normales <img src> oder srcset ein. Bilder, die per JavaScript eingefügt werden oder data-src für eine Lazy-Loading-Bibliothek nutzen, werden spät entdeckt.
• Laden Sie das LCP-Bild nie per Lazy Loading. Entfernen Sie loading="lazy" vom Hero-Bild; web.dev sagt klar: „Never lazy-load your LCP image.“
• Fügen Sie dem LCP-Bild fetchpriority="high" hinzu, und höchstens ein bis zwei weiteren Bildern.
• Ist das Bild ein CSS-Hintergrund, laden Sie es mit <link rel="preload"> und hoher Fetch-Priorität vor oder wechseln Sie zu einem <img>.
• Liefern Sie kritische Bilder wenn möglich von derselben Origin wie das HTML aus, um die Verbindung wiederzuverwenden.

Hohe Resource load duration

• Liefern Sie das Bild in der angezeigten Größe aus, mit srcset und sizes, damit Smartphones kein Desktop-Bild laden.
• Nutzen Sie moderne Formate wie AVIF oder WebP und komprimieren Sie sauber.
• Verwenden Sie ein Bild-CDN, das automatisch skaliert und konvertiert.
• Reduzieren Sie andere Downloads mit hoher Priorität, die gleichzeitig um Bandbreite konkurrieren.

Hohe Element render delay

Das Bild ist angekommen, aber etwas hindert den Browser am Zeichnen:

• Renderblockierendes CSS: reduzieren, unkritische Styles zurückstellen, nur sehr kleines kritisches CSS inline einbinden.
• Synchrone Skripte im <head>: async oder defer ergänzen.
• Client-Side Rendering: Erscheint der Seiteninhalt erst, nachdem ein JavaScript-Framework läuft, bevorzugen Sie Server-Side Rendering oder Prerendering.
• A/B-Test- oder Personalisierungsskripte, die die Seite verbergen, bis sie entschieden haben, welche Variante gezeigt wird.
• Lange JavaScript-Tasks, die genau dann laufen, wenn das Bild bereit ist.

Ist der LCP ein Textblock statt eines Bildes, sind Resource load delay und duration null, und das Problem liegt bei TTFB, renderblockierenden Ressourcen oder Webfonts.

Schritt 3: INP über die drei Phasen verbessern

INP erfasst Klicks, Taps und Tastenanschläge während des gesamten Besuchs (nicht Scrollen oder Hovern) und meldet die langsamste Interaktion, wobei pro 50 Interaktionen ein Ausreißer ignoriert wird (INP auf web.dev). Jede Interaktion hat drei Phasen:

Das zugrunde liegende Problem sind fast immer Long Tasks: jede Aufgabe, die auf dem Main Thread länger als 50 Millisekunden dauert. Solange ein Long Task läuft, kann der Browser nicht auf den Nutzer reagieren.

Input delay reduzieren

• Laden Sie beim Start weniger JavaScript; die Skriptauswertung erzeugt Long Tasks genau dann, wenn Nutzer zum ersten Mal tippen.
• Prüfen Sie Ihren Tag Manager. Web.dev merkt an, dass „ältere Tags mit ungenutztem Code entfernt werden können“. Chat-Widgets, Heatmaps, A/B-Tests und Werbeskripte verursachen oft viel Last auf dem Main Thread.
• Nutzen Sie das Coverage-Tool von Chrome und Code Splitting, um keinen Code mehr auszuliefern, den die Seite nicht verwendet.

Processing duration reduzieren

• Tun Sie im Event-Handler weniger. Aktualisieren Sie zuerst, was der Nutzer sehen muss, und verschieben Sie den Rest (Analytics-Aufrufe, Zustand speichern, Empfehlungen neu berechnen).
• Geben Sie den Main Thread zwischen Arbeitsschritten frei (Yielding). await scheduler.yield() setzt die restliche Arbeit in einem neuen, priorisierten Task fort. Es wird nicht von jedem Browser unterstützt, daher empfiehlt web.dev einen Fallback auf setTimeout in einem Promise (Optimize long tasks).
• Vermeiden Sie Layout Thrashing: Wer Layoutwerte (etwa offsetHeight) direkt nach einer Style-Änderung im selben Task liest, zwingt den Browser zur synchronen Layoutberechnung. Bündeln Sie Lese- und Schreibzugriffe.

Presentation delay reduzieren

• Halten Sie das DOM klein. Optimize INP erklärt, dass der Rendering-Aufwand mit der DOM-Größe wächst.
• Nutzen Sie content-visibility, um das Rendern von Bereichen außerhalb des Bildschirms zu überspringen, etwa lange Bewertungslisten oder Footer.
• Vermeiden Sie es, als Reaktion auf einen Klick große HTML-Blöcke per JavaScript zu rendern; rendern Sie nur, was nötig ist.

Um die langsame Interaktion zu finden, schauen Sie zuerst auf die Nutzerdaten (welche Seiten durchfallen) und reproduzieren Sie das Problem dann in den Chrome DevTools: Zeichnen Sie einen Performance-Trace auf, während Sie bei gedrosselter CPU auf das verdächtige Element klicken, und suchen Sie nach Long Tasks nach dem Klick.

Schritt 4: CLS Ursache für Ursache beheben

CLS summiert unerwartete Layoutverschiebungen. Jede Verschiebung erhält einen Wert aus dem Anteil des verschobenen Viewports multipliziert mit der Verschiebungsdistanz, Verschiebungen werden in Fenstern von bis zu fünf Sekunden gruppiert, und der CLS ist das schlechteste Fenster (CLS auf web.dev). Verschiebungen innerhalb von 500 ms nach einem Klick, Tap oder Tastenanschlag werden ausgeschlossen, weil der Nutzer sie erwartet. Scrollen zählt nicht als Eingabe, daher zählen Inhalte, die sich beim Scrollen verschieben, weiterhin.

Laut Optimize CLS sind das die üblichen Ursachen und Lösungen:

Zwei Hinweise aus der Praxis:

• Auch schrumpfender Platz verursacht Verschiebungen. Web.dev warnt, dass das Entfernen reservierten Platzes „genauso viel CLS verursachen kann wie das Einfügen von Inhalten“. Bleibt ein Werbeplatz leer, behalten Sie den Platzhalter.
• Cookie-Banner und Promo-Leisten sind häufige Übeltäter. Legen Sie sie als Overlay über den Inhalt, statt die Seite nach unten zu schieben.

Den Back/Forward-Cache nicht vergessen

Drücken Nutzer „Zurück“, erscheint eine aus dem bfcache wiederhergestellte Seite sofort, ohne neue Ladeverschiebungen. Web.dev bezeichnet die bfcache-Tauglichkeit als sehr wirksame Technik, um den CLS niedrig zu halten. Die zwei häufigsten Blocker laut bfcache-Leitfaden von web.dev: unload-Event-Listener (stattdessen pagehide verwenden) und der Header Cache-Control: no-store auf Seiten ohne sensible Daten. Die Chrome DevTools bieten dafür einen Test unter Application › Back/forward cache.

Ein Praxisbeispiel (hypothetische Zahlen)

Das Folgende ist ein hypothetisches Beispiel, keine echten Daten. Fernwood Home, ein erfundener Online-Möbelshop, besteht die Core-Web-Vitals-Bewertung mobil für das Produktseiten-Template nicht. Die Feldwerte am 75. Perzentil:

LCP: 4,6 s

Ein DevTools-Trace mit gedrosseltem Smartphone-Profil zeigt, dass das LCP-Element das Hauptproduktfoto ist. Die Aufschlüsselung:

Die Resource load delay liegt mehr als dreimal über ihrem Zielanteil, also kommt sie zuerst. Die Maßnahmen: das erste Foto als schlichtes <img> im Server-HTML ausgeben, loading="lazy" entfernen, fetchpriority="high" hinzufügen, AVIF und WebP in Smartphone-Größen über srcset ausliefern, das HTML am CDN cachen und Tracking-Parameter im Cache-Key ignorieren und das A/B-Skript mit defer laden.

Laborergebnis nach dem Release: TTFB 0,7 s, Load delay 0,2 s, Load duration 0,6 s, Render delay 0,3 s, also ein LCP von 1,8 s.

INP: 340 ms

Die Felddaten weisen auf die Produktseite; bei der Reproduktion in den DevTools ist die langsame Interaktion der Button „In den Warenkorb“. Der Trace zeigt rund 90 ms Input delay (ein Chat-Widget und zwei Tracking-Tags laufen gleichzeitig), 190 ms Verarbeitung (der Handler rendert die gesamte Warenkorb-Schublade neu und sendet synchron drei Analytics-Aufrufe) und 60 ms Presentation delay.

Die Maßnahmen: das Chat-Widget erst nach der ersten Nutzerinteraktion laden, zuerst die Aktualisierung der Warenkorb-Schublade zeigen und dann vor Analytics und Empfehlungs-Updates den Main Thread freigeben. Labormessung mit demselben gedrosselten Profil: etwa 150 ms.

CLS: 0,21

Drei Ursachen: ein Bewertungssterne-Widget, das nach dem Laden oberhalb des Preises eingefügt wird, ein Webfont-Wechsel, der den Produkttitel umbricht, und Vorschaubilder ohne Abmessungen. Die Maßnahmen: die Höhe des Bewertungs-Widgets reservieren, die Titelschrift vorladen und die Fallback-Schrift mit size-adjust anpassen, allen Vorschaubildern width und height geben. Labor-CLS: 0,04.

Das Ergebnis richtig lesen

Die Laborwerte bestätigen, dass die Fixes funktionieren. Die Feldwerte, die über die Bewertung entscheiden, ändern sich, indem neue Besuche im 28-Tage-Fenster alte ersetzen. Fernwood sollte über etwa vier Wochen mit einer schrittweisen Veränderung rechnen und dann im Bericht der Search Console auf „Tracking starten“ klicken, um die Validierung zu beginnen, die ebenfalls 28 Tage läuft. Landet der Feld-LCP zum Beispiel bei 2,3 s statt bei 1,8 s, ist das normal: Echte Smartphones und Netzwerke sind langsamer als jedes Laborprofil.

Häufige Fehler

• Dem Lighthouse-Score hinterherjagen. Der Score von 0 bis 100 ist eine Laborzusammenfassung. Googles Bewertung nutzt Felddaten am 75. Perzentil.
• Nur auf dem Desktop testen. Mobil wird getrennt bewertet und fällt meist zuerst durch.
• Alles per Lazy Loading laden. Lazy Loading für Bilder unterhalb des sichtbaren Bereichs ist gut; das Hero-Bild per Lazy Loading zu laden, ist eine der häufigsten Ursachen für schlechten LCP.
• Nur die Startseite optimieren. Der meiste Traffic landet oft auf Produkt-, Kategorie- oder Artikel-Templates. Beheben Sie die Templates mit den meisten durchfallenden URLs.
• Noch ein Skript hinzufügen. Jedes Tag, Widget und Testskript konkurriert um den Main Thread. Entfernen Sie für jedes neue eines.
• Sofortige Ergebnisse erwarten. Felddaten brauchen etwa 28 Tage, um ein Release vollständig abzubilden.
• Mobile Grundlagen ignorieren. Eine Seite ohne Viewport-Tag oder mit überdimensionierten Bildern ist auf Smartphones langsam, noch bevor irgendeine Optimierung greift. Der kostenlose Mobile-Friendly-Test prüft diese Grundlagen.

Checkliste für die erste Stunde

1. Prüfen Sie Ihre Domain mit dem kostenlosen Core Web Vitals Checker auf reale LCP-, INP- und CLS-Werte auf Smartphones sowie Serverantwortzeit, Komprimierung und blockierende Skripte.
2. Öffnen Sie den Core-Web-Vitals-Bericht der Search Console für Mobilgeräte und listen Sie die durchfallenden URL-Gruppen auf.
3. Testen Sie pro durchfallender Gruppe eine URL in PageSpeed Insights und notieren Sie, welche Metrik in den Felddaten durchfällt.
4. Zeichnen Sie für den LCP einen DevTools-Trace auf und notieren Sie die vier Teilbereiche. Beheben Sie zuerst den größten.
5. Finden Sie für den INP die langsame Interaktion und die Long Tasks danach.
6. Prüfen Sie für den CLS Bilder ohne Abmessungen, spät eingefügte Inhalte und Fonts.
7. Veröffentlichen, im Labor bestätigen und die Felddaten nach zwei und nach vier Wochen prüfen.

Core Web Vitals sind nur ein Teil der technischen Gesundheit einer Website. Unser Leitfaden zum technischen SEO-Audit ordnet sie in den Kontext von Crawling, Indexierung, Weiterleitungen und strukturierten Daten ein.

So unterstützt Searvia bei den Core Web Vitals

Der kostenlose Core Web Vitals Checker braucht kein Konto und zeigt Ihnen in unter einer Minute das Bild echter Nutzer für Ihre Website. In Searvia führt der Tab Page speed eines Website-Projekts jede Woche PageSpeed Insights für Ihre meistbesuchten Seiten aus und zeigt sowohl Laborwerte als auch echte Chrome-Nutzerdaten der letzten 28 Tage für LCP, INP und CLS. Die Fixes sind nach der eingesparten Zeit sortiert, und Write a fix plan for my files with AI macht aus den wichtigsten Punkten schrittweise Änderungen für Ihren Stack (3 Credits). Verbinden Sie die Search Console, um Klicks und Positionen neben der Ladegeschwindigkeit zu sehen und zu erkennen, ob ein schnelleres Template tatsächlich mehr Traffic gebracht hat. Die Hilfe zur Seitengeschwindigkeit erklärt die Einrichtung in etwa zwei Minuten.