Leitfäden

Sie starten Lighthouse, erhalten 100 und veröffentlichen. Einen Monat später meldet die Search Console, dass genau diese URL ihre Core-Web-Vitals-Bewertung nicht besteht. Dazwischen ist nichts kaputtgegangen, und keines der beiden Werkzeuge lügt. Sie beantworten unterschiedliche Fragen.

Googles eigene Dokumentation zieht die Grenze eindeutig. Labordaten sind **„Daten, die in einer kontrollierten Umgebung mit vordefinierten Geräte- und Netzwerkeinstellungen erhoben werden“**. Felddaten sind **„Daten, die von den echten Nutzern Ihrer Website erhoben werden“**, auch Real User Monitoring genannt; für die Core Web Vitals stammen sie aus dem Chrome User Experience Report.

Felddaten sind eine Verteilung, keine Zahl

Die wichtigste Folge ist struktureller Natur, und sie wird am häufigsten übersehen: Felddaten **sind keine einzelne Zahl**. Sie sind eine Verteilung. Werkzeuge, die einen Core-Web-Vitals-Feldwert melden, nehmen das **75. Perzentil** der echten Seitenaufrufe über ein gleitendes Fenster von **28 Tagen**. Ihr Labordurchlauf ist ein Aufruf, auf einem Gerät, über eine Verbindung. Ihr Feldwert ist das, was drei Viertel Ihrer Besucher erlebt haben oder besser, über einen Monat hinweg.

Das allein erklärt den größten Teil der Abweichung. Die Ursachen unterscheiden sich jedoch je nach Metrik, und zu wissen, welche Sie gerade ansehen, sagt Ihnen, wo Sie suchen müssen.

Warum sie auseinandergehen, Metrik für Metrik

Beim [Largest Contentful Paint](/de/articles/was-ist-largest-contentful-paint-lcp) ist womöglich das LCP-Element selbst nicht dasselbe. Viewport-Größe, personalisierte Inhalte, A/B-Tests, installierte Schriften und URL-Fragmente können alle verändern, welches Element als größtes zählt. Auch der Cache-Zustand unterscheidet sich: Ein Labortest startet kalt, während wiederkehrende Besucher Ressourcen im Cache haben können. Und die Wiederherstellung aus dem Vor-/Zurück-Cache ist für echte Nutzer nahezu augenblicklich, was kein Labordurchlauf nachbildet.

• Labor: kontrollierte Umgebung, vordefiniertes Gerät und Netzwerk, ein Durchlauf, reproduzierbar
• Feld: echte Nutzer, echte Geräte, echte Verbindungen, gemeldet im 75. Perzentil über 28 gleitende Tage
• Nur im Labor: Speed Index, Total Blocking Time (Diagnosewerte, keine Core Web Vitals)
• Cache-Zustand, Vor-/Zurück-Cache, Viewport und Personalisierung unterscheiden sich zwischen beiden
• Google: liegen beide vor, nach Felddaten priorisieren

Beim [Interaction to Next Paint](/de/articles/was-ist-inp-interaction-to-next-paint) liegt der Grund tiefer: Ein Labortest **kann nicht wissen, wann ein Nutzer interagieren wird**, und womit. Deshalb existiert die [Total Blocking Time](/de/articles/was-ist-total-blocking-time) als laborseitiger Ersatzwert, und deshalb ist dieser Ersatzwert unvollkommen. Die TBT erfasst nicht die Tippverzögerung von 300 ms, die Seiten ohne mobil optimierten Viewport weiterhin trifft.

Beim [Cumulative Layout Shift](/de/articles/was-ist-cls) beobachtet das Labor in der Regel nur Verschiebungen oberhalb des Falzes und während des Ladens. Echte Nutzer scrollen. Verzögert geladene Bilder und iframes ohne reservierte Abmessungen verschieben die Seite lange nachdem der Labortest aufgehört hat hinzusehen, und Werbung wie personalisierte Blöcke landen bei jedem anders.

Welche Google tatsächlich meldet

Worauf sollten Sie also reagieren? Google formuliert es unmissverständlich: **Wenn beides vorliegt, sollten die Felddaten Ihre Prioritäten bestimmen.** Sie sind es, welche die Core-Web-Vitals-Bewertung meldet, und die Core Web Vitals gehören zum Page-Experience-Signal. Ein grüner Laborwert ist eine Hypothese. Felddaten sind das Urteil.

Das Labor ist nicht nutzlos, es ist diagnostisch

Das macht das Labor nicht nutzlos, und das zu glauben ist der spiegelbildliche Fehler. Felddaten sagen Ihnen, **dass** ein Problem besteht und für wen; sie sagen Ihnen nicht, welches Skript den Haupt-Thread blockiert hat. Laborwerkzeuge sind reproduzierbar und zuordenbar, und genau das braucht man, sobald das Feld auf eine Seite gezeigt hat. Manche Metriken, darunter der [Speed Index](/de/articles/was-ist-der-speed-index) und die Total Blocking Time, existieren nur im Labor und sind von Haus aus Diagnosewerte.

Der blinde Fleck: wenn CrUX nichts über Sie hat

Eine Grenze sollte man kennen, bevor man sich ganz auf das Feld verlässt. CrUX erhebt nur aus Chrome, und weder aus Chrome unter iOS noch aus Android-WebViews. Gezählt werden nur Nutzer, die das Melden von Nutzungsstatistiken aktiviert haben, ihren Browserverlauf synchronisieren und keine Sync-Passphrase gesetzt haben. Die Seite muss öffentlich auffindbar sein und eine Mindestzahl an Besuchern überschreiten, die Google bewusst nicht veröffentlicht. Eine Seite unterhalb dieser Schwelle hat schlicht keine Felddaten, und eine junge oder wenig besuchte Website hat womöglich nirgends welche. Genau diese Lücke schließt Ihr eigenes Real User Monitoring: Ihre Seiten, jeder Browser, ab dem ersten Besuch statt ab dem tausendsten.

Die Reihenfolge, die funktioniert

Die praktische Reihenfolge lautet daher: das Feld lesen, um zu entscheiden, **wo** gearbeitet wird, das Labor nutzen, um herauszufinden, **was** zu ändern ist, und achtundzwanzig Tage später ins Feld zurückkehren, um zu bestätigen, dass sich tatsächlich etwas bewegt hat. Alles andere optimiert eine Zahl, die niemand erlebt. Für die konkreten Hebel, sobald Sie wissen, wo zu graben ist, beginnen Sie mit der [Verbesserung Ihrer Core Web Vitals](/de/articles/core-web-vitals-verbessern).