So bestehst du die Core Web Vitals: Schritt für Schritt (2026)

Der schnellste Weg, die Core Web Vitals zu bestehen

Du weißt, dass deine Core Web Vitals Arbeit brauchen. Die Google Search Console zeigt Rot oder Orange, ein Kunde stellt Fragen oder PageSpeed Insights hat dir gerade schlechte Nachrichten geliefert. Diese Seite zeigt dir den Workflow, mit dem ich Websites so schnell wie möglich von durchgefallen auf bestanden bringe.

Mit diesem Workflow habe ich Websites auf Hunderttausenden von Seiten dabei geholfen, die Core Web Vitals zu bestehen. Er funktioniert mit WordPress, Shopify, Eigenentwicklungen und jeder Plattform dazwischen. Die Reihenfolge, in der du Probleme behebst, ist entscheidend. Optimiere zuerst das Fundament und arbeite dich nach außen vor. Sonst verschwendest du Zeit damit, Dinge zu optimieren, die von einem tiefer liegenden Problem überlagert werden.

Wo das Web aktuell steht

Laut dem Web Almanac 2025 (basierend auf CrUX-Daten vom Juli 2025) bestehen 48 % der mobilen Websites und 56 % der Desktop-Websites alle drei Core Web Vitals. Das ist eine Verbesserung gegenüber 44 % mobil 2024, bedeutet aber immer noch, dass mehr als die Hälfte des mobilen Webs durchfällt.

Aufgeschlüsselt nach Metrik (Anteil der Origins mit der Bewertung „gut“ auf Mobilgeräten):

Quelle: Web Almanac 2025 (HTTP Archive, CrUX-Daten vom Juli 2025). RUM-Daten von CoreDash über überwachte Websites hinweg zeigen ähnliche Verteilungen.

LCP ist der Flaschenhals. 77 % bestehen INP und 81 % bestehen CLS, aber nur 62 % bestehen LCP. Genau das zieht die Gesamterfolgsquote auf 48 % herunter. Deshalb priorisiert der folgende Workflow zuerst TTFB und LCP.

Schritt 1: Bestimme deinen aktuellen Stand

Bevor du etwas änderst, finde genau heraus, welche Metriken auf welchen Seiten durchfallen. Wenn du diesen Schritt überspringst und rätst, verschwendest du Zeit damit, die falschen Dinge anzugehen.

Prüfe die Google Search Console

Gehe in deine Search-Console-Property und öffne den Core Web Vitals-Bericht unter „Nutzererfahrung“. Dort siehst du:

• wie viele URLs als „Gut“, „Optimierung erforderlich“ oder „Schlecht“ eingestuft sind
• welche konkrete Metrik durchfällt (LCP, INP oder CLS)
• URL-Gruppen mit demselben Problem (z. B. alle Produktseiten fallen bei INP durch)

Die Search Console nutzt echte field data von Chrome-Nutzern über einen rollierenden Zeitraum von 28 Tagen. Das sind die Daten, die Google für das Ranking heranzieht. Wenn die Search Console anzeigt, dass du bestehst, dann bestehst du – egal, was Lighthouse sagt.

Teste wichtige Seiten mit PageSpeed Insights

Teste mindestens eine URL jedes Seitentyps: deine Startseite, einen Blogbeitrag, eine Produktseite, eine Kategorie- oder Übersichtsseite. PageSpeed Insights liefert dir sowohl field data (sofern verfügbar) als auch lab data mit detaillierten Diagnosen.

Schau dir zuerst den field-data-Bereich an (beschriftet mit „Discover what your real users are experiencing“). Zeigt er für alle drei Metriken Grün an, hat diese Seite bestanden. Sind keine field data verfügbar, hat die Seite nicht genug Traffic für CrUX-Daten. Google nutzt in diesem Fall unter Umständen Daten auf Origin-Ebene oder aus URL-Gruppen.

Richte Real User Monitoring ein

Die Search Console und CrUX basieren auf einem rollierenden Zeitraum von 28 Tagen, weshalb Verbesserungen erst nach Wochen sichtbar werden. Um die unmittelbaren Auswirkungen deiner Änderungen zu sehen, richte eine Real-User-Monitoring-Lösung (RUM) wie CoreDash ein. RUM liefert dir field data in Echtzeit für jede Seite, jedes Gerät und jedes Land. So kannst du jeden Fix verifizieren, bevor du zum nächsten übergehst.

Schritt 2: Finde heraus, welche Metrik du zuerst beheben musst

Wenn mehrere Metriken durchfallen, behebe sie in dieser Reihenfolge:

Die TTFB gehört selbst nicht zu den Core Web Vitals, aber jede Millisekunde bei der TTFB schlägt direkt auf deinen LCP und FCP durch. Eine Seite mit 800 ms TTFB hat bereits ein Drittel des LCP-Budgets von 2,5 Sekunden verbraucht, bevor der Browser überhaupt mit dem Rendern beginnt. Der CrUX-Grenzwert für „gut“ liegt bei der TTFB bei 800 ms, aber schneller ist immer besser: Jede Verbesserung der TTFB überträgt sich direkt auf deine Paint-Metriken. Mehr dazu erfährst du in unserem Time-to-First-Byte-Guide.

Schritt 3: Repariere das Fundament (TTFB)

Liegt deine Time to First Byte dauerhaft über 400 ms, fange hier an. Die typischen Probleme:

• Langsames Hosting: Wechsle zu einem hochwertigen Hoster mit Caching auf Serverebene. Managed-Hoster für WordPress (Kinsta, SiteGround, Cloudways) oder Shopifys integrierte Infrastruktur decken das ab.
• Kein Page-Caching: Stelle sicher, dass dein CMS das fertig gerenderte HTML cacht, damit der Server es nicht bei jedem Request neu erzeugen muss.
• Kein CDN: Richte ein CDN ein (Cloudflare ist kostenlos), um Seiten von Edge-Standorten nahe bei den Besuchern auszuliefern. Siehe dazu unseren Cloudflare-Konfigurations-Guide.
• Weiterleitungen: Jeder Redirect bedeutet einen kompletten Roundtrip. Eliminiere unnötige Weiterleitungsketten.
• Langsames Backend: Nicht optimierte Datenbankabfragen, zu viele WordPress-Plugins oder rechenintensive serverseitige Prozesse. Nutze Query-Monitoring-Tools, um Engpässe aufzuspüren.

Ziel: Bringe die TTFB für die meisten Besucher unter 200 ms. Mindestens aber unter 400 ms.

Schritt 4: Behebe LCP

Sobald die TTFB stabil ist, behebst du Largest Contentful Paint. Das Vorgehen:

Identifiziere dein LCP-Element

Lass die betroffene Seite durch PageSpeed Insights laufen und suche im Bereich „Diagnose“ nach dem „Largest Contentful Paint element“. Meist handelt es sich um ein Hero-Image, ein Beitragsbild oder einen großen Textblock.

Wenn der LCP ein Bild ist

1. Stelle sicher, dass der Browser das Bild im HTML findet. Die Bild-URL muss in einem normalen <img src="">-Tag stehen – nicht hinter einem data-src-Attribut versteckt oder per JavaScript geladen werden. Wenn der HTML-Parser des Browsers die Bild-URL nicht sieht, kann er sie nicht frühzeitig laden. Laut dem Web Almanac 2025 verstecken 7 % der Websites ihr LCP-Bild immer noch auf diese Weise.
2. Füge dem <img>-Tag fetchpriority="high" hinzu. Das signalisiert dem Browser, dieses Bild gegenüber anderen Ressourcen zu priorisieren, die um Bandbreite konkurrieren. Ohne dieses Attribut lädt der Browser möglicherweise zuerst Stylesheets, Skripte und andere Bilder herunter. In einem Test von Google auf Google Flights verbesserte diese einzelne Änderung den LCP von 2,6 s auf 1,9 s.
3. Entferne loading="lazy". Lazy loading verzögert den Request, bis das Bild nah am Viewport ist. Bei einem LCP-Bild fließt diese Verzögerung eins zu eins in deinen LCP-Wert ein.
4. Optimiere die Dateigröße. Konvertiere Bilder nach WebP oder AVIF. Liefere über srcset und sizes die passenden Abmessungen für den Viewport aus.
5. Wenn das Bild nicht im HTML steht (CSS-Hintergrundbild, per JavaScript geladen oder auf einer Seite, auf der du das <img>-Tag nicht anpassen kannst): Füge einen Preload hinzu. Verwende <link rel="preload" as="image" href="..." fetchpriority="high"> im <head>. Ein Preload zwingt den Browser dazu, das Bild frühzeitig zu entdecken, selbst wenn es im HTML-Quelltext nicht direkt sichtbar ist. Bei Bildern, die bereits in einem normalen <img>-Tag stehen, ist ein Preload meist überflüssig, da der Parser sie ohnehin findet.

Wenn der LCP ein Text ist

1. Halte render blocking CSS klein. Lade nur das CSS, das die Seite tatsächlich nutzt, damit der Browser den Text rendern kann, ohne auf ein großes Stylesheet zu warten.
2. Optimiere das Laden der Fonts. Hoste deine Fonts selbst und setze einen Preload auf die wichtigste Font-Datei, um die Zeit bis zum Rendern des Texts zu verkürzen.
3. Minimiere render blocking JavaScript. Verzögere unkritisches JavaScript, damit es den HTML-Parser nicht blockiert.

Schritt 5: Behebe INP

Sobald der LCP passt, gehst du Interaction to Next Paint an. Der INP fällt durch, wenn JavaScript bei Nutzerinteraktionen den main thread blockiert.

Finde den Engpass

Öffne die Chrome DevTools, wechsle in das Performance-Panel und zeichne auf, wie du mit der Seite interagierst. Halte Ausschau nach long tasks (Tasks über 50 ms, dargestellt als rote Balken). Genau diese verhindern, dass der Browser auf deine Klicks reagiert.

Was den main thread typischerweise blockiert:

• Drittanbieter-Skripte (Analytics, Anzeigen, Chat-Widgets, Marketing-Tags), die um Rechenzeit auf dem main thread konkurrieren
• Große JavaScript-Bundles von Frameworks, Page-Buildern oder Plugins, die während des Ladens der Seite ausgeführt werden
• Nicht optimierte Event-Handler, die als Reaktion auf einen Klick oder Tastendruck zu viel Arbeit verrichten

Priorität bei den Fixes

1. Verzögere Drittanbieter-Skripte. Chat-, Analytics-, Social- und Marketing-Skripte sollten erst nach der ersten Nutzerinteraktion laden, nicht beim Laden der Seite.
2. Lade unkritisches eigenes JavaScript verzögert. Nutze defer oder async für Skripte, die nicht ausgeführt werden müssen, bevor die Seite interaktiv ist.
3. Teile long tasks auf. Wenn Funktionen in deinem eigenen Code länger als 50 ms dauern, gib per yield an den main thread ab, damit der Browser Nutzereingaben zwischen einzelnen Arbeitsschritten verarbeiten kann. Der moderne Weg dafür ist scheduler.yield() (unterstützt ab Chrome 129 und in Edge). Für eine breitere Browserunterstützung greifst du auf einen Fallback mit setTimeout(resolve, 0) innerhalb eines Promise zurück:

   async function yieldToMain() {
     if ('scheduler' in window && 'yield' in scheduler) {
       return scheduler.yield();
     }
     return new Promise(resolve => setTimeout(resolve, 0));
   }

4. Entferne ungenutztes JavaScript. Nutze den Coverage-Tab in den Chrome DevTools, um JavaScript zu identifizieren, das zwar geladen, aber nie ausgeführt wird. Entferne es oder lade es nur bei Bedarf.

Die vollständige Optimierungsstrategie für den INP findest du in unserem INP-Optimierungs-Guide.

Schritt 6: Behebe CLS

Der CLS ist meist die am einfachsten zu behebende Metrik. Die häufigsten Ursachen und Lösungen:

Bilder ohne Größenangaben

Jedes <img>-Tag braucht explizite width- und height-Attribute. Ohne sie weiß der Browser nicht, wie viel Platz er reservieren muss, und der Inhalt verschiebt sich, sobald das Bild lädt. Das ist weltweit die Ursache Nummer eins für CLS. Siehe dazu unseren CLS-Guide.

Webfont-Swapping

Wenn ein Webfont lädt und den Fallback ersetzt, kann der Text neu umbrechen und umliegende Elemente verschieben. Lösung: Fonts selbst hosten, font-display: optional nutzen oder mit der CSS-Eigenschaft size-adjust die Abmessungen der Fallback-Schriftart an den Webfont anpassen.

Dynamisch eingefügte Inhalte

Cookie-Banner, Hinweisleisten, Anzeigenplätze und Pop-ups, die Inhalte nach dem Laden nach unten verschieben. Lösung: Reserviere mit CSS min-height Platz für diese Elemente oder lade sie so, dass sie das umliegende Layout nicht beeinflussen (z. B. als Overlay statt durch Inline-Einfügung).

Schritt 7: Mit field data verifizieren

Nachdem du deine Fixes umgesetzt hast, musst du prüfen, ob sie in der realen Welt funktionieren – und nicht nur in Lighthouse.

• Sofortige Überprüfung: Nutze CoreDash oder ein anderes RUM-Tool, um field data in Echtzeit zu sehen. Änderungen sollten innerhalb weniger Stunden sichtbar sein.
• CrUX-Verifizierung: Der Chrome User Experience Report deckt die vergangenen 28 Tage ab und wird täglich aktualisiert. Jeder Tag bringt neue Besuche nach dem Fix hinzu und lässt ältere herausfallen. Es dauert daher bis zu 28 Tage, bis das Zeitfenster ausschließlich Besuche nach dem Fix enthält.
• Search-Console-Verifizierung: Der Core-Web-Vitals-Bericht in der Search Console aktualisiert sich auf Basis von CrUX. Sobald CrUX Verbesserungen zeigt, zieht die Search Console nach.

Wegen dieser Verzögerung ist RUM unverzichtbar. Ohne RUM hast du erst nach Wochen Einblick darin, ob deine Änderungen tatsächlich gewirkt haben.

Schritt 8: Kontinuierlich überwachen und pflegen

Performance verschlechtert sich mit der Zeit. Jedes neue Plugin, jedes Theme-Update oder Drittanbieter-Skript kann deine Arbeit zunichtemachen. Richte ein dauerhaftes Monitoring ein:

• Prüfe den Core-Web-Vitals-Bericht in der Search Console wöchentlich
• Nutze CoreDash für kontinuierliches Echtzeit-Monitoring mit Alarmen
• Teste nach jeder größeren Änderung erneut mit PageSpeed Insights (neues Plugin, Theme-Update, neues Drittanbieter-Skript)
• Prüfe Drittanbieter-Skripte vierteljährlich. Entferne alles, was nicht mehr benötigt wird.

Eine vollständige Übersicht aller Prüfpunkte findest du in unserer ultimativen Checkliste für die Core Web Vitals.

Quick Wins: Die Fixes mit der größten Wirkung

Wenn du nur Zeit für fünf Dinge hast, bringen diese Fixes plattformübergreifend den größten Effekt:

Diese Wertebereiche stammen aus echten Messdaten des CoreDash-RUM aus verschiedenen Optimierungsprojekten. Deine tatsächliche Verbesserung hängt von deinem Ausgangspunkt, deinem Hosting und deinem Traffic-Profil ab. Websites mit sehr schlechten Ausgangswerten (LCP über 5 Sekunden) erzielen oft noch deutlich größere Verbesserungen. Websites, die bereits nah am Grenzwert liegen, sehen zwar absolut geringere Gewinne – oft machen genau diese aber den Unterschied zwischen durchgefallen und bestanden aus.

Die Daten des Web Almanac 2025 stützen diese Prioritäten. Startseiten bestehen die Core Web Vitals mobil nur zu 45 %, während Unterseiten auf 56 % kommen. Dieser Unterschied liegt daran, dass Startseiten meist mehr dynamische Inhalte, größere Hero-Images und mehr Drittanbieter-Skripte haben. Fällt deine Startseite durch, während Unterseiten bestehen, dann optimiere LCP und INP gezielt im Template der Startseite.