LCP, INP und CLS am p75
Die drei Ranking-Signal-Metriken, verfolgt am 75. Perzentil, dem Schwellenwert, den Google verwendet, um zu bewerten, ob eine URL „gut" ist.
Felddaten, keine Labor-Simulationen. Verfolgen Sie die drei Core Web Vitals, die Google als Ranking-Signal nutzt (pro Seite, am p75), erhoben von Ihren tatsächlichen Besuchern über das leichtgewichtige Site Qwality RUM-Skript.
Lighthouse misst eine Laborbedingung. Core Web Vitals von echten Nutzern messen das, was Googles Crawler sieht, wenn er Ihre Seiten für das Ranking bewertet. Site Qwality erhebt Felddaten von Ihren Besuchern, standardmäßig aus 100 % der Sessions, und zeigt p50, p75 und p95 im Zeitverlauf, dazu den p75 für jede Seite, damit Sie auf die Zahlen reagieren können, die wirklich zählen.
Die drei Ranking-Signal-Metriken, verfolgt am 75. Perzentil, dem Schwellenwert, den Google verwendet, um zu bewerten, ob eine URL „gut" ist.
Erhoben über das Site Qwality RUM-Snippet bei echten Seitenladevorgängen. Kein Headless-Browser in einem Labornetzwerk.
Sehen Sie, welche spezifischen Seiten Regressionen aufweisen, statt nur einen seitenweiten Durchschnitt, mit p75 für LCP, INP, CLS und Ladezeit jeder Seite.
Messwerte werden standardmäßig 458 Tage lang gespeichert, also gut 15 Monate, in jedem Tarif, und Sie können pro Anwendung eine kürzere Obergrenze setzen. Die Zeitraumauswahl der Übersicht bietet heute bis zu 30 Tage; ein längeres Fenster darzustellen bedeutet daher, die API direkt abzufragen.
Dieselbe Grafik trägt den Median, den Ranking-Schwellenwert und den Ausläufer, sodass Sie eine seitenweite Regression von einer kleinen Gruppe sehr langsamer Sessions unterscheiden können.
Geplante Lighthouse- und Page-Speed-Audits laufen neben den Real-User-Vitals, Sie haben für eine Seite also sowohl den Labor-Score als auch die Felddaten. Das sind heute zwei Ansichten, nicht eine kombinierte Grafik.
Ein Lighthouse-Audit läuft unter kontrollierten Bedingungen: schnelle Verbindung, leistungsstarker Rechner, leerer Cache. Ihre echten Besucher kommen mit einem 4G-Telefon von der anderen Seite der Welt mit 20 offenen Browser-Tabs. Core Web Vitals-Felddaten erfassen deren Erfahrung, und das ist die Erfahrung, die Google rankt.
Ein seitenweiter p75 sagt Ihnen, dass sich etwas bewegt hat. Die Top-Seiten zeigen p75 für LCP, INP, CLS und Ladezeit jeder Seite im selben Fenster, sodass Sie sehen, welche Routen es tragen. Von dort sagen Ihnen Error-Tracking und Session Replay, worauf diese Nutzer gestoßen sind.
Google-Ranking-Signal-Vitals, am p75 verfolgt
gzip-komprimiertes Kern-Skript von SDK 2.2.1, lädt asynchron und blockiert nie das Rendering
genau das Perzentil, das Google in seinem Page-Experience-Signal verwendet
kostenloser Tarif, ohne Kreditkarte starten
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 Snippet in den <head> Ihrer Seite ein. Es puffert frühe Aufrufe und Fehler, lädt das SDK asynchron vom CDN und ruft SiteQwalityRUM.init({ applicationId, clientToken }) auf. Das Kern-Skript von SDK 2.2.1 ist 25,8 KB gzip-komprimiert und blockiert das Rendering nie. Vitals werden mit der nativen PerformanceObserver-API des Browsers gemessen, mit denselben Metrik-Definitionen wie Googles web-vitals-Bibliothek. 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.
Nicht im Dashboard. Die Overview-API akzeptiert die Filter device_type, browser, os und url. 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.
Uptime, Cron, Synthetic, Logs, RUM, Incidents und Statusseiten. Kostenlose Stufe bei jedem Produkt.