Core Web Vitals lassen sich auf zwei grundsätzlich verschiedene Arten messen: Labordaten aus einem einzelnen synthetischen Testlauf (zum Beispiel Lighthouse in PageSpeed Insights) und Felddaten aus echten Besuchen realer Nutzerinnen und Nutzer der letzten 28 Tage (Chrome User Experience Report, CrUX). Beide Werte können erheblich voneinander abweichen, weil sie grundlegend unterschiedliche Dinge messen – in einem eigenen Test wich die Labor-Ladezeit einer bekannten Baumarkt-Website um mehr als das Zehnfache von der echten Felddaten-Ladezeit ab. Für die Bewertung durch Google zählen dabei ausschließlich die Felddaten.
Labordaten: Ein einziger Testlauf unter künstlichen Bedingungen
Laut Googles eigener Dokumentation entsteht ein Labor-Wert, indem eine Seite einmalig unter exakt festgelegten Bedingungen geladen wird: ein einziges simuliertes Gerät, eine einzige gedrosselte Internetverbindung, ein einziger Serverstandort. Werkzeuge wie Lighthouse, das auch hinter dem unteren Bereich von PageSpeed Insights steckt, arbeiten bewusst nach diesem Prinzip, damit ein Testlauf von einem zum nächsten vergleichbar bleibt. Ein Beispiel aus der eigenen Praxis: Ein aktueller Lighthouse-Test unserer eigenen Website growenmedia.com ergab einen Labor-LCP von 2,8 Sekunden und einen Performance-Score von 95 von 100 Punkten – gemessen an einem simulierten Moto G Power unter gedrosselter „Slow 4G“-Verbindung, nicht an einem echten Besuchergerät. Was der 0-100-Score im Detail misst und warum er zwischen zwei Testläufen schwankt, erklärt unser Ratgeber zu PageSpeed Insights.
Felddaten: Echte Nutzerdaten aus 28 Tagen, als 75. Perzentil
Felddaten stammen dagegen nicht aus einem einzelnen Testlauf, sondern aus dem Chrome User Experience Report (CrUX) – einer Sammlung echter Messwerte aller Chrome-Nutzerinnen und -Nutzer, die eine Website in den letzten 28 Tagen tatsächlich besucht haben. Entscheidend dabei: Felddaten sind keine einzelne Zahl, sondern eine Verteilung vieler unterschiedlicher Ladeerlebnisse. In einem von Google selbst veröffentlichten Beispiel zeigte eine LCP-Verteilung 88 Prozent „gut“, 8 Prozent „verbesserungswürdig“ und 4 Prozent „schlecht“ – der daraus berichtete 75.-Perzentil-Wert lag bei 1,8 Sekunden, während derselbe Labortest für dieselbe Seite 3,0 Sekunden zeigte. Der 75.-Perzentil-Wert bedeutet: 75 Prozent aller echten Seitenaufrufe waren mindestens so schnell wie dieser Wert – weder der Durchschnitt noch der schlechteste Fall, sondern ein bewusst konservativer Blick auf die Mehrheit der echten Besuche. Was LCP, INP und CLS im Einzelnen bedeuten und welche Schwellenwerte als gut gelten, erklärt unser Ratgeber zu Core Web Vitals.
Eigener Test: Wie stark Labor und Feld in der Praxis auseinanderlaufen
Wie groß der Unterschied in der Praxis ausfallen kann, zeigt ein eigener Test der Baumarkt-Website hagebau.de, einer stark frequentierten Seite mit ausreichend Besucherverkehr für echte Felddaten:
| Metrik | Labordaten (Lighthouse) | Felddaten (CrUX, 28 Tage) |
|---|---|---|
| LCP | 15,6 Sekunden | 1,5 Sekunden (gut) |
| INP | im Labor nicht messbar | 240 Millisekunden (verbesserungswürdig) |
| CLS | 0,009 | 0,01 (gut) |
| Gesamtbewertung | Performance-Score 41/100 | Core-Web-Vitals-Bewertung „nicht bestanden“ |
Das Diagramm stellt die LCP-Werte nebeneinander:
Largest Contentful Paint in Sekunden. Hellgrün: Labor (Lighthouse), dunkelgrün: Feld (CrUX, 28 Tage). Gestrichelt: Grenze für einen guten LCP-Wert bei 2,5 Sekunden.
Die Labor-LCP von 15,6 Sekunden entsteht durch die bewusst strenge Simulation: ein mittelmäßiges Smartphone (Moto G Power) auf einer gedrosselten „Slow 4G“-Verbindung, ohne jeden Cache-Vorteil eines wiederkehrenden Besuchs. Die echte Felddaten-LCP von 1,5 Sekunden entsteht dagegen aus der Mischung aller echten Besuche – darunter viele wiederkehrende Kundinnen und Kunden mit bereits gefülltem Browser-Cache und deutlich schnelleren Verbindungen als im Labor simuliert. Auffällig: Obwohl die Feld-LCP klar im grünen Bereich liegt, gilt die Core-Web-Vitals-Bewertung insgesamt trotzdem als „nicht bestanden“ – weil INP mit 240 Millisekunden knapp im verbesserungswürdigen Bereich liegt und für eine bestandene Bewertung alle drei Werte gleichzeitig gut sein müssen. INP lässt sich dabei grundsätzlich nicht im Labor messen, weil ein automatisierter Testlauf keine echte Nutzerinteraktion wie einen Klick oder eine Texteingabe simulieren kann.
Ein zweites Beispiel zeigt die gegenteilige Situation: Für die eigene, deutlich kleinere Website growenmedia.com meldete derselbe Bericht bei den Felddaten den Hinweis, es lägen nicht genug echte Geschwindigkeitsdaten vor – zu wenig Besucherverkehr, um überhaupt eine CrUX-Verteilung zu bilden. In diesem Fall bleibt der Labor-Wert (hier: LCP 2,8 Sekunden, Score 95) die einzige verfügbare Orientierung, bis genug echter Verkehr gesammelt wurde.
Die häufigsten technischen Gründe für Abweichungen
Neben der grundsätzlich unterschiedlichen Messmethode gibt es laut Google mehrere konkrete technische Gründe, warum Labor- und Felddaten selbst für dieselbe Seite auseinanderlaufen:
- Caching und wiederkehrende Besuche: Ein Labortest lädt eine Seite immer „kalt“, während ein großer Teil echter Besuche von bereits im Browser-Cache liegenden Ressourcen profitiert – das verbessert die Felddaten-Werte gegenüber dem Labor spürbar.
- Unterschiedliches LCP-Element: Je nach Bildschirmgröße, personalisierten Inhalten, laufenden A/B-Tests oder installierten Schriftarten kann bei echten Besuchen ein anderes Element als „größtes sichtbares Element“ gelten als im immer identischen Labortest.
- Fehlender echter Interaktionsanteil: Scrollen, Antippen oder Texteingaben realer Besucher beeinflussen reale Reaktionszeiten messbar – ein automatisierter Labortest simuliert dagegen nur den reinen Seitenaufruf ohne solche Interaktionen.
- Verzerrung durch Ladeabbrüche: Felddaten erfassen laut Google nur Besuche, bei denen eine Seite auch erfolgreich geladen wurde – Nutzerinnen und Nutzer, die bei extrem langsamen Verbindungen vorher abbrechen, fließen gar nicht erst in die Felddaten-Verteilung ein, während ein Labortest diesen Fall weiterhin sichtbar macht.
Was für Google zählt: Feld vor Labor
Laut Googles eigener Empfehlung gilt als Grundregel: Liegen für eine Seite sowohl Feld- als auch Labordaten vor, sollten Felddaten für die Priorisierung der eigenen Arbeit den Ausschlag geben, weil sie die tatsächliche Erfahrung echter Nutzerinnen und Nutzer widerspiegeln. Auch die offizielle Search-Central-Dokumentation bezeichnet Core Web Vitals ausdrücklich als Kennzahlen für die „reale Nutzererfahrung“ und verweist zur Kontrolle auf den Core-Web-Vitals-Bericht in der Google Search Console – dieser basiert, genau wie PageSpeed Insights, auf echten CrUX-Felddaten, nicht auf einzelnen Labor-Testläufen. Zeigen die Felddaten dagegen durchgehend gute Werte, lohnt sich laut Google trotzdem ein Blick ins Labor: Es hilft dabei, die Seite auch für Nutzerinnen und Nutzer mit langsameren Geräten oder Verbindungen zugänglicher zu machen, die in den Felddaten möglicherweise unterrepräsentiert sind, weil sie beim Laden vorher abbrechen.
Praxis: Was tun, wenn Labor und Feld widersprechen?
Wählen Sie unten die Konstellation, die am ehesten der eigenen Situation entspricht:
Fazit: Beide Werte lesen, aber dem Feld vertrauen
Labor- und Felddaten messen unterschiedliche Dinge und können gerade deshalb stark auseinanderlaufen, wie der eigene Test von hagebau.de mit einer Abweichung von mehr als dem Zehnfachen bei der LCP zeigt. Für die Bewertung durch Google zählen ausschließlich die echten Felddaten aus dem Chrome User Experience Report – Labordaten bleiben trotzdem ein wertvolles Werkzeug, um konkrete Ursachen zu finden und zu beheben. Welche Ursachen hinter einem schlechten LCP-Wert am häufigsten stecken, zeigt unser Ratgeber zur LCP-Verbesserung.