LCP, INP und CLS
von echten Nutzern.

Labordaten (von Lighthouse oder synthetischen Audits) werden in einer kontrollierten Umgebung auf einem simulierten Gerät und einer simulierten Verbindung gemessen. Felddaten werden von echten Nutzern auf ihren tatsächlichen Geräten und Verbindungen erhoben. Googles Page-Experience-Ranking-Signal verwendet Felddaten, keine Labordaten. Deshalb ist das Tracking echter Nutzer-Vitals für SEO wichtig.

Googles Core-Web-Vitals-Bewertung bestimmt den Status einer URL („Gut", „Verbesserungsbedarf" oder „Schlecht") anhand des 75. Perzentils. Wenn Ihr p75-LCP unter 2,5 Sekunden liegt, erleben 75 % Ihrer Nutzer eine „gute" Ladezeit. Die Überwachung am p75 richtet Ihr Monitoring nach dem aus, was das Ranking tatsächlich beeinflusst.

Fügen Sie das Modul-Script-Tag in den Ihrer Seite ein und rufen Sie SiteQwalityRUM.init({ applicationId, clientToken }) auf. Das Bundle ist 5,7 kB gzip-komprimiert auf der Leitung und lädt als verzögertes ES-Modul, blockiert das Rendering also nie. Vitals werden mit der web-vitals-Bibliothek auf Basis der nativen PerformanceObserver-API des Browsers gemessen. Kein Framework erforderlich, und es gibt ein npm-Paket, falls Sie es lieber importieren.

Pro Seite. Das Snippet erfasst die aktuelle URL für jedes Ereignis, sodass Sie LCP, INP und CLS für die Startseite, Produktseiten, den Checkout und jede andere Route separat anzeigen können.

Ja. Gerätetyp (Desktop, Mobil, Tablet), Browser und Betriebssystem werden bei jedem Ereignis aus dem User-Agent des Requests abgeleitet, und Sie können außerdem nach URL filtern. Kombinieren Sie sie, um zum Beispiel zu verstehen, warum der mobile LCP höher ist als der Desktop-LCP. Eine Segmentierung nach Verbindungstyp ist nicht verfügbar: Das Skript liest die Network Information API nicht.

Heute weder noch. Es gibt keine Alert-Regel für Vitals, keinen p75-Schwellenwert zum Konfigurieren und nichts, das auslöst, wenn Felddaten ihn überschreiten. Es gibt auch keine Deployment-Markierungen: Nichts hält ein Release gegen die Zeitleiste fest, und es gibt keinen Vorher-Nachher-Vergleich für ein bestimmtes Deployment. Eine frühere Fassung dieser Seite warb für beides, und das war falsch. Alerts decken heute Uptime-, Cron-, TLS-, DNS- und Browser-Prüfungen ab, nicht Core Web Vitals.

Aggregierte Messwerte werden 458 Tage lang aufbewahrt, also gut 15 Monate, in jedem Tarif einschließlich des kostenlosen. Mehr zu zahlen verlängert das Fenster nicht, und ein Downgrade verkürzt es nicht, es ist also standardmäßig für alle dasselbe. Sie können weniger verlangen: Eine Aufbewahrungsobergrenze wird pro RUM-Anwendung über die API gesetzt (settings.retention.observe_days bei PUT /rum/{app_id}), die Untergrenze ist ein Tag, und das Absenken gilt auch für Messwerte, die für diese Anwendung bereits gespeichert sind, nicht nur für neue. Im Dashboard gibt es dafür noch keine Bedienung, heute ist es ein API-Aufruf. Die Zeitraumauswahl der Übersicht bietet bis zu 30 Tage, weiter zurückzulesen bedeutet also, die API direkt abzufragen.