Was Core Web Vitals 2026 wirklich bedeuten
Core Web Vitals sind die Teilmenge der Web Vitals, die Google als geschäftskritisch einstuft: drei Kennzahlen für Ladeleistung, Reaktivität und visuelle Stabilität. Der entscheidende Punkt, den Tutorial-Blogs übergehen, ist die Datenquelle. Gewertet wird nicht der Wert, den Sie gerade in PageSpeed Insights sehen, sondern der aggregierte Wert echter Chrome-Nutzer am 75. Perzentil über ein rollierendes 28-Tage-Fenster. Diese Felddaten stammen aus dem Chrome User Experience Report (CrUX), nicht aus Ihrer Lighthouse-Simulation.
Der praktische Reflex daraus: Wenn jemand einen Screenshot mit «100/100» zeigt, fragen Sie nach den CrUX-Werten. Der Lighthouse-Score ist eine Laborprognose unter synthetischen Bedingungen, gedrosselte CPU, fixe Netzwerklatenz. Er korreliert oft, deckt sich aber regelmäßig nicht mit dem, was Google in der Search Console als bestanden oder durchgefallen meldet. Core Web Vitals sind seit dem Page-Experience-Update (Google Search Central, 2021) Teil des Ranking-Systems, und seither verwechseln Audits diese beiden Datenquellen mit beeindruckender Regelmäßigkeit.
Welches Gewicht das Signal im Ranking wirklich hat
Hier braucht es eine klare Haltung statt Marketing-Nebel: Core Web Vitals sind ein bestätigtes, aber schwaches Ranking-Signal. Google beschreibt Page Experience selbst als Faktor, der bei vergleichbarer Relevanz den Ausschlag gibt, nicht als Hebel, der irrelevante Seiten nach oben zieht. Wer 200 Millisekunden am LCP feilt und einen Ranking-Sprung erwartet, hat das Kräfteverhältnis nicht verstanden. Relevanz und Linkprofil bewegen die Position, die Vitals entscheiden im Zweifel zwischen zwei ähnlich starken Ergebnissen.
Für eine Netlinking-Operation ist die ehrliche Einordnung wichtig: Core Web Vitals sind eine On-Page- und Technikgröße, kein Link-Hebel. Die Werte eines Mediums wandern nicht über einen Backlink zu Ihrer Zielseite. Lassen Sie sich also keine «CWV-optimierten Backlinks» verkaufen, das ist Begriffsvermischung. Relevant wird die Technik dort, wo Sie die Seiten selbst betreiben: Bei Stringer entstehen die linktragenden Beiträge auf einem frei einsehbaren Medienverzeichnis, dessen technische Basis intern kalibriert wird, statt sie einem fremden Verlag mit unbekanntem Hosting zu überlassen.
Die drei Kernmetriken: LCP, INP und CLS
LCP (Largest Contentful Paint) misst, wann das größte sichtbare Element im Viewport gerendert ist, meist das Hero-Bild oder die Überschrift. Schwellenwert für «gut»: bis 2,5 Sekunden am 75. Perzentil (Google, web.dev). Mehr dazu im Eintrag zu der Ladekennzahl für das größte Element.
INP (Interaction to Next Paint) hat im März 2024 First Input Delay als Reaktivitäts-Metrik abgelöst (Google Search Central). Während FID nur die Verzögerung der ersten Interaktion maß, bewertet INP die Latenz über alle Interaktionen einer Sitzung, von Klick bis zur nächsten visuellen Antwort. «Gut» liegt bei höchstens 200 Millisekunden. Diese Umstellung war kein Detail, sie hat viele Seiten, die unter FID grün waren, ins Gelbe gedrückt, weil JavaScript-lastige Interaktionen jenseits des ersten Klicks plötzlich zählten. Die Mechanik ist im Eintrag zu der Metrik für Reaktivität ausführlicher beschrieben.
Dieses deutschsprachige Video ordnet die drei Metriken anschaulich ein:
CLS (Cumulative Layout Shift) erfasst unerwartete Layoutverschiebungen während des Ladens, Schwellenwert für «gut» bei höchstens 0,1. Klassischer Auslöser: nachgeladene Bilder ohne reservierte Maße, Web-Fonts, die einen Reflow verursachen, oder ein Cookie-Banner, das den Inhalt nach unten schiebt.
Messen: Felddaten, Labordaten und die richtigen Tools
Die wichtigste Unterscheidung beim Messen ist Feld gegen Labor. Felddaten (CrUX) sind das, was Google wertet: echte Nutzer, echte Geräte, echte Netze, aggregiert am 75. Perzentil. Labordaten (Lighthouse) sind reproduzierbar und gut zum Debuggen, sagen aber nichts über Ihre tatsächliche Nutzerbasis aus. Eine Seite mit überwiegend mobilen Nutzern auf mittelmäßigen Geräten kann im Labor glänzen und im Feld scheitern.
Die operative Werkzeugkette: Die Search Console liefert den CWV-Bericht auf CrUX-Basis für Ihre verifizierten Properties, PageSpeed Insights zeigt Feld- und Labordaten nebeneinander für einzelne URLs, das Performance-Panel der Chrome DevTools dient der Detailanalyse, und für eigenes Real-User-Monitoring bindet man die quelloffene web-vitals-Bibliothek von Google ein. Letztere ist die einzige Methode, um die Vitals pro Seite und Segment live im eigenen Analytics zu erfassen, ohne auf das 28-Tage-Fenster von CrUX zu warten.
Wie man die Werte direkt in den Chrome DevTools live mitliest, zeigt dieses kurze Tutorial:
Ein häufiger Trugschluss: PageSpeed Insights liefert für URLs ohne ausreichendes CrUX-Volumen gar keine Felddaten, nur das Labor. Bei kleinen oder neuen Seiten beurteilen Sie also Labordaten und nennen es Feld. Wer das übersieht, optimiert gegen die falsche Zahl.
Optimieren in der Praxis, Metrik für Metrik
LCP verbessert man an drei Fronten: Serverantwortzeit (TTFB) senken, etwa über Caching und ein nahes CDN, das Hero-Bild komprimieren und in einem modernen Format wie WebP oder AVIF ausliefern, und kritische Web-Fonts vorladen statt sie spät nachzuziehen. Ein vorausgeladenes, korrekt dimensioniertes Hero-Bild bringt in der Praxis mehr als jede Mikro-Optimierung am JavaScript.
INP ist fast immer ein JavaScript-Problem: lange Tasks auf dem Hauptthread blockieren die Antwort auf Klicks. Die Hebel sind Aufteilen langer Tasks, Reduzieren und Aufschieben von Drittanbieter-Skripten und das Auslagern schwerer Berechnungen. CLS löst man durch feste Maßangaben auf Bildern und Embeds sowie reservierten Platz für Banner und Anzeigen, bevor sie geladen werden.
Die folgenden technischen Optimierungstechniken pro Metrik vertieft dieses Video:
Ein Punkt, der deutschsprachige Seiten besonders trifft: spät injizierte Cookie-Banner. Ein Consent-Layer, der nach dem ersten Paint einfährt, verschiebt Inhalte (CLS) und blockiert beim Schließen den Hauptthread (INP). Das ist kein Argument gegen DSGVO-Konformität, sondern eines für früh im Markup reservierten Platz für das Banner. Wer den Consent-Dialog nachträglich per schwerem Drittanbieter-Skript einbaut, zahlt an zwei Metriken gleichzeitig.
Was wir bei deutschen Seiten regelmäßig schiefgehen sehen
Aus eigener Audit-Erfahrung wiederholen sich vier Muster. Erstens günstiges Shared-Hosting mit hoher TTFB, das jede LCP-Optimierung im Frontend zunichtemacht, weil der Server schon eine Sekunde verbraucht, bevor das erste Byte fließt. Zweitens überladene WordPress-Installationen: ein schweres Theme plus zwei Dutzend Plugins, die jeweils eigenes CSS und JavaScript einschleusen, ruinieren INP zuverlässig.
Drittens unkomprimierte Bilder im falschen Format, oft direkt aus der Kamera in voller Auflösung eingebunden und per CSS verkleinert. Viertens, und am teuersten in der Diagnose, das Optimieren des Laborwerts bei Ignorieren des Feldwerts. Die Jagd nach 100/100 in Lighthouse fühlt sich produktiv an, ändert aber nichts an der Search-Console-Bewertung, wenn die echten Nutzer langsamere Geräte haben. Wer eine technisch saubere Basis als Fundament für seine Sichtbarkeit will, baut sie ins eigene Setup ein, statt sie über einen direkt beim Verlag platzierten Link zu erhoffen, der die Technik der Zielseite ohnehin nicht berührt.