Core Web Vitals, erklärt ohne Fachjargon.

Über Core Web Vitals wird oft als reine SEO-Checkbox gesprochen, was ihnen nicht gerecht wird. Sie sind Googles Versuch, etwas Reales zu messen: ob eine Seite schnell lädt, reagiert, wenn du sie berührst, und visuell stabil bleibt, während du sie nutzt. Ihre Behebung verbessert das Ranking — aber aus demselben Grund verbessert sie auch die Conversion-Rate.

Die drei Metriken

Largest Contentful Paint (LCP) misst, wie lange das größte sichtbare Element — meist ein Hero-Bild oder eine Überschrift — zum Rendern braucht; unter 2,5 Sekunden ist gut. Interaction to Next Paint (INP) misst, wie reaktionsschnell sich die Seite anfühlt, wenn ein Besucher klickt, antippt oder tippt; unter 200 ms ist gut. Cumulative Layout Shift (CLS) misst, wie stark sich Inhalte beim Laden der Seite verschieben; unter 0,1 ist gut.

Zwei Details zählen mehr als die Zahlen selbst. Google bewertet am 75. Perzentil echter Besuche — eine Seite ist also erst „gut“, wenn drei Viertel der tatsächlichen Sitzungen den Schwellenwert schaffen; deine eigene schnelle Verbindung ist nicht die Messung. Und INP hat First Input Delay im März 2024 abgelöst. Deshalb messen ältere Analysen und Blogposts, die noch FID zitieren, etwas, das Google nicht mehr verwendet.

Warum sie Ranking und Conversions beeinflussen

Google nutzt die Seitenerfahrung als eines von vielen Rankingsignalen, sodass Core Web Vitals allein eine Seite ohne relevanten Content nicht retten. Aber genau dieselben Probleme, die diese Werte verschlechtern — langsames Laden, träge Interaktionen, springende Layouts — sind genau das, was einen echten Besucher dazu bringt, vor der Conversion abzuspringen. Der Ranking-Effekt und der Conversion-Effekt haben dieselbe Ursache.

Wo Websites meist Punkte verlieren

Unoptimierte Hero-Bilder und Hintergrundvideos sind der häufigste LCP-Killer. Renderblockierendes JavaScript und schwere Drittanbieter-Skripte — Chat-Widgets, Ad-Tags, Marketing-Pixel — ruinieren meist den INP-Wert. CLS wird meist durch Anzeigen, Web-Fonts oder Embeds (Bewertungs-Widgets, Karten) verursacht, die spät laden und Inhalte nach unten schieben, nachdem der Besucher schon zu lesen begonnen hat.

Beheben, ohne neu zu bauen

Das meiste davon lässt sich schrittweise beheben: Bilder unterhalb des sichtbaren Bereichs komprimieren und per Lazy Loading laden, nicht-kritische Drittanbieter-Skripte bis nach der ersten Interaktion verzögern, Layout-Platz für alles reservieren, was asynchron lädt, und statische Assets über ein CDN mit korrekten Caching-Headern ausliefern. Ein kompletter Neubau ist selten der erste Schritt — meist reicht eine gezielte Performance-Überarbeitung.

Zur Einordnung, wie verbreitet das Problem ist: In den Plattformdaten des HTTP Archive für 2025 bestanden nur 45 % der mobilen WordPress-Seiten alle drei Metriken, gegenüber 85 % bei Duda und 74 % bei Wix. Ein durchgefallener Wert ist der Normalzustand des Webs, kein ungewöhnlicher Defekt — genau deshalb ist es weiterhin ein Wettbewerbsvorteil, ihn zu beheben.

Wenn Laborwert und Felddaten sich widersprechen

Zwei Werkzeuge können dir zwei verschiedene Urteile über dieselbe Seite liefern, und beide können stimmen. Lighthouse ist ein Labordurchlauf: ein Seitenaufruf, ein simuliertes Gerät, eine Verbindung, ein Ort. Die Felddaten oben in PageSpeed Insights sind das, was echten Besucherinnen und Besuchern tatsächlich passiert ist — mit der Hardware, dem Netz und der Geduld, die sie mitgebracht haben.

Wenn beide sich widersprechen, ist die Empfehlung von Google eindeutig: Die Felddaten bestimmen die Priorität, weil sie abbilden, was deine Nutzer wirklich erlebt haben. Praktisch heißt das, dass ein perfekter Laborwert auf einem schnellen Laptop bequem über einem durchgefallenen Feldwert stehen kann — und der Feldwert ist der, der dir in der Search Console folgt. Labordaten behalten ihren Platz für die Fehlersuche: Sie sind reproduzierbar und sagen dir, *warum* etwas langsam ist. Felddaten sagen dir, *ob es zählt*. Nimm das Labor, um die Ursache zu finden, und das Feld, um zu entscheiden, ob sich die Reparatur gelohnt hat.

Quellen

Die Definitionen der Kennzahlen, die Schwellenwerte, die Bestehensquoten und die Einordnung von Labor- gegen Felddaten stammen aus diesen Quellen, geprüft im August 2026.

• web.dev — Web Vitals ↗

  Die maßgebliche Definition der Core Web Vitals, die Schwellen gut/verbesserungswürdig/schlecht und die 75-Perzentil-Regel, nach der Google bewertet.

• web.dev — Interaction to Next Paint (INP) ↗

  Wie INP über den gesamten Besuch statt nur über die erste Eingabe gemessen wird, und die Ablösung von First Input Delay als Core Web Vital im März 2024.

• Google Search Central — Understanding page experience in Google Search results ↗

  Googles Aussage, dass Page Experience ein Signal unter vielen ist und relevanter Inhalt eine schnellere, aber inhaltsärmere Seite weiterhin schlägt.

• HTTP Archive — Web Almanac 2025, CMS-Kapitel ↗

  Echte Nutzerdaten für Mobilgeräte nach Plattform: Duda 85 %, TYPO3 79 %, Wix 74 %, Weebly 47 %, WordPress 45 %.

• web.dev — When lab and field data are different (and what to do about it) ↗

  Felddaten bilden die reale Vielfalt an Netzen, Geräten und Verhalten ab; Labordaten begrenzen die Variablen bewusst. Wo beides vorliegt, sollten die Felddaten die Priorisierung bestimmen.