Was sind die Core Web Vitals: LCP, INP und CLS mit Schwellenwerten erklärt

Die Core Web Vitals sind drei von Google definierte Metriken, die das reale Lade- und Interaktionserlebnis einer Seite messen: LCP (Largest Contentful Paint) misst, wie lange der Hauptinhalt braucht, um zu erscheinen, INP (Interaction to Next Paint) misst, wie schnell die Seite auf Nutzerinteraktionen reagiert, und CLS (Cumulative Layout Shift) misst, wie stark sich Inhalte unerwartet verschieben. Eine Seite besteht die Bewertung, wenn 75 % ihrer echten Besuche innerhalb der „guten“ Schwellenwerte liegen: LCP ≤ 2,5 s, INP ≤ 200 ms und CLS ≤ 0,1.

Dieser Artikel erklärt, was jede Metrik misst, woher die Daten stammen und was sie typischerweise verschlechtert, ohne Ranking-Versprechen zu machen, die Google selbst nicht gibt.

Die drei Metriken und ihre Schwellenwerte

Metrik	Was sie misst	Gut	Verbesserungswürdig	Schlecht
LCP	Zeit, bis das größte sichtbare Inhaltselement gezeichnet ist	≤ 2,5 s	2,5 – 4 s	> 4 s
INP	Latenz von Interaktionen (Klicks, Taps, Tastendrücke) über den gesamten Besuch	≤ 200 ms	200 – 500 ms	> 500 ms
CLS	Summe unerwarteter Layoutverschiebungen	≤ 0,1	0,1 – 0,25	> 0,25

Die Schwellenwerte gelten für das 75. Perzentil der Besuche: Eine Seite besteht eine Metrik, wenn mindestens drei von vier Nutzererlebnissen im guten Bereich liegen. Das ist bewusst anspruchsvoll, damit es nicht reicht, auf einem leistungsstarken Rechner mit guter Verbindung schnell zu sein.

LCP: wann der wichtige Teil erscheint

LCP markiert den Moment, in dem der Browser das größte Element innerhalb des Viewports zeichnet: meist ein Titelbild, ein Video mit Poster oder ein großer Textblock. Was es am stärksten verzögert:

• Schwere Hauptbilder oder solche mit niedriger Priorität (siehe Lazy Loading und fetchpriority).
• Langsame Serverantwort (hohe TTFB).
• Render-blockierendes CSS oder JavaScript.
• Webfonts, die die Textanzeige verzögern.

INP: wie die Seite reagiert

INP hat im März 2024 FID (First Input Delay) als Core Web Vital abgelöst. Anders als FID, das nur die erste Interaktion maß, beobachtet INP jede Interaktion des Besuchs und meldet eine der schlechtesten (in der Praxis die langsamste, wobei auf Seiten mit sehr vielen Interaktionen einige Ausreißer ignoriert werden). Gemessen wird vom Moment der Interaktion bis der Browser den nächsten Frame zeichnet.

Was INP verschlechtert, ist fast immer JavaScript: lange Tasks im Hauptthread, schwere Event-Handler, Frameworks, die die ganze Seite hydrieren, bevor sie reagieren, Drittanbieter-Skripte (Werbung, Analytics, Chats), die um die CPU konkurrieren.

CLS: nichts darf springen

CLS summiert die Verschiebungen sichtbarer Elemente, die passieren, ohne dass der Nutzer sie ausgelöst hat. Die klassischen Ursachen:

• Bilder, Videos oder iframes ohne width und height.
• Anzeigen oder Einbettungen, die ohne reservierten Platz eingefügt werden.
• Webfonts, die beim Laden die Textgröße verändern.
• Dynamisch eingefügte Inhalte oberhalb des bereits Sichtbaren (Hinweise, Banner).

Wenn eine Website Werbung anzeigen soll, ist das Reservieren der Höhe jedes Anzeigenplatzes vor dem Laden die wirksamste Maßnahme gegen CLS.

Woher die Daten stammen: Feld und Labor

Es gibt zwei Arten von Messung, die man nicht verwechseln sollte:

• Felddaten (echt). Sie stammen von echten Chrome-Nutzern, die der Weitergabe von Statistiken zugestimmt haben, gesammelt im Chrome UX Report (CrUX). Diese Daten verwendet die Google Search Console im Bericht zu den Core Web Vitals, und sie zählen für die Bewertung. Sie existieren nur, wenn die Seite genug Traffic hat.
• Labordaten (simuliert). Erzeugt von einem Werkzeug wie Lighthouse oder PageSpeed Insights in einer kontrollierten Umgebung. Nützlich zum Diagnostizieren und Reproduzieren von Problemen, aber sie spiegeln nicht die Vielfalt echter Geräte und Verbindungen wider. INP lässt sich im Labor zudem gar nicht messen, weil es von Nutzerinteraktionen abhängt (Lighthouse bietet TBT, Total Blocking Time, als Näherung).

PageSpeed Insights zeigt beides: oben die CrUX-Felddaten (falls vorhanden) und darunter die Laboranalyse.

Wie du sie auf deiner Website misst

1. PageSpeed Insights (pagespeed.web.dev): URL eingeben und zuerst den Abschnitt mit echten Daten ansehen.
2. Google Search Console, Bericht „Core Web Vitals“: gruppiert die URLs der Website nach Status (gut, verbesserungswürdig, schlecht) auf Basis von CrUX.
3. Chrome DevTools, Panel „Performance“: zeigt LCP, INP und CLS live beim Surfen und markiert das jeweils verantwortliche Element.
4. Die Bibliothek web-vitals (npm install web-vitals): erlaubt, die Metriken bei den eigenen Nutzern zu erfassen und an die eigene Analytics-Lösung zu senden.

Wie sie mit dem Ranking zusammenhängen

Google erklärt in seiner Search-Dokumentation, dass die Core Web Vitals Teil der Signale zur Seitenerfahrung sind, und empfiehlt Website-Betreibern gute Werte, stellt aber auch klar, dass relevanter, hochwertiger Inhalt das Wichtigste bleibt und exzellente Vitals schlechten Inhalt nicht ausgleichen. Es ist vernünftig, sie als das zu behandeln, was sie sind: ein Qualitätsmaß für Nutzer, das zugleich einen Nachteil gegenüber Konkurrenten mit gleich relevanten, aber schnelleren Seiten vermeidet.

Häufige Fehler beim Optimieren

• Nur für Lighthouse optimieren. Eine Punktzahl von 100 im Labor garantiert keine guten Felddaten, wenn deine echten Nutzer bescheidene Smartphones verwenden.
• Das LCP-Bild verzögern. loading="lazy" auf dem Hauptbild verschlechtert LCP.
• Drittanbieter-Skripte unkontrolliert laden. Sie sind die häufigste Ursache für hohes INP. Lade nur das Nötigste, und wenn etwas von der Einwilligung des Nutzers abhängt, lade es erst, wenn sie vorliegt.
• CLS durch Werbung ignorieren. Reserviere Platz mit min-height auf jedem Anzeigenplatz.

Fazit

LCP, INP und CLS fassen in drei Zahlen zusammen, ob eine Seite schnell erscheint, schnell reagiert und nicht springt. Sie werden mit echten Nutzerdaten am 75. Perzentil bewertet und durch konkrete Entscheidungen verbessert: das Hauptbild priorisieren, JavaScript minimieren und verzögern, Abmessungen deklarieren und Platz für alles reservieren, was spät eingefügt wird. Miss zuerst im Feld, bevor du optimierst; nutze dann das Labor, um die Ursache zu finden.