Core Web Vitals

Kurz gesagt

Core Web Vitals sind drei Google-Metriken, die messen, ob eine Webseite sich für echte Menschen gut anfühlt: Wird der Hauptinhalt schnell sichtbar? Reagiert die Seite zügig auf Klicks und Taps? Bleibt das Layout ruhig, oder springt plötzlich etwas weg?

Die aktuellen Core Web Vitals sind LCP, INP und CLS. LCP steht für Largest Contentful Paint und misst das Ladeerlebnis. INP steht für Interaction to Next Paint und misst die Reaktionsfähigkeit. CLS steht für Cumulative Layout Shift und misst visuelle Stabilität.

Ordne Feld- und Labormessungen in den technischen SEO-Audit-Ablauf ein, damit Performance zusammen mit Crawlbarkeit und Seitenverhalten bewertet wird.

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 träge reagieren oder der Inhalt beim Lesen springt.

Einfach erklärt

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 große Bild oder der eigentliche Text auf. Das ist ein LCP-Problem.

Dann willst du ein Akkordeon öffnen oder einen Filter antippen. Du tippst, aber einen Moment passiert nichts. Vielleicht fühlt sich die Seite schwerfällig 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, plötzlich triffst du etwas anderes. Das ist ein CLS-Problem.

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

Warum Core Web Vitals für SEO wichtig sind

Google empfiehlt gute Core Web Vitals für Erfolg in der Suche und für eine gute allgemeine Nutzererfahrung. Sie gehören zur Page-Experience-Betrachtung, also zu der Frage, ob Menschen eine Seite angenehm nutzen können.

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

Für 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 spät 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 Schönheit um ihrer selbst willen. Es geht darum, dass wichtige Seiten ihre Aufgabe erfüllen: gefunden werden, verstanden werden, Vertrauen schaffen und Nutzer ohne Frust zum nächsten Schritt bringen.

Die drei Core Web Vitals

LCP: Largest Contentful Paint

LCP misst, wann das größte relevante sichtbare Inhaltselement geladen ist. Das kann ein Hero-Bild, ein großer 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 für den Nutzer wirklich angekommen?"

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

Typische Ursachen für schlechten LCP sind langsame Serverantworten, große Bilder, fehlende responsive Images, render-blockierendes CSS, zu viel JavaScript vor dem Hauptinhalt oder Client-Side Rendering, das den sichtbaren Inhalt erst spät 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 große Produktbild wird als normales Bild weit hinten im Ladeprozess behandelt. Nutzer warten auf den eigentlichen visuellen Anker. Für LCP ist das schlecht, auch wenn manche kleinere Elemente früh 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 Reaktionsfähigkeit über den Besuch hinweg.

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

INP hat First Input Delay, kurz FID, am 12. März 2024 als Core Web Vital ersetzt. Das war ein wichtiger Schritt, weil FID nur einen engeren Ausschnitt gemessen hat. INP ist näher 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 Oberfläche. Für Nutzer fühlt sich das an wie eine Seite, die zwar geladen ist, aber nicht richtig zuhört.

CLS: Cumulative Layout Shift

CLS misst unerwartete Layoutverschiebungen. Die Frage lautet: Bleibt die Seite stabil, während Nutzer lesen oder klicken, oder springen Elemente nachträglich herum?

Ein guter CLS liegt bei 0,1 oder niedriger. Zwischen 0,1 und 0,25 gilt als verbesserungsbedürftig. Mehr als 0,25 gilt als schlecht. CLS ist kein Sekundenwert, sondern ein Score für visuelle Stabilität.

Typische Ursachen sind Bilder ohne feste Größenangaben, Ads ohne reservierten Platz, eingebettete Inhalte, spät geladene Fonts, Promo-Leisten, Cookie-Banner oder dynamische Komponenten, die nach dem ersten Rendern plötzlich Platz beanspruchen.

CLS ist aus Nutzersicht besonders unangenehm, weil es Vertrauen stört. 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: Für die meisten Nutzer ist die Erfahrung wahrscheinlich solide. Needs Improvement bedeutet: Es gibt spürbare 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 zählt

Core Web Vitals werden üblicherweise 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 älteren 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 Büro-WLAN kann beruhigend wirken, während 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 Geräteleistung, Netzwerk, JavaScript-Menge, Bildgrößen oder responsiven Layouts. Wenn beide schlecht sind, kann auch Serverantwort, CDN, Rendering-Strategie oder globale Template-Architektur eine größere 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 Geräte, Browser, Netzwerke, Regionen, Nutzerverhalten und Seitentypen.

Für 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 nervös 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 prüfen, 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 groß? Welches Script erzeugt lange Tasks? Welche Layout-Verschiebung tritt beim Laden auf?

Lab Data ist aber kein Ersatz für Field Data. Ein Lab-Test kann auf einem simulierten Gerät gut aussehen, während 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 für Priorisierung, Lab Data für Diagnose. Erst herausfinden, welche URL-Gruppen echte Probleme haben. Dann mit Lab-Tools verstehen, warum.

URL-Gruppen und Templates

Search Console arbeitet häufig mit URL-Gruppen. Das bedeutet: Ähnliche Seiten werden zusammen bewertet. Für große 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 weißt, welches Element gemessen wird, kannst du sinnvoll optimieren. Ist es ein Bild, ein Textblock, ein Banner oder etwas Unerwartetes?

Häufige Hebel sind schnellere Serverantworten, Caching, CDN-Nutzung, optimierte Bildformate, passende Bildgrößen, responsive Images, Preload für das wichtigste Bild, weniger render-blockierendes CSS und eine Rendering-Strategie, die Hauptinhalt nicht unnötig spät erzeugt.

Ein Detail, das oft übersehen wird: Lazy Loading ist für untere Bilder sinnvoll, aber für das wichtigste sichtbare Hero-Bild oft falsch. Wenn der LCP-Kandidat lazy geladen wird, priorisiert der Browser genau das Element zu spät, das Nutzer zuerst brauchen.

INP verbessern

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

Hilfreich sind kürzere Tasks, Code-Splitting, weniger Hydration-Arbeit, schnellere Event Handler, Debouncing, Throttling, Web Workers für schwere Berechnungen und ein kritischer Blick auf Drittanbieter-Scripte. Chat, Tracking, Heatmaps, A/B-Testing und Personalisierung können nützlich sein, aber sie dürfen die Bedienung nicht blockieren.

Gute INP-Optimierung fühlt sich manchmal unspektakulär an. Ein Menü öffnet ohne Verzögerung. Ein Filter reagiert direkt. Ein Formularfeld hängt 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, Höhe oder Aspect Ratio. Anzeigen und Embeds brauchen feste Container. Banner sollten nicht nachträglich über 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 nachträglich 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 für die gesamte Vergleichsseiten-Gruppe.

Ein einzelner Lighthouse-Test im Büro 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 später 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 später verbessert sich auch die Field Data.

Der eigentliche Gewinn ist nicht nur ein grüner Report. Die Seite fühlt sich ruhiger und direkter an. Nutzer können schneller vergleichen, verstehen mehr und brechen seltener ab.

Häufige Missverständnisse

"Ein 100er Lighthouse-Score reicht"

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

"Core Web Vitals sind nur für Entwickler"

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

"Wenn alles grün ist, ranken wir besser"

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

"FID ist noch die Interaktivitätsmetrik"

Nein. INP hat FID als Core Web Vital ersetzt. Wenn ein Audit noch FID als Hauptmetrik führt, ist es veraltet oder zumindest unvollständig.

"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 für ein größeres Muster.

Mini-Workflow für SEO-Teams

1. Öffne den Core-Web-Vitals-Report in Search Console. 2. Trenne Mobile und Desktop. 3. Identifiziere betroffene URL-Gruppen und die schlechteste Metrik. 4. Prüfe in PageSpeed Insights, ob Field Data für URL oder Origin vorliegt. 5. Bestimme den Seitentyp und das verantwortliche Template. 6. Nutze Lighthouse und DevTools für 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 endgültig 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-Ausreißer.

Sinnvolle Priorisierung kombiniert:

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

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

Mit Crawl Foundry anwenden

Der Site Audit von Crawl Foundry verbindet Crawl-Ergebnisse, interne Links und technische Befunde. Prüfe betroffene URLs und priorisiere die nötigen Korrekturen.

Site Audit ansehen

Verwandte Begriffe

Diese Begriffe passen als nächste Leseschritte:

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

Quellen für 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