Hauptbereich
Agency
technisches-seo

Core Web Vitals — Lab- vs. Field-Daten verstehen

Redaktion ·

Core Web Vitals — Lab- vs. Field-Daten verstehen

Du öffnest Lighthouse, drückst auf Start, und die Seite bekommt einen Performance-Score von 100. Alles grün. Zwei Tage später schaust du in die Search Console — und dort steht dieselbe URL bei den Core Web Vitals auf „verbesserungswürdig”. Kein Fehler, kein Widerspruch. Du schaust nur auf zwei völlig verschiedene Datenquellen, und genau das ist der häufigste Denkfehler beim Thema Web-Performance.

Es gibt zwei Welten, in denen Core Web Vitals gemessen werden: Lab (synthetisch, eine kontrollierte Messung) und Field (echte Nutzer, statistisch über 28 Tage gemittelt). Beide haben einen Zweck. Aber nur eine davon entscheidet über dein Ranking. Wer das verwechselt, optimiert wochenlang an der falschen Stellschraube.

Lab-Daten — die synthetische Einzelmessung

Lab-Daten entstehen in einer kontrollierten Umgebung: definiertes Gerät, definierte Netzwerkgeschwindigkeit, eine einzige Messung. Das klassische Werkzeug dafür ist Lighthouse — gebaut in die Chrome DevTools, in PageSpeed Insights und in unzählige CI-Pipelines.

Der große Vorteil: Lab-Daten sind reproduzierbar. Du änderst eine Zeile Code, lädst neu, misst — und siehst sofort, ob es besser oder schlechter wurde. Kein Warten auf echte Nutzer. Genau deshalb ist das Lab der richtige Ort zum Debuggen. Welches Bild blockiert das LCP? Welches Script verschiebt das Layout? Welcher Render-Blocker hängt im <head>? Das beantwortet dir nur eine kontrollierte Messung, in der du eine Variable nach der anderen drehen kannst.

Der große Nachteil: Das Lab ist eine Fiktion. Es kennt keinen Browser-Cache, keinen bfcache, keine A/B-Tests, keine echten Klickmuster. Es misst ein einziges Gerät auf einem einzigen Netzwerk an einem einzigen Ort. Deine echten Nutzer sitzen auf drei Jahre alten Android-Geräten im 4G-Funkloch, auf Gigabit-Glasfaser am MacBook und auf allem dazwischen. Diese Verteilung bildet das Lab schlicht nicht ab.

Field-Daten — was echte Nutzer wirklich erleben

Field-Daten (auch Real User Monitoring genannt) stammen von echten Besuchern. Googles öffentliche Quelle dafür ist der Chrome User Experience Report (CrUX) — anonymisierte Performance-Daten von Chrome-Nutzern, die dem Teilen zugestimmt haben. Diese Daten landen in der Search Console und in der Field-Sektion von PageSpeed Insights.

Field-Daten sind keine Einzelmessung, sondern eine Verteilung. Und zwei Eckwerte musst du dafür kennen:

  • 75. Perzentil (p75): Eine Seite besteht ein Core-Web-Vitals-Kriterium, wenn mindestens 75 % der Seitenaufrufe einen „guten” Wert erreichen (Quelle: corewebvitals.io, Stand 2026). Nicht der Durchschnitt zählt, nicht der Median — sondern die Erfahrung der langsameren drei Viertel. Das ist bewusst streng: Es ignoriert nicht die langsame Hälfte (wie der Median es täte), lässt aber einzelne Ausreißer auf miserablen Netzen nicht durchschlagen.
  • 28-Tage-Fenster: CrUX berechnet diesen p75-Wert über die letzten 28 Tage, rollierend. Das ist keine künstliche Verzögerung, sondern eine Glättung — sie filtert Tagesrauschen und einzelne Lastspitzen heraus.

Der Preis dieser Realitätsnähe: Field-Daten reagieren träge. Du deployst heute einen Fix, aber das 28-Tage-Fenster braucht Wochen, bis sich der neue Zustand voll durchsetzt. Und: Wer zu wenig Traffic hat, taucht in CrUX gar nicht erst auf — dann gibt es schlicht keine Field-Daten für deine URL.

Warum nur Field-Daten fürs Ranking zählen

Hier liegt der Kern. Google bewertet die Page Experience anhand echter Nutzererfahrung — also Field-Daten aus CrUX. Dein Lighthouse-Score, so grün er auch ist, fließt in kein Ranking ein. Er ist ein Diagnose-Werkzeug, kein Bewertungs-Werkzeug.

Das ergibt Sinn, sobald man es einmal sauber trennt: Google interessiert nicht, wie schnell deine Seite unter Idealbedingungen sein könnte. Google interessiert, wie schnell sie für die Menschen tatsächlich ist, die sie aufrufen. Ein perfekter Lab-Score auf einer Seite, die echte Nutzer auf schwachen Geräten quält, ist für die Bewertung wertlos.

INP gibt es nur im Feld

Ein Spezialfall macht den Unterschied besonders greifbar: INP (Interaction to Next Paint), seit März 2024 die offizielle Responsiveness-Metrik anstelle von FID. INP misst, wie lange die Seite braucht, um auf eine Nutzer-Interaktion sichtbar zu reagieren — Klick, Tap, Tastendruck.

Und genau das kann ein klassischer Lab-Lauf nicht messen. Lighthouse lädt die Seite und misst, was beim Laden passiert. Aber wann ein Nutzer auf welchen Button klickt, weiß keine synthetische Messung im Voraus. INP entsteht erst, wenn jemand wirklich interagiert. Deshalb erscheint INP in der Field-Sektion, aber nicht im klassischen Lab-Score — du brauchst echte Nutzer, um es überhaupt zu sehen.

LCP und CLS hingegen werden in beiden Welten gemessen — nur eben mit den oben beschriebenen Vorbehalten gegenüber der Lab-Variante. Die aktuellen „gut”-Schwellen (Stand 2026): LCP unter 2,5 s, INP unter 200 ms, CLS unter 0,1.

Welches Tool wofür — der praktische Spickzettel

Drei Werkzeuge, drei Aufgaben — und die Verwirrung kommt fast immer daher, dass Leute sie durcheinanderwerfen:

  • PageSpeed Insights — zeigt beides. Oben die Field-Daten („Was deine echten Nutzer erleben”), darunter den Lighthouse-Lab-Lauf mit Diagnose. Faustregel: Field-Sektion zuerst lesen, die entscheidet. Seit Dezember 2024 stehen dort auch die Datumsangaben des CrUX-Fensters.
  • Lighthouse / Chrome DevTools — reines Lab. Dein Debugging-Werkzeug. Hier findest du heraus, warum ein Wert schlecht ist, und testest Fixes in Sekunden.
  • CrUX Dashboard / CrUX-API + Search Console — reines Field. Hier bewertest du, ob deine Seite tatsächlich besteht. Die Search Console gruppiert URLs zudem nach Status und zeigt dir, welche URL-Gruppen unter die Schwelle fallen.

Der saubere Arbeitsablauf: Im Feld erkennen, dass ein Problem existiert. Im Lab herausfinden, woran es liegt. Im Feld nachprüfen, ob der Fix nach ein paar Wochen wirklich angekommen ist. Lab und Field sind keine Konkurrenten — sie sind zwei Phasen desselben Prozesses.

Wie diese Performance-Schicht ins größere Bild passt, steht im Überblick zum technischen SEO.

FAQ

Meine Seite hat 100 in Lighthouse — sind meine Core Web Vitals damit bestanden? Nein. Lighthouse liefert Lab-Daten, eine synthetische Einzelmessung unter Idealbedingungen. Bestanden oder nicht entscheidet sich an den Field-Daten aus CrUX, gemessen am 75. Perzentil echter Nutzer über 28 Tage. Ein perfekter Lab-Score kann mit schlechten Field-Werten koexistieren.

Warum sehe ich für meine URL keine Field-Daten? CrUX braucht ein Mindestmaß an echtem Traffic, um eine statistisch belastbare Verteilung zu bilden. Hat eine einzelne URL zu wenige Besuche, fehlt sie im Datensatz — dann fällt PageSpeed Insights auf den Origin-Durchschnitt zurück oder zeigt nur die Lab-Sektion.

Ich habe gestern einen Fix deployt — warum ändert sich der Field-Wert nicht? Field-Daten laufen über ein rollierendes 28-Tage-Fenster. Dein Fix wirkt sofort für neue Besucher, aber der gemeldete p75-Wert mischt noch wochenlang alte und neue Messungen. Voll durchsetzen tut sich die Verbesserung erst, wenn das alte Fenster komplett durchgelaufen ist.

Warum lässt sich INP nicht im Lab messen? INP misst die Reaktionszeit auf echte Interaktionen — Klicks, Taps, Tastendruck. Ein Lab-Lauf lädt die Seite, kann aber nicht wissen, wann und worauf ein Nutzer klicken wird. Deshalb existiert INP nur als Field-Metrik; im klassischen Lighthouse-Lauf taucht es nicht auf.

Was ist der p75-Wert und warum nicht der Durchschnitt? Der p75 ist der Wert, den 75 % der Seitenaufrufe erreichen oder unterbieten. Google nutzt ihn statt des Durchschnitts, weil ein Mittelwert langsame Nutzer wegglättet, während der Median die langsamere Hälfte ganz ignoriert. Das 75. Perzentil ist der Kompromiss: streng genug, um echte Probleme sichtbar zu machen, robust genug gegen einzelne Ausreißer.

Themenuebersicht

Technisches SEOCore Web VitalsPageSpeed & Performance