Core Web Vitals 2026: offizielle Schwellenwerte, Messwerkzeuge und Optimierungsprioritäten

Drei Metriken bestimmen weiterhin, wie Google die Nutzererfahrung bewertet: LCP, INP und CLS. Ihre Schwellenwerte für „gut“, „verbesserungswürdig“ und „schlecht“ haben sich seit der letzten Aktualisierung der offiziellen web.dev-Dokumentation nicht verändert, trotz anhaltender Gerüchte über eine Verschärfung im Laufe des Jahres 2026. Was sich dagegen ändert, ist, wie leicht ein schlecht durchgeführtes Audit zu einer falschen Diagnose führt — und die Optimierungsarbeit in die falsche Richtung lenkt.

#Die drei Metriken und ihre offiziellen Schwellenwerte

Jede Metrik wird am 75. Perzentil der Seitenaufrufe bewertet, getrennt nach Mobilgerät und Desktop. Eine Website gilt bei einer Metrik nur dann als „gut“, wenn 75 % ihrer tatsächlichen Besuche unter dem „guten“ Schwellenwert liegen — nicht, wenn nur der Durchschnitt darunterliegt.

INP löste FID (First Input Delay) im März 2024 als offizielle Reaktionsfähigkeits-Metrik ab. Anders als FID, das nur die Verzögerung bis zur ersten Verarbeitung einer Interaktion maß, betrachtet INP sämtliche Interaktionen einer Sitzung und behält den schlechtesten repräsentativen Wert — eine deutlich strengere Berechnung für JavaScript-lastige Oberflächen.

#Richtig messen: Felddaten versus Labordaten

Die häufigste Verwechslung besteht darin, eine Website nur mit Lighthouse oder PageSpeed Insights im „Labor“-Modus zu prüfen und dann einen Score zu verkünden, während Google Seiten tatsächlich anhand von Felddaten aus dem Chrome User Experience Report (CrUX) und von echten Nutzern einstuft, die der Telemetrieübermittlung zugestimmt haben.

• Labordaten (Lighthouse, WebPageTest): eine reproduzierbare Simulation auf einer standardisierten Maschine und einem standardisierten Netzwerk. Nützlich zum Debuggen, nicht zur Beurteilung der Ranking-Wirkung.
• Felddaten (Search-Console-Bericht „Core Web Vitals“, PageSpeed-Insights-Tab „Erfahrung echter Nutzer“, CrUX direkt): Nur diese spiegeln wider, was Google tatsächlich fürs Ranking heranzieht.

Eine Website kann lokal einen hervorragenden Lighthouse-Score zeigen und in der Produktion beim INP dennoch als „schlecht“ eingestuft werden — einfach weil ihre echten Besucher Einsteigergeräte oder eine schwache mobile Verbindung nutzen, die der Labortest nie nachbildet.

Teams, die beide Quellen verfolgen möchten, ohne drei separate Dashboards zu pflegen, können die PageSpeed-Insights-API nutzen: Sie liefert Labordaten (ein frischer Lighthouse-Lauf) und Felddaten (der aktuelle CrUX-Schnappschuss für diese URL und ihren Ursprung) in einer einzigen JSON-Antwort — praktisch, um einen wöchentlichen Bericht oder ein internes Dashboard zu speisen, ohne manuell etwas aus der Search Console zu exportieren.

#LCP verbessern

LCP misst, wie lange das Rendern des größten sichtbaren Elements im anfänglichen Viewport dauert — meist ein Hero-Bild, eine Überschrift oder ein Textblock. Die wirksamsten Hebel, in der Regel in dieser Reihenfolge:

• Die kritische Ressource mit <link rel="preload"> vorladen, statt sie vom Browser spät entdecken zu lassen.
• Bereits dimensionierte, komprimierte Bilder im AVIF- oder WebP-Format ausliefern, mit fetchpriority="high" auf dem LCP-Element.
• Die Serverantwortzeit (TTFB) senken — oft vernachlässigt, obwohl sie den Startpunkt der gesamten Zeitachse festlegt.
• Rendering-blockierende Ressourcen (synchrones CSS und JavaScript) oberhalb des sichtbaren Bereichs entfernen.

#INP verbessern

INP verschlechtert sich, wenn der Hauptthread nach einer Interaktion — Klick, Tastendruck, Tap — zu lange beschäftigt bleibt, bevor der Browser das Ergebnis zeichnen kann. Die Lösung besteht so gut wie nie darin, eine isolierte Funktion zu „beschleunigen“, sondern die Arbeit in Häppchen aufzuteilen, damit der Hauptthread Luft bekommt:

import {onINP} from 'web-vitals';

onINP((metric) => {
  // Protokolliert jede gemessene Interaktion samt verantwortlichem Element
  console.log('INP:', metric.value, metric.attribution.interactionTarget);
  navigator.sendBeacon('/analytics/web-vitals', JSON.stringify(metric));
});

Die offizielle web-vitals-Bibliothek stellt ein Feld attribution bereit, das das DOM-Element identifiziert, das für die langsamste Interaktion verantwortlich ist — beim echten Debugging oft hilfreicher als ein isolierter Lighthouse-Score. Gängige Lösungen sind das Aufteilen langer Aufgaben mit scheduler.yield(), das Aufschieben unkritischen JavaScripts bis nach der ersten Nutzerinteraktion und die Reduzierung der Rendering-Arbeit, die jede Zustandsaktualisierung auslöst.

#CLS stabilisieren

CLS bestraft unerwartete Layoutverschiebungen nach dem ersten Rendern: ein Bild ohne reservierte Abmessungen, ein Schriftartwechsel, der spät eintrifft, ein Werbebanner, das über bereits gelesenem Inhalt eingefügt wird. Platz im Voraus zu reservieren — mit expliziten width/height-Attributen oder einem CSS-Subgrid-Layout mit vordimensionierten Spuren — vermeidet die meisten Regressionen. Bei Animationen sollte man sich auf transform und opacity beschränken, die nie eine Neuberechnung des Layouts auslösen — ein zentrales Prinzip der bewährten Praktiken aus dem Leitfaden zu scrollgesteuerten CSS-Animationen, wo schon eine kleine Layoutverschiebung den Effekt ebenso zerstört wie den Score.

Eine Website kann lokal einen hervorragenden Lighthouse-Score zeigen und in der Produktion trotzdem als „schlecht“ eingestuft werden: Fürs Ranking zählen nur Felddaten.

#Mit CrUX-Daten priorisieren

Vor einem Relaunch lohnt es sich zu wissen, ob ein Problem die ganze Website betrifft oder nur eine einzelne Vorlage. Der öffentliche CrUX-Datensatz, kostenlos abfragbar über BigQuery oder die CrUX-History-API, zeigt die monatliche Entwicklung aller drei Metriken nach Ursprung oder URL, segmentiert nach effektivem Verbindungstyp (4G, 3G) und Gerätetyp. Den eigenen Trend mit dem eines direkten Wettbewerbers im selben Zeitraum zu vergleichen, hilft dabei, eine website-spezifische Regression von einem breiteren saisonalen Effekt zu unterscheiden (verändertes Geräteverhalten, Auslastung eines gemeinsam genutzten CDN usw.).

Damit eine Regression nicht unbemerkt zwischen zwei monatlichen Audits durchrutscht, bleibt ein direkt in der Continuous Integration verankertes Performance-Budget die zuverlässigste Methode: Der Build schlägt fehl, wenn der simulierte LCP einen festgelegten Schwellenwert überschreitet — noch bevor die Änderung in Produktion geht.

{
  "ci": {
    "assert": {
      "assertions": {
        "largest-contentful-paint": ["error", {"maxNumericValue": 2500}],
        "cumulative-layout-shift": ["error", {"maxNumericValue": 0.1}],
        "total-blocking-time": ["warn", {"maxNumericValue": 300}]
      }
    }
  }
}

Diese Lighthouse-CI-Konfiguration ersetzt keine Feldmessung — sie bleibt ein Sicherheitsnetz auf Laborebene — verhindert aber, dass eine grobe Regression (ein unkomprimiertes Bild, das sich in einen Commit eingeschlichen hat, ein Drittanbieter-Skript ohne async) unbemerkt in die Produktion gelangt.

#Was man sich merken sollte

Die Schwellenwerte selbst sind stabil und gut dokumentiert; den Unterschied macht die Messdisziplin. Mit Felddaten auditieren, die tatsächlich betroffene Seitenvorlage isolieren, bevor man handelt, und LCP, INP und CLS als drei getrennte Probleme mit drei getrennten technischen Hebeln behandeln — statt als einen einzigen Score, den es zu steigern gilt.

Zum Weiterlesen: Die offizielle Dokumentation und die vollständige Methodik sind auf web.dev verfügbar.