CORE WEB VITALS 2026: WAS JEDE METRIK BEEINFLUSST UND WIE DU SIE LÖST

Was sind Core Web Vitals überhaupt?

Core Web Vitals (CWV) sind ein Set aus drei Kennzahlen, mit denen Google die tatsächliche Nutzererfahrung auf einer Webseite misst. Nicht die reine Ladezeit auf dem Papier, sondern wie sich eine Seite für echte Besucher anfühlt: Wie schnell erscheint der Inhalt, wie flott reagiert die Seite auf Klicks, und wie stabil bleibt das Layout beim Laden.

Die drei Metriken sind:

• Largest Contentful Paint (LCP): misst die Ladegeschwindigkeit
• Interaction to Next Paint (INP): misst die Reaktionsfähigkeit
• Cumulative Layout Shift (CLS): misst die visuelle Stabilität

Seit 2021 sind die Core Web Vitals ein bestätigter Ranking-Faktor bei Google und Teil des sogenannten Page-Experience-Signals. Das heißt nicht, dass sie über allem stehen. Guter Content bleibt der wichtigste Hebel. Aber bei zwei inhaltlich ähnlich starken Seiten geben die Core Web Vitals oft den Ausschlag.

Man kann sie sich als Türsteher vorstellen: Sie machen guten Content nicht besser, aber schlechte Werte können verhindern, dass guter Content sein volles Potenzial erreicht.

Feld- statt Labordaten: der Punkt, den viele übersehen

Ein Detail, das gern untergeht: Google bewertet die Core Web Vitals mit Felddaten, nicht mit Labordaten.

• Labordaten entstehen in einer künstlichen Testumgebung, etwa wenn du eine Seite einmalig durch ein Tool wie Lighthouse jagst. Praktisch zum Debuggen, aber eine Momentaufnahme unter idealen Bedingungen.
• Felddaten stammen von echten Nutzern mit echten Geräten und echten Verbindungen. Google sammelt sie anonymisiert aus dem Chrome-Browser.

Für das Ranking zählen die Felddaten. Und die werden über die jeweils letzten 28 Tage erhoben. Das hat eine praktische Konsequenz: Wenn du heute einen Fix ausspielst, siehst du das Ergebnis nicht am selben Nachmittag. Es dauert, bis genug reale Besuche eingeflossen sind. Wer nach einem einzigen PageSpeed-Test in Panik Plugins rausreißt, optimiert oft gegen ein Laborergebnis, das die Nutzer nie so gespürt haben.

Was bedeutet das 75. Perzentil?

Noch ein Begriff, der ständig auftaucht: Google bewertet jede Metrik am 75. Perzentil. Das klingt sperriger, als es ist. Es bedeutet schlicht: 75 Prozent deiner Besuche müssen im „guten“ Bereich liegen, damit die Seite als bestanden gilt. Nicht der Durchschnitt, nicht dein Bestwert auf dem schnellen Bürorechner. Es zählt die Erfahrung der breiten Masse, inklusive der Leute auf dem drei Jahre alten Android-Handy im ICE.

Warum ausgerechnet 75 Prozent? Google erklärt die Wahl in seiner Dokumentation zu den Grenzwerten als bewussten Kompromiss zwischen zwei Zielen: Einerseits soll die große Mehrheit der Besuche den Zielwert erreichen, andererseits soll die Bewertung nicht von einzelnen Ausreißern gekippt werden.

Ein höheres Perzentil wie das 95. wäre anfälliger dafür. Bei 100 Besuchen würden dort schon fünf Ausreißer (etwa über eine kaputte Mobilverbindung) den Wert verzerren. Beim 75. Perzentil müssten dagegen 25 von 100 Besuchen aus dem Rahmen fallen, damit sich das Ergebnis verschiebt. Das ist deutlich robuster, und gleichzeitig weißt du: Drei von vier Besuchern erleben mindestens die gemessene Leistung.

Und alle drei Metriken müssen gleichzeitig bestehen. Zwei grüne Werte nützen wenig, wenn der dritte im roten Bereich hängt. Das ist auch der häufigste Grund, warum Seiten scheitern: Eine einzige schwache Metrik zieht zwei starke mit runter.

Die aktuellen Schwellenwerte im Überblick

Bevor wir in die Details gehen, die Zahlen auf einen Blick. Das sind die offiziellen Grenzwerte laut Google-Dokumentation (Stand: aktuelle Search-Central- und web.dev-Dokumentation):

Largest Contentful Paint (LCP): Warum lädt meine Seite gefühlt so lahm?

Largest Contentful Paint (LCP) misst, wie lange es dauert, bis das größte sichtbare Element im Viewport geladen ist. Meistens ist das ein großes Hero-Bild, ein Video-Thumbnail oder ein prominenter Textblock. Der LCP markiert also den Moment, in dem der Nutzer das Gefühl bekommt: Aha, jetzt ist die Seite da.

Der Zielwert liegt bei unter 2,5 Sekunden.

Was beeinflusst den LCP?

LCP-Probleme haben fast immer mit Ressourcen und Serverzeiten zu tun. Die üblichen Verdächtigen:

• Langsame Serverantwort (hoher TTFB). Wenn dein Server schon Sekunden braucht, bis überhaupt das erste Byte ankommt, kann der Rest noch so optimiert sein.
• Große, unkomprimierte Bilder. Ein 3-MB-Hero-Bild ist ein Klassiker. Es muss erst runtergeladen werden, bevor es gerendert werden kann.
• Render-blockierende Ressourcen. CSS- und JavaScript-Dateien, die der Browser erst vollständig verarbeiten muss, bevor er etwas anzeigt.
• Kein Preloading der wichtigen Ressource. Der Browser entdeckt das Hero-Bild spät, weil es tief im HTML oder in einem CSS-Hintergrund versteckt ist.
• Client-seitiges Rendering. Bei JavaScript-lastigen Setups muss erst der ganze Code laufen, bevor überhaupt Inhalt erscheint.

Ein konkretes Beispiel

Nimm einen typischen Online-Shop mit einem fetten Produktbild oben. Das Bild kommt unkomprimiert im alten JPEG-Format, 2,8 MB schwer, und der Browser findet es erst, nachdem er das halbe HTML durchgearbeitet hat. Ergebnis: LCP bei 5,2 Sekunden. Tiefrot.

Die Lösung für einen schlechten LCP

• Serverzeit verbessern. Besseres Hosting, sinnvolles Caching und ein CDN (Content Delivery Network, ein Netz aus verteilten Servern, das Inhalte geografisch näher am Nutzer ausliefert). Der TTFB sollte idealerweise unter 200 Millisekunden liegen.
• Die wichtigste Ressource vorladen. Das Hero-Bild explizit priorisieren, damit der Browser es sofort holt:

<link rel="preload" href="/hero.webp" as="image" type="image/webp" fetchpriority="high">

• Moderne Bildformate nutzen. WebP oder AVIF statt JPEG oder PNG. Das spart oft 30 bis 70 Prozent Dateigröße bei gleicher Optik. Dazu die Bilder korrekt dimensionieren und responsive ausliefern (srcset).
• Render-Blocker auflösen. Kritisches CSS inline in den Head, alles andere asynchron nachladen. Nicht kritisches JavaScript mit defer oder async laden.
• Resource Hints setzen. Verbindungen zu wichtigen Fremd-Domains früh anbahnen, damit der Browser nicht erst spät den Handshake startet:

<link rel="preconnect" href="https://cdn.example.com">
<link rel="dns-prefetch" href="https://cdn.example.com">

• Serverseitige Basics prüfen. Komprimierung mit Brotli oder Gzip aktivieren und moderne Protokolle wie HTTP/2 oder HTTP/3 nutzen. Das reduziert Übertragungszeiten spürbar, oft ohne eine einzige Zeile am Frontend zu ändern.
• Server-Side Rendering erwägen, wenn eine JavaScript-lastige Seite ihren Content sonst erst spät ausgibt.

Wenn man diese Punkte durchzieht, sind aus 5,2 Sekunden schnell mal 1,8 Sekunden. Der Unterschied ist nicht nur eine grüne Zahl, sondern spürbar für jeden, der die Seite öffnet.

Woraus setzt sich der LCP eigentlich zusammen?

Wenn du den LCP gezielt fixen willst, hilft es zu wissen, dass er aus vier aufeinanderfolgenden Phasen besteht. Jede ist ein eigener Hebel:

1. Time to First Byte (TTFB): die Zeit, bis der Server das erste Byte schickt. Hebel: Hosting, Caching, CDN.
2. Resource Load Delay: die Verzögerung, bis der Browser überhaupt anfängt, die LCP-Ressource zu laden. Hebel: Preload und fetchpriority, damit das Bild früh entdeckt wird.
3. Resource Load Duration: wie lange das Laden der Ressource selbst dauert. Hebel: kleinere Dateien, moderne Formate, CDN.
4. Element Render Delay: die Zeit zwischen fertigem Laden und tatsächlichem Anzeigen. Hebel: Render-Blocker beseitigen, damit der Browser nicht wartet.

Der Trick: Miss zuerst, welche der vier Phasen bei dir am längsten ist, und setz genau dort an. Sonst optimierst du am Symptom vorbei.

Interaction to Next Paint (INP): Warum reagiert meine Seite so träge?

Interaction to Next Paint (INP) misst, wie schnell eine Seite auf Interaktionen reagiert: Klicks, Taps, Tastatureingaben. Genauer gesagt die Zeit zwischen der Aktion des Nutzers und dem Moment, in dem der Browser die nächste sichtbare Reaktion zeichnen kann. INP schaut sich dabei alle Interaktionen während des gesamten Besuchs an und meldet die langsamste (bzw. eine hohe Perzentile davon).

Der Zielwert liegt bei unter 200 Millisekunden.

Kurzer Rückblick: INP hat FID abgelöst

Bis März 2024 hieß die Metrik für Reaktionsfähigkeit First Input Delay (FID). FID hat nur die Verzögerung bei der allerersten Interaktion gemessen. Das Problem: Der erste Klick sagt wenig darüber aus, wie sich die Seite über den ganzen Besuch anfühlt. INP misst deshalb das komplette Interaktionsverhalten und ist damit ehrlicher, aber auch deutlich schwerer zu bestehen.

Verschiedenen Auswertungen zufolge ist INP inzwischen die am häufigsten gerissene Core-Web-Vitals-Metrik.

Was beeinflusst den INP?

INP ist die Metrik, bei der es an die JavaScript-Architektur geht. Compression und Attribute helfen hier nicht, es geht darum, wie dein Code mit Interaktionen umgeht:

• Schweres JavaScript auf dem Main Thread. Jede JavaScript-Aufgabe, die länger als 50 Millisekunden läuft, blockiert den Hauptprozess. Solange sie läuft, kann der Browser nicht auf Klicks reagieren.
• Teure Event-Handler. Aufwändige Berechnungen, die bei jedem Klick oder Scroll ausgelöst werden.
• Third-Party-Skripte. Chat-Widgets, Analytics, Tag-Manager, Werbe-Skripte. Alles, was fremder Code auf dem Main Thread anstellt, geht auf deine INP-Rechnung.
• Ein riesiges DOM. Je mehr Elemente die Seite hat, desto länger dauert jede Neuberechnung.
• Unnötige Re-Renders, gerade bei React, Vue und Co., wenn Komponenten öfter neu rendern als nötig.

Ein konkretes Beispiel

Ein Klick auf den Warenkorb-Button löst im Hintergrund eine schwere, ungeteilte JavaScript-Funktion aus. Die läuft 600 Millisekunden am Stück, blockiert dabei den Main Thread, und der Nutzer starrt eine gefühlte Ewigkeit auf einen Button, der einfach nichts tut. INP: tiefrot.

Die Lösung für einen schlechten INP

• Lange Aufgaben aufbrechen. Große Tasks in kleine Häppchen zerlegen und dem Browser zwischendurch Luft geben. Modern geht das mit scheduler.yield(), als Fallback mit setTimeout oder requestIdleCallback.
• Code-Splitting einsetzen. JavaScript in Chunks aufteilen, die nur bei Bedarf geladen werden, statt alles auf einmal auszuliefern.
• Nicht kritische Skripte mit defer oder async laden, damit sie das Rendering nicht blockieren.
• Das DOM verschlanken und unnötige Re-Renders vermeiden.
• Third-Party-Skripte kritisch prüfen. Braucht es wirklich fünf Tracking-Tools? Vieles lässt sich später oder bei Bedarf laden.

Cumulative Layout Shift (CLS): Warum springt meine Seite beim Laden herum?

Cumulative Layout Shift (CLS) misst, wie sehr sich das Layout einer Seite während des Ladens unerwartet verschiebt. Kennst du das? Du willst auf einen Link tippen, im letzten Moment lädt ein Banner nach, alles rutscht nach unten, und du landest auf dem falschen Element. Genau das erfasst CLS.

Der Wert ist keine Zeit, sondern eine Punktzahl. Sie ergibt sich aus dem Anteil des Viewports, der sich verschiebt, multipliziert mit der Distanz der Verschiebung. Der Zielwert liegt bei unter 0,1.

Was beeinflusst den CLS?

CLS-Probleme drehen sich fast immer um fehlende reservierte Plätze. Der Browser weiß nicht, wie viel Raum ein Element brauchen wird, und muss nachträglich umbauen:

• Bilder, Videos oder iframes ohne feste Maße. Ohne Höhen- und Breitenangabe reserviert der Browser keinen Platz und schiebt alles zur Seite, sobald das Element geladen ist.
• Werbung und Embeds, die dynamisch nachgeladen werden und ihren Platz erst beim Erscheinen einnehmen.
• Dynamisch eingefügter Content, etwa Cookie-Banner, Hinweise oder Nachrichten, die sich über bestehenden Inhalt schieben.
• Web-Fonts. Lädt eine Schrift nach und ersetzt eine Ersatzschrift mit anderen Maßen, verschiebt sich der Text (FOUT/FOIT).
• Layout-auslösende Animationen, die Elemente über Eigenschaften wie top oder height bewegen statt über transform.

Ein konkretes Beispiel

Eine Produktkategorie-Seite lädt eine Reihe Bilder ohne width und height. Der Text steht erst sauber da, dann ploppen nacheinander die Bilder rein und schieben die ganze Liste ruckelnd nach unten. Wer in dem Moment auf ein Produkt tippen wollte, klickt daneben. CLS: rot.

Die Lösung für einen schlechten CLS

• Feste Maße für alle Medien setzen. Jedem Bild, Video und iframe explizit width und height mitgeben oder über CSS aspect-ratio arbeiten. Dann reserviert der Browser den Platz von Anfang an:

<img src="/produkt.webp" width="800" height="600" alt="Produktfoto">

• Platz für Werbung und Embeds reservieren. Für jeden Anzeigenslot einen Container mit fester Mindesthöhe vorhalten, damit nichts springt, wenn die Anzeige lädt.
• Kein Content oberhalb von bestehendem Inhalt einfügen. Banner und Hinweise lieber überlagernd (z. B. als Overlay) einblenden, statt bestehende Elemente nach unten zu drücken.
• Web-Fonts entschärfen. Schriften vorladen, font-display sinnvoll setzen und mit size-adjust dafür sorgen, dass Ersatz- und Zielschrift ähnliche Maße haben.
• Für Animationen transform nutzen statt Eigenschaften, die das Layout neu berechnen.

Der Charme an CLS: Von den drei Metriken ist sie oft am schnellsten zu fixen. Feste Maße und reservierter Platz, das war es bei vielen Seiten schon zu großen Teilen.

Lohnt sich Lazy Loading für die Core Web Vitals?

Lazy Loading bezeichnet die Technik, Ressourcen erst dann zu laden, wenn sie wirklich gebraucht werden, also typischerweise erst, wenn der Nutzer sie durch Scrollen in Sichtweite bringt. Statt beim ersten Aufruf alle 40 Bilder einer langen Seite herunterzuladen, holt der Browser zunächst nur, was im sichtbaren Bereich liegt. Nativ geht das seit Jahren ganz ohne JavaScript:

<img src="/produkt.webp" width="800" height="600" loading="lazy" alt="Produktfoto">

Klingt nach einem reinen Gewinn, ist es aber nicht. Lazy Loading kann deine Core Web Vitals verbessern oder verschlechtern, je nachdem, wie du es einsetzt. Deshalb lohnt sich ein genauerer Blick.

Wann hilft Lazy Loading?

• Below the Fold. Bilder, Videos und iframes, die erst nach dem Scrollen sichtbar werden, müssen nicht sofort geladen werden. Das spart Bandbreite und reduziert die Konkurrenz um Netzwerk und Rechenzeit beim ersten Rendern.

Wo Lazy Loading zur Falle wird

Und jetzt der Punkt, den viele übersehen: Lade niemals das LCP-Element oder Bilder above the fold lazy. Wenn du ausgerechnet dein Hero-Bild mit loading="lazy" versiehst, zwingst du den Browser zu warten, bis er weiß, dass es sichtbar ist, bevor er es holt. Genau das größte Element, auf das dein LCP wartet, wird dadurch künstlich verzögert. Das ist einer der häufigsten selbstgemachten LCP-Killer.

Die Faustregel:

• Above the Fold (der sofort sichtbare Bereich): ganz normal laden, das LCP-Bild zusätzlich per Preload und fetchpriority="high" priorisieren.
• Below the Fold: loading="lazy" einsetzen.

Und noch ein Zusammenhang zu CLS: Auch lazy geladene Bilder brauchen width und height (oder aspect-ratio). Sonst reserviert der Browser keinen Platz, und beim Nachladen springt das Layout genau dann, wenn der Nutzer schon dort scrollt. Lazy Loading ohne feste Maße tauscht also ein LCP-Problem gegen ein CLS-Problem. Beides zusammen gedacht, wird ein Schuh draus.

Welche Hilfsmetriken solltest du kennen?

Die drei Core Web Vitals sind das, was zählt. Aber beim Debuggen stößt du auf weitere Kennzahlen, die keine Core Web Vitals sind und trotzdem enorm nützlich, weil sie zeigen, warum eine Metrik schwächelt:

• Time to First Byte (TTFB): Zeit bis zum ersten Byte vom Server. Frühindikator für LCP-Probleme. Gut ist unter 200 ms, kritisch ab etwa 500 bis 600 ms.
• First Contentful Paint (FCP): Zeitpunkt, an dem der erste Inhalt überhaupt erscheint (Text, Bild, irgendwas). Ein schlechter FCP zieht fast immer einen schlechten LCP nach sich.
• Total Blocking Time (TBT): die im Labor gemessene Zeit, in der der Main Thread blockiert war. TBT ist der beste Labor-Stellvertreter für INP, denn INP selbst lässt sich ohne echte Interaktionen im Labor kaum messen.
• Speed Index: wie schnell sich der sichtbare Bereich visuell füllt.

Wichtig zur Einordnung: Diese Metriken tauchen in Lighthouse und PageSpeed Insights auf, fließen aber nicht direkt ins Ranking ein. Sie sind Diagnosewerkzeuge, keine Bewertungskriterien. Behandle sie als Wegweiser zur Ursache, nicht als Selbstzweck.

Warum unterscheidet Google zwischen mobil und Desktop?

Ein Detail, das gern zu bösen Überraschungen führt: Google bewertet die Core Web Vitals getrennt für mobile und Desktop-Geräte. In der Praxis ist die mobile Wertung fast immer der Flaschenhals. Handys haben schwächere Prozessoren, langsamere Verbindungen und kleinere Bildschirme, auf denen JavaScript-Last stärker durchschlägt.

Was auf deinem MacBook mit Glasfaser blitzschnell wirkt, kann sich auf einem drei Jahre alten Mittelklasse-Android zäh anfühlen. Genau diese Nutzer will Google abbilden. Deshalb: Optimiere und teste immer zuerst mobil. Wer nur die Desktop-Werte im Blick hat, wundert sich später, warum die Search Console trotzdem meckert.

Wie messe ich meine Core Web Vitals?

Fixen kannst du nur, was du misst. Zum Glück gibt es dafür ein solides Set an kostenlosen Werkzeugen. Sinnvoll ist eine Kombination aus Feld- und Labordaten:

1. Google Search Console, Bericht „Core Web Vitals“. Der Startpunkt. Zeigt auf Basis echter Felddaten, welche URLs oder URL-Gruppen Probleme haben. Hier siehst du das Gesamtbild deiner Domain.
2. PageSpeed Insights. Kombiniert Feld- und Labordaten für einzelne URLs und liefert konkrete Verbesserungsvorschläge. Einfach die URL eingeben und „Analysieren“ klicken. Ideal, um eine auffällige Seite genauer anzusehen.
3. Chrome DevTools (Tabs „Performance“ und „Lighthouse“). Die Developer Tools direkt im Browser, zum lokalen Debuggen. Hier findest du render-blockierende Ressourcen und lange JavaScript-Tasks über 50 Millisekunden, die deinen INP killen. Der große Vorteil gegenüber PageSpeed Insights: Du kannst damit auch lokale Seiten und Bereiche hinter einem Login testen.

Ein pragmatischer Ablauf: Search Console öffnen, die „schlechten“ Seiten identifizieren, die Top-Seiten durch PageSpeed Insights schicken, Feld- und Labordaten vergleichen, dann mit DevTools ins Detail gehen. Nach jeder Änderung erneut testen, aber Geduld haben, bis die Felddaten nachziehen.

Wie liest du mit Claude im Terminal konkrete Schwachstellen aus?

PageSpeed Insights sagt dir zwar, was im Argen liegt („nicht genutztes JavaScript entfernen“, „Bilder in modernen Formaten ausliefern“). Aber die Befunde bleiben oft allgemein und unsortiert, und du musst selbst herausfiltern, was davon bei dir wirklich zählt. Genau da hilft es, sich die Analyse von Claude auslesen und einordnen zu lassen.

Was ist der Chrome DevTools MCP?

Google hat im September 2025 den Chrome DevTools MCP veröffentlicht. MCP steht für Model Context Protocol, einen offenen Standard, über den KI-Assistenten mit externen Werkzeugen und Datenquellen sprechen können. Der Chrome DevTools MCP ist ein solcher Baustein: Er gibt einem KI-Coding-Agenten wie Claude Code (Claude im Terminal) direkten Zugriff auf einen echten, laufenden Chrome-Browser.

Claude kann darüber eine Seite öffnen, eine echte Performance-Aufzeichnung erstellen, Netzwerkanfragen und Konsole inspizieren und, ganz wichtig, dieselbe Art von Analyse fahren wie Lighthouse und PageSpeed Insights, inklusive einer LCP-Aufschlüsselung und echten Felddaten.

Der Mehrwert gegenüber dem reinen PageSpeed-Report: Claude liest dir die Analyse in Klartext aus und ordnet sie ein. Statt „optimiere deine Bilder“ bekommst du konkret genannt, welches Element den LCP bremst, welcher Task den INP blockiert und welche Maßnahme am meisten bringt. Du bekommst also nicht nur eine Liste von Symptomen, sondern eine verständliche, priorisierte Einordnung, wo du ansetzen solltest.

Zwei Wege, das zu nutzen

• Ergebnisse einsprechen. Du kopierst die konkreten Befunde aus PageSpeed Insights ins Terminal und lässt Claude daraus eine priorisierte To-do-Liste machen: Was bringt am meisten, was ist schnell erledigt, wo liegt der größte Hebel?
• Selbst messen lassen. Du gibst Claude einfach die URL, der MCP erstellt eine eigene Aufzeichnung, und Claude meldet die tatsächlichen Engpässe aus erster Hand zurück, statt sich auf einen fremden Report zu verlassen.

So richtest du es ein

Zwei Zutaten brauchst du: eine aktuelle Node.js-Version (22 oder neuer) und einen aktuellen Chrome. Dann installierst du das offizielle Plugin, das den MCP-Server plus passende Skills mitbringt:

claude plugin marketplace add ChromeDevTools/chrome-devtools-mcp
claude plugin install chrome-devtools-mcp

Alternativ, etwas schlanker, nur den Server hinzufügen:

claude mcp add chrome-devtools npx chrome-devtools-mcp@latest

Danach reicht ein Prompt in natürlicher Sprache, zum Beispiel:

„Nutze den Chrome MCP. Prüfe die Core Web Vitals von https://meine-seite.de, schlüssle den LCP auf und schlag mir konkrete Verbesserungen vor.“

Claude öffnet daraufhin die Seite, erstellt eine Aufzeichnung und kommt mit belastbaren Vorschlägen zurück, etwa nicht kritisches JavaScript aufzuschieben oder ein bestimmtes Bild zu optimieren, um den LCP zu senken.

Die offizielle Anleitung findest du in der Chrome-Dokumentation für Agents und auf der Plugin-Seite von Anthropic.

Welche Metrik zuerst? So priorisierst du richtig

Wenn alle drei Werte gleichzeitig zählen, aber die Zeit knapp ist: Womit anfangen?

Die Antwort ist fast immer: Fixe die schwächste Metrik zuerst. Genau die eine Zahl, die dich unter die Bestehensgrenze zieht, bringt am meisten. Es lohnt sich selten, einen schon grünen LCP von 2,3 auf 1,9 Sekunden zu drücken, wenn gleichzeitig der INP bei 400 Millisekunden im roten Bereich hängt.

Welche Maßnahmen pro Metrik am meisten bringen, hat das Chrome-Team in einer eigenen Übersicht zusammengestellt: Die effektivsten Wege zur Verbesserung der Core Web Vitals. Eine gute Orientierung, wenn du nicht weißt, wo du den größten Hebel findest.

Als grobe Orientierung, welche Seitentypen typischerweise wo scheitern:

• Blogposts und Startseiten scheitern am häufigsten am LCP, meist wegen großer Bilder.
• Produkt- und Kategorieseiten kämpfen oft mit CLS, weil dynamische Inhalte nachladen.
• Checkouts, Formulare und filterlastige Listen reißen meist den INP, weil viel JavaScript im Spiel ist.

Und ein letzter Tipp aus der Praxis: Der TTFB (Time to First Byte), also die Zeit bis zum ersten Byte vom Server, ist selbst keine Core-Web-Vitals-Metrik, aber ein guter Frühindikator. Liegt er dauerhaft über 500 bis 600 Millisekunden, ist selten dein Frontend das Problem, sondern dein Hosting oder Caching. Der TTFB ist quasi die Untergrenze für deinen LCP: Ist der Server langsam, kann der LCP gar nicht schnell sein, egal wie sauber der Rest ist.

Was tun, wenn Google keine Daten anzeigt?

Ein Problem, gegen das kleinere Seiten ständig laufen: In PageSpeed Insights oder der Search Console steht sinngemäß „nicht genügend Daten“. Der Grund ist simpel. Google zeigt Felddaten erst, wenn eine Seite genug Besucher hat, damit die Werte anonym und statistisch belastbar sind. Viele Websites erreichen diese Schwelle auf Einzelseiten-Ebene nie.

Das ist kein Grund zur Panik, sondern eine Frage der Herangehensweise:

• Origin-Level-Daten nutzen. Fehlen die Daten für eine einzelne URL, fällt Google oft auf aggregierte Werte für die gesamte Domain zurück. Die geben zumindest eine grobe Richtung.
• Auf Labordaten stützen. Ohne Felddaten werden Lighthouse und die Chrome DevTools zu deiner Hauptquelle. Sie messen zwar nur eine simulierte Momentaufnahme, zeigen aber zuverlässig konkrete Schwachstellen.

Kurz: Keine Daten heißt nicht „kein Problem“. Es heißt nur, dass du selbst messen musst, statt dich auf Googles fertigen Bericht zu verlassen.

Warum sich der Aufwand lohnt

Man könnte das alles als reine Technik-Fleißarbeit abtun. Ist es aber nicht. Bessere Core Web Vitals zahlen doppelt ein: auf die Sichtbarkeit und auf die Zahlen, die dahinter zählen.

Eine viel zitierte Faustregel aus der Performance-Forschung besagt, dass schon eine Sekunde zusätzliche Ladezeit die Conversions um rund 7 Prozent senken kann. Man muss die Zahl nicht auf die Nachkommastelle glauben, um die Richtung zu erkennen: Langsame, springende, träge Seiten kosten Nutzer, und zwar bevor sie überhaupt beim Content ankommen.

Schnelle, stabile Seiten halten Leute länger, senken die Absprungrate und verbessern damit genau die Verhaltenssignale, die Google ohnehin beobachtet.

Und es gibt einen neueren Aspekt: KI-Suchsysteme wie Google AI Overviews, ChatGPT Search oder Perplexity werden als Antwortkanäle wichtiger. Tempo spielt dabei durchaus eine Rolle, aber vor allem als Türöffner: KI-Crawler holen Seiten in Echtzeit und mit knappen Zeitfenstern, und eine schnelle Server-Antwortzeit erhöht die Chance, überhaupt abgerufen und zitiert zu werden (Übersicht bei Otterly.AI).

Ein Hebel, der dir Zitierungen verschafft, ist Geschwindigkeit dagegen nicht: Die bislang größte Auswertung von über 107.000 Seiten in Google AI Overviews findet nur einen schwachen Zusammenhang zwischen Core Web Vitals und KI-Sichtbarkeit. Zitiert wird am Ende nach klarem, gut strukturiertem und aktuellem Inhalt. Performance ist damit auch für KI-Antworten kein Ranking-Turbo, aber die Basis dafür, dass deine Inhalte überhaupt in den Auswahltopf kommen.

Offizielle Quellen und Tools

Wer tiefer einsteigen will, findet hier die relevanten Anlaufstellen direkt von Google:

• PageSpeed Insights: das kostenlose Tool zum Testen einzelner URLs (Feld- und Labordaten in einem)
• Chrome DevTools: die Developer Tools im Browser für lokales Debugging
• Lighthouse: das Audit-Werkzeug hinter den Labordaten
• Google Search Central: Core Web Vitals: die offizielle Doku zum Ranking-Zusammenhang
• web.dev: Web Vitals: die technische Referenz des Chrome-Teams zu allen Metriken
• web.dev: So wurden die Grenzwerte definiert: die Hintergründe zu den Schwellenwerten und zur Wahl des 75. Perzentils
• web.dev: Die effektivsten Wege zur Verbesserung der Core Web Vitals: vom Chrome-Team priorisierte Best Practices pro Metrik
• Chrome DevTools MCP: um Performance-Analysen direkt mit einem KI-Agenten wie Claude Code zu fahren

Am Ende ist die Sache erfreulich unspektakulär: Core Web Vitals sind kein undurchschaubares Google-Mysterium, sondern drei Fragen mit klaren Antworten. Erscheint der Inhalt schnell (LCP)? Reagiert die Seite flott (INP)? Bleibt das Layout ruhig (CLS)? Für jede dieser Fragen kennst du jetzt die typischen Ursachen und die passenden Fixes.

Mein Rat: Fang nicht mit dem Werkzeugkasten an, sondern mit einer Messung. Öffne die Search Console, finde deine schwächste Metrik, und arbeite dich von dort vor. Ein Fix nach dem anderen. Das ist deutlich entspannter, als es sich gerade anfühlt.