Was sind die Core Web Vitals?

von

Die Core Web Vitals sind eine Reihe von Metriken, die von Google definiert wurden, um die Nutzerfreundlichkeit zu messen. Diese Metriken konzentrieren sich auf Aspekte wie: Ladezeit, Interaktivität bzw. Reaktionsfähigkeit und visuelle Stabilität. Die Core Web Vitals basieren auf dem bestehenden Core Web Vitals Framework aus dem Chrome User Experience Report (CrUX).

Das Core Web Vitals-Framework besteht aus den Werten:

  • Interaction to Next Paint (INP)
  • Largest Contentful Paint (LCP)
  • Cumulative Layout Shift (CLS)
  • First Input Delay (FID)

Wie definiert Google die Core Web Vitals?

Google definiert die Core Web Vitals als eine Gruppe standardisierter, nutzerzentrierter Leistungsmetriken, die die Ladegeschwindigkeit, die visuelle Stabilität und die Interaktivität einer Webseite anhand realer Felddaten messen.

Diese Messwerte werden im 75. Perzentil des Chrome User Experience Reports (CrUX) erhoben. Sie dienen im Page-Experience-System als direkte Ranking-Faktoren.

Largest Contentful Paint misst die Ladegeschwindigkeit des Hauptinhalts

Largest Contentful Paint (LCP) erfasst den Zeitpunkt, an dem das größte sichtbare Inhaltselement – wie ein Hero-Image, ein Video-Vorschaubild oder ein großer Textblock – im Viewport des Nutzers vollständig gerendert ist.

  • Der mathematische Grenzwert: Ein LCP-Wert von unter 2,5 Sekunden gilt als ideal und sichert die Einstufung im grünen Bereich.
  • Der algorithmische Hebel: Ein verzögertes Laden des Hauptinhalts signalisiert dem Googlebot eine unzureichende Serverleistung oder blockierte Render-Pfade. Dies erhöht die Abbruchquote ungeduldiger Besucher sofort.
  • Primäre Optimierung: Die Reduktion der Serverantwortzeit (TTFB), das Komprimieren von Bildern in moderne Formate (WebP/AVIF) und das Eliminieren von render-blockierendem JavaScript beschleunigen das LCP systemisch.

Cumulative Layout Shift quantifiziert die visuelle Stabilität beim Rendern

Cumulative Layout Shift (CLS) berechnet die Summe aller unvorhersehbaren Layout-Verschiebungen von Elementen, die während der gesamten Ladephase im sichtbaren Bereich einer Seite auftreten.

  • Der mathematische Grenzwert: Ein exzellenter CLS-Score liegt bei unter 0,1.
  • Der algorithmische Hebel: Springende Schaltflächen oder nachträglich hineingeladene Werbebanner erzeugen visuelle Instabilität. Dies provoziert frustrierte Fehlklicks der Nutzer, was von Google als mangelhafte User Experience gewertet wird.
  • Primäre Optimierung: Das explizite Zuweisen von Höhen- und Breitenattributen (width und height) im HTML-Code für Bilder und Video-Container verhindert Layout-Verschiebungen vollständig.

Interaction to Next Paint bewertet die Reaktionsfähigkeit während der gesamten Sitzung

Interaction to Next Paint (INP) identifiziert die längste visuelle Verzögerung zwischen einer Nutzerinteraktion – wie einem Klick auf eine Schaltfläche oder dem Tippen auf ein Formularfeld – und dem direkt darauffolgenden visuellen Feedback auf dem Bildschirm.

  • Der mathematische Grenzwert: Eine reibungslose Interaktion erfordert einen INP-Wert von unter 200 Millisekunden.
  • Der algorithmische Hebel: Da INP im Gegensatz zum veralteten First Input Delay (FID) nicht nur die erste, sondern sämtliche Interaktionen eines Seitenbesuchs überwacht, entlarvt die Metrik träg reagierende Seitenarchitekturen unnachgiebig. Sie verhindert unbewusste Abbrüche im Checkout-Flow.
  • Primäre Optimierung: Das Aufbrechen langer JavaScript-Tasks im Hauptthread (Main Thread) sowie das asynchrone Laden von Third-Party-Skripten stellen die sofortige Reaktionsfähigkeit der Benutzeroberfläche sicher.

Warum Interaction to Next Paint das veraltete FID ersetzt?

Google hat am 12. März 2024 den First Input Delay (FID) offiziell durch Interaction to Next Paint (INP) als Core Web Vital ersetzt. INP misst die Gesamtreaktionsfähigkeit einer Website bei allen Interaktionen, während FID nur die Verzögerung des allerersten Klicks erfasste. Da Nutzer die meiste Zeit nach dem Laden auf einer Seite verbringen, bietet INP ein viel echteres Bild der Nutzererfahrung.

INP ist besser als FID, weil es nicht nur die erste Verzögerung misst, sondern jeden Klick, Tippen oder Tastendruck während des gesamten Besuchs erfasst, dabei die volle Dauer bis zum nächsten sichtbaren Bild auf dem Bildschirm berechnet und so auch spätere Verzögerungen durch schweres JavaScript aufdeckt.

Wie bestraft NavBoost schlechte Core Web Vitals?

NavBoost bestraft schlechte Core Web Vitals nicht durch Code-Analyse, sondern durch die Auswertung frustrierter Nutzerinteraktionen – Short Clicks, vorzeitige Abbrüche und Missclicks – die über 13 Monate gespeichert und in eine gerätespezifische Ranking-Demotion übersetzt werden.

Welche Nutzersignale wandelt NavBoost in badClicks um?

NavBoost bewertet Suchergebnisse anhand der Klickqualität. Drei technische CWV-Fehler lösen spezifische badClick-Muster aus:

  • Hoher LCP & Short Clicks: Nutzer brechen den Ladevorgang ab, noch bevor der Largest Contentful Paint sichtbar wird. Die Seite wird innerhalb von Sekunden wieder verlassen.
  • Hoher INP & Abbruche: Verzögerte Reaktionen auf Klicks oder Tippeingaben simulieren einen technischen Fehler. Nutzer vermuten Defekt und kehren zur SERP zurück.
  • Hoher CLS & Missclicks: Verspringende Layout-Elemente führen zu Fehlklicks auf Werbebanner oder falsche Links. Nutzer verlassen die Seite sofort frustriert.

Wie löst Pogo-Sticking die serpDemotion aus?

Registriert NavBoost eine hohe Anzahl schneller Rücksprünge zur Google-Suchergebnisseite, greift der algorithmische Filter namens serpDemotion. NavBoost wertet wiederholtes Pogo-Sticking als klares Signal mangelnder Suchintention – entweder inhaltlich oder technisch bedingt. Die betroffene URL verliert daraufhin messbar an Sichtbarkeit in den organischen Ergebnissen.

Warum verlieren schlechte CWV den Last Longest Click?

Der Last Longest Click ist der wertvollste Klick für NavBoost: das Suchergebnis, auf dem Nutzer am längsten verweilen und ihre Suche abschließen. Schlechte Core Web Vitals verkürzen die Verweildauer (Dwell Time) massiv. Ihr Ranking-Gewicht verschiebt sich schrittweise zu technisch stabileren Konkurrenten, die den Klick halten können.

Wie erfolgt die gerätespezifische Herabstufung?

NavBoost trennt Nutzerinteraktionsdaten strikt nach Gerätetyp (Desktop vs. Mobile). Eine Seite mit exzellenten Desktop-Werten, aber roten Mobile-CWV zeigt nur im mobilen Ranking einen Absturz. Die Desktop-Positionen bleiben stabil. Die Bestrafung erfolgt isoliert und zielgerichtet.

Wie minimieren Sie badClicks durch CWV-Optimierung?

  • LCP minimieren: Server-Response-Zeiten (TTFB) reduzieren, Textinhalte priorisieren, Bilder in modernen Formaten (AVIF/WebP) ausliefern, Render-blockierende Ressourcen eliminieren.
  • INP optimieren: Lange JavaScript-Tasks aufbrechen, ungenutzte Third-Party-Skripte entfernen oder deferieren, Layout-Thrashing vermeiden, requestIdleCallback für nicht-kritische Prozesse nutzen.
  • CLS eliminieren: Feste Höhen- und Breitenangaben für Medien und Platzhalter setzen, font-display: optional für Webfonts verwenden, dynamische Einblendungen unterhalb des sichtbaren Bereichs platzieren.
  • Monitoring implementieren: CrUX-Dashboard, PageSpeed Insights und Search Console Core Web Vitals Report für kontinuierliche Überwachung einsetzen. Felddaten (CrUX) gegenüber Lab-Daten priorisieren, da NavBoost ausschließlich reale Nutzerinteraktionen auswertet.

Welche Tools identifizieren badClicks und technische Ursachen?

  • Google Search Console: Core Web Vitals Report mit Seiten-URLs und Problemklassifizierung
  • PageSpeed Insights: Kombinierte Feld- und Lab-Daten mit konkreten Optimierungsvorschlägen
  • CrUX Dashboard: Visuelle Auswertung historischer Felddaten ohne SQL-Kenntnisse
  • Web Vitals Chrome Extension: Echtzeit-Messung im Browser während der Nutzerinteraktion
  • Lighthouse CI: Automatisierte Lab-Tests im Entwicklungs-Workflow zur Früherkennung von Regressionen

Verfehlt eine Plattform die von Google definierten Grenzwerte, führt dies im Live-Betrieb zu unmittelbaren Verhaltungs-Abbrüchen der Besucher. Diese unbewussten Nutzersignale triggern im System verheerende Effekte:

  • LCP-Verzögerung (> 2,5s): Lange Ladezeiten des primären Hauptinhalts erhöhen die Absprungrate im ersten Viewport exponentiell. [1]
  • CLS-Instabilität (> 0,1): Unerwartete Layout-Verschiebungen während des Rendervorgangs führen zu frustrierten Fehlklicks und zerstören das Nutzervertrauen augenblicklich. [1]
  • Die NavBoost-Konsequenz: Diese usability-bedingten Frustrationen provozieren das sogenannte Pogosticking – das blitzschnelle Zurückspringen des Nutzers zur Suchergebnisseite (Short Clicks). Das im DOJ-Verfahren offengelegte NavBoost-System speichert diese negativen Klicksignale über ein 13-Monats-Fenster pro Suchanfrage und stuft die organische Domain-Autorität systematisch herunter.

Core Web Vitals optimieren

Die Optimierung der Core Web Vitals erfordert das systematische Beseitigen technischer Bremsen in den Bereichen Server-Infrastruktur, Asset-Größen und JavaScript-Verarbeitung, um Ladezeiten, Stabilität und Reaktionsfähigkeit nachweislich zu verbessern.

Technische Maßnahmen für den Largest Contentful Paint (LCP)

  • Time to First Byte (TTFB) senken: Implementieren Sie serverseitiges Caching (z. B. Redis oder Varnish) und optimieren Sie Datenbankabfragen, um die initiale Antwortzeit des Webservers auf unter 800 Millisekunden zu drücken.
  • Kritische Ressourcen vorladen (Preloading): Setzen Sie das HTML-Attribut <link rel="preload"> gezielt für das LCP-Element ein, damit der Browser Hero-Images oder oberste Text-Schriftarten (Fonts) sofort in der ersten Welle lädt.
  • Modernste Bildformate erzwingen: Transformieren Sie alle Bild-Assets in stark komprimierte Next-Gen-Formate wie AVIF oder WebP und nutzen Sie das srcset-Attribut für gerätespezifisch skalierte Auslieferung.
  • Render-blocking CSS eliminieren: Extrahieren Sie das kritische CSS, das für die Darstellung des ersten Sichtbereichs (Above the Fold) nötig ist, direkt in das HTML (inline) und laden Sie restliche Stylesheets asynchron.

Technische Maßnahmen für den Cumulative Layout Shift (CLS)

  • Explizite Dimensionen zuweisen: Hinterlegen Sie für jedes Bildelement, Video und iFrame im HTML-Quelltext feste Breiten- und Höhenattribute (width und height).
  • Platzhalter für dynamischen Content definieren: Reservieren Sie für nachträglich per JavaScript injizierte Inhalte (wie Werbebanner oder Cookie-Hinweise) feste CSS-Mindesthöhen (min-height), um ein plötzliches Aufspringen des Layouts zu verhindern.
  • Schriftarten-Austausch stabilisieren: Nutzen Sie in CSS die Eigenschaft font-display: optional oder passen Sie die Metriken via size-adjust an, damit der Wechsel von der Systemschrift zur Webschrift keine sichtbaren Zeilenverschiebungen auslöst.

Technische Maßnahmen für das Interaction to Next Paint (INP)

  • Lange JavaScript-Tasks aufbrechen: Splitten Sie Skripte, deren Ausführung länger als 50 Millisekunden dauert, mittels setTimeout() oder requestIdleCallback(), um den Hauptthread des Browsers sofort für Nutzereingaben freizugeben.
  • Third-Party-Code minimieren: Reduzieren Sie externe Tracking-Pixel, Tag-Manager-Skripte und Widgets auf das absolute Minimum oder laden Sie diese strikt über die Attribute defer oder async.
  • Layout-Thrashing verhindern: Vermeiden Sie das synchrone Lesen und direkt anschließende Schreiben von DOM-Eigenschaften in derselben JavaScript-Schleife, da dies rechenintensive, mehrfache Layout-Berechnungen des Browsers provoziert.

Quellen – Offizielle Google-Dokumentation

CrUX (Chrome User Experience Report)

INP (Interaction to Next Paint)

Core Web Vitals Gesamtüberblick

Praxis-Tools