Core Web Vitals: LCP, INP und CLS verständlich erklärt

Die drei Metriken und ihre Grenzwerte

Die Core Web Vitals sind drei Kennzahlen, mit denen Google die Nutzererfahrung einer Seite beschreibt. Stand: Oktober 2026 nennt web.dev diese Zielwerte:

Gemessen wird am 75. Perzentil der Seitenaufrufe, getrennt nach Mobilgeräten und Desktop. Das heißt: Mindestens 75 Prozent der Aufrufe müssen den Zielwert erreichen. Eine Seite besteht nach web.dev nur, wenn alle drei Metriken diesen Wert schaffen.

LCP ist der Zeitpunkt, an dem das größte sichtbare Element gerendert ist. Dazu zählen <img>, <image> in SVG, <video> (Poster oder erstes Bild), Elemente mit url()-Hintergrundbild und Blockelemente mit Text. INP erfasst die Latenz aller Klicks, Taps und Tastendrücke eines Besuchs und meldet die schlechteste, ohne Ausreißer. Scrollen und Hovern zählen nicht. CLS ist der größte Ausschlag unerwarteter Layoutverschiebungen: Verschiebungen innerhalb von weniger als einer Sekunde Abstand bilden ein Fenster von höchstens fünf Sekunden, das Fenster mit dem höchsten Wert zählt.

INP hat FID abgelöst

Vor INP war First Input Delay (FID) die Interaktivitätsmetrik. FID erfasste nur die Verzögerung der ersten Interaktion, INP betrachtet alle Interaktionen. web.dev beschreibt INP als Nachfolger von FID. INP wurde 2023 als „pending" geführt und 2024 ein stabiler Core Web Vital. Wer noch FID in Berichten oder alten Artikeln findet, arbeitet mit überholten Angaben.

Was Google zum Ranking sagt

Google schreibt in der Dokumentation zur Page Experience: „Core Web Vitals werden von unseren Ranking-Systemen genutzt." Im gleichen Atemzug: Gute Werte garantieren keine Spitzenplätze, und ein perfekter Score allein aus SEO-Gründen ist nicht unbedingt der beste Einsatz deiner Zeit. Andere Aspekte der Page Experience helfen laut Google nicht direkt beim Ranking. Es gibt dort ausdrücklich „kein einzelnes Signal", und Google zeigt weiterhin das relevanteste Ergebnis, selbst wenn die Seitenerfahrung mäßig ist.

Für dich bedeutet das: Behandle die Metriken als Qualitätsziel für Nutzer. Sie sind ein Faktor unter vielen, und Relevanz schlägt Geschwindigkeit. Der Kontext in einer Gesamtstrategie steht im Leitfaden zu technischem SEO.

Messen: Felddaten und Labordaten

web.dev unterscheidet:

• Felddaten stammen von echten Nutzern und sind die maßgebliche Messung. Laborwerte sind laut web.dev kein Ersatz dafür. In der Search Console zeigt der Core-Web-Vitals-Bericht, wie deine Seiten abschneiden.
• Labordaten entstehen in kontrollierten Umgebungen wie den Chrome DevTools oder Lighthouse. Sie helfen in der Entwicklung und bei der Erkennung von Regressionen.

Lighthouse kann INP nicht messen, weil kein Nutzer interagiert. Als Stellvertreter im Labor dient die Total Blocking Time (TBT). Wenn eine Seite im Lab gut und im Feld schlecht aussieht, liegt es oft an echten Geräten, Netzen oder Interaktionen, die dein Testlauf nicht abbildet.

LCP verbessern

web.dev zerlegt die LCP-Zeit in vier Teile mit Richtwerten für ihren Anteil:

Die Prozentwerte sind Richtlinien, keine strikten Regeln. Die beiden Verzögerungen sollten möglichst nahe null liegen. Daraus folgen diese Maßnahmen:

1. Die LCP-Ressource früh laden. Ist das Bild nur in CSS oder JavaScript referenziert, entdeckt der Browser es spät. Ein Preload im HTML hilft:

<link rel="preload" fetchpriority="high" as="image" href="/bilder/hero.webp" type="image/webp">

2. Priorität setzen. Mit fetchpriority="high" auf dem <img>, das voraussichtlich das LCP-Element ist, signalisierst du dem Browser die Wichtigkeit. web.dev warnt: Setzt du es auf mehr als ein oder zwei Bildern, verliert es an Wirkung. Das Attribut ist ein Hinweis, keine Garantie. MDN führt fetchPriority als Baseline 2024 („newly available"), es funktioniert seit Oktober 2024 in den aktuellen Browsern, aber möglicherweise nicht in älteren.

<img src="/bilder/hero.webp" alt="Produktfoto" width="1200" height="600" fetchpriority="high">

3. Das LCP-Bild nicht lazy laden. loading="lazy" verzögert das Bild, bis das Layout bestätigt, dass es im Viewport liegt, und erhöht so die Ladeverzögerung. web.dev sagt: niemals das LCP-Bild lazy laden. Für Bilder weiter unten auf der Seite ist Lazy Loading dagegen richtig, wie im Artikel zu JavaScript-SEO beschrieben.

<!-- Nicht für das LCP-Bild -->
<img src="/bilder/hero.webp" alt="Produktfoto" loading="lazy">

4. TTFB senken. Die Serverantwort ist neben dem Download der Ressource einer der beiden größten Blöcke. Wird die Seite bei jedem Aufruf dynamisch gerendert, können Caching und vorab erzeugte Seiten helfen, etwa mit Astro und statischen Websites. Ob und wie viel das bei dir bringt, zeigt erst die Messung.

INP verbessern

Die Latenz einer Interaktion setzt sich aus drei Phasen zusammen: Input Delay (bis die Event-Handler starten), Verarbeitungsdauer (die Handler selbst) und Presentation Delay (bis das nächste Bild gezeichnet ist). Die zentralen Hebel aus web.dev:

• Lange Tasks aufbrechen. Pausiere zwischendurch, damit der Browser Eingaben bearbeiten kann. web.dev: „Wahlloses Yielden ist besser als gar kein Yielden."
• Zuerst die UI aktualisieren, dann den Rest verschieben.
• Layout-Thrashing vermeiden: nicht Stile ändern und im selben Task Layoutwerte lesen.
• DOM klein halten, content-visibility für Bereiche außerhalb des Bildschirms nutzen und nicht große HTML-Mengen im Client rendern.

Zum Yielden verwendet web.dev setTimeout, nach eigener Aussage in allen Browsern funktionierend. Eine modernere Methode ist scheduler.yield(). MDN markiert sie ausdrücklich als nicht Baseline („limited availability"), weil sie in einigen der meistgenutzten Browser nicht funktioniert. Deshalb brauchst du Feature-Erkennung und einen Fallback:

function yieldToMain() {
  if (globalThis.scheduler?.yield) {
    return globalThis.scheduler.yield();
  }
  return new Promise((resolve) => setTimeout(resolve, 0));
}

async function processInChunks(items, handle, budgetMs = 50) {
  let deadline = performance.now() + budgetMs;
  for (const item of items) {
    handle(item);
    if (performance.now() > deadline) {
      await yieldToMain();
      deadline = performance.now() + budgetMs;
    }
  }
}

Der Helfer arbeitet die Elemente ab und gibt nach etwa 50 Millisekunden die Kontrolle ab, damit anstehende Eingaben bearbeitet werden können. Im Testlauf mit Node.js, wo nur der setTimeout-Fallback aktiv ist, wurden 200 Elemente verarbeitet und ein parallel laufender Timer feuerte zwischendurch, der Main Thread war also zwischenzeitlich frei:

sum 19900 timer lief zwischendurch: true

Bei scheduler.yield() wird die Fortsetzung laut MDN als priorisierter Task geplant. Das gilt nur dort, wo die Methode vorhanden ist.

CLS verbessern

Layoutverschiebungen entstehen, wenn Inhalte nachladen und Platz beanspruchen, der vorher nicht reserviert war. Die Maßnahmen aus web.dev:

Bilder mit Abmessungen versehen, damit der Browser den Platz vorab reserviert, und per CSS responsiv halten:

<img src="/bilder/produkt.jpg" width="640" height="360" alt="Produkt">

img {
  width: 100%;
  height: auto;
}

Platz für späte Inhalte reservieren (Anzeigen, Einbettungen, iframes), etwa mit aspect-ratio oder min-height. Zeigt ein Platz am Ende doch keinen Inhalt, sollte ein Platzhalter bleiben, sonst entsteht beim Einklappen die Verschiebung.

.video-slot {
  width: 100%;
  aspect-ratio: 16 / 9;
}
.ad-slot {
  min-height: 250px;
}

Webfonts: font-display: optional nutzt die Schrift nur, wenn sie beim ersten Layout bereit ist. Dazu eine passende Ersatzschrift angeben und kritische Fonts vorladen.

@font-face {
  font-family: "Beispielschrift";
  src: url("/fonts/beispielschrift.woff2") format("woff2");
  font-display: optional;
}
body {
  font-family: "Beispielschrift", sans-serif;
}

Animationen mit transform statt top oder left, denn Letztere lösen Layoutverschiebungen aus. Außerdem zählen Verschiebungen nicht, die innerhalb von 500 ms nach einer Nutzereingabe passieren. Inhalte per Klick („Mehr laden") nachzuladen ist also unkritisch. Zuletzt rät web.dev, Seiten für den Back/Forward-Cache geeignet zu halten: Wiederhergestellte Seiten erscheinen ohne die Verschiebungen des Ladevorgangs.

Symptome und Ursachen auf einen Blick

Die Tabelle verbindet typische Beobachtungen mit der betroffenen Metrik und dem passenden Hebel. Sie fasst die Maßnahmen von web.dev zusammen.

Arbeite nach der Reihenfolge der Search Console: erst die Seitengruppe mit den meisten Aufrufen, dann die Metrik mit dem größten Abstand zum Zielwert. Sitzt ein Problem in einem Template, kann eine einzelne Änderung mehrere Seiten betreffen. Prüfe das nach dem Release im Bericht.

Messen mit der web-vitals-Bibliothek

Mit der JavaScript-Bibliothek web-vitals erfasst du LCP, INP und CLS bei echten Nutzern, also als Felddaten für deine eigene Auswertung. Der Code ist illustrativer Browsercode: Er setzt ein Bündelungs- oder Modulsystem voraus, das die Bibliothek bereitstellt, und einen Endpunkt /analytics, den du selbst bauen musst.

import {onCLS, onINP, onLCP} from 'web-vitals';

function sendToAnalytics(metric) {
  const body = JSON.stringify({
    name: metric.name,
    value: metric.value,
    rating: metric.rating,
    id: metric.id,
  });
  navigator.sendBeacon('/analytics', body);
}

onLCP(sendToAnalytics);
onINP(sendToAnalytics);
onCLS(sendToAnalytics);

Jeder Callback bekommt ein Objekt mit name, value, rating (good, needs-improvement oder poor), delta und id. sendBeacon() kann laut README auch Daten senden, während die Seite entladen wird. Manche Metriken melden erst, wenn der Nutzer mit der Seite interagiert hat, oder wenn der Tab gewechselt wird. Für die Fehlersuche gibt es einen Attribution-Build (web-vitals/attribution), der etwa beim INP das auslösende Element und die Phase der Verzögerung liefert. Er ist etwas größer, setze ihn deshalb nur ein, wenn du diese Daten wirklich nutzt.

Daten von Nutzern zu erfassen und an einen Endpunkt zu schicken, kann je nach Ausgestaltung rechtlich relevant sein. Wie du Messung und Datenfluss grundsätzlich organisierst, beschreibt der Artikel zu Server-Side Tracking; eine Rechtsberatung ersetzt er nicht.

Nächster Schritt

Öffne in der Search Console den Core-Web-Vitals-Bericht und notiere die Seitengruppen mit „Verbesserungsbedarf" oder „Schlecht". Nimm die wichtigste Gruppe, bestimme die auffällige Metrik und prüfe die Maßnahmen dieses Artikels in dieser Reihenfolge: bei LCP Preload, fetchpriority und kein Lazy Loading auf dem Hero-Bild; bei INP die längsten Tasks aufbrechen; bei CLS Bilder und Slots mit festen Abmessungen. Miss danach im Feld erneut. Felddaten sammeln sich erst über die Zeit, bewerte das Ergebnis also erst, wenn genügend Aufrufe vorliegen.