Felddaten beschreiben bereits erfolgte Besuche, Labordaten einen kontrollierten Test. PageSpeed Insights zeigt beides zusammen, obwohl Geräte, Verhalten und Zeiträume unterschiedlich sind. Nutzen Sie Felddaten zur Bewertung echter Erfahrungen und Laboraufzeichnungen zur Ursachenanalyse und Änderungskontrolle.
Ein grüner Lighthouse-Wert belegt keine bestandenen Core Web Vitals bei echten Besuchern. Ein langsamer synthetischer Lauf widerlegt ebenso wenig gute Felddaten. Bestimmen Sie zunächst die Bedeutung jeder Zahl. Die Einführung in Core Web Vitals erklärt die Metriken; hier geht es um ihre Messung.
Beginnen Sie mit Population und Fragestellung
CrUX, der Chrome User Experience Report, aggregiert Erfahrungen teilnahmeberechtigter Chrome-Nutzer. Er erfasst nicht alle Websitebesucher. Browseroptionen, unterstützte Umgebungen und genügend geeignete Beobachtungen bestimmen die Aufnahme. Google nennt keine universelle Besucherzahl, die sie garantiert.
Auch die Seite muss die Anforderungen erfüllen, darunter öffentliche Auffindbarkeit und Indexierbarkeit. Besuche allein bedeuten nicht, dass ein geschützter Kontobereich CrUX-Daten haben sollte. Eine manuelle Anmeldung zur Aufnahme gibt es nicht. Fehlende Daten bedeuten weder schnell noch langsam.
Ein Lighthouse-Navigationslauf lädt eine URL in einer konfigurierten Browserumgebung. Er liefert Diagnosen ohne echte Besucher und vor Veröffentlichungen. Er repräsentiert jedoch ein Testszenario, nicht die Geräteverteilung Ihrer Zielgruppe.
Die folgende Gegenüberstellung trennt die Einsatzbereiche.
| Aspekt | CrUX-Felddaten in PSI | Lighthouse-Navigationsdaten |
|---|---|---|
| Population | Geeignete echte Chrome-Besuche | Kontrollierter Seitenaufruf |
| Zeitraum | Zurückliegende 28 Tage | Aktueller Test |
| Geräte | Beobachtete Geräte nach Formfaktor | Konfiguriertes Geräte- und Drosselungsprofil |
| Verhalten | Tatsächliche Seitennutzung | Aufgezeichnete Navigation und Beobachtungszeit |
| Zweck | Anhaltende Besucherprobleme erkennen | Ursachen und Änderungen untersuchen |
| Grenze | Aggregation und Teilnahmebedingungen | Ein Szenario deckt nicht jede Nutzung ab |
Lesen Sie das Perzentil nicht als Durchschnitt
Der Feldwert ist gewöhnlich das 75. Perzentil, kurz p75. Bei 2,4 Sekunden LCP am p75 erreichten mindestens 75% der erfassten Erfahrungen diesen Zeitpunkt nach höchstens 2,4 Sekunden. Das ist weder die Wartezeit jedes Besuchers noch der arithmetische Mittelwert. Die Zahl dient nur als Rechenbeispiel.
Gut sind höchstens 2,5 Sekunden LCP, 200 Millisekunden INP und 0,1 CLS. Prüfen Sie Mobilgeräte und Desktop getrennt. Gute Desktopwerte kompensieren keine mobilen Probleme; die Grenzwerte sind identisch.
Betrachten Sie auch die Verteilung. Ein knapp guter p75 kann mit vielen langsamen Erfahrungen zusammenfallen. Prüfen Sie nach Möglichkeit Regionen, Vorlagen und Interaktionen, bevor Sie die grüne Einstufung als Abschluss betrachten.
Googles Vergleich von Labor- und Felddaten erklärt den Hintergrund. Geben Sie Population und Perzentil immer mit an.
Prüfen Sie, ob der Feldwert zur URL gehört
PSI versucht URL-Daten anzuzeigen und kann bei fehlenden Beobachtungen auf Origin-Daten zurückgreifen. Eine Origin besteht aus Schema, Hostname und Port, nicht aus dem gesamten Pfad oder sämtlichen Subdomains einer Organisation.
Eine Origin kann schnelle Artikel und langsame Produktseiten zusammenfassen. Beschreibt das Feldpanel diesen Gesamtbestand und das Labor nur einen Artikel, ist die Abweichung kein Beweis für eine fehlerhafte Messung.
Notieren Sie angeforderte und endgültige URL, Gerät, Datenumfang und Zeitraum. „Mobiler LCP schlecht“ verrät nicht, welche Population betroffen ist. Benennen Sie einen Origin-Wert in Dashboards niemals in URL-Wert um.
Fehlt die konkrete URL, zeigen Sie diese Grenze und Origin-Kontext getrennt. Die PageSpeed-Insights-Anleitung erläutert die Kennzeichnung im Bericht.
Verstehen Sie die Grenzen der Drosselung
Lighthouse kann Leistung unter CPU- und Netzwerkbeschränkungen simulieren. Andere Konfigurationen verwenden andere Methoden. Lesen Sie die Einstellungen: Gleiche Lighthouse-Marke bedeutet keine identischen Bedingungen.
Entwicklungsrechner, Erweiterungen, Hintergrundlast und Teststandort können Ergebnisse verändern. Wiederholungen schwanken auch ohne Codeänderung. Speichern Sie Browser- und Lighthouse-Version, Strategie, Umgebung sowie Einzelmetriken und vergleichen Sie passende Läufe.
Auch der Cachezustand zählt. Ein neuer Aufruf kann einen leeren Browsercache treffen, während wiederkehrende Besucher Ressourcen wiederverwenden. Das Labor kann umgekehrt einen warmen CDN-Cache erreichen, den andere Besucher nicht erhalten. Benennen Sie die kalte Cacheebene; lokales Löschen leert keinen Edge-Cache.
Simulation hilft, teure Arbeit zu untersuchen, verspricht aber keinen exakten Wert für ein bestimmtes Telefon. Wählen Sie zusätzliche Szenarien aus Besucherevidenz statt den Standardtest bis zum grünen Ergebnis zu wiederholen.
Folgen Sie der Metrik, die den Unterschied erklärt
Vergleichen Sie bei LCP das tatsächliche größte Element und seinen Lieferweg. Andere Viewportbreiten können andere Bilder oder Textblöcke hervorbringen. Entfernung, Serverantwort, Ressourcenentdeckung und Rendering verändern den Engpass. Das Desktopbild ist nicht automatisch repräsentativ.
Verlängern Sie bei CLS die Nutzung: zu Einbettungen scrollen, Anzeigen abwarten, Einwilligung ändern und zurücknavigieren. Ein Ladetest kann spätere Bewegung übersehen. Die verschobene Überschrift ist möglicherweise nur vom wachsenden Container darüber betroffen.
Prüfen Sie für INP echte Aktionen. Ein normaler Lighthouse-Navigationslauf liefert nicht die CrUX-INP-Verteilung. Total Blocking Time kann Belastung des Hauptthreads beim Laden zeigen, ersetzt INP aber nicht. Kontrollierte interaktive Werkzeuge können Interaktionslatenz messen; Grenzen sind Szenario und Abdeckung.
Reproduzieren Sie Menüs, Sucheingaben oder Produktoptionen in DevTools. Nach einem unauffälligen Laden kann der erste Klick teuer sein. Dokumentieren Sie Aktion, Ziel und Trace für die Wiederholung durch andere.
Berücksichtigen Sie das gleitende Fenster nach Releases
CrUX in PSI beschreibt die vorherigen 28 Tage und wird täglich aktualisiert. Direkt nach einer Korrektur stammt ein großer Teil noch von der alten Implementierung. Labor und Feld beantworten dann unterschiedliche zeitliche Fragen.
Markieren Sie das Release im Monitoring. Nutzen Sie neue eigene Messungen und vergleichbare Tests, während weitere Besuche in das öffentliche Fenster gelangen. Versprechen Sie keine Änderung nach einer festen Stundenzahl und erklären Sie ein weiterhin schlechtes Label nicht vorschnell zum Misserfolg.
Auch die Zielgruppe verändert sich. Eine Kampagne mit langsameren Netzwerken kann die Verteilung trotz verbessertem Code verschlechtern. Vergleichen Sie Segmente, soweit möglich, und benennen Sie die verbleibende Unsicherheit des Aggregats.
Ergänzen Sie RUM für fehlenden Ursachenbezug
Real User Monitoring kann eigene Messwerte mit Vorlage und Releaseversion verbinden. Planen Sie Erfassung, Einwilligung, Aufbewahrung und Zugriff vorab. Übermitteln Sie keine Kontodaten, Formulareingaben oder vollständigen URLs mit sensiblen Parametern.
Die offizielle Bibliothek web-vitals berücksichtigt wichtige Lebenszyklusdetails. In einem Projekt mit installierter und gebündelter Abhängigkeit protokolliert dieses Modul unterstützte Werte lokal, ohne Serverübertragung.
import {onCLS, onINP, onLCP} from 'web-vitals';
function reportMetric(metric) {
console.log({
name: metric.name,
value: metric.value,
id: metric.id,
rating: metric.rating,
navigationType: metric.navigationType
});
}
onCLS(reportMetric);
onINP(reportMetric);
onLCP(reportMetric);Ersetzen Sie den Logger erst nach Backendplanung durch eine freigegebene Erfassung. Werte können mehrfach aktualisiert werden; vermeiden Sie doppelte Zählung. Ein Callback ist nicht automatisch ein neuer Besuch. Fehlender INP kann fehlende geeignete Interaktion bedeuten und darf nicht als null gespeichert werden.
RUM muss CrUX nicht exakt entsprechen. Browserabdeckung, Stichprobe, Einwilligung, Navigationsdefinition und iframe-Sichtbarkeit unterscheiden sich. Nutzen Sie bei Bedarf den Attribution-Build, prüfen Sie aber die zusätzlichen Daten vor der Übermittlung.
Ordnen Sie Ergebnisse den richtigen Entscheidungen zu
Belegen Sie eine technische Verbesserung zunächst im reproduzierbaren Ablauf unter gleichen Bedingungen. Bewerten Sie Besuchererfahrung anhand von Felddaten mit Umfang und Zeitraum. Für Search sind Core Web Vitals von Lighthouse zu trennen; dessen Punktzahl ist keine Rankingnote.
Wählen Sie eine problematische Metrik, eine Vorlage und einen Ablauf. Speichern Sie die Ausgangslage, ändern Sie die vermutete Ursache und prüfen Sie Funktion und Zeit. Nutzen Sie den aktivierten PageSpeed-Analysator und die Core-Web-Vitals-Anleitungen. Eine erklärte Abweichung mit überprüfter Reparatur ist das sinnvolle Ergebnis.
