Core Web Vitals: Die drei Zahlen, die Google wichtiger sind als Ihr Design

Eine vollständige Anleitung zur Optimierung der Ladezeit bietet der Artikel Ladezeit und Conversion. 

Faustregel: Das Hero-Bild ist in 80 Prozent der Fälle der LCP-Verursacher. Komprimieren Sie es auf maximal 200 KB, bevor Sie andere Optimierungen angehen.

INP – Interaction to Next Paint

INP (ehemals FID – First Input Delay) misst die Reaktionsfähigkeit einer Seite. Konkret: Wie schnell reagiert die Seite, nachdem ein Nutzer geklickt oder getippt hat? Der Wert erfasst die Verzögerung zwischen der Nutzereingabe und dem Moment, an dem die Seite visuell darauf reagiert. 

Schwellenwerte: 

• Gut: unter 200 Millisekunden
• Verbesserungswürdig: 200 bis 500 ms
• Schlecht: über 500 ms

INP ist der Nachfolger von FID, den Google 2024 als offiziellen Metrik für Interaktivität eingeführt hat. Anders als FID, der nur die erste Eingabe maß, erfasst INP die schlechteste Interaktion während des gesamten Seitenbesuchs. 

Hauptverursacher: 

• Blockierende Skripte auf dem Haupt-Thread
• Drittanbieter-Tools wie Tracking-Skripte, Chat-Widgets und Consent-Banner
• Komplexe DOM-Manipulationen nach Nutzereingaben

Die Optimierung zielt darauf ab, den Haupt-Thread von JavaScript-Arbeiten zu entlasten – etwa durch Lazy-Loading von Skripten, die nicht sofort benötigt werden. 

CLS – Cumulative Layout Shift

CLS misst, wie stark sich das Layout während des Ladens verschiebt. Das passiert, wenn Elemente nachgeladen werden und andere Inhalte dadurch verrutschen. Ein Klassiker: Ein Werbebanner wird geladen, schiebt den gerade gelesenen Artikel nach unten, und der Nutzer klickt versehentlich auf die falsche Stelle. 

Schwellenwerte: 

• Gut: unter 0,1
• Verbesserungswürdig: 0,1 bis 0,25
• Schlecht: über 0,25

Die Hauptverursacher: 

• Bilder und Videos ohne Größenangaben. Der Browser reserviert keinen Platz, bis die Datei geladen ist.
• Nachgeladene Werbung oder Embeddings. Sie werden oft erst nach dem initialen Seitenaufbau eingefügt.
• Dynamisch eingefügte Inhalte wie Consent-Banner oder Cookie-Hinweise.
• Webfonts mit Verzögerung. Der Text springt, wenn der Font wechselt.

Die Lösung ist einfach: Geben Sie jedem Bild, Video und eingebetteten Element eine feste Höhe und Breite im CSS mit. Consent-Banner sollten Platz reservieren oder als Overlay ohne Layout-Verschiebung eingeblendet werden. 

Wie Core Web Vitals gemessen werden

Google verwendet zwei Datenquellen: 

Felddaten (CrUX – Chrome User Experience Report): Echte Nutzerdaten von Chrome-Nutzern, die Ihre Seite besucht haben. Diese Daten sind die Grundlage für die Bewertung im Google-Ranking. Sie sind über die Google Search Console, PageSpeed Insights und die CrUX API einsehbar. 

Labordaten (Lighthouse): Synthetische Tests unter kontrollierten Bedingungen. Sie geben Hinweise auf Probleme, sind aber nicht identisch mit den tatsächlichen Nutzererfahrungen. 

Für die Ranking-Bewertung zählen ausschließlich die Felddaten. Eine Seite kann in Lighthouse perfekt abschneiden, aber durch reale Netzwerkbedingungen, alte Geräte oder geblockte Skripte schlechte Core Web Vitals haben. 

Auswirkungen auf SEO

Core Web Vitals sind einer von über 200 Rankingfaktoren. Sie entscheiden nicht allein über die Position, aber sie können den Unterschied zwischen Platz 3 und Platz 7 ausmachen, wenn alle anderen Faktoren gleich sind. Der Artikel SEO vs. SEA ordnet ein, wie viel Gewicht organische Sichtbarkeit im Vergleich zu bezahlten Kanälen hat. 

Besonders relevant sind Core Web Vitals auf mobilen Endgeräten, wo Google die Bewertung standardmäßig auf den Mobile-First-Index stützt. Eine Seite, die auf dem Desktop schnell lädt, auf dem Smartphone aber langsam ist, wird entsprechend schlechter eingestuft. Die Optimierung sollte daher immer mit der mobilen Version beginnen – das betrifft insbesondere die lokale Suche, wie im Artikel Local SEO beschrieben. 

Praktische Priorisierung

Nicht alle drei Metriken müssen gleichzeitig perfekt sein. Die Priorisierung richtet sich nach dem größten Problem: 

1. LCP zuerst adressieren – es ist die sichtbarste Metrik und am einfachsten zu optimieren.
2. CLS als Zweites – Ursachen sind meist schnell identifiziert (Bilder ohne Maße, nachgeladene Elemente).
3. INP zuletzt – die Optimierung ist am aufwendigsten, betrifft aber oft nur eine Teilmenge der Seiten.

Eine saubere technische Basis und die richtige Datenstruktur helfen nicht nur bei den Core Web Vitals, sondern auch bei der Sichtbarkeit in KI-gestützten Suchergebnissen. Der Artikel Answer Engine Optimization zeigt, wie strukturierte Daten und klare Inhalte beide Ziele gleichzeitig unterstützen. 

Core Web Vitals mit den richtigen Tools messen

Ohne Messung keine Optimierung. Die Core Web Vitals lassen sich mit verschiedenen Tools erfassen, die unterschiedliche Perspektiven bieten: 

Google Search Console ist der Ausgangspunkt. Unter dem Bereich „Core Web Vitals" sehen Sie eine Aufschlüsselung Ihrer URLs nach Status (gut, verbesserungswürdig, schlecht) getrennt für Mobile und Desktop. Die Search Console zeigt die Felddaten aus dem CrUX-Bericht – also echte Nutzerdaten. Das ist die einzige Quelle, die Google selbst für das Ranking verwendet. 

PageSpeed Insights verbindet Feld- und Labordaten. Sie geben eine URL ein und erhalten sowohl CrUX-Daten (falls verfügbar) als auch einen Lighthouse-Test. Der Vorteil: PageSpeed Insights zeigt konkrete Optimierungsvorschläge, z. B. „Bild um 40 Prozent komprimieren" oder „Render-blockierende Ressourcen entfernen". 

Lighthouse in Chrome DevTools ist das Tool für die Entwicklung. Öffnen Sie die DevTools (F12), gehen Sie zum Tab „Lighthouse" und führen Sie einen Test durch. Lighthouse misst unter idealen Bedingungen – das zeigt die theoretische Obergrenze, aber nicht die reale Nutzererfahrung. 

CrUX API und BigQuery sind für fortgeschrittene Analysen geeignet. Die CrUX API liefert programmatischen Zugriff auf die Felddaten, während Google den vollständigen CrUX-Datensatz kostenlos in BigQuery bereitstellt. Damit lassen sich Trends über mehrere Monate und Vergleiche mit Wettbewerbern analysieren. 

Web Vitals Library ist ein JavaScript-Paket von Google, das die drei Metriken direkt im Browser misst. Ideal, um eigene Dashboards aufzubauen oder Core Web Vitals in vorhandene Monitoring-Tools zu integrieren. 

Tipp: Führen Sie regelmäßig (mindestens monatlich) eine Search-Console-Analyse durch. Die Felddaten zeigen, ob Ihre Optimierungen tatsächlich bei den Nutzern ankommen – nicht nur im Labor.

Praktische Optimierungstipps für jede Metrik

Die richtige Messung ist die eine Hälfte, die konkrete Optimierung die andere. Hier die wirksamsten Maßnahmen für jede der drei Metriken: 

LCP optimieren – die effektivsten Hebel: 

• Bilder sofort komprimieren. Tools wie Squoosh oder ShortPixel reduzieren die Dateigröße um 60 bis 80 Prozent ohne sichtbaren Qualitätsverlust.
• Ein Content Delivery Network (CDN) einsetzen. Es verkürzt die Server-Antwortzeit, indem es Inhalte von einem geografisch nahen Server ausliefert.
• Wichtige CSS-Ressourcen inline einbinden. Statt auf externe Stylesheets zu warten, betten Sie die für den ersten Bildschirmbereich relevanten CSS-Regeln direkt ins HTML ein.
• Critical CSS extrahieren und priorisieren. Das verkürzt die Zeit, bis das Hauptelement sichtbar wird, um oft mehrere hundert Millisekunden.

INP optimieren – den Haupt-Thread entlasten: 

• JavaScript-Code aufteilen (Code Splitting). Nur der Code, der für die erste Interaktion benötigt wird, wird geladen. Alles andere folgt verzögert.
• Drittanbieter-Skripte lazy-loaden. Tracking-Tools, Chat-Widgets und Consent-Banner sollten nicht blockierend geladen werden. Nutzen Sie async oder defer für nicht-kritische Skripte.
• Lange Tasks vermeiden. Aufgaben, die länger als 50 Millisekunden dauern, blockieren den Haupt-Thread. Brechen Sie lange Berechnungen in kleinere Einheiten auf oder verschieben Sie sie in Web Worker.
• Konsolenausgaben reduzieren. console.log in Produktion scheint harmlos, erzeugt aber messbare INP-Verschlechterung bei vielen Aufrufen.

CLS optimieren – Layout-Verschiebungen vermeiden: 

• Für jedes Bild, Video und Iframe feste Größen im HTML oder CSS angeben: width und height oder aspect-ratio.
• Consent-Banner als Overlay einblenden, das aus dem Dokumentenfluss genommen wird (position: fixed).
• Webfonts mit font-display: swap laden, damit Text sofort in einer System-Schriftart erscheint und erst später wechselt.
• Werbeflächen mit festen Platzhaltern reservieren, bevor die Anzeige geladen wird.

Faustregel: Konzentrieren Sie sich zuerst auf LCP. In über 60 Prozent der Fälle ist LCP der Engpass, der den Gesamteindruck dominiert. Die Optimierung ist zudem am einfachsten umzusetzen.

Häufige Fehler, die Ihre Scores verschlechtern

Viele Unternehmen investieren Zeit in Core-Web-Vitals-Optimierung, machen aber grundlegende Fehler, die den Erfolg zunichtemachen: 

Fehler 1: Nur den Desktop testen. Google bewertet Ihre Seite standardmäßig auf Basis der mobilen Version (Mobile-First-Index). Wer nur den Desktop optimiert, übersieht, dass mobile Netzwerke langsamer sind und ältere Geräte schwächere Prozessoren haben. Testen Sie daher immer zuerst die mobile Ansicht. 

Fehler 2: Bilder zwar komprimieren, aber ohne moderne Formate. JPEG und PNG sind oft doppelt so groß wie WebP oder AVIF bei gleicher Qualität. Viele CMS bieten inzwischen automatische WebP-Konvertierung an – aktivieren Sie diese Funktion. 

Fehler 3: Zu viele Drittanbieter-Skripte. Ein einzelnes Tracking-Tool verursacht selten Probleme, aber die Summe von Analytics-Tag, Facebook-Pixel, LinkedIn-Insight, Hotjar, Cookie-Banner und Chat-Widget kann den INP-Wert um mehrere hundert Millisekunden verschlechtern. Prüfen Sie kritisch, ob jedes Skript wirklich auf jeder Seite benötigt wird. 

Fehler 4: Dynamische Inhalte ohne Platzhalter. Nachgeladene Elemente wie Empfehlungs-Widgets, Related-Posts oder Social-Media-Embeddings verschieben das Layout, wenn keine feste Höhe definiert ist. Reservieren Sie für jeden dynamischen Bereich einen Platzhalter mit Mindesthöhe. 

Fehler 5: Kein Monitoring nach dem Go-Live. Eine Seite, die heute gute Core Web Vitals hat, kann morgen schlecht sein – etwa durch ein neues Plugin, ein größeres Hero-Bild oder ein zusätzliches Tracking-Skript. Richten Sie ein regelmäßiges Monitoring über die Search Console oder PageSpeed Insights API ein, idealerweise wöchentlich. 

Der Artikel Ladezeit und Conversion zeigt, wie stark sich selbst kleine Verbesserungen bei den Core Web Vitals auf die tatsächlichen Geschäftsergebnisse auswirken – von der Absprungrate bis zur Conversion-Rate. 

LeadRaum unterstützt Unternehmen dabei, die Core Web Vitals systematisch zu analysieren und zu optimieren – mit messbaren Ergebnissen sowohl in der Search Console als auch in den tatsächlichen Conversion-Zahlen. 

LCP optimieren: Konkrete Techniken für unter 2,5 Sekunden

Die Optimierung des Largest Contentful Paint ist in den meisten Fällen der effektivste Hebel – und zugleich der mit den klarsten Handlungsanweisungen. 

Bildoptimierung als erster Schritt. Das LCP-Element ist in über 80 Prozent der Fälle ein Bild. Die wirksamste Maßnahme: Bilder im Next-Gen-Format (WebP oder AVIF) ausliefern, das LCP-Bild auf maximal 200 KB komprimieren und ein responsive Image-Set mit srcset bereitstellen. Ein Hero-Bild, das auf dem Desktop 1.920 Pixel breit ist, muss auf dem Smartphone nur 400 Pixel breit sein – wer trotzdem das Desktop-Bild ausliefert, verschenkt Sekunden. 

Server-Antwortzeit verkürzen. Der Time to First Byte (TTFB) sollte unter 300 Millisekunden liegen. Maßnahmen: Ein Content Delivery Network (CDN) einsetzen, den Webhosting-Tarif prüfen (geteilter Hosting vs. VPS) und serverseitiges Caching aktivieren. Besonders bei WordPress hilft ein Caching-Plugin wie WP Rocket oder Flying Press, die Server-Antwortzeit um 50 bis 80 Prozent zu reduzieren. 

Render-blockierende Ressourcen eliminieren. CSS- und JavaScript-Dateien, die den Seitenaufbau blockieren, verlängern den LCP signifikant. Critical CSS – also die für den ersten sichtbaren Bereich notwendigen Styles – sollte inline im HTML stehen. Alles andere wird asynchron geladen. JavaScript, das nicht sofort benötigt wird, erhält das Attribut defer oder async. 

Prefetch und Preload strategisch einsetzen. Das LCP-Bild kann über <link rel="preload"> bereits vor dem regulären HTML-Aufbau angefordert werden. Wichtig: Preload nur für das tatsächliche LCP-Element verwenden – zu viele Preloads heben den Effekt auf. 

Tipp: Nutzen Sie PageSpeed Insights nicht nur zur Bewertung, sondern lesen Sie die „Diagnose"-Ergebnisse. Dort listet Google die genauen Dateien auf, die den LCP verzögern – mit Dateiname und Ladezeit.

INP und CLS in der Praxis optimieren

Während LCP oft mit wenigen Maßnahmen in den grünen Bereich gebracht wird, erfordern INP und CLS eine systematischere Herangehensweise. 

INP-Optimierung: Den Haupt-Thread entlasten. Der Haupt-Thread ist die Abarbeitungseinheit des Browsers – solange JavaScript läuft, kann keine Nutzerinteraktion verarbeitet werden. Drei Strategien helfen: 

1. Lange Tasks aufteilen. Skripte, die länger als 50 Millisekunden laufen, blockieren den Haupt-Thread. JavaScript-Code in kleinere, asynchrone Einheiten aufteilen mit requestAnimationFrame oder setTimeout.
2. Drittanbieter-Skripte verzögern. Tracking-Tools, Chat-Widgets und Consent-Banner sollten erst nach der ersten Interaktion geladen werden. Ein Tool wie Google Tag Manager mit verzögerter Auslösung ("After DOM Ready" oder "After Page Loaded") entlastet den Haupt-Thread erheblich.
3. DOM-Manipulation minimieren. Komplexe DOM-Änderungen nach einer Nutzereingabe – etwa das Einblenden eines umfangreichen Filtermenüs – sollten virtualisiert oder in kleinere Schritte zerlegt werden.

CLS-Optimierung: Layout-Verschiebungen vermeiden. Cumulative Layout Shift ist die am einfachsten zu behebende Metrik, weil die Ursachen klar und die Lösungen bekannt sind: 

• Bildern und Videos immer Größenangaben mitgeben. Jedes <img>-Tag benötigt width und height im HTML oder CSS. Der Browser reserviert dann den Platz, bevor das Bild geladen ist.
• Webfonts mit font-display: swap laden. Der Text wird sofort in einer System-Schrift angezeigt und erst später durch die gewünschte Schrift ersetzt – minimale Verschiebung statt sichtbarem Sprung.
• Consent-Banner Platz reservieren. Cookie-Hinweise, die von oben oder unten eingeschoben werden, verursachen regelmäßig CLS. Entweder als Overlay ohne Layout-Verschiebung einblenden oder den Platz im Layout von Anfang an freihalten.
• Dynamische Inhalte mit Platzhaltern. Werbung, Embeds oder dynamisch geladene Inhalte sollten feste Container mit einer Mindesthöhe erhalten, die auch dann bestehen bleibt, wenn die Anzeige nicht geladen wird.

Faustregel: CLS-Werte über 0,05 lassen sich in 90 Prozent der Fälle auf fehlende Größenangaben bei Bildern zurückführen. Prüfen Sie zuerst diese eine Ursache, bevor Sie andere CLS-Quellen suchen.

Mobile vs. Desktop: Unterschiede bei den Core Web Vitals

Google bewertet Core Web Vitals auf Basis des Mobile-First-Index – die mobile Version einer Seite ist die primäre Grundlage für das Ranking. Ein Unternehmen, das nur den Desktop optimiert, ignoriert die relevantere Bewertung. 

Mobile LCP ist systematisch schlechter. Auf mobilen Geräten sind die Netzwerkgeschwindigkeiten langsamer, die Prozessoren schwächer und die Bildschirme kleiner – trotzdem laden viele Seiten auf dem Smartphone dieselben großen Bilder wie auf dem Desktop. Die Lösung: Unterschiedliche Bildgrößen für mobile und Desktop-Ansicht über Media Queries oder ein CDN mit Device-Detection. 

INP leidet unter schwächeren Prozessoren. Ein Smartphone-Prozessor bewältigt JavaScript-Aufgaben langsamer als ein Desktop-Prozessor. Skripte, die auf dem Desktop unauffällig laufen, können auf dem Smartphone den Haupt-Thread blockieren. Testen Sie INP daher immer auf einem mittelklassigen Smartphone (nicht auf dem aktuellen Flaggschiff) – das entspricht der realen Nutzererfahrung eher. 

CLS ist auf mobilen Geräten häufiger. Durch die geringere Bildschirmbreite wirken sich Layout-Verschiebungen stärker aus. Ein nachgeladener Banner verschiebt auf dem Smartphone eine viel größere relative Fläche als auf dem Desktop. Die bereits beschriebenen Maßnahmen (feste Größenangaben, Platzhalter) sind auf mobilen Geräten daher noch wichtiger. 

Datengrundlage für die mobile Optimierung. Die Google Search Console zeigt Core Web Vitals getrennt für mobile und Desktop-Geräte. Prüfen Sie beide Ansichten: Eine Seite kann auf dem Desktop grün sein und auf dem Smartphone rot. Optimieren Sie immer zuerst die mobile Ansicht, da diese die Ranking-Grundlage bildet. 

CrUX-Daten richtig interpretieren

Der Chrome User Experience Report (CrUX) ist die offizielle Datenquelle für die Core-Web-Vitals-Bewertung durch Google. Wer die CrUX-Daten richtig liest, erkennt Optimierungspotenziale, die Lighthouse nicht zeigt. 

Felddaten vs. Labordaten verstehen. Lighthouse testet unter idealisierten Bedingungen (schnelles Netzwerk, leistungsstarker Rechner). CrUX hingegen sammelt Daten von echten Nutzern mit realen Netzwerkbedingungen und Geräten. Der Unterschied kann erheblich sein: Eine Seite, die in Lighthouse mit 95 von 100 Punkten bewertet wird, kann im CrUX-Bericht „verbesserungswürdige" LCP-Werte aufweisen. 

Den Perzentil-Wert beachten. Google bewertet nicht den Durchschnitt, sondern das 75. Perzentil. Das bedeutet: 75 Prozent der Nutzer müssen eine gute Erfahrung machen. Wenn 25 Prozent der Nutzer schlechte Werte haben – etwa durch langsames 3G-Netz oder alte Geräte – fällt die Seite insgesamt durch. Optimieren Sie daher nicht nur den Durchschnitt, sondern die „langsamen Ausreißer". 

CrUX in der Search Console auswerten. Unter „Core Web Vitals" in der Google Search Console sehen Sie für jede URL-Gruppe, ob die Werte gut, verbesserungswürdig oder schlecht sind. Die Ansicht zeigt, wie viele URLs betroffen sind – oft sind es nur einige Dutzend Seiten, die das Gesamtbild verzerren. Konzentrieren Sie sich auf diese Problem-URLs, statt die gesamte Website umzubauen. 

PageSpeed Insights als Diagnose-Tool nutzen. PageSpeed Insights kombiniert CrUX-Felddaten (oben) mit Lighthouse-Labordaten (unten). Die obere Hälfte zeigt, was Google tatsächlich über Ihre Seite weiß – die untere Hälfte gibt Handlungsempfehlungen. Viele Nutzer optimieren nur nach Lighthouse und ignorieren die Felddaten. Das ist der häufigste Fehler bei der Core-Web-Vitals-Optimierung. 

Die LeadRaum-Erfahrung zeigt: Unternehmen, die CrUX-Felddaten systematisch auswerten und ihre Optimierung daran ausrichten, erreichen ihre Core-Web-Vitals-Ziele im Durchschnitt drei bis vier Wochen schneller als solche, die ausschließlich nach Lighthouse optimieren. 

Faustregel: Ein monatlicher Check der CrUX-Daten in der Search Console reicht für die meisten Websites, um negative Trends früh zu erkennen. Bei wöchentlichen Veröffentlichungen empfiehlt sich ein 14-tägiger Rhythmus.

Core Web Vitals regelmäßig überwachen

Ein einmaliger Test liefert keine verlässliche Aussage, weil sich Ladezeiten durch Updates, neue Skripte oder geänderte Inhalte ständig verschieben. Wer seine Core Web Vitals nur nach einem Redesign prüft, hat kein Monitoring, sondern eine Momentaufnahme. Die Kombination aus Lighthouse (Vorab-Tests im Development-Workflow) und CrUX-Felddaten (echte Nutzerdaten der letzten 28 Tage) deckt beide Perspektiven ab und hilft, Trendverschlechterungen zu erkennen, bevor sie sich auf das Ranking auswirken. Regelmäßige Checks über die Search Console oder PageSpeed Insights sind der einzige Weg, um dauerhaft stabile Werte sicherzustellen.