Core Web Vitals: messen, einordnen, Business-Impact

Die Situation kennst du vermutlich: Das Marketing weiß seit Monaten, dass die Website langsam ist. Die IT hat andere Prioritäten. Und die Zentrale fragt nach Beweisen, bevor sie Budget freigibt. Wo steht, dass schlechte Core Web Vitals Traffic kosten? Wie groß ist der Effekt? Warum soll das wichtiger sein als das nächste Feature?

Dieser Artikel liefert die Antworten mit Quellen. Er zeigt, wie du Core Web Vitals richtig misst, wie stark sie das Ranking wirklich beeinflussen, und wo der eigentliche Business-Hebel liegt: weniger im Ranking, mehr in Conversion, Anzeigenkosten und Crawling. Und er sagt ehrlich, wo die Beweiskette dünn ist.

Zum CWV Business Calculator

Was Core Web Vitals sind und woran Google sie misst

Core Web Vitals sind drei Kennzahlen, mit denen Google die Nutzererfahrung einer Seite bewertet: Largest Contentful Paint (LCP) misst, wie schnell das größte sichtbare Element geladen ist. Interaction to Next Paint (INP) misst, wie schnell die Seite auf Klicks und Eingaben reagiert. Cumulative Layout Shift (CLS) misst, wie stark Inhalte während des Ladens springen. Für jede Metrik gibt es eine Schwelle für "gut", und Google bewertet nicht den Durchschnitt, sondern das 75. Perzentil aller Seitenaufrufe. Drei von vier Besuchern müssen die Schwelle also unterschreiten, sonst gilt die Seite als nicht bestanden.^[4]

Seit dem 12. März 2024 ist INP die offizielle Interaktionsmetrik und hat First Input Delay (FID) abgelöst.^[5] Wer noch FID-Werte in Reports hat, misst eine Metrik, die Google nicht mehr verwendet.

Die Datenbasis heißt Chrome UX Report (CrUX). Das ist das offizielle Dataset des Web-Vitals-Programms: echte Chrome-Nutzer, rollierende 28 Tage, ausgewertet pro URL und pro Origin. Google schreibt selbst, dass die Suche dieses Dataset verwendet, um den Rankingfaktor für die Nutzerfreundlichkeit zu ermitteln.^[7] Felddaten sind dabei nie eine einzelne Zahl, sondern eine Verteilung: Manche Nutzer erleben die Seite schnell, andere sehr langsam.^[6]

Wo das Web steht

Das HTTP Archive wertet CrUX-Daten für Millionen Websites aus. Im Web Almanac 2024 erreichen nur 45 Prozent der Startseiten auf Desktop und 38 Prozent auf Mobile gute Core Web Vitals. Unterseiten schneiden besser ab: 61 Prozent Desktop, 51 Prozent Mobile.^[14] Beim Time to First Byte, also der Antwortzeit des Servers, liegen 2025 nur 55 Prozent der Desktop-Sites und 44 Prozent der mobilen Sites im grünen Bereich.^[15]

Die Mehrheit der mobilen Startseiten besteht den Test also nicht. Das ist für dich zugleich Trost und Chance: Wer besteht, hebt sich von der Mehrheit ab.

Feld oder Labor: Warum dein PageSpeed-Score nicht dein Core-Web-Vitals-Status ist

Der häufigste Fehler in Diskussionen mit IT und Management: Jemand öffnet PageSpeed Insights, sieht einen Performance-Score von 85 und schließt daraus, dass alles in Ordnung ist. Dieser Score stammt aus Lighthouse, einer simulierten Einzelmessung unter festen Laborbedingungen. Er ist eine Note für einen Testlauf, keine Aussage über deine Nutzer.^[6]

Zwei Dinge fallen auf. Erstens: 30 Prozent des Scores hängen an Total Blocking Time, einer Metrik, die Google im Ranking gar nicht verwendet. Zweitens: INP, die echte Interaktionsmetrik, kommt im Score nicht vor, weil sie sich nur mit echten Nutzern messen lässt.^[8] Ein Score von 90 und ein CWV-Status "schlecht" schließen sich deshalb nicht aus. Beides gleichzeitig ist sogar häufig, etwa wenn die Seite im Labor auf einem schnellen Server gut aussieht, aber echte Nutzer über langsame Mobilfunknetze kommen.

Die Search Console zeigt dagegen den Status, der für Google zählt. Sie gruppiert ähnliche URLs und bewertet jede Gruppe nach ihrer schlechtesten Metrik: gute LCP plus schlechte CLS ergibt "schlecht". Hat eine Gruppe zu wenig Daten, fällt sie auf eine Origin-Gruppe für die ganze Domain zurück.^[9]

So misst du richtig in vier Schritten

1. Search Console, Bericht Core Web Vitals. Mobil und Desktop getrennt. Das ist der Status, den Google sieht, aufgeteilt nach URL-Gruppen.^[9]
2. PageSpeed Insights, oberer Block "Was echte Nutzer erleben". Das sind die CrUX-Felddaten für die getestete URL und für die Origin. Den Lighthouse-Score darunter nur als Diagnose lesen, nicht als KPI.^[6]
3. CrUX-API oder CrUX-Dashboard. Wenn du Werte ohne Login und für Wettbewerber brauchst. Origin-Werte gibt es für jede Domain mit genug Traffic, nicht nur für deine.^[7]
4. Eigenes Real User Monitoring. CrUX sagt dir, dass es ein Problem gibt. Ein eigenes RUM-Setup sagt dir, auf welchen Templates, in welchen Ländern und bei welchen Geräten.^[6]

Vier typische Fehlinterpretationen

• "Score 90, also alles gut." Der Score ist Labor. Der Status ist Feld. Nur der Status zählt.
• "Ich habe es gerade selbst getestet, lädt schnell." Ein Test im Büro-WLAN auf einem aktuellen Laptop ist die beste Bedingung, die deine Seite je bekommt. Das 75. Perzentil deiner Nutzer sieht anders aus.
• "Die Startseite ist optimiert." Umsatz und Leads entstehen auf Produkt-, Anwendungs- und Kampagnenseiten. Die haben eigene Templates und eigene Werte.
• "Desktop ist grün." Google bewertet mobil und desktop getrennt. Ein B2B-Publikum ist oft desktop-lastig, trotzdem ist der mobile Status ein eigener Befund mit eigener Konsequenz.

Wie stark Core Web Vitals das Ranking wirklich beeinflussen

Hier lohnt es sich, Google wörtlich zu zitieren, weil beide Hälften des Zitats in Diskussionen gern unterschlagen werden. In der offiziellen Dokumentation zur Page Experience steht:

"Core Web Vitals are used by our ranking systems. We recommend site owners achieve good Core Web Vitals for success with Search and to ensure a great user experience generally. Keep in mind that getting good results in reports like Search Console's Core Web Vitals report or third-party tools doesn't guarantee that your pages will rank at the top of Google Search results."

Google Search Central, Understanding page experience in Google Search results^[1]

Übersetzt: Core Web Vitals sind ein Rankingsignal, aber kein Freifahrtschein. Die Page-Experience-Signale sind seit Mai 2021 im Ranking aktiv und kombinieren Core Web Vitals mit Mobile-Freundlichkeit, HTTPS und den Regeln für störende Interstitials.^[3] 2023 hat Google klargestellt, dass auch das Helpful-Content-System Page-Experience-Signale "to a degree" berücksichtigt, sich aber primär an Inhaltssignalen orientiert.^[2]

Meine Einordnung aus der Praxis: Core Web Vitals wirken als Tiebreaker. Bei zwei Seiten mit ähnlicher Relevanz gewinnt die mit der besseren Nutzererfahrung. Das klingt nach wenig, ist aber genau in den Märkten viel, in denen der Content austauschbar ist. Wenn vier Hersteller dasselbe Produkt mit denselben Normen, Datenblättern und Anwendungsbeschreibungen erklären, ist "ähnliche Relevanz" nicht die Ausnahme, sondern der Normalfall. Dann entscheidet der Tiebreaker regelmäßig, und zwar systematisch gegen die langsamste Seite.

Genauso ehrlich: Inhalt, Suchintention und interne Verlinkung wiegen mehr. Eine Seite, die die Frage des Nutzers nicht beantwortet, wird durch 2,0 Sekunden LCP nicht gerettet. Wer Core Web Vitals als alleinigen Hebel verkauft, verliert die Glaubwürdigkeit beim ersten Gegencheck der IT.

Warum sie trotzdem geschäftskritisch sind: die Conversion-Evidenz

Die stärksten Belege für Core Web Vitals kommen nicht aus dem Ranking, sondern aus dem Verhalten der Nutzer nach dem Klick. Und hier ist die Datenlage ungewöhnlich dicht, weil Google seit 2020 Fallstudien mit Unternehmenszahlen veröffentlicht.

Den saubersten Beleg liefert Vodafone mit einem A/B-Test: Eine für Web Vitals optimierte Landingpage mit 31 Prozent besserer LCP erzielte 8 Prozent mehr Verkäufe, 15 Prozent mehr Leads pro Besuch und 11 Prozent mehr Warenkorb-Aufrufe pro Besuch.^[17] Ein A/B-Test schließt die übliche Kritik aus, dass schnelle Seiten einfach die besseren Unternehmen haben.

Für B2B und Lead-Generierung ist Renault die relevanteste Studie: 10 Millionen Besuche in 33 Ländern über vier Monate, gemessen auf Landingpages. Eine Sekunde bessere LCP korrelierte mit 14 Prozentpunkten weniger Absprung und 13 Prozent mehr Conversions, gemessen an ausgefüllten Lead-Formularen.^[18] Farfetch hat die Schwelle von 2,5 Sekunden statistisch bestätigt: Oberhalb davon sinkt die Conversion-Rate im Schnitt um 1,3 Prozent je 100 Millisekunden mehr LCP, und die Exit-Rate sinkt um 3,1 Prozent je 0,01 weniger CLS.^[19]

Dazu kommen breitere Studien. Google und Deloitte haben 2020 für "Milliseconds Make Millions" Mobile-Daten aus Retail, Travel, Luxus und Lead-Generierung in Europa und den USA ausgewertet: Eine Verbesserung um nur 0,1 Sekunden ging mit 8,4 Prozent mehr Retail-Conversions, 10,1 Prozent mehr Travel-Conversions und 8,3 Prozent weniger Absprung auf Lead-Gen-Informationsseiten einher.^[16] Die BBC verliert nach eigenen Angaben 10 Prozent ihrer Nutzer für jede zusätzliche Ladesekunde.^[26] Und die oft zitierte Google-Zahl, dass 53 Prozent der mobilen Nutzer abbrechen, wenn eine Seite länger als drei Sekunden lädt, findet sich bis heute in Googles eigenen Fallstudien.^[25]

Speziell für B2B hat Portent 2022 Ladezeit gegen Goal-Conversions ausgewertet: rund 40 Prozent bei einer Sekunde, 34 Prozent bei zwei, 29 Prozent bei drei Sekunden, und oberhalb von fünf Sekunden etwa die Hälfte der Conversion-Rate einer schnellen Seite.^[27] Die absoluten Werte hängen an Portents Datenbasis, die Kurve ist das Entscheidende: Der steilste Abfall liegt zwischen einer und drei Sekunden, also genau in dem Bereich, den die LCP-Schwelle abdeckt.

Zwei weitere Hebel: SEA-Effizienz und Crawling

Langsame Seiten kosten doppelt. Der erste versteckte Posten steht im Google-Ads-Konto. Der Quality Score setzt sich aus drei Komponenten zusammen: erwartete Klickrate, Anzeigenrelevanz und Landing Page Experience, jeweils bewertet im Vergleich zu anderen Werbetreibenden für dieselbe Suche.^[10] In den Empfehlungen zur Verbesserung der Landing Page Experience nennt Google ausdrücklich: "Improve loading speed. The speed at which your page loads can be the difference between someone bouncing or buying."^[11] Der Quality Score fließt in den Anzeigenrang und damit in den Klickpreis ein. Eine langsame Landingpage bezahlt also für dieselbe Position mehr als eine schnelle, und das bei jedem einzelnen Klick.

Der zweite Posten ist das Crawling. Google berechnet für jede Website ein Crawl Capacity Limit. In der Dokumentation steht: Bleiben die Antwortzeiten inklusive Time to First Byte stabil oder werden besser, steigt das Limit. Wird die Seite langsamer, sinkt es, und Google crawlt weniger.^[12] Bei großen Sites mit vielen Produktseiten und Länderversionen entscheidet das darüber, wie schnell Änderungen im Index ankommen.

Dazu kommt das Rendering. Google verarbeitet JavaScript-Seiten in drei Phasen, Crawling, Rendering und Indexing, und stellt Seiten für das Rendering in eine eigene Warteschlange.^[13] Eine Seite, deren Text erst im Browser entsteht, ist doppelt im Nachteil: Der Nutzer wartet auf die LCP, und Googlebot wartet auf die Render-Queue. Serverseitiges Rendering löst beides mit einer Maßnahme. Wie viel Text deine Seite bereits im Server-HTML ausliefert, zeigt dir in einer Minute mein kostenloser JavaScript-SEO- und SSR-Checker. Meine Einschätzung, ohne Quelle, aus der Praxis: Was Googlebot erst rendern muss, sehen viele KI-Crawler gar nicht, weil sie JavaScript nicht ausführen. Wer für KI-Suche sichtbar sein will, hat mit serverseitigem Rendering also ein weiteres Argument.

So baust du den Business Case in fünf Schritten

1. Baseline aus Felddaten. CrUX-Werte für die Origin und für die drei bis fünf umsatzrelevanten Templates, mobil und desktop getrennt, mit Datum. Keine Lighthouse-Scores.^[7][9]
2. Benchmark mit derselben Methode. Zwei bis drei Wettbewerber am selben Tag mit demselben Werkzeug messen. Ein Faktor 3 bei der mobilen LCP gegenüber dem Marktführer ist ein Argument, das jede Zentrale versteht.
3. Ursache trennen. Liegt der Abstand vor dem ersten Byte (Server, Rendering, Hosting) oder danach (Fonts, Scripts, Bilder, Cookie-Banner)? Die Antwort bestimmt, ob Quick Wins reichen oder die Auslieferung geändert werden muss. Den Rendering-Anteil prüfst du mit dem SSR-Checker, den TTFB mit den CrUX-Felddaten.^[12][13]
4. Ziele als Schwellen formulieren. "Raus aus Schlecht in sechs Monaten, dann Gut" ist messbar und lässt sich nicht wegdiskutieren. "Schneller werden" nicht.^[4]
5. Sensitivitätsrechnung, nicht Prognose. Nimm publizierte Multiplikatoren und rechne eine Spanne, klar als Rechenbeispiel markiert.^[18][19][27]

Rechenbeispiel (fiktiv): Eine B2B-Website hat 20.000 Besuche pro Monat auf Produkt- und Anwendungsseiten, eine mobile LCP von 5 Sekunden und eine Lead-Rate von 1 Prozent, also 200 Anfragen. Legt man den Renault-Multiplikator an, 13 Prozent mehr Conversions je Sekunde bessere LCP, entspräche eine Verbesserung um eine Sekunde 26 zusätzlichen Anfragen im Monat.^[18] Nach Farfetch, 1,3 Prozent je 100 Millisekunden, wären es bei derselben Sekunde rund 12 Prozent, also 24 Anfragen.^[19] Zwei unabhängige Datensätze, dieselbe Größenordnung. Das ist keine Prognose für deine Seite, aber eine belastbare Spanne für eine Entscheidung.

Rechne es für deine Website durch

Fallbeispiele aus den Studien, angewendet auf deine Zahlen

Was du nicht tun solltest: den Lighthouse-Score als KPI in den Monatsbericht schreiben, eine Umsatzprognose als Versprechen formulieren, oder die Startseite als Maßstab nehmen. Alle drei Fehler kosten dich beim ersten Gegencheck die Glaubwürdigkeit, und die brauchst du für die nächsten sechs Monate.

Fazit

Core Web Vitals sind kein Ranking-Hammer, aber ein verlässlicher Verstärker. Sie entscheiden Gleichstände im Ranking, sie verändern den Preis jedes bezahlten Klicks, sie bestimmen, wie viel Google crawlt, und sie legen fest, wie viele Besucher überhaupt bis zur ersten Interaktion kommen.

• Miss im Feld, nicht im Labor. Search Console und CrUX zeigen den Status, der für Google zählt. Der PageSpeed-Score ist ein Diagnosewerkzeug.
• Ordne ehrlich ein. Tiebreaker im Ranking, Hebel bei Conversion, Anzeigenkosten und Crawling. Wer mehr verspricht, verliert die IT als Partner.
• Bau den Case aus Felddaten, Benchmark und publizierten Multiplikatoren. Schwellen als Ziele, Sensitivitätsrechnung statt Prognose, monatlicher Bericht.

Quellen

1. Google Search Central – Understanding page experience in Google Search results, FAQ "What aspects of page experience are used in ranking?". Abgerufen 08.09.2026. developers.google.com
2. Google Search Central Blog – The role of page experience in creating helpful content, April 2023, Updates bis 12.03.2024. developers.google.com
3. Google Search Central Blog – Timing for bringing page experience to Google Search, 10.11.2020, Update Juni 2021. developers.google.com
4. web.dev – Web Vitals: Metriken und Schwellenwerte (LCP 2,5 s, INP 200 ms, CLS 0,1, 75. Perzentil). web.dev
5. web.dev Blog – Interaction to Next Paint is officially a Core Web Vital, 12.03.2024. web.dev
6. web.dev – Why lab and field data can be different (and what to do about it). web.dev
7. Chrome for Developers – Chrome UX Report (CrUX) Overview. developer.chrome.com
8. Chrome for Developers – Lighthouse performance scoring, Gewichtung Lighthouse 10. developer.chrome.com
9. Search Console Help – Core Web Vitals report. support.google.com
10. Google Ads Help – About Quality Score for Search campaigns. support.google.com
11. Google Ads Help – 5 ways to use Quality Score to improve your performance, Abschnitt "Consider updating your landing page". support.google.com
12. Google Search Central – Crawl Budget Management, Abschnitt "Crawl capacity limit". developers.google.com
13. Google Search Central – Understand JavaScript SEO basics, Abschnitt "How Google processes JavaScript". developers.google.com
14. HTTP Archive – Web Almanac 2024, Kapitel Performance, Abschnitt Core Web Vitals (Figure 9.4), 11.11.2024. almanac.httparchive.org
15. HTTP Archive – Web Almanac 2025, Kapitel Performance, TTFB (Figure 7.5), 15.01.2026. almanac.httparchive.org
16. Deloitte Digital mit Google – Milliseconds Make Millions, 2020. deloitte.com
17. web.dev Case Study – Vodafone: A 31% improvement in LCP increased sales by 8%, 17.03.2021. web.dev
18. web.dev Case Study – How Renault improved its bounce and conversion rates by measuring and optimizing Largest Contentful Paint. web.dev
19. web.dev Case Study – Luxury retailer Farfetch sees higher conversion rates for better Core Web Vitals. web.dev
20. web.dev Case Study – How Swappie increased mobile revenue by 42% by focusing on Core Web Vitals. web.dev
21. web.dev Case Study – How CLS optimizations increased Yahoo! JAPAN News's page views per session by 15%. web.dev
22. web.dev Case Study – How redBus improved their website's Interaction to Next Paint (INP) and increased sales by 7%. web.dev
23. web.dev Case Study – How The Economic Times passed Core Web Vitals thresholds and achieved an overall 43% better bounce rate. web.dev
24. web.dev Case Study – How focusing on web performance improved Tokopedia's click-through rate by 35%. web.dev
25. web.dev Case Study – Nikkei achieves a new level of quality and performance with their multi-page PWA (enthält die Google-Zahl "53 % der mobilen Nutzer brechen nach 3 s ab"). web.dev
26. web.dev – Why does speed matter? (BBC: 10 % Nutzerverlust je zusätzlicher Sekunde). web.dev
27. Portent – Site Speed is (Still) Impacting Your Conversion Rate, Update 20.04.2022. portent.com