Real User Monitoring Core Web Vitals aus dem eigenen Verkehr, am nächsten Tag und je Seitentyp, Markt und Gerät
Ein Real User Monitoring misst die Core Web Vitals im Browser der eigenen Besucher und meldet sie an eine eigene Auswertung. Der Chrome User Experience Report, nach dem Google bewertet, mittelt über 28 Tage und zeigt eine Verschlechterung erst nach Wochen vollständig. Ein Real User Monitoring zeigt sie am nächsten Tag, aufgeteilt nach Seitentyp, Markt und Gerät, und liefert die Ursache gleich mit. Auf Plattformen mit wöchentlichen Releases ist es damit die Grundlage jeder Kontrolle im Betrieb.
Real User Monitoring und Chrome UX Report: gleiche Kennzahlen, andere Stichprobe
Beide Quellen messen dieselben Kennzahlen mit denselben Schnittstellen des Browsers. Sie unterscheiden sich darin, wessen Besuche sie zählen, wie schnell sie berichten und wie fein sie sich aufteilen lassen.
| Merkmal | Chrome User Experience Report | Real User Monitoring |
|---|---|---|
| Rolle | Maßstab, nach dem Google bewertet | Frühwarnung und Ursachensuche |
| Browser | nur Chrome | alle Browser, die die Messschnittstellen unterstützen |
| Zeitraum | gleitendes Fenster über 28 Tage | frei wählbar, ab einem Tag |
| Aufteilung | Origin und einzelne Adressen mit genug Verkehr | Seitentyp, Markt, Gerät, Browser, Release, Einwilligung |
| Ursachen | keine | Element, Skript und Teilzeiten je Messung |
| Lücken | Seiten mit wenig Verkehr fehlen | Besucher ohne Einwilligung fehlen, je nach Einrichtung |
Welche Werkzeuge welche Quelle nutzen, steht unter Core Web Vitals messen. Die Methodik des Chrome User Experience Report beschreibt Google unter CrUX methodology.
Browserunterstützung 2026: LCP und INP auch in Safari und Firefox, CLS nur in Chromium
Bis 2025 sah ein Real User Monitoring die Core Web Vitals praktisch nur aus Chromium-Browsern. Das hat sich geändert:
- Safari: Seit Safari 26.2 vom 12. Dezember 2025 stehen die Schnittstellen für Largest Contentful Paint und die Event Timing API bereit, auf der Interaction to Next Paint beruht.
- Firefox: Largest Contentful Paint misst Firefox seit Anfang 2024. Mit Firefox 144 vom Oktober 2025 kam die Zuordnung von Ereignissen zu Interaktionen dazu, die Interaction to Next Paint voraussetzt.
- Cumulative Layout Shift: Die Layout Instability API gibt es bisher nur in Chromium-Browsern. Cumulative Layout Shift bleibt im Monitoring deshalb eine Chrome- und Edge-Kennzahl.
Für die Auswertung folgt daraus: Werte je Browser getrennt auswerten. Der Abgleich mit Google läuft über das Chrome-Segment, die anderen Browser zeigen zusätzlich, wie es den Besuchern auf iPhones tatsächlich geht. Auf Märkten mit hohem iOS-Anteil ist das häufig die größere Gruppe.
Dimensionen eines Real User Monitoring auf Enterprise-Plattformen: Seitentyp, Markt, Gerät und Release
Ein Wert für die ganze Domain hilft im Betrieb kaum. Auswertbar wird ein Monitoring erst mit Merkmalen, die jeder Messung mitgegeben werden:
- Seitentyp: Startseite, Kategorie, Produkt, Artikel, Suche, Formular. Die Zuordnung kommt aus dem Template der Plattform, nicht aus Adressmustern, die sich mit jeder Kampagne ändern.
- Markt und Sprache: Auf mehrsprachigen Plattformen unterscheiden sich Inhalte, Tags und Verbindungen je Land.
- Gerät und Browser: Mobil und Desktop getrennt, dazu die Browser-Engine wegen der unterschiedlichen Unterstützung.
- Release: Die Versionsnummer der Auslieferung als Merkmal. Erst damit lässt sich eine Verschlechterung einem Deployment zuordnen. Wie das in die Abnahme nach dem Release eingeht, beschreibt AEM DevOps.
- Einwilligung: Ob der Besucher Tags zugestimmt hat. Mit Zustimmung laden mehr Skripte, der Wert für Interaction to Next Paint ist dann meist ein anderer.
Dazu gehört die Ursache je Messung. Googles Bibliothek web-vitals liefert sie im Attribution-Build: für Largest Contentful Paint das Element und die Teilzeiten von der Antwort des Servers bis zum Zeichnen, für Interaction to Next Paint das angeklickte Element, Eingabeverzögerung, Verarbeitungszeit und Darstellungsverzögerung sowie die langen Animationsframes mit den beteiligten Skripten. Damit wird aus der Meldung, dass ein Wert schlechter geworden ist, die Angabe, welches Skript auf welchem Seitentyp ihn verursacht.
Zwei Verzerrungen gehören in jede Auswertung. Erstens fehlen Besucher, die einer Messung nicht zugestimmt haben, wenn das Monitoring an die Einwilligung gebunden ist; die Stichprobe ist dann nicht mehr repräsentativ für alle Besuche. Zweitens erheben viele Werkzeuge nur einen Teil der Seitenaufrufe. Adobe Experience Manager etwa erfasst über die Operational Telemetry standardmäßig einen Seitenaufruf je hundert, wie unter AEM Sites Optimizer beschrieben.
Werkzeuge für Real User Monitoring: eigenes Skript, spezialisierter Dienst oder APM-Plattform
Die Angebote lassen sich in drei Klassen teilen. Welche passt, entscheidet sich weniger am Funktionsumfang als an der Frage, wer die Daten im Betrieb liest.
| Klasse | Beispiele | Stärke | Grenze |
|---|---|---|---|
| Eigenes Skript | Bibliothek web-vitals, Versand an Analytics oder ein eigenes Data Warehouse | volle Kontrolle über Merkmale und Datenhaltung | Auswertung, Alarme und Pflege liegen im eigenen Team |
| Spezialisierter Dienst | SpeedCurve, Akamai mPulse, RUMvision, DebugBear | fertige Auswertungen für Core Web Vitals, Ursachen und Vergleich mit Labordaten | eigenes Skript auf der Seite, Abrechnung nach Datenvolumen prüfen |
| APM-Plattform mit RUM-Modul | Dynatrace, Datadog, New Relic | Verbindung von Browser- und Serverdaten in einer Ansicht | Core Web Vitals sind eine Ansicht unter vielen, Auswertung je Seitentyp oft Eigenbau |
Ist in der Organisation bereits eine APM-Plattform im Einsatz, liegt der kürzeste Weg meist dort: Das Skript ist schon auf der Seite, es fehlen Merkmale und Auswertungen. Fehlt eine solche Plattform, ist ein spezialisierter Dienst schneller nutzbar als ein Eigenbau. Für Adobe Experience Manager kommt die Operational Telemetry hinzu, die der Sites Optimizer nutzt.
Alarmgrenzen im Real User Monitoring: 75. Perzentil je Seitentyp gegen den Zielwert
Aus den Messungen wird erst eine Kontrolle, wenn feststeht, wann ein Wert eine Reaktion auslöst. Bewährt hat sich ein einfaches Schema:
- Je Seitentyp, Markt und Gerät wird das 75. Perzentil berechnet, wie Google es für die Bewertung tut.
- Jeder Seitentyp hat einen Zielwert mit Abstand zur Schwelle von Google, etwa 2,2 statt 2,5 Sekunden für Largest Contentful Paint. Der Abstand fängt die Streuung ab, bevor die Felddaten von Google kippen.
- Überschreitet ein Wert seinen Zielwert an zwei Tagen in Folge, entsteht ein Ticket mit dem Release, in dem die Verschlechterung begann, und den Ursachen aus der Attribution.
Wie solche Tickets aussehen, zeigen die Vorlagen unter Core Web Vitals Abnahmekriterien. Wie Monitoring, Zielwerte und Abnahme im Projekt zusammenkommen, steht unter Website Performance Optimierung. Die Auslieferung als zweite Ursache großer Werte beschreibt die Seite CDN für Enterprise-Plattformen.
Kostenfreie Performance-Erstanalyse buchen
30 Minuten per Video. Sie sehen die Google-Nutzerdaten Ihrer Plattform und welche Merkmale Ihrem Monitoring fehlen.
Häufige Fragen zu Real User Monitoring
Ersetzt ein Real User Monitoring den Chrome User Experience Report?
Nein. Google bewertet eine Website nach dem Chrome User Experience Report, der Maßstab bleibt also dort. Ein Real User Monitoring ergänzt ihn um Tagesaktualität, Seitentypen mit wenig Verkehr, weitere Browser und die Ursachen hinter einem Wert. Für den Abgleich mit Google zählt das Chrome-Segment des eigenen Monitorings.
Warum weichen die Werte des Monitorings von der Search Console ab?
Weil beide Quellen verschiedene Besuche zählen. Der Chrome User Experience Report erfasst nur Chrome und mittelt über 28 Tage, ein Real User Monitoring erfasst je nach Einrichtung weitere Browser, nur Besucher mit Einwilligung und oft nur eine Stichprobe. Vergleichbar werden die Zahlen, wenn das Monitoring auf Chrome, dasselbe Gerät und denselben Zeitraum gefiltert wird.
Misst ein Real User Monitoring auch Besucher mit Safari und Firefox?
Für Largest Contentful Paint und Interaction to Next Paint ja: Safari unterstützt die nötigen Schnittstellen seit Version 26.2 vom Dezember 2025, Firefox Largest Contentful Paint seit Anfang 2024 und die Zuordnung von Interaktionen seit Version 144 vom Oktober 2025. Cumulative Layout Shift messen bisher nur Chromium-Browser.
Wie viele Messungen braucht ein Seitentyp?
So viele, dass das 75. Perzentil von Tag zu Tag stabil bleibt. Eine feste Zahl gibt es nicht, sie hängt von der Streuung der Werte ab. Bei einer Stichprobe von einem Seitenaufruf je hundert, wie sie AEM für die Operational Telemetry standardmäßig erhebt, reichen Seitentypen mit wenig Verkehr oft nicht für eine Tagesauswertung, dann wird über eine Woche zusammengefasst.