Core Web Vitals 2026: Schwellenwerte und Neuerungen
Die Metriken haben sich dieses Jahr nicht geändert. Das Werkzeug drumherum sehr wohl. Was gerade wirklich gilt.
Drei Metriken, und zwar dieselben drei seit 2024. Largest Contentful Paint sollte bei höchstens 2,5 Sekunden landen, Interaction to Next Paint bei höchstens 200 Millisekunden und Cumulative Layout Shift bei höchstens 0,1. Bewertet wird jede davon im 75. Perzentil der echten Seitenaufrufe, getrennt nach Mobil und Desktop.
Wie lauten die Core-Web-Vitals-Schwellenwerte 2026?
Sie stammen direkt von den Metrik-Seiten auf web.dev, wo Google die Definitionen veröffentlicht. Gewertet wird alles im 75. Perzentil der Seitenaufrufe. Sie bestehen also, wenn drei Viertel Ihrer echten Besucher ein gutes Ergebnis bekommen, nicht wenn Ihr Laptop es tut.
| Metrik | Was sie misst | Gut | Verbesserungswürdig | Schlecht |
|---|---|---|---|---|
| LCP | Ladeverhalten, also wann das größte sichtbare Element fertig gerendert ist | Höchstens 2,5 Sekunden | 2,5 bis 4,0 Sekunden | Über 4,0 Sekunden |
| INP | Reaktionsfähigkeit über sämtliche Interaktionen der Seite hinweg | Höchstens 200 ms | Über 200 ms bis 500 ms | Über 500 ms |
| CLS | Visuelle Stabilität, gemessen am schlimmsten Ausbruch unerwarteter Verschiebungen | Höchstens 0,1 | Über 0,1 bis 0,25 | Über 0,25 |
Haben sich die Core Web Vitals 2026 wirklich geändert?
Nein. Weder der Satz an Metriken noch ein einziger Schwellenwert. Die letzte strukturelle Änderung fiel auf den 12. März 2024, als Interaction to Next Paint ein stabiler Core Web Vital wurde und First Input Delay ausgemustert wurde. Angekündigt hat web.dev das im Beitrag INP becomes a Core Web Vital. Seither besteht der Satz aus drei stabilen Metriken, ohne dass ein experimenteller oder anstehender Nachfolger benannt wäre. Googles eigene Regel lautet, dass sich stabile Core Web Vitals höchstens einmal pro Jahr ändern, und 2025 wie 2026 gingen ohne eine solche Änderung vorbei.
Bewegt hat sich die Messebene darunter. Die Release Notes zum Chrome UX Report auf Chrome for Developers halten fest, dass LCP image subparts und LCP resource types im Januar 2025 in die CrUX API kamen, dass die ECT-Dimension in derselben Ausgabe aus BigQuery entfernt wurde und dass das alte CrUX Dashboard Ende November 2025 eingestellt wurde. Unabhängig davon hat die Arbeit an Soft Navigations Chrome 151 erreicht: Single-Page-Apps können LCP, INP und CLS damit einzelnen Routenwechseln zuordnen statt einem einzigen endlosen Seitenaufruf. Die Dokumentation sagt ausdrücklich, dass noch offen ist, wie Soft Navigations im CrUX berichtet werden. Auf Ihre Zahlen in der Search Console wirkt sich das also noch nicht aus.
Wenn Ihnen jemand erzählt, dieses Jahr sei eine neue Metrik dazugekommen: fragen Sie, welche. Es gibt keine.
Was gegen einen langsamen LCP hilft
Fast jeder schlechte LCP ist ein Auffindbarkeitsproblem. Der Leitfaden zu den wichtigsten Maßnahmen auf web.dev stellt drei Dinge nach vorn: Die LCP-Ressource muss im HTML-Quelltext sichtbar sein und darf nicht per Skript nachgeschoben werden, sie gehört mit fetchpriority="high" ausgezeichnet, und die Time to First Byte sinkt mit einem CDN, das schon das Dokument selbst cacht. Darüber hinaus zielen Sie auf sofortige Navigationen über den Back/Forward-Cache oder Speculation Rules, damit die nächste Seite beim Klick längst da ist.
Was gegen einen hohen INP hilft
INP zerfällt in drei Teile: die Verzögerung, bis Ihr Handler überhaupt startet, die Verarbeitungsdauer des Handlers und die Verzögerung, bis das nächste Frame gezeichnet wird. Der berichtete Wert entspricht ungefähr der schlechtesten Interaktion auf der Seite, wobei pro fünfzig Interaktionen ein Ausreißer ignoriert wird. Empfohlen wird: häufig yielden, damit lange Tasks den Main Thread nicht blockieren, von vornherein weniger JavaScript ausliefern und Rendering-Updates klein halten, mit schlankem DOM und CSS Containment. Nehmen Sie sich Ihren Tag Manager vor. Dort steckt es meistens.
Was gegen Layout-Verschiebungen hilft
CLS betrachtet den schlimmsten Ausbruch an Verschiebungen, definiert als Verschiebungen mit weniger als einer Sekunde Abstand innerhalb eines Fensters von höchstens fünf Sekunden. Setzen Sie auf jedes Bild und jedes Embed feste Breite und Höhe oder ein Seitenverhältnis, reservieren Sie Platz für alles, was spät eingefügt wird, etwa Banner und Consent-Leisten, halten Sie die Seite für den Back/Forward-Cache tauglich und animieren Sie mit transform statt mit Eigenschaften, die ein Layout erzwingen.
Wo sollten Sie Core Web Vitals messen?
Immer zuerst Felddaten. Laborwerkzeuge sind dazu da, Regressionen vor dem Ausrollen zu erwischen, und web.dev sagt unumwunden, dass sie echte Nutzer auf echten Geräten nicht ersetzen. Der Chrome User Experience Report ist der Felddatensatz. PageSpeed Insights und der Core-Web-Vitals-Bericht in der Search Console lesen beide daraus, und die JavaScript-Bibliothek web-vitals liefert Ihnen eigene Zahlen mit weit weniger Verzug als ein rollierendes 28-Tage-Fenster. Chrome DevTools und Lighthouse decken die Laborseite ab. Nutzen Sie beides, entschieden wird aber allein über Felddaten.
Wirken sich Core Web Vitals noch auf Google-Rankings aus?
Google Search Central führt Core Web Vitals weiterhin als Teil der Page Experience und beschreibt sie als Metriken, die echte Nutzererfahrung messen und mit dem übereinstimmen, was die Core-Ranking-Systeme belohnen sollen. Das ist bewusst weicher formuliert als ein Rankingfaktor. Behandeln Sie die Werte als Zünglein an der Waage zwischen ansonsten vergleichbaren Seiten, und als etwas, das die Conversions ganz unabhängig davon verbessert, was die Suche daraus macht. Dieselbe Logik gilt für den Rest Ihres technischen Fundaments, und genau darauf schaut unser KI-Readiness-Checker.
Allen, die einem perfekten Score hinterherjagen, sei gesagt: Alle drei Schwellenwerte im 75. Perzentil zu bestehen ist die Ziellinie. Eine Bonusstufe darüber gibt es nicht. Sobald alles grün ist, steckt man die nächste Stunde besser in die Frage, ob Crawler die Seite überhaupt erreichen. Das ist ein Fünf-Minuten-Blick in Ihre robots.txt.