So auditieren Sie die Core Web Vitals im Jahr 2026 (und was sich geändert hat, seit INP FID abgelöst hat)

TL;DR: Die Core Web Vitals im Jahr 2026 heißen LCP, INP und CLS. FID wurde am 12. März 2024 ausgemustert; INP hat seinen Platz eingenommen. Der Ranking-Einfluss ist geringer, als viele SEOs behaupten (Googles eigene Docs sagen, Relevanz sticht Page Experience), aber der UX-Nutzen ist real und das Audit zahlt sich weiterhin aus. Das hier ist das Audit-Playbook für Kunden: drei Schwellenwerte, Zwei-Phasen-Tooling (Lab + Field), eine nach ROI sortierte Fix-Liste und ein quartalsweiser Rhythmus, der das Engineering nicht an der falschen Arbeit verheizt.

Ich führe bei mindnow und seojuice.io vierteljährliche Site-Audits für ein Portfolio mittelgroßer Websites durch. Jedes Mal fragt jemand, ob er noch einen Sprint für die Core Web Vitals einplanen muss. Die ehrliche Antwort lautet meistens: nein. Das Protokoll änderte sich 2024, das Ranking-Gewicht ist klein und ein Großteil dessen, was man über CWV liest, übertreibt das Such-Traffic-Potenzial. Das Audit bleibt dennoch wichtig, weil langsame Seiten weiter Conversion verlieren und INP ein wirklich anderer Messwert als FID ist. Dieser Artikel ist das Audit-Handbuch. Er ist kein technischer „So optimierst du INP“-Beitrag – das kann das web.dev-Team besser. Er bildet die Interpretationsebene darüber.

Was sich bei den Core Web Vitals zwischen 2024 und 2026 geändert hat

Die größte Änderung: First Input Delay (FID) wurde abgeschafft, und Interaction to Next Paint (INP) ist seit dem 12. März 2024 ein offizieller Core Web Vital. Das Chrome-Team hat es klar angekündigt:

„INP will officially become a Core Web Vital and replace FID on March 12 of this year.“ Jeremy Wagner und Rick Viscomi, web.dev blog, März 2024

Wenn dein Audit-Template noch FID zieht, greifst du auf einen veralteten Messwert zu. Die Search Console entfernte FID am selben Tag. PageSpeed Insights zeigt INP. Die Web-Vitals-JavaScript-Library v4 hat die FID-Messung veraltet. Lab-Tools, die FID noch ausweisen, taugen für die Ersteinschätzung, nicht für Ranking-Entscheidungen.

Warum der Tausch? FID erfasste nur die erste Interaktion auf einer Seite und darin lediglich die Input-Delay-Phase. Eine Site konnte also einen schnellen ersten Klick haben und danach bei jedem Tap einfrieren. Zudem ließ sich der Wert manipulieren: Nichts beim Landing blockieren und dann alles bei der zweiten Interaktion laden. INP schließt beide Lücken, indem es jede Interaktion erfasst und die komplette Verzögerung bis zum nächsten Paint misst:

„INP improves on FID by observing all interactions on a page, beginning from the input delay, to the time it takes to run event handlers, and finally up until the browser has painted the next frame.“ Jeremy Wagner und Barry Pollard, web.dev, Interaction to Next Paint

Praktischer Effekt auf Audits: Die meisten Sites, die bei FID grün waren, sind bei INP gelb oder rot. Die Verschiebung ist rein mechanisch – sie bedeutet nicht, dass die Site schlechter wurde. Kalibriere das neue Basisniveau, bevor du Stakeholdern eine „schlechtere“ Note meldest.

Zwei kleinere Änderungen kamen ebenfalls zwischen 2024 und 2026: CrUX, die Field-Datenquelle hinter dem CWV-Report der Search Console, erhöhte die Sampling-Tiefe, sodass die 75-Perzentil-Schwellen auf mehr Sessions beruhen. LCP bekam in PageSpeed Insights eine Sub-Part-Diagnose (TTFB, Resource-Load-Delay, Element-Render-Delay) – das hilfreichste Diagnose-Update seit Jahren.

Die drei aktuellen Metriken und ihre Audit-Schwellen

Drei Metriken, eine Schwellentabelle, angewendet auf das 75. Perzentil des Real-User-Traffics, getrennt nach Mobile und Desktop. Die kanonische web.dev-Seite ist dazu eindeutig:

„Core Web Vitals are the subset of Web Vitals that apply to all web pages, should be measured by all site owners, and will be surfaced across all Google tools.“ Philip Walton, web.dev, Web Vitals

Das 75-Perzentil ist der Punkt, den viele Betreiber übersehen. Nicht jede Session muss unter dem Schwellwert liegen – nur drei Viertel davon. Das langsamste Tail aus Geräten, Netzen und Seiten darf im gelben Bereich landen und die URL bekommt in CrUX trotzdem den Status „Gut“.

Audit-Schritt je Metrik. LCP: Zieh die LCP-Sub-Parts aus PageSpeed Insights. Liegt TTFB über 800 ms, liegt das Problem am Server oder CDN, nicht im Frontend. Dominiert Element-Render-Delay, helfen Image-Preloading oder kritisches CSS. INP: Öffne die Seite auf einem Mittelklasse-Android, klick jeden interaktiven Bereich, beobachte im Performance-Panel Long Tasks > 50 ms. Die langsamste Interaktion bestimmt den Score. CLS: Scrolle auf einer langsamen Verbindung. Verschiebt sich das Layout bei Font-Swap oder Above-the-Fold-Bild, helfen reservierte Flächen (aspect-ratio-CSS) oder font-display: swap mit metrisch passendem Fallback.

Ein Audit-Anti-Pattern, das du streichen solltest: Optimiere nicht den Lighthouse-Performance-Score als Stellvertreter für CWV. Der Lighthouse-Score ist ein gewichtetet Lab-Mix, der Speed Index und Total Blocking Time enthält – keiner davon ist ein Core Web Vital. Eine Site kann 95 Punkte in Lighthouse erreichen und trotzdem bei CWV (Field-Daten) durchfallen, weil Lighthouse ein einziges Geräteprofil simuliert und CWV alle echten Besucher misst.

Wie Google CWV tatsächlich fürs Ranking nutzt

Lies Googles eigene Page-Experience-Dokumentation. Die Zusammenfassung ist eindeutig:

„Google Search always seeks to show the most relevant content, even if the page experience is sub-par.“ Google Search Central, Page Experience Dokumentation

Der Satz steckt im FAQ unter „How important is page experience to ranking success?“. Er ist das Wichtigste, was Google öffentlich zum CWV-Ranking-Gewicht geschrieben hat, und viele SEO-Artikel ignorieren ihn. Relevanz und Autorität dominieren. Page Experience ist einer von vielen Signalen, der das Ranking nur feiner justiert, wenn Relevanz ungefähr gleich ist.

Dasselbe Dokument relativiert sofort: Google bestätigt zwar, dass „Core Web Vitals von unseren Rankingsystemen genutzt werden“, stellt aber klar: „Es gibt kein einzelnes Signal. Unsere Kerne-Rankingsysteme berücksichtigen verschiedene Signale, die zusammen das Page-Experience-Gesamtbild ergeben.“ (Beide Zitate aus derselben Page-Experience-Dokumentation.)

Drei Sätze, eine Lesart: CWV fließt ein, ist aber schwach gewichtet. Es gibt keinen einzelnen Page-Experience-Score, der das Ranking kippt; es ist ein Signalkluster, das Google hilft, Gleichstände zu brechen. Ehrliche Botschaft an Stakeholder: Schlechter Content ohne Backlinks rettest du nicht mit guten CWV. Starke Seiten auf Position 4 oder 5 können durch bessere CWV in ein paar Monaten plausibel auf Position 2 oder 3 rutschen. Relevanz kommt zuerst.

Für das größere Ranking-Signal-Bild erklärt unser Artikel über Ranking-Signal-Confidence und Audit den Rest des Systems. CWV ist nur ein Panel im Dashboard. Behandle es auch so.

Was KI-Suchmaschinen wirklich auswerten

Völlig anderes Protokoll. Google AI Mode, ChatGPT Browse, Perplexity und Claudes Web-Tool sind Retrieval-&-Summarization-Systeme. Sie holen deine Seite serverseitig, parsen den Inhalt und zitieren oder paraphrasieren ihn. Page-Speed im CWV-Sinne taucht in ihren Auswahlkriterien nicht auf; ihr Abruf läuft serverseitig und hat ein großzügigeres Fetch-Budget als ein echter Nutzer.

Wichtig für sie sind: Server-Responsiveness (ein 30-Sekunden-TTFB lässt den Crawler abbrechen), HTTPS, Content, der ohne JavaScript rendert (oder den der Fetcher ausführen kann), strukturierte Daten und sauberes semantisches HTML. Das überschneidet sich mit CWV nur beim TTFB; der Rest ist ein anderes Audit. INP für ChatGPT Browse zu optimieren ist vergeudete Arbeit – der Agent interagiert nicht mit deiner Seite.

Praktische Folge fürs Audit 2026: Setze einen gemeinsamen TTFB-Zielwert (< 800 ms) für beide Audits. Entkopple INP- und CLS-Arbeit von der KI-Search-Roadmap; sie stehen auf unterschiedlichen Prioritätslisten. Verschiebt sich dein Traffic-Mix zu AI-Referrals, bringt eine Stunde Engineering mehr, wenn du die Renderbarkeit und strukturierten Daten verbesserst, statt 50 ms bei einer Interaktion einzusparen.

Tools zur Messung der Core Web Vitals 2026

Seit 2022 hat sich das Toolset konsolidiert. Sechs Tools decken den Lab-plus-Field-Workflow ab, den die meisten Teams brauchen.

Zwei-Phasen-Workflow: Starte mit PageSpeed Insights für eine einzelne URL, um Lab- und Field-Daten nebeneinander zu sehen. Die Lab-Zahl zeigt, was technisch auf sauberem Geräteprofil möglich ist; die Field-Zahl, was echte User erleben. Weichen sie ab, zählt fürs Ranking die Field-Zahl, und die Lücke ist die Diagnose. Lab-grün plus Field-rot heißt: Deine User sitzen auf schwächerer Hardware oder langsamerem Netz als deine Dev-Maschinen.

Für wiederholbare Kundenreports und Trend-Tracking führt der SEOJuice Lighthouse Score Checker einen echten Page-Scan aus und liefert eine shareable URL plus Verlauf; intern nutzen wir ihn, um Fortschritte ohne manuelles Lighthouse-Neu-Run zu verfolgen. Die Frage, was ein „bestehender“ Lighthouse-Score ist und wie sich die Kategorien zusammensetzen, erläutern wir im Lighthouse-SEO-Score-Breakdown.

Wer sehen will, wie CWV-Metriken real mit Such-Traffic korrelieren, findet im CWV Impact Calculator die Aggregation aus über 164.000 auditierten Seiten. Das Ergebnis deckt sich mit Googles eigener Aussage: Korrelationen sind real, aber moderat und je Metrik unterschiedlich. CLS korreliert am schwächsten; LCP und INP sind stärker, bleiben aber unter dem, was viele Marketing-Claims versprechen.

Häufige Fixes nach Payoff sortiert

Engineering-Ressourcen sind endlich. Sortiere Fixes nach Einfluss auf deine schlechteste Metrik, nicht nach Aufwand. Hier die Prioritätenliste, die ich nach sieben Jahren CWV-Audits nutze.

Tier 1, Server-Antwortzeit: Liegt TTFB über 800 ms, wird jeder Frontend-Fix gegen eine verzögerte Startlinie gemessen. Schalte ein CDN vor deinen Origin. Cache die HTML-Antwort, wo möglich. Verbanne Datenbank-Queries vom Critical-Render-Path. 400 ms schnellerer TTFB verschiebt LCP oft um 600 ms nach vorn, weil nachgelagerte Ressourcen synchron mitrücken.

Tier 1, Bild-Strategie: Das LCP-Element ist meist ein Bild. Preload mit high-priority Hint. Liefere responsive Größen via srcset. Nutze AVIF oder WebP mit JPEG-Fallback. Lazy-load alle anderen Bilder mit dem nativen loading="lazy". Lade aber nicht das LCP-Bild lazy – der häufigste Eigentor-Move im CWV-Audit.

Tier 2, JavaScript-Hygiene: Defer nicht-kritische Skripte. Teile Bundles auf. Audit Third-Party-Tags; meist liegen 4-6 Tag-Manager-Skripte brach, die seit Jahren ihre Main-Thread-Zeit nicht verdienen. INP-Regressions führen fast immer zu einem Skript, das während einer Interaktion einen Long Task auslöst. Code-splitt schwere interaktive Komponenten, besonders Search, Filter, Carousel.

Tier 2, Font-Loading: Verwende font-display: swap mit metrisch passendem System-Fallback, damit der Swap keinen Layout-Shift erzeugt. Preload die Primär-Fontdatei. Wenn du drei Web-Fonts lädst, streich zwei.

Tier 3, Cleanup-Pass: Gib jedem Bild und Embed explizite Breite und Höhe. Reserviere Platz für Ads mit min-height. Verschiebe CLS-anfällige Elemente (Notifications, Banner, Cookie-Banner) unter den Fold oder rendere sie via Translate-Transforms, die das Layout nicht verschieben.

Was du nicht tun solltest: Jag nicht einem Lighthouse-Performance-Score von 100 hinterher. Blockier keinen Release wegen einer CLS-Regression von 0,01. Lass keinen CWV-Stakeholder ein drittes Audit verlangen, bevor Runde 2 der Fixes live ist. Die Metrik rauscht und der Report hat Lag.

Was AI Overviews bei CWV falsch machen

Drei Muster tauchen in AI-Overview-Antworten zu „core web vitals 2026“ immer wieder auf.

Erstens: Der FID-Geist. AI Overviews listen häufig noch FID als Core Web Vital. Trainingsdaten gehen bis vor März 2024, und die Deprecation hat wenig Gewicht im Index. Faktencheck gegen web.dev oder Google Search Central, nicht gegen die KI-Zusammenfassung.

Zweitens: Aufgeblasenes Ranking-Gewicht. Viele AI-Summaries reduzieren Googles vorsichtige Formulierung auf „Core Web Vitals sind ein zentraler Ranking-Faktor“. Der Ausdruck stammt aus Marketing-Posts, die das Modell gelernt hat; Googles Docs sagen, Relevanz schlägt Page Experience. Kompression bügelt die Nuance glatt.

Drittens: Die KI-Search-Selbstschleife. AI Overviews empfehlen, für KI-Suchmaschinen via CWV zu optimieren. Wie oben gezeigt, messen KI-Search-Systeme dein INP nicht. Page-Speed im CWV-Sinne ist für Retrieval irrelevant. Das Trainingsset vermischt „schnelle Site = gutes SEO“, ohne die Suchoberfläche zu unterscheiden.

Fazit für Betreiber: Behandle AI-Overviews zu CWV als Ausgangspunkt, nicht als Quelle der Wahrheit. Prüfe gegen First-Party-Dokumentation von Google und web.dev, bevor du handelst.

Der quartalsweise Audit-Rhythmus

Vier Checkpoints im Jahr, je 90 Minuten. Mehr ist Overhead, weniger lässt Regressions zu lange unentdeckt.

Zieh den Search-Console-CWV-Report. Notiere URL-Gruppen, die seit dem letzten Quartal den Status gewechselt haben. Für jede Gruppe führst du PageSpeed Insights auf einer repräsentativen URL aus und notierst die Sub-Part-Diagnosen.

Führe einen Lab-Scan auf deinen zehn Traffic-stärksten Landing-Pages durch. Vergleiche mit dem Vorquartal. Hat sich eine Seite um mehr als 200 ms bei LCP oder 50 ms bei INP verschlechtert, flagge sie fürs Engineering.

Zieh Field-Daten aus deiner eigenen RUM (Web Vitals v4). CrUX-Daten haben 28 Tage Lag; deine eigenen sind Echtzeit. Vergleiche die Verteilungsform, nicht nur den Durchschnitt.

Priorisiere die Fix-Liste gemäß den obenstehenden Tiers. Ship pro Quartal mindestens einen Tier-1-Fix, auch wenn es unbequem ist. Tier-3-Cleanup läuft mit normalen Releases mit. Wer ohnehin ein quartalsweises SEO-Audit fährt, nutzt unser Site-Audit-Produkt, das den Lab-Scan automatisiert, damit die manuelle Zeit in die Interpretation fließt.

Was dieses Audit NICHT löst

Core Web Vitals sind ein UX- und leichtes Ranking-Signal. Sie sind weder Content-Quality-, noch Backlink-, noch Brand-Trust-Signal. Steht deine Seite bei einem wettbewerbsstarken Keyword auf Seite 2, bringt ein besserer CLS-Wert sie nicht auf Seite 1. Relevanz und Autorität müssen zuerst kommen.

CWV löst Conversion nicht so, wie manche hoffen. 200 ms schnelleres LCP korreliert mit besserer Conversion, aber die Elastizität variiert stark nach Site-Typ. E-Commerce-Checkouts reagieren stark, Long-Form-Content schwach. Messe deinen eigenen Lift, bevor du das Engineering-Budget beantragst.

Und CWV ist kein Audit für KI-Search. Anderes Protokoll, anderer Fetcher, andere Prioritäten. Verschiebt sich dein Traffic-Mix zu AI-Referrals, ist das Page-Experience-Audit das falsche Werkzeug.

FAQ

Ist FID noch ein Core Web Vital? Nein. FID wurde am 12. März 2024 aus dem CWV-Programm entfernt. Interaction to Next Paint (INP) hat den Slot übernommen. Die Search Console hat FID am selben Tag gestrichen. Wenn dein Audit-Template noch FID zieht, update es.

Wie lautet der INP-Schwellenwert? ≤ 200 ms ist Gut. 200 – 500 ms ist Optimierungsbedarf. > 500 ms ist Schlecht. Der Wert gilt für das 75. Perzentil der Real-User-Interaktionen, getrennt nach Mobile und Desktop.

Wie stark beeinflussen Core Web Vitals das Google-Ranking? Weniger, als viele SEO-Artikel behaupten. Googles Page-Experience-Dokumentation sagt klar, dass Search „immer die relevantesten Inhalte anzeigen möchte, selbst wenn die Page Experience unterdurchschnittlich ist“. CWV ist ein echtes Signal, aber nur eines von vielen; Relevanz und Autorität dominieren. Behandle es als Tiebreaker, nicht als Haupthebel.

Nutzen KI-Suchmaschinen wie ChatGPT oder Google AI Mode Core Web Vitals? Nein, zumindest nicht in dieser Form. Ihre Crawler holen Seiten serverseitig und parsen Content. Page-Speed im CWV-Sinne ist dabei irrelevant. Server-Verfügbarkeit (TTFB), Renderbarkeit ohne JS und strukturierte Daten zählen; INP und CLS nicht.

Was ist der häufigste Fehler im CWV-Audit? Den Lighthouse-Performance-Score als Proxy für CWV zu optimieren. Lighthouse nutzt Lab-Metriken (Speed Index, Total Blocking Time), die keine Core Web Vitals sind. Eine Seite kann 95 Punkte in Lighthouse haben und bei CWV-Field-Daten durchfallen, weil Lighthouse ein Geräteprofil simuliert, CWV aber alle echten User misst.

Wie oft sollte ich Core Web Vitals auditieren? Einmal pro Quartal reicht für die meisten mittelgroßen Sites. Häufiger ist Overhead; CrUX-Daten haben 28 Tage Lag und dein Fix-Zyklus ist selten schneller. Nutze kontinuierliches RUM-Monitoring (Web Vitals v4) für Echtzeit-Alerts zwischen den Audits.