Core Web Vitals 2026: LCP, INP und CLS Grenzwerte

Google bewertet die Nutzererfahrung von Websites anhand von drei Hauptmetriken, unterstützt durch serverseitige Metriken wie Time to First Byte (TTFB). Jede Metrik enthält drei Leistungsbewertungen: Gut, Verbesserungswürdig und Schlecht. Google berechnet diese Metriken unabhängig für mobile und Desktop-Besuche unter Verwendung von Felddaten echter Nutzer, die vom Chrome User Experience Report gesammelt wurden.

• Largest Contentful Paint (LCP): Gut ist 2,5 Sekunden oder weniger; Schlecht ist mehr als 4,0 Sekunden.
• Interaction to Next Paint (INP): Gut ist 200 Millisekunden oder weniger; Schlecht ist mehr als 500 Millisekunden.
• Cumulative Layout Shift (CLS): Gut ist 0,1 oder weniger; Schlecht ist mehr als 0,25.
• Time to First Byte (TTFB): Das gute Ziel liegt bei 0,8 Sekunden oder weniger, um die anfängliche Antwortbereitstellung zu unterstützen.

Um in Search Console-Berichten ein Bestehen zu erreichen, müssen 75 Prozent der Seitenaufrufe, die während eines 28-Tage-Fensters aufgezeichnet wurden, den Schwellenwert „Gut“ für jede Metrik erreichen. Wenn auch nur eine Metrik am 75. Perzentil in die Kategorie „Verbesserungswürdig“ oder „Schlecht“ fällt, besteht die URL die Gesamtbewertung nicht.

Gerätefähigkeiten und Netzwerkgeschwindigkeiten variieren erheblich zwischen Desktop-Computern und Mobilgeräten. Smartphone-CPUs sind im Allgemeinen weniger leistungsfähig als Desktop-Prozessoren, und die Latenz des Mobilfunknetzes ändert sich je nach Signalstärke. Die separate Messung der Leistung verhindert, dass starke Desktop-Metriken schlechte mobile Nutzererfahrungen verbergen.

Der Schwellenwert am 75. Perzentil stellt sicher, dass die Mehrheit der Besucher eine leistungsstarke Web-Erfahrung erhält. Wenn 74 Prozent der mobilen Sitzungen in unter 2,5 Sekunden laden, aber 26 Prozent längere Wartezeiten erleben, fällt die Seite in die Kategorie „Verbesserungswürdig“. Dieser Ansatz ermutigt technische Teams, robuste Websites zu erstellen, die auf Geräten der unteren Preisklasse und bei langsameren Verbindungen konsistent funktionieren.

Largest Contentful Paint verfolgt die Zeit, die benötigt wird, um das Hauptelement im Viewport des Nutzers zu rendern, wie z. B. ein Hero-Banner-Bild, ein Video-Thumbnail oder einen großen Textblock. Hohe LCP-Werte resultieren meist aus langsamen Serverantwortzeiten, Render-blockierendem CSS oder JavaScript und verzögertem Herunterladen von Assets. Zielen Sie auf eine Time to First Byte (TTFB) von 0,8 Sekunden oder weniger ab, um dem Browser genügend Zeit zu geben, kritische Assets zu laden.

In einem typischen E-Commerce-Shop mit hochauflösenden Bildern dient das Hero-Bild auf Produktseiten häufig als LCP-Element. Wenn Webseiten Lazy Loading auf Medien im sichtbaren Bereich anwenden, verzögern Browser das Herunterladen dieser Assets, bis die JavaScript-Ausführung abgeschlossen ist. Um das Laden zu beschleunigen, entfernen Sie Lazy Loading von Haupt-Header-Bildern und wenden Sie das Attribut fetchpriority=”high” direkt auf das HTML-Tag an.

Die Optimierung der CSS-Bereitstellung verbessert ebenfalls die LCP-Zeiten. Überflüssige CSS-Regeln blockieren das Rendern des Haupt-Threads, bevor der Browser den visuellen Hauptblock zeichnen kann. Extrahieren Sie kritisches CSS, das für das Rendern des anfänglichen Viewports erforderlich ist, in Inline-Style-Tags, während Sie nicht-kritische externe Stylesheets zurückstellen.

Interaction to Next Paint bewertet die allgemeine Reaktionsfähigkeit der Seite, indem die Zeit zwischen Nutzeraktionen – wie dem Tippen auf eine Schaltfläche oder der Texteingabe – und der anschließenden visuellen Frame-Aktualisierung gemessen wird. Hohe INP-Werte treten auf, wenn lange Aufgaben auf dem Haupt-Browser-Thread ausgeführt werden, was ein sofortiges UI-Rendering verhindert.

Um INP unter 200 Millisekunden zu halten, muss Front-End-Code die Ausführung langer Aufgaben vermeiden, die 50 Millisekunden überschreiten. Entwickler können monolithische Funktionen in kleinere asynchrone Ausführungsblöcke unterteilen, indem sie native API-Optionen wie setTimeout oder scheduler.yield() verwenden. Dies ermöglicht es dem Haupt-Thread des Browsers, Nutzerereignisse schnell zwischen den Ausführungsschritten zu verarbeiten.

Skripte von Drittanbietern wie Live-Chat-Widgets, Analytik-Tracker und Marketing-Pixel lösen häufig unerwartete Verzögerungen des Haupt-Threads aus. Bei einem typischen Website-Audit blockiert das gleichzeitige Ausführen mehrerer Drittanbieter-Tags die Thread-Ausführung während Klicks auf Schaltflächen. Überprüfen Sie externe Skripte regelmäßig, laden Sie nicht-essenzielle Tags asynchron oder verlagern Sie Hintergrundberechnungen in Web-Worker.

Cumulative Layout Shift quantifiziert die visuelle Stabilität, indem gemessen wird, wie oft Layout-Elemente während des Seiten-Renderings unerwartet verschoben werden. Layout-Verschiebungen treten auf, wenn Elemente asynchron ohne vorab reservierten Platz geladen werden, was dazu führt, dass sich vorhandene Inhalte plötzlich bewegen.

Die Hauptursache für hohe CLS-Werte sind fehlende Layout-Dimensionen bei Bildern, Einbettungscontainern und dynamisch geladenen Anzeigen. Wenn dem Browser vordefinierte Dimensionen fehlen, kann er die Seitengeometrie erst berechnen, wenn das Herunterladen der Assets abgeschlossen ist, was zu Reflows führt.

• Geben Sie explizite Breiten- und Höhenattribute für alle HTML-Elemente für Bilder und Videos an oder definieren Sie explizite Seitenverhältnisse mithilfe von CSS.
• Reservieren Sie dedizierte Layout-Container für dynamische Inhalte wie Werbebanner und Benachrichtigungsleisten, um zu verhindern, dass umgebende Elemente springen.
• Verwenden Sie font-display: swap oder font-display: optional zusammen mit dem Vorladen von Schriftarten, um Text-Reflow-Verschiebungen zu eliminieren, die durch Verzögerungen beim Laden von Web-Schriftarten verursacht werden.
• Vermeiden Sie es, neue HTML-Inhalte über vorhandenen sichtbaren Elementen nach dem Rendern der Seite einzufügen, es sei denn, dies wird explizit durch eine direkte Nutzereingabe initiiert.