Was sind die Core Web Vitals?

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 im Suchalgorithmus?

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 hat

Interaction to Next Paint (INP) ist eine von Google definierte Core-Web-Vitals-Metrik, welche die kontinuierliche Reaktionsfähigkeit einer Webseite auf sämtliche Nutzerinteraktionen während der gesamten Besuchsdauer misst.

Im März 2024 hat INP den alten Rankingfaktor First Input Delay (FID) vollständig abgelöst. Während FID ausschließlich die rein technische Verzögerung bei der allerersten Interaktion eines Nutzers erfasste und somit unvollständige Daten lieferte, bewertet INP die tatsächliche Benutzerfreundlichkeit (UI-Reaktionszeit) über den gesamten Lebenszyklus einer Sitzung hinweg. Ein exzellenter INP-Wert liegt mathematisch bei unter 200 Millisekunden und wird im 75. Perzentil realer Felddaten im Chrome User Experience Report (CrUX) gemessen.


Wie schlechte Core Web Vitals Ihre Rankings über NavBoost zerstören

Die Core Web Vitals wirken im Page-Experience-System von Google nicht nur als direkter, technischer Rankingfaktor, sondern steuern maßgeblich die Kausalkette nachgelagerter Nutzersignale.

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.