Core Web Vitals

Kurz gesagt

Core Web Vitals sind drei Google-Metriken, die messen, ob eine Webseite sich fuer echte Menschen gut anfuehlt: Wird der Hauptinhalt schnell sichtbar? Reagiert die Seite zuegig auf Klicks und Taps? Bleibt das Layout ruhig, oder springt ploetzlich etwas weg?

Die aktuellen Core Web Vitals sind LCP, INP und CLS. LCP steht fuer Largest Contentful Paint und misst das Ladeerlebnis. INP steht fuer Interaction to Next Paint und misst die Reaktionsfaehigkeit. CLS steht fuer Cumulative Layout Shift und misst visuelle Stabilitaet.

Wichtig ist die richtige Einordnung: Core Web Vitals bewerten nicht, ob dein Inhalt hilfreich, einzigartig oder fachlich stark ist. Sie bewerten die technische Nutzbarkeit rund um diesen Inhalt. Eine schnelle, aber inhaltlich schwache Seite wird dadurch nicht automatisch gut. Eine fachlich starke Seite kann aber Wirkung verlieren, wenn Nutzer zu lange warten, Klicks traege reagieren oder der Inhalt beim Lesen springt.

Einfach erklaert

Stell dir vor, du suchst eine Antwort, klickst auf ein Ergebnis und landest auf einer Seite. Zuerst siehst du nur Logo, Navigation und einen leeren Bereich. Nach ein paar Sekunden taucht endlich das grosse Bild oder der eigentliche Text auf. Das ist ein LCP-Problem.

Dann willst du ein Akkordeon oeffnen oder einen Filter antippen. Du tippst, aber einen Moment passiert nichts. Vielleicht fuehlt sich die Seite schwerfaellig an, obwohl sie optisch schon geladen ist. Das ist ein INP-Problem.

Kurz darauf schiebt ein Cookie-Banner, eine Anzeige oder ein nachgeladenes Bild den Inhalt nach unten. Dein Finger war schon auf dem Button, ploetzlich triffst du etwas anderes. Das ist ein CLS-Problem.

Genau solche Momente machen Core Web Vitals greifbar. Sie uebersetzen schwammige Aussagen wie "die Seite wirkt langsam" in konkrete Signale. Das hilft SEO, Entwicklung, Design und Content-Teams, weil nicht mehr alle ueber ein anderes Gefuehl sprechen. Man sieht, welche Art von Reibung wirklich vorliegt.

Warum Core Web Vitals fuer SEO wichtig sind

Google empfiehlt gute Core Web Vitals fuer Erfolg in der Suche und fuer eine gute allgemeine Nutzererfahrung. Sie gehoeren zur Page-Experience-Betrachtung, also zu der Frage, ob Menschen eine Seite angenehm nutzen koennen.

Trotzdem sind Core Web Vitals kein Ranking-Wunder. Google will vor allem hilfreiche, relevante Ergebnisse zeigen. Wenn eine Seite die Suchintention verfehlt, retten gruene Performance-Werte sie nicht. Umgekehrt sollte eine sehr relevante Seite schlechte Nutzbarkeit nicht ignorieren, besonders wenn Wettbewerber aehnlich gute Inhalte mit besserer Erfahrung anbieten.

Fuer SEO-Teams sind Core Web Vitals so wertvoll, weil sie technische Arbeit priorisierbar machen. "Page Speed verbessern" ist zu ungenau. "Der LCP unserer Produkt-Templates ist schlecht, weil das Hero-Bild spaet priorisiert wird" ist ein umsetzbares Problem. "Mobile INP ist schlecht, weil ein Pricing-Rechner und Drittanbieter-Scripte den Main Thread blockieren" ist noch konkreter.

Am Ende geht es nicht um technische Schoenheit um ihrer selbst willen. Es geht darum, dass wichtige Seiten ihre Aufgabe erfuellen: gefunden werden, verstanden werden, Vertrauen schaffen und Nutzer ohne Frust zum naechsten Schritt bringen.

Die drei Core Web Vitals

LCP: Largest Contentful Paint

LCP misst, wann das groesste relevante sichtbare Inhaltselement geladen ist. Das kann ein Hero-Bild, ein grosser Textblock, ein Produktbild, ein Video-Poster oder ein Hauptbanner sein. Die Metrik fragt also nicht: "Wann startet die Seite?" Sie fragt: "Wann wirkt der zentrale Inhalt fuer den Nutzer wirklich angekommen?"

Ein guter LCP liegt bei 2,5 Sekunden oder schneller. Zwischen 2,5 und 4 Sekunden gilt als verbesserungsbeduerftig. Mehr als 4 Sekunden gilt als schlecht.

Typische Ursachen fuer schlechten LCP sind langsame Serverantworten, grosse Bilder, fehlende responsive Images, render-blockierendes CSS, zu viel JavaScript vor dem Hauptinhalt oder Client-Side Rendering, das den sichtbaren Inhalt erst spaet erzeugt. Bei vielen modernen Websites ist nicht die gesamte Seite langsam, sondern genau das wichtigste Element wird falsch priorisiert.

Ein praktisches Beispiel: Eine Landingpage hat sofort Navigation und Hintergrundfarbe, aber das grosse Produktbild wird als normales Bild weit hinten im Ladeprozess behandelt. Nutzer warten auf den eigentlichen visuellen Anker. Fuer LCP ist das schlecht, auch wenn manche kleinere Elemente frueh erscheinen.

INP: Interaction to Next Paint

INP misst, wie schnell eine Seite sichtbar auf Nutzerinteraktionen reagiert. Gemeint sind zum Beispiel Klicks, Taps und Tastatureingaben. Die Metrik betrachtet nicht nur die allererste Interaktion, sondern die Reaktionsfaehigkeit ueber den Besuch hinweg.

Ein guter INP liegt bei 200 Millisekunden oder weniger. Zwischen 200 und 500 Millisekunden gilt als verbesserungsbeduerftig. Mehr als 500 Millisekunden gilt als schlecht.

INP hat First Input Delay, kurz FID, am 12. Maerz 2024 als Core Web Vital ersetzt. Das war ein wichtiger Schritt, weil FID nur einen engeren Ausschnitt gemessen hat. INP ist naeher an der echten Nutzung, besonders bei Seiten mit viel JavaScript, Filtern, Konfiguratoren, Karten, Chat-Widgets oder Personalisierung.

Schlechter INP entsteht oft nicht durch ein einzelnes sichtbares Problem, sondern durch zu viel Arbeit im Browser. Lange JavaScript-Tasks blockieren den Main Thread. Event Handler machen zu viel auf einmal. Drittanbieter-Scripte konkurrieren mit der eigentlichen Oberflaeche. Fuer Nutzer fuehlt sich das an wie eine Seite, die zwar geladen ist, aber nicht richtig zuhoert.

CLS: Cumulative Layout Shift

CLS misst unerwartete Layoutverschiebungen. Die Frage lautet: Bleibt die Seite stabil, waehrend Nutzer lesen oder klicken, oder springen Elemente nachtraeglich herum?

Ein guter CLS liegt bei 0,1 oder niedriger. Zwischen 0,1 und 0,25 gilt als verbesserungsbeduerftig. Mehr als 0,25 gilt als schlecht. CLS ist kein Sekundenwert, sondern ein Score fuer visuelle Stabilitaet.

Typische Ursachen sind Bilder ohne feste Groessenangaben, Ads ohne reservierten Platz, eingebettete Inhalte, spaet geladene Fonts, Promo-Leisten, Cookie-Banner oder dynamische Komponenten, die nach dem ersten Rendern ploetzlich Platz beanspruchen.

CLS ist aus Nutzersicht besonders unangenehm, weil es Vertrauen stoert. Wenn ein Button im letzten Moment wegrutscht, wirkt die Seite nicht nur langsam, sondern unsauber. Bei sensiblen Aktionen, etwa Formularen, Preisen oder Checkout-Schritten, ist das mehr als ein optisches Problem.

Schwellenwerte richtig verstehen

Good, Needs Improvement und Poor

Die Core-Web-Vitals-Reports arbeiten mit drei Bereichen: Good, Needs Improvement und Poor. Diese Labels sind keine moralische Bewertung deiner Website. Sie sind eine praktische Priorisierungshilfe.

Good bedeutet: Fuer die meisten Nutzer ist die Erfahrung wahrscheinlich solide. Needs Improvement bedeutet: Es gibt spuerbare Reibung, aber nicht zwingend einen Notfall. Poor bedeutet: Diese URL-Gruppe sollte ernsthaft untersucht werden, weil ein relevanter Teil der Nutzer vermutlich ein schlechtes Erlebnis hat.

Warum das 75. Perzentil zaehlt

Core Web Vitals werden ueblicherweise am 75. Perzentil bewertet, getrennt nach Mobile und Desktop. Vereinfacht gesagt: Mindestens 75 Prozent der Besuche sollten im guten Bereich liegen.

Das ist strenger und sinnvoller als ein Durchschnitt. Ein Durchschnitt kann gut aussehen, obwohl viele Menschen auf langsameren Smartphones, schlechten Netzen oder aelteren Browsern leiden. Das 75. Perzentil zwingt Teams, nicht nur den idealen Testfall zu optimieren, sondern die reale Mehrheit der Nutzung.

Mobile und Desktop getrennt betrachten

Viele Core-Web-Vitals-Probleme sind mobil deutlich schlimmer. Ein Desktop-Test im schnellen Buero-WLAN kann beruhigend wirken, waehrend reale mobile Nutzer lange warten. Deshalb solltest du mobile und Desktop-Daten nie gedanklich zusammenwerfen.

Wenn nur Mobile schlecht ist, liegt die Ursache oft in Geraeteleistung, Netzwerk, JavaScript-Menge, Bildgroessen oder responsiven Layouts. Wenn beide schlecht sind, kann auch Serverantwort, CDN, Rendering-Strategie oder globale Template-Architektur eine groessere Rolle spielen.

Field Data vs Lab Data

Field Data: echte Nutzung

Field Data kommt von echten Nutzern, etwa aus dem Chrome UX Report oder aus dem Core-Web-Vitals-Report in Search Console. Sie zeigt, wie deine Seiten unter realen Bedingungen funktionieren: verschiedene Geraete, Browser, Netzwerke, Regionen, Nutzerverhalten und Seitentypen.

Fuer SEO-Priorisierung ist Field Data besonders wichtig. Sie beantwortet die Frage: "Wo haben echte Nutzer wirklich ein Problem?" Dadurch vermeidest du, nur eine einzelne Testumgebung zu optimieren.

Field Data hat aber eine Eigenschaft, die Teams oft nervoes macht: Sie reagiert nicht sofort. Nach einem Deployment kann es dauern, bis neue Nutzerdaten sichtbar werden. Deshalb ist Geduld Teil des Workflows. Du kannst technische Verbesserungen sofort im Labor pruefen, aber die echte SEO-relevante Bewertung braucht frische reale Daten.

Lab Data: kontrollierte Diagnose

Lab Data entsteht in kontrollierten Tests, zum Beispiel mit Lighthouse, PageSpeed Insights oder Chrome DevTools. Sie ist ideal, um Ursachen zu finden: Welche Ressource blockiert Rendering? Welches Bild ist zu gross? Welches Script erzeugt lange Tasks? Welche Layout-Verschiebung tritt beim Laden auf?

Lab Data ist aber kein Ersatz fuer Field Data. Ein Lab-Test kann auf einem simulierten Geraet gut aussehen, waehrend echte Nutzer weiterhin Probleme haben. Umgekehrt kann ein einzelner Lab-Test schlecht aussehen, obwohl die reale Mehrheit gut zurechtkommt.

Die beste Regel ist einfach: Field Data fuer Priorisierung, Lab Data fuer Diagnose. Erst herausfinden, welche URL-Gruppen echte Probleme haben. Dann mit Lab-Tools verstehen, warum.

URL-Gruppen und Templates

Search Console arbeitet haeufig mit URL-Gruppen. Das bedeutet: Aehnliche Seiten werden zusammen bewertet. Fuer grosse Websites ist das hilfreich, weil ein einziges Template-Problem hunderte oder tausende URLs betreffen kann.

Genau hier passieren aber viele Fehlinterpretationen. Ein Team optimiert eine einzelne Beispiel-URL und wundert sich, warum die Gruppe schlecht bleibt. Wenn das Problem im Template, in einer wiederverwendeten Komponente oder in einem globalen Script liegt, reicht eine einzelne Korrektur nicht.

Darum solltest du bei jedem Core-Web-Vitals-Problem fragen:

• Welcher Seitentyp ist betroffen?
• Tritt das Problem auf Mobile, Desktop oder beidem auf?
• Ist eine Komponente auf allen betroffenen URLs gleich?
• Ist der LCP-Kandidat wirklich der gleiche?
• Gibt es Drittanbieter-Scripte, die nur auf bestimmten Templates laufen?
• Sind schlechte Werte auf wichtige SEO-Seiten konzentriert oder auf Randbereiche?

Diese Fragen verhindern Aktionismus. Du optimierst nicht die lauteste URL, sondern das eigentliche Muster.

Wie man Core Web Vitals praktisch verbessert

LCP verbessern

Bei LCP lohnt sich zuerst die Frage: Was ist der LCP-Kandidat? Erst wenn du weisst, welches Element gemessen wird, kannst du sinnvoll optimieren. Ist es ein Bild, ein Textblock, ein Banner oder etwas Unerwartetes?

Haeufige Hebel sind schnellere Serverantworten, Caching, CDN-Nutzung, optimierte Bildformate, passende Bildgroessen, responsive Images, Preload fuer das wichtigste Bild, weniger render-blockierendes CSS und eine Rendering-Strategie, die Hauptinhalt nicht unnoetig spaet erzeugt.

Ein Detail, das oft uebersehen wird: Lazy Loading ist fuer untere Bilder sinnvoll, aber fuer das wichtigste sichtbare Hero-Bild oft falsch. Wenn der LCP-Kandidat lazy geladen wird, priorisiert der Browser genau das Element zu spaet, das Nutzer zuerst brauchen.

INP verbessern

Bei INP geht es um Browserarbeit nach Interaktionen. Frage nicht nur: "Wie gross ist unser JavaScript-Bundle?" Frage auch: "Was passiert genau, wenn jemand klickt?"

Hilfreich sind kuerzere Tasks, Code-Splitting, weniger Hydration-Arbeit, schnellere Event Handler, Debouncing, Throttling, Web Workers fuer schwere Berechnungen und ein kritischer Blick auf Drittanbieter-Scripte. Chat, Tracking, Heatmaps, A/B-Testing und Personalisierung koennen nuetzlich sein, aber sie duerfen die Bedienung nicht blockieren.

Gute INP-Optimierung fuehlt sich manchmal unspektakulaer an. Ein Menue oeffnet ohne Verzoegerung. Ein Filter reagiert direkt. Ein Formularfeld haengt nicht. Genau diese kleinen Momente entscheiden, ob eine Seite professionell wirkt.

CLS verbessern

Bei CLS lautet die Grundregel: Reserviere Platz, bevor Inhalt kommt. Bilder und Videos brauchen Breite, Hoehe oder Aspect Ratio. Anzeigen und Embeds brauchen feste Container. Banner sollten nicht nachtraeglich ueber dem Inhalt einschieben. Fonts sollten so geladen werden, dass Text nicht stark umbricht oder springt.

Auch Consent- und Promo-Komponenten sind wichtig. Ein Cookie-Banner, der unten erscheint, ist oft unproblematischer als eine Leiste, die nachtraeglich oberhalb des Inhalts Platz beansprucht. Ein Newsletter-Popup kann Conversion bringen, aber wenn es Layout verschiebt, bezahlt die Seite mit Vertrauen.

Ein realistisches Beispiel

Ein SaaS-Unternehmen hat eine wichtige Vergleichsseite. Der Inhalt ist gut recherchiert, die Suchintention passt, und die Seite bringt viele qualifizierte Besucher. Trotzdem ist die mobile Conversion schwach. Search Console zeigt schlechte INP-Werte fuer die gesamte Vergleichsseiten-Gruppe.

Ein einzelner Lighthouse-Test im Buero sieht gar nicht katastrophal aus. Die Field Data bleibt aber schlecht. In DevTools zeigt sich: Auf Mittelklasse-Smartphones laufen beim ersten Scrollen und bei Filter-Klicks mehrere Dinge gleichzeitig. Ein A/B-Test-Script berechnet Varianten, ein Chat-Widget initialisiert sich, Tracking sendet Events, und ein Vergleichsrechner aktualisiert viele DOM-Elemente.

Das Team entscheidet nicht blind "alles raus". Es priorisiert nach Nutzen. Der Chat wird nach hinten verschoben. Der Vergleichsrechner wird in kleinere Teile zerlegt. Unwichtige Tracking-Events werden spaeter gesendet. Der Filter aktualisiert zuerst sichtbar die UI und erledigt schwere Arbeit danach. Nach dem Deployment zeigen Lab-Daten bessere Long-Task-Werte. Einige Wochen spaeter verbessert sich auch die Field Data.

Der eigentliche Gewinn ist nicht nur ein gruener Report. Die Seite fuehlt sich ruhiger und direkter an. Nutzer koennen schneller vergleichen, verstehen mehr und brechen seltener ab.

Haeufige Missverstaendnisse

"Ein 100er Lighthouse-Score reicht"

Nein. Lighthouse ist hilfreich, aber ein einzelner Lab-Score ist nicht die Realitaet deiner Nutzer. Core Web Vitals sollten mit Field Data verbunden werden.

"Core Web Vitals sind nur fuer Entwickler"

Nein. Entwickler setzen viele Loesungen um, aber SEO, Content, Design, Analytics und Marketing beeinflussen die Ursachen mit. Riesige Hero-Bilder, schwere Widgets, aggressive Banner oder komplexe Personalisierung entstehen oft ausserhalb reiner Entwicklung.

"Wenn alles gruen ist, ranken wir besser"

Nicht automatisch. Gruene Werte helfen der Nutzbarkeit, ersetzen aber keine Relevanz, keine hilfreichen Inhalte und keine klare Suchintention.

"FID ist noch die Interaktivitaetsmetrik"

Nein. INP hat FID als Core Web Vital ersetzt. Wenn ein Audit noch FID als Hauptmetrik fuehrt, ist es veraltet oder zumindest unvollstaendig.

"Wir fixen eine URL und sind fertig"

Selten. Viele Probleme sitzen in Templates, Komponenten oder globalen Scripten. Eine einzelne URL ist oft nur ein Beispiel fuer ein groesseres Muster.

Mini-Workflow fuer SEO-Teams

1. Oeffne den Core-Web-Vitals-Report in Search Console. 2. Trenne Mobile und Desktop. 3. Identifiziere betroffene URL-Gruppen und die schlechteste Metrik. 4. Pruefe in PageSpeed Insights, ob Field Data fuer URL oder Origin vorliegt. 5. Bestimme den Seitentyp und das verantwortliche Template. 6. Nutze Lighthouse und DevTools fuer Ursachenanalyse. 7. Priorisiere Seiten mit hohem SEO-, Umsatz- oder Lead-Wert. 8. Formuliere konkrete Tickets: LCP-Kandidat, INP-Interaktion oder CLS-Ursache. 9. Messe nach dem Deployment im Labor erneut. 10. Warte auf neue Field Data, bevor du den Erfolg endgueltig bewertest.

Gute Priorisierung

Nicht jede Core-Web-Vitals-Warnung ist gleich wichtig. Eine schlechte URL-Gruppe mit vielen organischen Einstiegen und hoher Conversion-Relevanz ist dringender als ein Archivbereich ohne Traffic. Ein schlechtes Mobile-Template ist oft dringender als ein einzelner Desktop-Ausreisser.

Sinnvolle Priorisierung kombiniert:

• SEO-Potenzial der betroffenen Seiten
• Business-Wert der betroffenen Nutzerreise
• Schweregrad der Metrik
• Anzahl betroffener URLs
• Wiederverwendbarkeit der Loesung
• Entwicklungsaufwand und Risiko

So werden Core Web Vitals nicht zum endlosen Performance-Spiel, sondern zu einem klaren Verbesserungsprogramm.

Contextter-Perspektive

Contextter betrachtet Core Web Vitals nicht als isolierte Technikzahl. Fuer moderne SEO zaehlt das Zusammenspiel: Passt der Inhalt zur Suchintention? Ist er hilfreich und differenziert? Wird er schnell genug sichtbar? Laesst er sich angenehm lesen, vergleichen und nutzen?

Gerade bei Content-Portfolios ist diese Verbindung entscheidend. Eine Seite kann fachlich stark sein und trotzdem unterperformen, wenn Nutzer den Hauptinhalt zu spaet sehen oder Interaktionen auf Mobile zaeh wirken. Umgekehrt bringt technische Perfektion wenig, wenn die Seite keine echte Antwort liefert.

In einem guten SEO-Workflow markieren Core Web Vitals deshalb nicht das Ende der Optimierung, sondern den technischen Qualitaetsboden. Darauf bauen Content-Tiefe, interne Verlinkung, Suchintention, Autoritaet und Conversion-Fuehrung auf.

Verwandte Begriffe

Diese Begriffe passen als naechste Leseschritte:

• page-speed
• lighthouse
• server-side-rendering
• mobile-first-indexing
• javascript-rendering-seo

Quellen fuer den Review

• web.dev: Web Vitals
• Google Search Central: Core Web Vitals and Google Search results
• Google Search Central: Page experience in Google Search
• web.dev: Interaction to Next Paint
• web.dev: Largest Contentful Paint
• web.dev: Cumulative Layout Shift
• Google Search Central Blog: Introducing INP to Core Web Vitals