Plaximo

Core Web Vitals verstehen und gezielt verbessern

LCP, INP und CLS bestimmen, wie schnell und stabil eine Seite wirkt. Was die drei Werte messen, welche Schwellen gelten und welche Hebel sie verbessern.

5 Min. Lesezeit

Was Google wirklich misst

Google bewertet die Qualität einer Seite nicht nach Gefühl, sondern nach messbaren Größen. Drei davon bilden seit 2020 die Core Web Vitals und fließen seitdem als Signal in das Ranking ein. Sie beschreiben drei unterschiedliche Aspekte des Erlebnisses, das eine Seite im Browser auslöst.

Largest Contentful Paint (LCP) erfasst, wann das größte sichtbare Element geladen ist. Das ist meist das Hero-Bild oder die Hauptüberschrift. Interaction to Next Paint (INP) misst, wie schnell die Seite auf Eingaben reagiert, etwa auf einen Klick oder eine Tastatureingabe. Cumulative Layout Shift (CLS) beschreibt, wie stark Inhalte während des Ladens verspringen.

INP hat im März 2024 die ältere Metrik First Input Delay abgelöst. Der Grund liegt in der Genauigkeit. FID maß nur die Verzögerung der ersten Interaktion, INP betrachtet alle Interaktionen über die gesamte Sitzung und gibt den nahezu schlechtesten Wert aus.

Die drei Werte und ihre Schwellen

Jede Metrik kennt drei Bereiche. Maßgeblich ist immer das 75. Perzentil der realen Seitenaufrufe, also der Wert, den drei von vier Besuchen erreichen oder unterbieten. Eine Seite gilt erst dann als bestanden, wenn alle drei Werte im grünen Bereich liegen.

MetrikGutVerbesserung nötigSchlechtWichtigster Hebel
LCPunter 2,5 s2,5 bis 4 süber 4 sHero-Ressource priorisieren, Server beschleunigen
INPunter 200 ms200 bis 500 msüber 500 mslanges JavaScript aufbrechen, Hauptthread entlasten
CLSunter 0,10,1 bis 0,25über 0,25feste Maße für Bilder, Schriften und Werbeflächen

Eine Seite besteht die Core Web Vitals erst, wenn LCP, INP und CLS gleichzeitig im grünen Bereich liegen. Ein einzelner Ausreißer zieht das Gesamturteil nach unten.

LCP, wann der Inhalt sichtbar wird

LCP ist die Zeit bis zum größten sichtbaren Element. Vier Faktoren bestimmen diesen Wert, und jeder davon lässt sich gezielt angehen.

Der erste ist die Antwortzeit des Servers, gemessen als Time to First Byte. Je länger sie ausfällt, desto später beginnt das Laden, und der gesamte LCP verschiebt sich nach hinten. Ein vorgeschaltetes CDN, serverseitiges Rendering und schlanke Datenbankabfragen verkürzen diese Phase. Der zweite Faktor sind blockierende Ressourcen. CSS und Render-blockierendes JavaScript verzögern den ersten sinnvollen Frame, deshalb sollte kritisches CSS inline im Kopf der Seite stehen und der Rest asynchron nachladen.

Der dritte Faktor ist die LCP-Ressource selbst. Ist das größte Element ein Bild, hilft ein modernes Format wie WebP oder AVIF, eine passende Größe statt eines überdimensionierten Originals und ein fetchpriority="high" auf dem entscheidenden Bild. Der vierte Faktor ist die Darstellung auf der Client-Seite. Wird der Hauptinhalt erst per JavaScript zusammengesetzt, verschiebt sich der LCP nach hinten, weshalb der wichtigste Inhalt schon im ausgelieferten HTML stehen sollte.

INP, wie schnell die Seite antwortet

INP misst die Spanne zwischen einer Eingabe und der nächsten sichtbaren Reaktion des Bildschirms. Hohe Werte entstehen fast immer durch einen überlasteten Hauptthread. Wenn JavaScript dort lange Aufgaben ausführt, kann der Browser auf Klicks erst reagieren, wenn die Aufgabe beendet ist.

Die wirksamsten Hebel zielen daher auf den Hauptthread.

  • Lange Aufgaben in kleinere Stücke teilen, sodass der Browser zwischendurch auf Eingaben reagieren kann
  • Nicht dringende Arbeit aufschieben, etwa über requestIdleCallback oder scheduler.yield
  • Aufwendige Berechnungen in einen Web Worker auslagern, weg vom Hauptthread
  • Den Umfang des ausgelieferten JavaScript reduzieren, denn weniger Code bedeutet weniger Ausführung
  • Drittanbieter-Skripte prüfen, da Analyse- und Chat-Werkzeuge den Hauptthread oft unbemerkt belasten

INP lässt sich nur im Feld vollständig beurteilen, weil echte Interaktionen nötig sind. Labordaten geben einen Anhaltspunkt, das verbindliche Urteil liefern die Felddaten aus dem Chrome User Experience Report.

CLS, warum das Layout ruhig bleiben muss

CLS beschreibt das Verspringen von Inhalten während des Ladens. Der klassische Fall ist ein Klick, der ins Leere geht, weil sich im letzten Moment ein Bild oder ein Banner dazwischenschiebt. Der Wert ist kein Zeitmaß, sondern ein Anteil, der die Fläche und die Distanz der Verschiebungen kombiniert.

Die Ursachen sind überschaubar und damit gut beherrschbar. Bilder und Videos ohne feste Maße reservieren keinen Platz, deshalb gehören width und height oder ein definiertes aspect-ratio an jedes Medium. Schriften, die spät laden und den Text neu umbrechen, verschieben das Layout, was sich mit font-display: optional oder vorab geladenen Schriften vermeiden lässt. Nachträglich eingefügte Elemente wie Banner oder Hinweise brauchen einen reservierten Platz, statt bestehenden Inhalt nach unten zu drücken.

Animationen richtig umsetzen

Bewegung ist erlaubt, solange sie das Layout nicht verschiebt. Transformationen über transform und opacity laufen außerhalb des Layoutflusses und zählen nicht in den CLS ein. Animationen über top, left, width oder height dagegen lösen Reflows aus und verschlechtern den Wert.

Labor gegen Feld, beide haben ihre Rolle

Für die Messung gibt es zwei Quellen, die sich ergänzen. Labordaten entstehen in einer kontrollierten Umgebung mit fester CPU-Drosselung und definierter Verbindung. Lighthouse in den Chrome DevTools liefert sie und eignet sich zum Debuggen, weil das Ergebnis reproduzierbar ist.

Felddaten stammen aus echten Besuchen und fließen über den Chrome User Experience Report in das Ranking ein. PageSpeed Insights zeigt beide Quellen nebeneinander, die Search Console bündelt die Felddaten über alle Seiten einer Domain. Vor jeder Behauptung über Performance steht die Messung auf gedrosselter CPU, nicht die Schätzung.

Eine Zahl ohne Messumgebung ist wertlos. Erst die Angabe, ob ein Wert aus dem Labor oder aus dem Feld stammt, macht ihn vergleichbar.

Vorgehen in der Praxis

Die drei Werte hängen zusammen, lassen sich aber getrennt angehen. Sinnvoll ist die Reihenfolge LCP, dann CLS, dann INP, weil die ersten beiden meist mit klar umrissenen Eingriffen lösbar sind, während INP eine genauere Analyse des JavaScript-Verhaltens braucht.

Dieses Vorgehen entspricht unserer Methodik. Erst weiter denken, was die größte Bremse ist, dann weiter planen, in welcher Reihenfolge die Hebel greifen, dann weiter umsetzen und am Ende weiter gehen, indem die Werte im Feld dauerhaft überwacht werden. Mehr zu dieser Haltung steht auf der Seite Mission. Wer den aktuellen Stand einer Seite kennen will, kann eine Messung über die Seite Kontakt anfragen.


Eine Messung mit konkreten Vorher-Nachher-Werten zeigt, wo eine Seite bei LCP, INP und CLS wirklich steht. Wir messen und optimieren.

Einen Schritt weiter

Aus einem Gedanken wird ein Projekt, sobald das Gespräch beginnt.