Die Core-Web-Vitals-Schwellenwerte haben sich 2026 nicht geändert

Wer im Sommer 2026 nach Core Web Vitals sucht, stößt schnell auf eine Ankündigung. Google bewerte die Werte seit dem März-Core-Update site-weit, alle Seiten einer Domain flössen in einen Gesamtwert, und eine einzige langsame Produktseite ziehe die komplette Domain herunter. Das steht in keiner Google-Quelle.

Ich habe die Primärquellen am 27. Juli 2026 durchgesehen. Nicht die Zusammenfassungen, sondern die Dokumentationsseiten selbst, die Chromium-Changelogs, das Search Status Dashboard und die CrUX-Release-Notes. Hier steht, was dort tatsächlich zu finden ist, was nicht, und was sich 2026 wirklich geändert hat.

Was in den Google-Quellen steht

Drei Metriken, drei Werte, jeweils gemessen am 75. Perzentil der Seitenaufrufe und getrennt nach Mobil und Desktop.

Largest Contentful Paint gilt als gut bei 2,5 Sekunden oder weniger. Die Seite web.dev/articles/lcp trägt als letzten Stand den 04.09.2025.

Interaction to Next Paint gilt als gut bei 200 Millisekunden oder weniger, als verbesserungswürdig bis 500 Millisekunden und darüber als schlecht. Stand der Seite ist der 02.09.2025.

Cumulative Layout Shift gilt als gut bei 0,1 oder weniger und ab 0,25 als schlecht. Diese Seite wurde zuletzt am 12.04.2023 angefasst.

Die Übersichtsseite web.dev/articles/vitals, Stand 31.10.2024, nennt genau diese drei Metriken und kennt keinen zusammengefassten Gesamtscore.

Dazu die Changelogs, die bei solchen Fragen mehr wert sind als jede Doku-Seite, weil sie jede Messänderung versioniert festhalten. Der Chromium-Changelog für LCP hat als jüngste Einträge Chrome 140 und Chrome 143, beide aus 2025 und beide zu einem zu früh gemeldeten Text-Zeitstempel. Der Changelog für INP endet bei Chrome 133 vom Februar 2025. Aus 2026 steht in beiden Dateien kein einziger Eintrag.

Zur Ausgangsfrage nach einer gesenkten LCP-Schwelle noch ein Nachtrag, der zur Sache gehört. Ich habe mehrere deutschsprachige Treffer zu dem Thema geprüft, auch solche, die den Suchbegriff bedienen. Alle nennen korrekt 2,5 Sekunden, eine stellt sogar ausdrücklich klar, dass die Werte seit dem INP-Rollout im März 2024 unverändert sind. Die Senkung ist also eher eine verbreitete Suchanfrage als eine verbreitete Behauptung. Die Behauptung, die tatsächlich kursiert, ist eine andere.

Foto: codzilla_swiss / Unsplash

Warum ausgerechnet 2,5 Sekunden

Google hat die Festlegung der Schwellen in einem eigenen Methodik-Dokument beschrieben, verfasst von Bryan McQuade und Barry Pollard, zuletzt aktualisiert am 07.05.2025. Drei Kriterien entscheiden. Der Wert muss eine hochwertige Nutzererfahrung abbilden, er muss erreichbar sein, und er muss geräteübergreifend gleich sein. Erreichbar heißt konkret, dass mindestens 10 Prozent der Origins den guten Wert überhaupt schaffen können.

Interessant ist der dokumentierte Zwischenschritt. Genau die Werte 1,5 Sekunden und 2 Sekunden wurden als LCP-Schwelle geprüft und verworfen, weil sie selbst für gut optimierte Seiten am 75. Perzentil nicht durchgängig erreichbar waren. 2,5 Sekunden war der niedrigste Wert, der die Erreichbarkeitshürde genommen hat.

Das ist der Grund, warum eine stille Senkung unplausibel wäre. Google müsste dafür das eigene 10-Prozent-Kriterium neu begründen und die Verschiebung dokumentieren. Beides ist nicht passiert.

Behauptung 1: site-weites Scoring seit März 2026

Die tragende Behauptung lautet, Google bewerte seit dem März-2026-Core-Update nicht mehr einzelne Seiten, sondern die gesamte Domain, und schlechte Unterseiten zögen den Rest mit.

Gegenprobe im offiziellen Search Status Dashboard. Für 2026 sind dort fünf Ranking-Updates verzeichnet, das Discover Update vom 05.02.2026 mit 21 Tagen und 17 Stunden Laufzeit, das Spam Update vom 24.03.2026 mit 19 Stunden und 30 Minuten, das Core Update vom 27.03.2026 mit 12 Tagen und 4 Stunden, das Core Update vom 21.05.2026 mit 11 Tagen und 21 Stunden und das Spam Update vom 24.06.2026 mit 2 Tagen und 1 Stunde. Keines davon betrifft Core Web Vitals oder Page Experience. Das letzte Page-Experience-bezogene Update im offiziellen Verlauf ist das Desktop-Update vom 22.02.2022.

Googles Page-Experience-Dokument in der Search Central wurde am 10.12.2025 zuletzt aktualisiert. Es nennt bewusst keine konkreten Zahlenschwellen und betont, dass es kein einzelnes Signal gibt. Die geprüfte Sekundärquelle verlinkt zwar Search Central, web.dev, das Status Dashboard und CrUX, zitiert daraus aber keinen einzigen Satz.

Der Umkehrschluss, Core Web Vitals seien ein reines Seiten-Signal, steht dort allerdings auch nicht. Das Dokument schreibt, die Kernsysteme bewerteten Inhalte im Allgemeinen seitenspezifisch, auch bei Aspekten der Page Experience, daneben gebe es aber einige site-weite Bewertungen. Das ist eine Aussage über die Ranking-Systeme insgesamt und keine über die Core Web Vitals im Besonderen. Als Beleg taugt sie weder für ein Domain-Signal noch für ein sauber abgegrenztes Seiten-Signal. Nachweisbar ist nur der eine Punkt. Für eine Umstellung auf site-weites Scoring im März 2026 existiert kein Google-Beleg, und das März-Update wurde als reguläres Core Update beschrieben.

Foto: firmbee / Unsplash

Behauptung 2: verschärfte INP-Messmethodik

Eine englischsprachige Quelle führt den Rückgang der Pass-Raten auf eine 2026 verschärfte INP-Messung zurück, dazu auf eine erweiterte CrUX-Abdeckung von Soft Navigations und ein prominenteres TTFB in PageSpeed Insights. Als Beleg nennt sie pauschal Doku-Aktualisierungen bis April 2026 und die öffentlichen Texte des Chrome-Teams, ohne URL, ohne Datum, ohne Zitat.

Der INP-Changelog hat aus 2026 keinen Eintrag. Google selbst erklärt den Rückgang anders, dazu gleich mehr. Diese Behauptung bleibt unbelegt.

Behauptung 3: der zusammengefasste Gesamtscore

Es gibt keinen aggregierten Core-Web-Vitals-Score. Die Übersichtsseite kennt drei Metriken mit drei Schwellen, mehr nicht.

Was es gibt und was leicht damit verwechselt wird, ist die CrUX-Kennzahl “gute Core Web Vitals insgesamt”. Das ist der Anteil der Origins, die alle drei Metriken bestehen, also eine Statistik über den Bestand des Webs und keine Bewertung einer einzelnen Website.

Auch die neue Lighthouse-Kategorie “Agentic Browsing” ist kein Score. Sie setzt Chrome 150 oder neuer voraus und ist laut Doku, Stand 05.05.2026, ausdrücklich informativ und unbenchmarked. Sie prüft die Registrierung von WebMCP-Tools, die Qualität des Accessibility-Baums, visuelle Stabilität über CLS und die Auffindbarkeit einer llms.txt. Eine gewichtete Zahl von 0 bis 100 fällt dabei nicht an.

Die Zahlen, die wirklich gefallen sind

Der CrUX-Datensatz Mai 2026, veröffentlicht am 09.06.2026, weist 68,6 Prozent gutes LCP aus (minus 0,5), 81,3 Prozent gutes CLS, 86,6 Prozent gutes INP (minus 0,6) und 55,9 Prozent gute Core Web Vitals insgesamt (minus 0,8). Der Juni-Datensatz vom 14.07.2026 liegt bei 67,7 Prozent LCP (minus 1,2), 81,4 Prozent CLS (plus 0,1), 85,9 Prozent INP (minus 0,8) und 55,3 Prozent insgesamt (minus 1,2).

Googles eigene Einordnung dazu nennt eine Regression vor allem auf Android und ordnet die weiteren Rückgänge im Jahresvergleich als saisonal ein. Zur Ursache heißt es wörtlich, man habe Vermutungen, aber “nothing definitive to share yet”. Eine Änderung an Metriken, Schwellenwerten, Dimensionen oder Messmethodik ist in den Release Notes 2026 nicht angekündigt.

Damit ist auch erklärt, wie die Verwechslung entstehen kann. CrUX liefert seit jeher zwei Ebenen, Origin-Level und Page-Level. Page-Level-Daten setzen zusätzlich öffentliche Auffindbarkeit voraus, also keinen Nicht-200-Status und kein noindex, dazu eine Mindest-Besucherzahl, die Google nicht veröffentlicht. Erlebnisse, die nur die Origin-Kriterien erfüllen, landen weiterhin im Origin-Datensatz. Wer im Tool nur die Origin-Ebene sieht, weil die Einzelseite die Page-Level-Hürde nicht nimmt, hält das schnell für eine neue site-weite Bewertung. Die Methodik-Doku dazu steht seit dem 20.06.2024 unverändert online.

Foto: lukechesser / Unsplash

Zeitleiste 2026

Lighthouse 13.0.0 erschien noch 2025, am 10.10., mit der Umstellung der Performance-Audits auf DevTools-Insights, Node 22.19 als Mindestanforderung und sieben ersatzlos entfernten Audits. Ausdrücklich ohne Änderung am Performance-Scoring, weil der Score auf Metriken und nicht auf Audits beruht.

2026 kamen laut Changelog 13.0.2 am 06.02., 13.0.3 am 11.02., 13.1.0 am 03.04. mit einem Baseline-Compatibility-Audit, 13.2.0 am 30.04. mit drei WebMCP-Audits, 13.3.0 am 07.05. mit Agentic Browsing in der Default-Konfiguration, 13.4.0 am 09.06. mit Agentic Browsing im PageSpeed-Insights-API-Viewer und 13.4.1 am 20.07.

Dazu der Chrome-Blogbeitrag zum “Agent-ready toolkit” vom 22.06.2026 mit drei Bausteinen, der Lighthouse-Kategorie ab Chrome M150, dem WebMCP-Standard und Chrome DevTools for Agents.

Der finale Origin Trial für die Soft-Navigations-API wurde am 20.04.2026 angekündigt und läuft von Chrome 147 bis Chrome 149. Getestet werden die Einträge SoftNavigationEntry und InteractionContentfulPaint sowie navigationId-Kennungen. Eine Soft Navigation ist über drei Kriterien definiert, sie wird durch eine Nutzeraktion ausgelöst, sie führt zu einer sichtbaren URL-Änderung und die Interaktion führt zu einem sichtbaren Paint. Ohne Flag verfügbar sein soll das ab Chrome 151, dessen Stable-Termin auf den 28.07.2026 datiert ist.

Wichtig für die Einordnung: Google schreibt zum Origin Trial ausdrücklich, dieser diene der Bewertung der API selbst und nicht der Frage, wie die Daten in CrUX oder in Tools verwendet werden. Das werde erst nach dem Launch entschieden.

// Soft Navigations ab Chrome 151 ohne Flag beobachten.
// Ob und wie diese Werte je in CrUX einfliessen, ist offen.
new PerformanceObserver(function (list) {
  for (const entry of list.getEntries()) {
    console.log('soft navigation', entry.name, entry.startTime, entry.navigationId);
  }
}).observe({ type: 'soft-navigation', buffered: true });

new PerformanceObserver(function (list) {
  for (const entry of list.getEntries()) {
    console.log('interaction contentful paint', entry.startTime, entry.navigationId);
  }
}).observe({ type: 'interaction-contentful-paint', buffered: true });

Wer eine SPA oder View Transitions einsetzt, bekommt damit endlich Messwerte für Navigationen, die bisher komplett unsichtbar waren. Ranking-relevant ist davon vorerst nichts.

Der Laborwert misst nicht, er rechnet

Der eigentliche Grund, warum Schwellenwert-Debatten so wenig bringen, liegt woanders. PageSpeed Insights und Lighthouse messen im Standardfall nicht, sie simulieren. Die Seite wird ungedrosselt geladen, danach rechnet das Lantern-Modell die Metriken auf ein Moto G Power hoch, auf langsames 4G mit 1,6 Mbit pro Sekunde und vierfache CPU-Drosselung.

Bei der V3-Optimierung von emit-solution.com am 09.07.2026 stieg der PageSpeed-Score von 70 auf 92 bis 96, das simulierte LCP fiel von 6,7 Sekunden auf 2,4 Sekunden. Der größte verdeckte Hebel waren 42 KB render-blockierendes CSS, die allein rund 3,5 Sekunden simuliertes LCP kosteten. Der Grund liegt im Modell. Lantern zählt alle Requests, die vor dem beobachteten LCP starten, als LCP-Abhängigkeit, unabhängig davon, ob der Paint sie überhaupt braucht.

Dazu die Varianz. Identischer Code lieferte in PageSpeed Insights einmal 52 und einmal 95 Punkte, weil sich die Test-Runner die CPU teilen. Ein einzelner Lauf taugt nicht als Grundlage, drei Läufe und der Median schon. Mehr dazu im Leitfaden zum Lighthouse-Score.

Für das Ranking zählt ohnehin CrUX, also Felddaten echter Nutzer. Der Laborwert ist Diagnose. Wenn der beobachtete Paint schnell ist und das Publikum auf ordentlichem Netz unterwegs ist, sind die Feldwerte oft besser, als die Simulation nahelegt.

Foto: zetong / Unsplash

Solche Meldungen selbst prüfen

Vier Quellen reichen für fast jede Behauptung dieser Art. Der Chromium-Changelog unter docs/speed/metrics_changelog beantwortet jede Frage zur Messmethodik einer Metrik. Das Search Status Dashboard listet jedes Ranking-Update mit Start, Ende und Laufzeit. Die CrUX-Release-Notes dokumentieren jede Änderung am Datensatz. Und die web.dev-Artikel tragen unten ihr Aktualisierungsdatum, was eine angeblich neue Schwelle auf einer seit 2023 unveränderten Seite sofort entlarvt.

Und wenn eine Zahl im eigenen Bericht nicht plausibel wirkt, hilft der Blick in das Rohaudit statt in die Ergebniskachel.

npx lighthouse <url> --form-factor=mobile --screenEmulation.mobile \
  --throttling-method=simulate --only-categories=performance \
  --output=json --output-path=audit.json --chrome-flags="--headless=new"

// Im JSON gezielt nachsehen:
// audits.metrics.details.items[0]             -> observed vs. simuliert
// audits['largest-contentful-paint-element']  -> LCP-Element plus Phasen
// audits['network-requests']                  -> gefiltert auf
//                                                networkRequestTime < observedLCP
//                                                ergibt die echte LCP-Kette
// audits['screenshot-thumbnails']             -> Filmstrip als Base64

Wenn du gerade eine Meldung zu Core Web Vitals auf dem Tisch hast und wissen willst, ob deine Seite davon betroffen wäre, schau in deine CrUX-Werte statt in den Laborscore. Bei der Einordnung, welche Zahl bei dir welchen Hebel hat, helfe ich gern. Melde dich einfach mit der URL.