Core Web Vitals sind drei Messwerte, mit denen Google beschreibt, wie sich eine Webseite für echte Nutzer anfühlt: Wie schnell der Hauptinhalt erscheint, wie zügig die Seite auf Klicks reagiert und wie ruhig das Layout dabei bleibt. Dieser Leitfaden zeigt, wie Du die Werte testest, welche Schwellenwerte gelten und mit welchen Hebeln Du sie verbesserst.
Und er sagt eine Sache, die Du auf den meisten Seiten zu diesem Thema nicht lesen wirst: Wann Du aufhören solltest. Die Jagd nach dem grünen 100er-Kreis in PageSpeed Insights ist einer der teuersten Irrtümer im technischen SEO.
Unsere Position: Die 100 ist kein Ziel
Während wir diesen Artikel überarbeitet haben, haben wir die Seite selbst durch Lighthouse geschickt. Version 13.4.0, Desktop, simulierte Drosselung. Ergebnis: Performance-Score 100 von 100, Largest Contentful Paint 672 ms, Cumulative Layout Shift 0,009, Server-Antwortzeit 46 ms, Seitengewicht 273 KB.
Wir könnten diese Messwerte als Beweis unserer Kompetenz verkaufen. Ehrlicher ist: Sie sagen fast nichts aus. Der Check lief auf einem simulierten Desktop mit schnellem Netz. Google bewertet primär Mobilgeräte, und zwar mit Nutzerdaten aus dem Feld. Diese 100 ist ein Laborergebnis unter Idealbedingungen, kein Ranking-Signal.
Deshalb ist unsere Haltung klar: Wir optimieren auf grüne Werte im Feld, nicht auf einen grünen Kreis. Sobald der Chrome User Experience Report für eine Gruppe von Seiten Gut meldet, ist die Arbeit erledigt. Die letzten Punkte von 92 auf 100 kosten mehr Entwicklerzeit als alle vorherigen zusammen und bringen dem Kunden keinen zusätzlichen Auftrag.
Ein Beispiel aus einem laufenden Projekt: Eine inhaltsreiche Leistungsseite kam im Check auf 4,2 Sekunden LCP. Getestet wurde auf einem gedrosselten Moto G Power mit langsamem 4G. Das ist die härteste Bedingung, die das Tool kennt, und sie entspricht nicht der Nutzung einer Münchner Zielgruppe mit modernem Smartphone. Die Daten in der Search Console lagen deutlich besser. Wer hier in Panik verfällt, optimiert gegen ein Testgerät statt gegen seine Nutzer.
Wo verliert Deine Website Kunden?
Eine kostenfreie Einschätzung, wo Deine Website noch Potenzial hat und Kunden verliert, als PDF.
Was Core Web Vitals sind und welche Werte gelten
Core Web Vitals sind drei Kennzahlen, die Google seit Juni 2021 als Teil des Page Experience Signals nutzt. Sie messen Ladeleistung, Reaktionsfähigkeit und visuelle Stabilität von Webseiten anhand definierter Schwellenwerte aus echten Nutzerdaten.
LCP, Largest Contentful Paint, misst die Ladeleistung. Gut ist unter 2,5 Sekunden, verbesserungswürdig 2,5 bis 4 Sekunden, schlecht über 4 Sekunden.
INP, Interaction to Next Paint, misst die Reaktionsfähigkeit. Gut ist unter 200 Millisekunden, verbesserungswürdig 200 bis 500 ms, schlecht über 500 ms.
CLS, Cumulative Layout Shift, misst die visuelle Stabilität. Gut ist unter 0,1, verbesserungswürdig 0,1 bis 0,25, schlecht über 0,25.
LCP – Largest Contentful Paint
Der Largest Contentful Paint misst, wann das größte sichtbare Element im ersten Bildschirmbereich fertig gerendert ist. Meist ist das ein Hero-Bild, eine große Überschrift oder ein dominanter Textblock.
Die entscheidende Erkenntnis für die Praxis: LCP ist keine einzelne Zahl, sondern die Summe von vier Phasen. Time to First Byte, also wie lange der Server für die erste Antwort braucht. Resource Load Delay, die Lücke zwischen erster Serverantwort und dem Moment, in dem der Browser anfängt, das Element zu laden. Resource Load Duration, wie lange dieses Laden dauert. Und Element Render Delay, die Zeit zwischen fertigem Laden und tatsächlicher Darstellung.
Wer diese vier Phasen misst statt nur den Gesamtwert anzustarren, findet das Problem meist in Minuten.
Wenn das LCP-Element gar kein Bild ist
Ein Fall aus unserer Arbeit, der das Modell greifbar macht. Ein Kunde meldete einen schlechten LCP. Das Hero-Bild war bereits komprimiert, mehrfach. Passiert war nichts.
Die Messung zeigte: Der LCP-Kandidat war gar nicht das Bild, sondern der Hero-Text. Time to First Byte lag bei 0 Millisekunden, das Rendering-Delay dagegen bei 2.330 Millisekunden. Der Browser hatte das HTML längst, konnte den Text aber nicht darstellen.
Die Ursache lag im Seitenaufbau: 157 KB HTML und 1.822 DOM-Elemente bei einer Verschachtelungstiefe von 21. Google empfiehlt unter 1.400 Elemente. Der eingesetzte Page Builder erzeugt für jeden Block zwei bis drei zusätzliche Container, und die summieren sich.
Das war der unbequeme Teil unserer Antwort: Dieses Problem ist mit Plugin-Einstellungen nicht lösbar. Es ist architekturbedingt und verschwindet erst mit einem Umbau des Layouts. Wir halten es für richtig, das so zu sagen, statt weiter an Bildern zu drehen, die längst optimiert sind.
INP – Interaction to Next Paint
Interaction to Next Paint ist seit dem 12. März 2024 ein Core Web Vital und misst, wie schnell eine Seite auf Eingaben reagiert, auf alle Klicks, Taps und Tastaturinteraktionen während der gesamten Sitzung.
Der INP-Wert zerfällt in drei Teile: Input Delay, Processing Time und Presentation Delay. In der Praxis liegt das Problem fast immer im mittleren Teil.
Ein Punkt, den viele Anleitungen auslassen: In Single-Page-Anwendungen misst INP zunächst falsch, weil der Browser einen Seitenwechsel ohne echten Neuaufbau nicht als solchen erkennt. Chrome arbeitet dafür an sogenannten Soft Navigations. Wer eine React- oder Vue-Anwendung betreut, sollte wissen, dass die Messwerte dort mit Vorsicht zu lesen sind.
CLS – Cumulative Layout Shift
Der Cumulative Layout Shift bewertet, wie stark sich das Layout während des Ladens verschiebt. Ein hoher CLS-Wert bedeutet: Inhalte springen. Der Leser will auf einen Link tippen, im selben Moment lädt ein Bild nach, alles rutscht, und der Klick landet woanders.
Die Messung ist simpel, die Ursachen sind es nicht. Sie liegen meist an unerwarteten Stellen: Webfonts ohne Fallback, Bilder ohne Höhen- und Breitenangabe, nachrückende Werbeflächen, dynamisch eingeblendete Hinweisleisten.
Warum First Input Delay ersetzt wurde
First Input Delay hatte einen Konstruktionsfehler: Der Wert maß nur die Verzögerung vor der allerersten Interaktion. Wurde der erste Klick schnell verarbeitet und stockte danach alles, lieferte FID trotzdem eine gute Bewertung.
INP behebt das, indem es die gesamte Sitzung beobachtet und den schlechtesten Wert als repräsentativ nimmt. Wer einen guten First Input Delay gewohnt war, sah nach dem Wechsel oft deutlich schlechtere Werte bei unveränderter Seite. Wenn Dir irgendwo noch FID-Werte begegnen, arbeitest Du mit veralteten Daten.
Core Web Vitals testen: welches Tool wofür
Bevor Du optimierst, brauchst Du eine belastbare Messung. Der häufigste Fehler an dieser Stelle: das falsche Tool für die falsche Frage.
Felddaten oder Labordaten
Für die Bewertung zählt bei Google ausschließlich der Chrome User Experience Report, kurz CrUX: Messwerte echter Nutzer auf echten Geräten. Lighthouse dagegen liefert Laborwerte unter kontrollierten Bedingungen, wertvoll für Diagnose und Entwicklung, aber ohne direkten Einfluss auf die Rankings.
Ein Lighthouse-Score von 92 kann problemlos mit einem CrUX-Wert im Bereich Verbesserungswürdig zusammenfallen. Und ein Score von 100 sagt über die Felddaten gar nichts.
Die 75-Prozent-Regel
Google bewertet keine Durchschnittswerte, sondern das 75. Perzentil. Mindestens 75 Prozent aller Seitenaufrufe müssen den Gut-Schwellenwert erreichen. Die schnellsten 25 Prozent fallen aus der Bewertung heraus, die langsamsten zählen voll. Für Seiten mit gemischtem Publikum ist das eine reale Hürde.
Warum Verbesserungen erst nach Wochen sichtbar werden
CrUX arbeitet mit einem rollierenden Zeitfenster von 28 Tagen. Jeder gemeldete Wert ist ein Mittel über die vergangenen vier Wochen. Wenn Du heute den Server umstellst, verdrängen die neuen, schnellen Ladevorgänge die alten nur nach und nach.
Das erklärt die Verzögerung von vier bis sechs Wochen, die uns in jedem Projekt begegnet, und sie ist keine Ausrede, sondern Rechenlogik.
URL-Gruppen statt Einzelseiten
CrUX bündelt ähnliche Seiten zu Gruppen. Liegen für eine URL zu wenige Daten vor, greift Google auf vergleichbare Seiten oder auf die Daten der gesamten Domain zurück. Eine schlecht performende Kategorieseite kann die Bewertung ganzer Seitenbereiche nach unten ziehen.
Die Tools im Überblick
PageSpeed Insights zeigt Feld- und Labordaten nebeneinander und eignet sich für den schnellen Check einzelner URLs. Der Core Web Vitals Bericht in der Search Console ist die einzige Quelle für Googles tatsächliche Einordnung und zeigt den Status je URL-Gruppe mit Beispiel-URLs. Das CrUX Dashboard in Looker Studio zeigt Trends über Monate. Lighthouse in den Chrome DevTools dient der Fehlersuche, etwa über die Total Blocking Time. GTmetrix und WebPageTest liefern Wasserfalldiagramme, sind aber nicht ranking-relevant.
So testen wir in der Praxis: Erst der Bericht in der Search Console, welche Gruppen von Seiten sind rot. Dann PageSpeed Insights auf eine Beispiel-URL jeder Gruppe. Dann Lighthouse in den DevTools zur Ursachensuche. Wer mit Lighthouse anfängt, optimiert Symptome, die im Feld womöglich gar nicht auftreten.
Vier Fälle aus unserer Arbeit
Inline-SVGs auf der eigenen Website
Auf jsh.marketing hatten wir SVG-Grafiken direkt im HTML eingebettet. Das bläht jede betroffene Seite auf. Nach dem Auslagern in externe Dateien sank das unkomprimierte HTML-Volumen deutlich, die Serverantwort wurde messbar schneller, und der Browser erkannte den kritischen Renderpfad früher.
Used CSS in WP Rocket, und wo es sich selbst im Weg steht
Die Funktion erzeugt für jede URL einen reduzierten CSS-Block mit nur den tatsächlich verwendeten Regeln. Statt eines globalen Stylesheets von mehreren hundert Kilobyte bekommt jede Seite ihren Anteil. Das senkt Renderblockaden und die Total Blocking Time spürbar.
Was wir dabei gelernt haben: Dieses reduzierte CSS wird inline ins HTML geschrieben. Bei komplexen Seiten kann der Block so groß werden, dass er das HTML nennenswert vergrößert, und genau dieses HTML muss der Browser verarbeiten, bevor er rendern kann. Eine Maßnahme gegen Renderblockaden kann also das Rendering-Delay erhöhen. Wenn ein LCP-Problem trotz Used CSS bestehen bleibt, lohnt ein Blick in den Quelltext auf die Größe des erzeugten Style-Blocks.
Der Cookie-Banner als LCP-Element
Ein unterschätzter Faktor auf deutschsprachigen Webseiten: Einwilligungsbanner, die synchron laden und vor dem Hero-Element erscheinen. Erkennt der Browser den Banner als größtes sichtbares Element, misst er dessen Renderzeit als LCP. Nebenbei ist derselbe Banner oft der größte Verursacher von Layoutverschiebungen, weil er beim Einblenden alles darunter wegschiebt.
Die Lösung ist unspektakulär: Banner asynchron laden, Platz im Layout reservieren, fetchpriority high auf das Hero-Element setzen.
August Weber: 88 Prozent weniger Seitengewicht
Bei diesem mittelständischen Kunden reduzierte ein gezielter SVG-Fix die Seitengröße um 88 Prozent, der Score stieg zweistellig. Die ehrliche Einordnung, die wir dem Kunden auch so gegeben haben: Die Felddaten zogen erst Wochen später nach, und der Umsatzeffekt war nicht isolierbar. Was messbar besser wurde, war die Nutzererfahrung auf Mobilgeräten.
Die versteckten Stellschrauben, die wir immer zuerst prüfen
Diese drei Punkte haben uns in den vergangenen Monaten mehr Zeit gespart als jede Bildoptimierung.
Die Ausnahmelisten im Caching-Plugin
WP Rocket bringt sogenannte Ein-Klick-Exklusionen mit: vorkonfigurierte Ausnahmen für bekannte Themes und Plugins, die vom verzögerten Laden ausgenommen werden. Gut gemeint, weil sie Konflikte verhindern. In der Praxis liegen dadurch Skripte im kritischen Pfad, die dort nichts verloren haben.
Ein konkreter Fall: Bei einem Kunden war die Formular-Erweiterung als Ausnahme aktiviert. Dadurch blockierte deren Validierungs-Skript den kritischen Pfad mit rund einer halben Sekunde, obwohl das Formular weit unterhalb des sichtbaren Bereichs lag und die Validierung erst beim Absenden gebraucht wird. Haken raus, Problem weg.
Wenn ein LCP-Problem trotz sauberer Konfiguration bleibt, sind diese Ausnahmelisten die erste Stelle, an der wir nachsehen.
Die CDN-Einstellungen, die miteinander streiten
Cloudflare und Caching-Plugins überschneiden sich in ihren Funktionen, und manche Kombinationen arbeiten gegeneinander. Unsere Erfahrungswerte: Automatic Platform Optimization mit Cache nach Gerätetyp an. Early Hints an. HTTP/2, HTTP/3 und 0-RTT an. Brotli-Kompression an, sie reduziert eine HTML-Datei von rund 157 KB auf etwa 50 bis 60 KB bei der Übertragung.
Rocket Loader gehört aus, wenn ein Caching-Plugin die JavaScript-Optimierung übernimmt. Beide greifen an derselben Stelle an.
Und ein Punkt, bei dem wir uns selbst korrigiert haben: Cloudflare Fonts ist nur dann sinnvoll, wenn Schriften extern geladen werden. Wer seine Fonts bereits lokal ausliefert, gewinnt damit nichts. Wir hatten das in einem Projekt zunächst empfohlen und die Empfehlung nach Rückfrage zurückgenommen. Solche Korrekturen gehören zur Arbeit dazu.
Die DOM-Größe, über die niemand spricht
In vielen Berichten steht dieser Punkt ganz unten und wird übersehen. Dabei ist die Anzahl der DOM-Elemente bei modernen Page Buildern oft die eigentliche Grenze. Über 1.500 Elemente wird es eng, über 1.800 bei hoher Verschachtelungstiefe ist ohne Umbau des Layouts kaum noch etwas zu holen.
Das ist unangenehm, weil es keine Plugin-Lösung gibt. Aber es ist ehrlicher, als weiter an Symptomen zu arbeiten.
Core Web Vitals verbessern: die Hebel, die wirken
LCP verbessern
TTFB zuerst: serverseitiges Caching, besseres Hosting, CDN. Braucht der Server 1,5 Sekunden für die erste Antwort, ist das Ziel von 2,5 Sekunden rechnerisch kaum erreichbar.
Hero-Element priorisieren mit fetchpriority high, und sicherstellen, dass das Bild im HTML steht und nicht per JavaScript nachgeladen wird.
Verbindungen vorbereiten mit preconnect für Domains kritischer Ressourcen und preload für die LCP-Ressource selbst.
Moderne Bildformate wie WebP oder AVIF, in der Größe passend zum mobilen Viewport. Kritisches CSS inline. Drittanbieter prüfen: Tag Manager, Chat-Widgets und Einwilligungstools blockieren regelmäßig den kritischen Pfad.
INP verbessern
Lange Aufgaben aufbrechen: Funktionen über 50 ms blockieren jede Interaktion, aufteilen mit scheduler.postTask oder scheduler.yield. Event-Handler entschlacken und schwere Logik erst nach dem ersten sichtbaren Feedback ausführen. Drittanbieter-Skripte prüfen. Bei Formularen genau hinschauen, denn Validierung bei jedem Tastendruck ist ein klassischer INP-Killer.
CLS stabilisieren
Breite und Höhe auf alle Bilder, denn fehlende Maßangaben sind der häufigste Auslöser. font-display optional verhindert Verschiebungen durch nachgeladene Schriften. Platz reservieren für Werbeflächen, Banner und dynamische Blöcke. content-visibility mit Größenangabe für lange Seiten spart Renderarbeit, ohne dass unten Inhalte springen.
Zwei Hebel, die kaum jemand nutzt
Back Forward Cache: Wenn ein Nutzer zurücknavigiert, kann Chrome die Seite komplett aus dem Speicher wiederherstellen, die Ladezeit liegt dann praktisch bei null. Blockiert wird das unter anderem durch bestimmte unload Event Handler und einzelne Cache-Header. Die DevTools zeigen direkt an, was im Weg steht.
Speculation Rules: Damit lassen sich wahrscheinliche Folgeseiten im Hintergrund vorab rendern. Klickt der Nutzer, ist die Seite sofort da. Sinnvoll etwa vom Blogartikel zur Leistungsseite. Vorsicht ist beim Tracking geboten, weil vorgerenderte Seiten Aufrufe erzeugen können, die nie ein Mensch gesehen hat.
Wie stark wirken Core Web Vitals auf die Rankings?
Unsere ehrliche Einschätzung: Core Web Vitals sind ein Ranking Faktor mit Stichentscheid-Charakter. Google kommuniziert das seit Jahren konsistent, inhaltliche Relevanz geht vor. Sind zwei Seiten inhaltlich vergleichbar, kann die Bewertung den Ausschlag geben. Ist eine Seite inhaltlich schwächer, rettet sie auch ein perfekter LCP nicht.
Der stärkere Effekt läuft ohnehin nicht über den Algorithmus, sondern über Menschen: Schnelle Seiten haben niedrigere Absprungraten, längere Verweildauern und bessere Abschlussquoten.
Wo wir aufhören: Wenn alle drei Messwerte im Feld auf Gut stehen, ist das Thema abgeschlossen. Dann geht die Zeit in Inhalte, interne Verlinkung und Conversion.
200+
5,0
zufriedene Kunden
Was sich 2026 verändert hat
Die 2-MB-Grenze beim HTML
Im Februar 2026 hat Google dokumentiert, dass der Crawler beim Crawling nur die ersten 2 MB einer HTML-Datei indexiert. John Mueller stellte klar, dass es sich um eine Klarstellung handelt, nicht um eine Verhaltensänderung. Für die meisten Webseiten mit HTML unter 100 KB ist das irrelevant.
Kritisch wird es bei inline eingebettetem JavaScript, großen SVG-Blöcken oder ungekürzten Datenblöcken direkt im Body. Alles jenseits der Grenze existiert für Google nicht, und die Search Console meldet dazu keinen Fehler.
Lighthouse prüft jetzt auch KI-Agenten
Neu in Lighthouse 13 ist eine Kategorie namens Agentic Browsing, die bewertet, wie gut eine Seite für KI-Agenten navigierbar ist. Unsere eigene Website kam dort auf 0,67, während Performance, Best Practices und SEO bei voller Punktzahl lagen.
Die Kategorie ist ausdrücklich noch in Entwicklung, und wir würden heute niemandem raten, darauf zu optimieren. Bemerkenswert ist trotzdem, wohin die Reise geht: Semantisches HTML, saubere Bedienbarkeit und klare Struktur werden für maschinelle Besucher relevant.
Häufige Fragen
Wie teste ich die Core Web Vitals meiner Website?
Beginne mit dem Core Web Vitals Bericht in der Google Search Console, das ist die einzige Quelle, die Googles tatsächliche Einordnung zeigt. Für einzelne URLs nutzt Du PageSpeed Insights, für die Ursachensuche Lighthouse in den Chrome DevTools.
Brauche ich einen PageSpeed Score von 100?
Nein. Der Score ist ein Laborwert und fließt nicht in die Rankings ein. Maßgeblich sind die Felddaten aus dem Chrome User Experience Report. Stehen LCP, INP und CLS dort auf Gut, ist das Ziel erreicht.
Warum ändern sich meine Werte nach der Optimierung nicht?
Weil CrUX über ein rollierendes Fenster von 28 Tagen mittelt. Rechne mit vier bis sechs Wochen, bis eine Maßnahme im Bericht sichtbar wird.
Mein Bild ist optimiert, der LCP bleibt schlecht. Woran liegt das?
Vermutlich ist das Bild gar nicht das LCP-Element. Prüfe in den DevTools, welches Element gemessen wird, und zerlege den Wert in seine vier Phasen. Liegt das Problem im Element Render Delay bei niedrigem TTFB, ist die Ursache meist zu großes HTML oder eine zu tiefe DOM-Struktur.
Gilt für Desktop und Mobilgeräte dasselbe?
Die Schwellenwerte sind identisch, die Gewichtung nicht. Google zieht primär mobile Felddaten heran. Wer nur am Desktop prüft, misst an den Rankings vorbei.
Was ist mit First Input Delay?
FID wurde am 12. März 2024 durch INP ersetzt und wird nicht mehr erhoben.
Core Web Vitals im SEO-Audit
In unserem SEO-Audit steht die Diagnose der Performance am Anfang. Nicht, weil die Metriken die Rankings dominieren, sondern weil schlechte Performance eine unsichtbare Decke ist, unter der alles andere wirkungslos bleibt.
Besonders nach einem Relaunch ist ein Check Pflicht. Templatewechsel und CMS-Migrationen setzen Messwerte zurück, die vorher grün waren. Für WordPress-Projekte haben wir einen festen Ablauf aus Plugin-Kombination, Used-CSS-Konfiguration und serverseitigem Caching.
Diagnose vor Therapie, das gilt hier wie überall. Wenn Du wissen willst, wo Deine Website tatsächlich steht, meld Dich für ein Strategiegespräch.
