Kaum ein SEO-Thema wird so oft überschätzt wie die Core Web Vitals. In Kundengesprächen hören wir regelmäßig den Satz "unsere Ladezeit ist schlecht, deshalb ranken wir nicht". Meistens stimmt das nur zur Hälfte. Core Web Vitals sind ein echter Rankingfaktor, aber ein vergleichsweise kleiner, und sie entfalten ihre Wirkung fast ausschließlich dort, wo der Inhalt bereits gut genug ist, um überhaupt zu konkurrieren. Wer diesen Zusammenhang versteht, spart sich teure Fehlinvestitionen und optimiert an den richtigen Stellen.
Was die Core Web Vitals überhaupt messen
Google fasst unter den Core Web Vitals drei Messwerte zusammen, die beschreiben, wie eine echte Person eine Seite erlebt: wie schnell der sichtbare Hauptinhalt lädt, wie zügig die Seite auf Klicks und Eingaben reagiert und wie stabil das Layout dabei bleibt. Das sind keine rein technischen Laborwerte, sondern Feld-Daten aus dem Chrome User Experience Report (kurz CrUX), die aus echten Besuchen echter Nutzer mit echtem Chrome-Browser stammen. Genau das unterscheidet die Core Web Vitals von klassischen PageSpeed-Tests: Ein Lighthouse-Score im Labor kann hervorragend aussehen, während die Feld-Daten auf Mobilgeräten mit schwacher Verbindung ein völlig anderes Bild zeigen. Für das Ranking zählt am Ende nur, was echte Besucher tatsächlich erleben.
Die drei Kennzahlen im Einzelnen:
- Largest Contentful Paint (LCP): Zeit bis zum Rendern des größten sichtbaren Elements im Viewport, meist ein Hero-Bild, eine Überschrift oder ein Videothumbnail.
- Interaction to Next Paint (INP): Reaktionszeit der Seite auf Nutzerinteraktionen wie Klicks, Taps oder Tastatureingaben, gemessen über die gesamte Sitzung hinweg.
- Cumulative Layout Shift (CLS): Summe aller unerwarteten Layoutverschiebungen während des Seitenaufbaus und der Interaktion.
LCP: Der größte Inhalt muss schnell da sein
Der Largest Contentful Paint gilt als gut, wenn er unter 2,5 Sekunden liegt, als verbesserungswürdig bis 4 Sekunden und als schlecht darüber. In der Praxis scheitert LCP an drei immer wiederkehrenden Ursachen: ein zu großes, nicht optimiertes Hero-Bild, eine langsame Serverantwortzeit (Time to First Byte) und render-blockierende Ressourcen wie CSS oder Web-Fonts, die den Aufbau der Seite verzögern. Besonders auf Shopify-Shops und WordPress-Seiten mit vielen Apps und Plugins summieren sich diese drei Faktoren gerne zu einem LCP jenseits von 4 Sekunden.
Was in der Praxis wirklich hilft: das größte Bild im ersten Bildschirmbereich als WebP oder AVIF ausliefern, in der tatsächlich benötigten Größe (nicht 4000 Pixel breit, wenn nur 800 angezeigt werden), mit fetchpriority="high" und ohne Lazy Loading, da Lazy Loading ausgerechnet das wichtigste Element verzögert, das man eigentlich sofort braucht. Kritisches CSS sollte inline im Head stehen, alles andere asynchron nachgeladen werden. Web-Fonts gehören selbst gehostet und per preload priorisiert, statt über externe Font-Server geladen zu werden, die eine zusätzliche DNS-Auflösung und Verbindung kosten. Wer ein neues Projekt plant, sollte diese Punkte von Anfang an im Aufbau berücksichtigen. Genau das ist einer der Gründe, warum wir bei jedem Webdesign-Projekt Performance nicht als nachträgliche Optimierung behandeln, sondern als Teil des technischen Fundaments.
INP: Die Reaktionsfähigkeit ersetzt den alten FID
Seit März 2024 hat Interaction to Next Paint den First Input Delay (FID) als offiziellen Rankingfaktor abgelöst. Der Unterschied ist wichtig: FID maß nur die Verzögerung bis zur ersten Reaktion auf die allererste Interaktion. INP dagegen bewertet die Reaktionszeit über die gesamte Sitzung, inklusive aller Klicks, Taps und Tastatureingaben, und meldet den schlechtesten typischen Wert. Eine Seite, die beim ersten Klick blitzschnell reagiert, aber beim Öffnen eines Filtermenüs oder eines Warenkorbs für 600 Millisekunden einfriert, bekommt dafür einen schlechten INP-Wert, unabhängig davon, wie gut der erste Eindruck war.
Gut ist ein INP unter 200 Millisekunden, verbesserungswürdig bis 500 Millisekunden, alles darüber gilt als schlecht. Die Hauptursache sind fast immer lange JavaScript-Aufgaben, die den Hauptthread blockieren: schwere Analytics-Skripte, Chat-Widgets, Cookie-Banner mit komplexer Logik, oder schlecht optimierte Filterfunktionen in Online-Shops. Die Lösung liegt selten in einem einzigen großen Fix, sondern in vielen kleinen Maßnahmen: lange Tasks in kleinere Häppchen aufteilen, nicht kritisches JavaScript per requestIdleCallback verzögern, Drittanbieter-Skripte konsequent auf ihre tatsächliche Notwendigkeit prüfen und Event-Handler entschlacken. Gerade bei Online-Shops mit vielen Apps, Trackingpixeln und Chat-Tools ist INP oft die Kennzahl, die zuerst kippt. Wer einen Online-Shop erstellen lässt, sollte diesen Punkt direkt in der Konzeptionsphase ansprechen, statt ihn erst zu spüren, wenn der Shop schon live ist und jede App-Deinstallation wehtut.
CLS: Wenn sich der Inhalt unter dem Klick verschiebt
Cumulative Layout Shift ist die Kennzahl, die Nutzer am direktesten spüren, auch wenn sie den Namen nie gehört haben. Jeder kennt die Situation: Man will auf einen Button tippen, in der Millisekunde davor lädt eine Werbeanzeige nach und die Seite springt, der Klick landet woanders. Ein CLS unter 0,1 gilt als gut, bis 0,25 als verbesserungswürdig, darüber als schlecht. Die häufigsten Verursacher: Bilder und Videos ohne definierte Breite und Höhe im HTML oder CSS, sodass der Browser beim Laden nicht weiß, wie viel Platz er reservieren muss. Web-Fonts, die beim Nachladen einen sichtbar anderen Zeilenumbruch erzeugen (Font-Swap ohne passende Fallback-Metriken). Dynamisch nachgeladene Inhalte wie Cookie-Banner, Newsletter-Popups oder Werbeanzeigen, die ohne reservierten Platz oberhalb des bestehenden Inhalts eingefügt werden.
Die Behebung ist meist unspektakulär, aber wirksam: jedem Bild und Video explizite width- und height-Attribute geben (der Browser berechnet daraus das Seitenverhältnis automatisch), für Werbeflächen und Embeds feste Platzhaltergrößen per CSS reservieren, und Banner oder Popups so einbauen, dass sie den bestehenden Inhalt nicht nach unten schieben, sondern darüber liegen oder von Anfang an eingeplanten Platz nutzen.
Wie stark wirken Core Web Vitals wirklich aufs Ranking
Hier trennt sich in der Praxis die Theorie von der Realität. Core Web Vitals sind Teil des sogenannten Page-Experience-Signals, das Google seit 2021 im Ranking berücksichtigt. Google selbst hat mehrfach öffentlich klargestellt, dass Page Experience als Rankingfaktor greift, sobald mehrere Seiten inhaltlich ähnlich relevant für eine Suchanfrage sind: dann kann die bessere Nutzererfahrung den Ausschlag geben. Bei klar besserer inhaltlicher Relevanz gewinnt weiterhin der bessere Inhalt, auch wenn seine Ladezeit mittelmäßig ist. In der Praxis heißt das: Eine Seite mit dünnem, wenig hilfreichem Inhalt rankt nicht plötzlich vorne, nur weil der LCP bei 1,2 Sekunden liegt. Umgekehrt kann ein exzellenter, gut strukturierter Ratgeberartikel trotz eines etwas trägen INP-Werts weiterhin gut ranken, solange die Werte nicht katastrophal schlecht sind. Core Web Vitals sind also eher ein Zünglein an der Waage als ein Hebel, mit dem man von Seite 3 auf Seite 1 springt. Wer trotzdem regelmäßig schlechte Werte hat, verliert aber an anderer Stelle: höhere Absprungraten, weniger Conversions, unzufriedene Nutzer, und mittelfristig auch ein schwächeres Crawling-Budget, weil der Googlebot bei langsamen Seiten weniger URLs pro Zeiteinheit abruft.
| Kennzahl | Gut | Verbesserungswürdig | Schlecht |
|---|---|---|---|
| LCP (Largest Contentful Paint) | unter 2,5 s | 2,5 bis 4 s | über 4 s |
| INP (Interaction to Next Paint) | unter 200 ms | 200 bis 500 ms | über 500 ms |
| CLS (Cumulative Layout Shift) | unter 0,1 | 0,1 bis 0,25 | über 0,25 |
Woran gute Werte in der Praxis meistens scheitern
Aus unserer Erfahrung mit Website-Audits für ganz unterschiedliche Branchen kristallisieren sich immer wieder dieselben Muster heraus, unabhängig davon, ob es sich um eine WordPress-Seite, einen Shopify-Shop oder eine individuell programmierte Anwendung handelt:
- Zu viele Drittanbieter-Skripte: Tracking-Pixel, Chat-Widgets, A/B-Testing-Tools und Retargeting-Codes, die sich über die Jahre ansammeln und niemand mehr entfernt.
- Bilder, die nie komprimiert oder in ein modernes Format konvertiert wurden, oft in der Originalgröße der Kamera oder des Grafikprogramms.
- Shared Hosting oder unterdimensionierte Server, die bei Lastspitzen die Time to First Byte in die Höhe treiben.
- Themes und Page-Builder, die für jede kleine Änderung zusätzliches CSS und JavaScript nachladen, das nie wieder entfernt wird.
- Fehlende Caching-Strategie: Jede Anfrage baut die Seite serverseitig komplett neu auf, statt gecachte Varianten auszuliefern.
Core Web Vitals in der Praxis verbessern: die Reihenfolge zählt
Wer mit begrenztem Budget arbeitet, sollte nicht wahllos an allen drei Werten gleichzeitig schrauben, sondern in einer sinnvollen Reihenfolge vorgehen. Zuerst die Basis: Hosting und Serverantwortzeit prüfen, denn eine langsame Time to First Byte wirkt sich auf alle drei Kennzahlen gleichzeitig negativ aus. Danach die Bildoptimierung, weil sie meist den größten Hebel für LCP darstellt und sich vergleichsweise einfach umsetzen lässt, auch ohne Entwicklerressourcen, etwa über ein automatisiertes Bildoptimierungs-Tool. Anschließend das Layout stabilisieren, indem alle Bilder, Embeds und dynamischen Elemente feste Platzhaltergrößen bekommen. Erst zum Schluss folgt die aufwendigste Aufgabe: das JavaScript entschlacken, unnötige Skripte entfernen und die verbleibenden so laden, dass sie den Hauptthread nicht blockieren. Für Shopify-Shops gilt eine Besonderheit: Viele Performance-Probleme entstehen nicht durch das Theme selbst, sondern durch installierte Apps, die jeweils eigenes JavaScript und CSS einschleusen. Eine ehrliche App-Bereinigung bringt hier oft mehr als jede Theme-Anpassung. Als Shopify-Agentur sehen wir regelmäßig Shops mit 15 oder mehr aktiven Apps, von denen die Hälfte längst ungenutzt ist, aber weiterhin Skripte lädt.
Messen statt raten: die richtigen Tools
Für eine belastbare Einschätzung braucht es beide Datenquellen, Feld-Daten und Labor-Daten, denn sie beantworten unterschiedliche Fragen. Die Google Search Console zeigt unter "Wichtige Web-Vitals" die tatsächlichen CrUX-Feld-Daten der letzten 28 Tage, gruppiert nach URL-Gruppen, und ist damit die verlässlichste Quelle für das, was Google für das Ranking heranzieht. PageSpeed Insights kombiniert Feld-Daten (sofern für die Domain vorhanden) mit einem Labor-Test und liefert zusätzlich konkrete, priorisierte Verbesserungsvorschläge. Chrome DevTools mit dem Performance-Panel eignet sich für die Detailanalyse einzelner langer Tasks, etwa um genau herauszufinden, welches Skript für einen schlechten INP-Wert verantwortlich ist. Wichtig dabei: Ein einzelner Lighthouse-Lauf auf dem eigenen Büro-WLAN sagt wenig über die reale Erfahrung eines Nutzers mit mittelmäßigem Mobilfunkempfang aus. Für eine ehrliche Einschätzung braucht es echte Feld-Daten über einen längeren Zeitraum.
Wo Core Web Vitals in ein größeres SEO-Konzept gehören
Technische Performance ist ein Baustein von vielen, kein Ersatz für die anderen. Inhaltliche Relevanz, saubere interne Verlinkung, ein durchdachtes Seitenkonzept und zunehmend auch Sichtbarkeit in KI-gestützten Suchergebnissen entscheiden weiterhin stärker über den Erfolg als ein paar Millisekunden gesparte Ladezeit. Wer eine SEO-Agentur mit der Optimierung beauftragt, sollte deshalb darauf achten, dass Core Web Vitals als ein Prüfpunkt unter vielen behandelt werden, nicht als alleiniger Fokus. Bevor man Budget in Performance-Optimierung steckt, lohnt sich ein Blick auf die Gesamtsituation. Wer die Kosten für eine technische Überarbeitung grob einschätzen möchte, findet über den Preiskalkulator einen ersten Anhaltspunkt, welcher Aufwand realistisch ist.
Häufige Fragen
Wie oft aktualisiert Google die Core-Web-Vitals-Daten?
Die Daten in der Search Console basieren auf einem gleitenden 28-Tage-Zeitraum und werden laufend aktualisiert. Änderungen an der eigenen Seite wirken sich also nicht sofort, sondern erst nach einigen Wochen sichtbar in den Berichten aus.
Reicht ein guter Lighthouse-Score im Labor als Nachweis für gute Core Web Vitals?
Nein. Lighthouse liefert Labordaten unter Idealbedingungen. Für das Ranking zählen die Feld-Daten aus der Search Console, die echte Nutzer mit realen Geräten und Verbindungen widerspiegeln. Beide Werte können deutlich auseinanderliegen.
Kann eine mobile Seite gute Core Web Vitals haben, die Desktop-Version aber schlechte?
Ja, das kommt sehr häufig vor. Google bewertet Mobil und Desktop getrennt, und da Google nach dem Mobile-First-Prinzip vor allem die mobile Version crawlt und bewertet, sollte die Priorität bei der Optimierung klar auf Mobilgeräten liegen.
Wie schnell wirkt sich eine Verbesserung der Core Web Vitals auf das Ranking aus?
Es gibt keine feste Frist. Da die Search-Console-Daten auf einem 28-Tage-Fenster basieren und Google Rankinganpassungen zusätzlich schrittweise vornimmt, sollte man realistisch mit mehreren Wochen bis wenigen Monaten rechnen, bis ein Effekt messbar wird.
Sind Core Web Vitals für kleine, lokale Websites genauso relevant wie für große Online-Shops?
Der Rankingeinfluss gilt grundsätzlich für alle Websites, wirkt sich aber bei stark umkämpften Suchbegriffen deutlicher aus. Bei einem lokalen Handwerksbetrieb mit wenig Konkurrenz spielt die Ladezeit für die Nutzererfahrung trotzdem eine Rolle, auch wenn der Rankingeffekt kleiner ausfällt.
Verschlechtern Cookie-Banner automatisch den CLS-Wert?
Nur, wenn sie unsauber eingebunden sind. Ein Banner, das ohne reservierten Platz nachträglich oben ins Layout eingefügt wird und den restlichen Inhalt nach unten schiebt, verursacht einen Layout-Shift. Wird von Anfang an Platz dafür eingeplant oder das Banner als Overlay über den Inhalt gelegt, entsteht kein messbarer CLS-Effekt.
Lohnt sich eine komplette Neuentwicklung nur wegen schlechter Core Web Vitals?
Selten als alleiniger Grund. Meist lassen sich die größten Probleme (Bildgrößen, unnötige Skripte, fehlende Platzhaltergrößen) mit gezielten Anpassungen am bestehenden System beheben. Eine Neuentwicklung lohnt sich eher, wenn ohnehin technische Altlasten, veraltete Technologie oder fehlende Erweiterbarkeit den Ausschlag geben.