Was sind Core Web Vitals? LCP, INP, CLS und die UX der Seitengeschwindigkeit

Kurz gesagt

Core Web Vitals beschreiben mit drei Zahlen, wie sich eine Seite für den Nutzer verhält. web.dev definiert diese drei Metriken als die Teilmenge der Web Vitals, die für jede Webseite gilt.

• LCP (Largest Contentful Paint): der Moment, in dem das größte Bild oder der größte Textblock im sichtbaren Bereich gezeichnet ist. Misst das Laden.
• INP (Interaction to Next Paint): die Reaktionszeit des Bildschirms nach Klicken, Tippen und Tastendruck. Misst die Interaktion.
• CLS (Cumulative Layout Shift): wie stark sich Inhalte unerwartet verschieben. Misst die visuelle Stabilität.

Diese Metriken wirken wie aus einem Entwicklerbericht. Für mich ist jede davon eine gemessene Nutzerbeschwerde: „Die Seite lädt nicht“, „Ich habe gedrückt, aber nichts passiert“, „Ich habe danebengeklickt“.

Schwellenwerte für LCP, INP und CLS

web.dev nennt für jede Metrik zwei Grenzen. Liegt der Wert auf oder unter der Gut-Grenze, gilt er als gut, liegt er über der Schlecht-Grenze, als schlecht. Dazwischen liegt der Bereich „Optimierung erforderlich“.

Metrik	Gut	Optimierung erforderlich	Schlecht
LCP	bis 2,5 s	2,5 s bis 4 s	über 4 s
INP	bis 200 ms	200 ms bis 500 ms	über 500 ms
CLS	bis 0,1	0,1 bis 0,25	über 0,25

Die Tabelle stammt aus dem Artikel von web.dev zu den Schwellenwerten, zuletzt aktualisiert am 7. Mai 2025. Auch die Hauptseite zu Web Vitals (zuletzt aktualisiert am 31. Oktober 2024) nennt dieselben Gut-Grenzen.

Die Regel des 75. Perzentils

Die Schwellenwerte gelten nicht für eine einzelne Messung. web.dev empfiehlt, das 75. Perzentil der Seitenaufrufe zu betrachten und Mobil und Desktop getrennt zu bewerten.

In der Praxis liest man das so: Erfüllen mindestens 75 Prozent der Seitenaufrufe die Gut-Grenze, ist das Ergebnis gut. Liegen mindestens 25 Prozent der Aufrufe im schlechten Bereich, ist das Ergebnis schlecht.

Ich mag diese Regel, weil sie den Nutzer sichtbar macht, den der Durchschnitt versteckt. Im schnellen Büronetz kann alles gut aussehen. Wer ein altes Handy und eine schwache Verbindung hat, sieht eine ganz andere Seite.

Geben Sie unten Ihre eigenen Werte ein. Die Labels nutzen die Grenzen aus der Tabelle oben.

Schwellenwert-Rechner

Dieses Tool braucht JavaScript. Die Schwellenwerte stehen in der Tabelle oben.

Die Labels nutzen die Schwellenwerte von web.dev: Ein Wert genau auf der Gut-Grenze gilt als gut, ein Wert über der Schlecht-Grenze als schlecht. Die Bereiche der Schieberegler habe ich gewählt. Geben Sie hier nicht eine einzelne Messung ein, sondern das 75. Perzentil der Besuche.

LCP: Wann sieht die Seite fertig aus?

LCP ist der Moment, in dem das größte Bild, Video oder der größte Textblock im sichtbaren Bereich gezeichnet ist. Das ist der Moment, in dem der Nutzer sagt: „Die Seite ist da.“ Auf einer Produktseite kann das das Produktfoto sein, in einem Artikel die Überschrift oder der erste Absatz.

Laut web.dev können img-Elemente, image-Elemente in SVG und video-Elemente LCP-Kandidaten sein. Auch Hintergrundbilder, die per CSS url() geladen werden, und Blockelemente mit Text zählen. Verläufe als Hintergrund zählen nicht.

Nach meiner Erfahrung aus Audits beginnt ein Teil der LCP-Probleme am Designtisch. Ein schweres Video auf dem ersten Screen oder eine Überschrift, die an einer spät geladenen Schrift hängt, sind Beispiele dafür.

web.dev empfiehlt für LCP:

• Das Hauptbild steht direkt im HTML-Quelltext, damit der Browser es findet, ohne auf JavaScript zu warten.
• Das Hauptbild bekommt kein Lazy Loading (loading="lazy"). Laut web.dev erzeugt das immer unnötige Verzögerung.
• Das Hauptbild bekommt fetchpriority="high". web.dev empfiehlt, diese Priorität nur ein oder zwei Bildern zu geben.
• Ist das LCP-Element Text in einer Webschrift, wird die Schrift im HTML mit rel="preload" geladen. So entdeckt der Browser sie früh.

Diese Punkte klingen nach Entwicklerarbeit. Aber welches Element zum LCP wird, entscheidet das Design. Ein einziges, klares Hauptbild auf dem ersten Screen macht dem Entwickler die Arbeit leicht.

INP: Ich habe gedrückt, ist etwas passiert?

INP misst, wie eine Seite insgesamt auf Nutzerinteraktionen reagiert. Gezählt werden Mausklicks, Tippen auf Touchscreens und Tastendrücke. Hover, Zoomen und Scrollen zählen nicht.

web.dev definiert INP als Nachfolger der Metrik FID (First Input Delay). FID maß nur die Eingabeverzögerung der ersten Interaktion auf der Seite.

In der Ankündigung schrieb web.dev, dass INP am 12. März 2024 zur Core Web Vital wird und FID ersetzt. Ein später ergänzter Hinweis auf der Seite sagt, dass INP FID offiziell ersetzt hat.

Aus Nutzersicht beantwortet INP eine einfache Frage: Hat das, was ich gedrückt habe, funktioniert? Reagiert der Bildschirm nicht, drücken Menschen ein zweites Mal oder halten die Seite für eingefroren.

Die Doherty-Schwelle ergänzt INP gut. Die Doherty-Schwelle betrachtet die Antwortzeit des Systems, INP die erste Reaktion des Bildschirms. Meine Lehre aus beiden ist dieselbe: Zeigen Sie dem Nutzer sofort, dass Sie ihn warten lassen.

Lange Aufgaben

Laut web.dev ist jede Aufgabe, die länger als 50 Millisekunden dauert, eine lange Aufgabe. Solange sie läuft, blockiert sie den Hauptthread.

web.dev empfiehlt, lange Aufgaben in kleine Teile zu zerlegen und zwischen den Teilen dem Hauptthread den Vortritt zu lassen (yield). So kann der Browser viel früher auf wichtigere Arbeit reagieren, etwa auf eine Nutzerinteraktion.

Die Aufgabe des Designers ist, diese erste Reaktion festzulegen. Gestalten Sie einen Zustand, der sich nach dem Drücken sofort ändert, oder einen Ladeindikator. Während die schwere Arbeit im Hintergrund läuft, sagt der Bildschirm dem Nutzer: „Angekommen.“

CLS: Die rutschende Seite und der Fehlklick

CLS bewertet den größten Schub unerwarteter Layoutverschiebungen, solange die Seite offen ist. web.dev formuliert es so: Eine Verschiebung ist nur schlecht, wenn der Nutzer sie nicht erwartet. Verschiebungen innerhalb von 500 Millisekunden nach einer Nutzereingabe können aus der Berechnung herausfallen.

Laut web.dev entstehen unerwartete Verschiebungen meist, wenn Ressourcen asynchron laden oder neue Elemente über bestehenden Inhalt eingefügt werden. Der Artikel nennt diese Ursachen:

• Bilder und Videos ohne Größenangabe.
• Webschriften, die größer oder kleiner als die Ersatzschrift gezeichnet werden.
• Werbung und eingebettete Inhalte von Dritten, die ihre Größe dynamisch ändern.

Für den Nutzer bedeutet CLS verlorene Lesestelle und Fehlklicks. Auf einer Checkout-Seite statt auf den Bestätigen-Button auf Werbung oder auf Abbrechen zu klicken, ist die teuerste Form der Verschiebung.

Laden Sie unten zuerst die Werbung mit ausgeschaltetem „Platz reservieren“ und bereiten Sie sich darauf vor, vor dem Erscheinen der Werbung auf „Bestellung bestätigen“ zu klicken. Schalten Sie dann „Platz reservieren“ ein und wiederholen Sie das Ganze.

Simulation einer Layoutverschiebung

Warenkorb

2 Artikel, gesamt inkl. Versand 89,90 €

Bestellung bestätigen Bestellung abbrechen

Dieses Beispiel braucht JavaScript. Ohne JavaScript lädt keine Werbung, und die Buttons bleiben an ihrem Platz.

Warenkorb, Werbung und Beträge sind erfunden. Die Werbung kommt mit 2 Sekunden Verzögerung, damit Sie die Verschiebung sehen. Die Buttons bewege ich mit CSS transform und halte die Höhe des Kastens fest, deshalb verschiebt sich diese Seite selbst nicht.

Platz zu reservieren ist im Code oft eine einzige Zeile: dem Werbebereich eine min-height zu geben. web.dev nennt das als einen Weg für Werbung und eingebettete Inhalte. Außerdem empfiehlt es, spät geladene Inhalte weiter unten auf der Seite zu platzieren, damit sie den CLS weniger beeinflussen.

Lösungen auf der Designseite

Ein Teil dieser Metriken wird in der Designdatei gewonnen oder verloren. Diese Punkte schaue ich mir in Audits an.

Bildgrößen

Legen Sie für jedes Bild und Video im Design das Seitenverhältnis fest. web.dev empfiehlt, bei jedem Bild und Video die Attribute width und height zu nutzen. Der andere Weg ist, den Platz per CSS aspect-ratio zu reservieren.

Bei Bildern, die Nutzer hochladen oder die aus dem Admin-Bereich kommen, schwankt das Verhältnis. Definieren Sie dafür im Design einen festen Rahmen und eine Zuschnittregel.

Skeleton Screens

Gestalten Sie für spät geladene Inhalte ein Skeleton in derselben Größe wie der kommende Inhalt. web.dev empfiehlt, den Platz für nachgeladene Oberflächen vorab mit einem Platzhalter oder Skeleton zu reservieren. Kommt der Inhalt, verschiebt sich die Seite nicht, und der Nutzer sieht, was kommt.

Worauf ich achte: Das Skeleton muss dieselbe Höhe haben wie der echte Inhalt. Kommt statt eines dreizeiligen Skeletons ein fünfzeiliger Text, verschiebt sich die Seite trotzdem.

Laden von Schriften

Während eine eigene Schrift lädt, kann der Browser zuerst die Ersatzschrift zeigen. Unterscheiden sich die Maße, ändern sich die Zeilen, und die Seite verschiebt sich. Wählen Sie eine Ersatzschrift, deren Maße der eigenen Schrift nahekommen.

web.dev empfiehlt font-display: optional gegen Neuumbrüche und das Vorladen kritischer Schriften. Ich reduziere außerdem die Schriftschnitte im Design, weil jeder Schnitt eine eigene Datei ist.

Erste Reaktion bei schweren Interaktionen

Gestalten Sie bei Interaktionen wie Filtern, In-den-Warenkorb-Legen oder Formularversand die erste Reaktion eigens. Der Button wechselt sofort in den gedrückten Zustand, das Ergebnis folgt. Bitten Sie den Entwickler, diese Reaktion vor der schweren Arbeit zu zeichnen.

Wer behebt was?

Wenn ich den Bericht im Team verteile, teile ich die Arbeit so auf. Diese Tabelle stammt nicht von web.dev, sie zeigt meine eigene Arbeitsweise.

Metrik	Im Design	Im Code
LCP	Ein Hauptbild auf dem ersten Screen, leichte Schriftwahl	Bild im HTML, Priorität, kein Lazy Loading
INP	Gedrückter Zustand, Ladeindikator, optimistisches Update	Lange Aufgaben zerlegen, erste Reaktion zuerst zeichnen
CLS	Feste Bildverhältnisse, Skeletons, Platz für Banner	Größenattribute, min-height, Einstellung zum Schriftladen

Animationen

Wenn Sie Bewegung gestalten, verschieben Sie Elemente nicht mit top oder left, sondern mit transform. web.dev empfiehlt transform-Animationen zum Verschieben, Skalieren, Drehen und Neigen. Deshalb habe ich auch die Demo oben mit transform gebaut.

Wie misst man?

Core Web Vitals werden mit echten Nutzerdaten bewertet. Der Chrome User Experience Report (CrUX) sammelt für jede Metrik anonyme Daten echter Nutzer. Diese Daten speisen PageSpeed Insights, die Chrome DevTools und den Core-Web-Vitals-Bericht in der Search Console.

Als Laborwerkzeuge nennt web.dev die Chrome DevTools und Lighthouse. Lighthouse kann INP nicht messen, weil es keine Nutzereingabe gibt. Im Labor dient die Total Blocking Time (TBT) als Näherung für INP.

Um eigene Messwerte zu sammeln, nennt web.dev die JavaScript-Bibliothek web-vitals als einfachsten Weg. Ich nutze beide Quellen zusammen: Felddaten zeigen, ob es ein Problem gibt, Labormessungen zeigen die Ursache.

Meine Notiz

Ich lese Core Web Vitals wie einen Zähler für drei Nutzerbeschwerden. Sehe ich im Bericht einen schlechten LCP, schaue ich zuerst auf den ersten Screen. Was sieht der Nutzer dort zuerst, und warum kommt es so spät?

Die häufigste Ursache für Verschiebungen in meinen Audits sind nachträglich erscheinende Banner. Ein Cookie-Hinweis oder ein Aktionsstreifen fährt oben ein und schiebt alles nach unten. Meist reicht es, dafür von Anfang an Platz zu reservieren oder sie unten am Bildschirm zu fixieren.

Auf dieser Website halte ich für Mobil ein strengeres Budget als die Gut-Grenzen von web.dev: im 75. Perzentil LCP unter 2 Sekunden, INP unter 150 Millisekunden, CLS unter 0,05. Wer knapp unter der Grenze bleibt, liegt auf langsamen Geräten schnell darüber.

Eine schnelle Seite rettet keinen schlechten Ablauf. Das Formular öffnet sich in einer Sekunde, und der Nutzer hängt trotzdem an der Fehlermeldung. Deshalb betrachte ich Core Web Vitals als Teil einer Ablaufanalyse.

Bei Arbeiten zur E-Commerce-UX schaue ich zuerst auf die Checkout-Seite und die Produktdetailseite. Wenn Sie diese drei Metriken zusammen mit Designentscheidungen sehen wollen: Der UX Audit schaut auch darauf. Wie der Prozess abläuft, beschreibe ich im Ratgeber zum UX-Audit.