Was Real User Monitoring beweist und Labortests nicht leisten können

Was ist Real User Monitoring (RUM)?

Web-Performance-Teams nutzen Real User Monitoring, um Performance- und Fehlerdaten passiv aus echten Besuchen in echten Browsern zu sammeln, sodass hinter jeder Messung ein reales Gerät, ein reales Netz und ein realer Ort steht. Der Browser selbst meldet die Zahlen über Standard-APIs wie PerformanceObserver, und das Skript sendet sie zurück, nachdem die Seite ihre Arbeit bereits erledigt hat. An der Messung ist nichts simuliert: Wenn eine Besucherin auf einem fünf Jahre alten Android-Telefon sechs Sekunden im Hotel-WLAN gewartet hat, gehen diese sechs Sekunden genau so in den Datensatz ein, wie sie erlebt wurden.

Das Wort "passiv" trägt den größten Teil der Bedeutung. Real User Monitoring steuert den Browser nicht, wählt die URL nicht und entscheidet nicht, wann gemessen wird. Über alle drei entscheidet der Traffic. Damit ist RUM eine Vollerhebung dessen, was passiert ist, kein Test dessen, was passieren könnte.

Was ist der Unterschied zwischen Felddaten und Labordaten?

Felddaten stammen aus Besuchen, die echte Menschen gemacht haben, und Labordaten stammen aus einem skriptgesteuerten Browser, den Sie konfiguriert und eingeplant haben. Real User Monitoring liefert Felddaten. Synthetic Monitoring liefert Labordaten: Ein Headless-Browser lädt alle paar Minuten eine gewählte URL mit festem Geräteprofil, fester CPU-Drosselung und fester Netzform, egal ob gerade jemand auf der Website ist.

Die beiden beantworten unterschiedliche Fragen, und der typische Fehler in den meisten Teams ist, der einen die Frage der anderen zu stellen.

Frage	Real User Monitoring	Synthetic Monitoring
Wer wird gemessen	Jeder Besucher, der die Seite lädt	Ein skriptgesteuerter Agent
Gerät und Netz	Was der Besucher gerade hat	Per Konfiguration festgelegt
Wann es läuft	Nur wenn Traffic eintrifft	Nach einem Zeitplan, den Sie festlegen
Ergebnisform	Eine Verteilung über Besuche	Eine wiederholbare Einzelzahl
Datenklasse	Feld	Labor

Wenn Sie den vollständigen Direktvergleich wollen, geht der Vergleich zwischen RUM und Synthetic Monitoring tiefer als diese Tabelle.

Was kann Real User Monitoring beweisen, was Synthetic Monitoring nicht kann?

Real User Monitoring beweist, was Ihre Besucher erlebt haben, segmentiert nach den Bedingungen, unter denen sie ankamen. Weil jede Stichprobe ein Gerät, ein Land, einen Verbindungstyp, eine Seite und ein Release mitführt, beantwortet RUM Fragen, für die ein Laboragent nicht zuständig ist: ob Safari auf iOS für Ihren Checkout langsamer ist als Chrome, oder ob das Deployment vom Dienstag die Preisseite für Nutzer in Brasilien verschlechtert hat.

Synthetic Monitoring beweist die entgegengesetzte Klasse von Dingen. Ein skriptgesteuerter Agent fängt ein kaputtes Deployment um 3 Uhr nachts ab, wenn niemand auf der Website ist, hält jede Variable fest, damit zwei Builds ehrlich verglichen werden können, und läuft gegen eine Staging-URL, bevor ein einziger Nutzer sie sieht. Real User Monitoring kann nichts davon, weil es keine Daten hat, bis jemand die Seite besucht.

Nutzen Sie beides und leiten Sie es unterschiedlich weiter. Synthetic-Fehler alarmieren einen Bereitschaftsingenieur. RUM-Regressionen eröffnen ein Ticket mit dem betroffenen Segment im Anhang.

An welchen Core-Web-Vitals-Schwellenwerten wird RUM gemessen?

Google bewertet die drei Core Web Vitals auf drei Stufen, und die vom Chrome-Team auf web.dev veröffentlichten Grenzwerte sind Stand September 2026 unverändert. Eine Seite besteht nur, wenn alle drei Metriken im 75. Perzentil gut sind, getrennt für Mobil und Desktop gemessen.

Metrik	Was sie misst	Gut	Verbesserung nötig	Schlecht
LCP	Zeit, bis das größte Inhaltselement gerendert ist	2,5s oder weniger	2,5s bis 4,0s	Über 4,0s
INP	Verzögerung von einer Interaktion bis zum nächsten Paint	200ms oder weniger	200ms bis 500ms	Über 500ms
CLS	Unerwartete Layoutbewegung während der Seitenlebensdauer	0,1 oder weniger	0,1 bis 0,25	Über 0,25

Jede Metrik hat eigene Fehlerursachen, weshalb Largest Contentful Paint, Interaction to Next Paint und Cumulative Layout Shift getrennt debuggt werden und nicht als eine Punktzahl. Der Überblick über die Core Web Vitals erklärt, wie die drei zusammenpassen.

Warum wird Real User Monitoring im p75 gelesen und nicht als Durchschnitt?

Ein Durchschnitt lässt eine schnelle Mehrheit eine langsame Minderheit verdecken, das 75. Perzentil nicht. Das Chrome-Team hat p75 für die Core Web Vitals gewählt, um zwei Bedingungen gleichzeitig zu erfüllen: Die Zahl muss das Erlebnis der meisten Besuche beschreiben, und sie muss der Verzerrung durch eine Handvoll Ausreißer standhalten. Bei p75 haben drei von vier Besuchen das Ziel erreicht, und um das Ergebnis in einer Menge von 100 Stichproben zu verzerren, braucht es 25 schlechte Stichproben statt 5.

Der Perzentilindex für eine aufsteigend sortierte Liste lautet:

index = ceil(0.75 × N)

Ein Beispiel. Eine Seite sammelt 1.000 LCP-Stichproben. 700 davon landen bei 0,9s auf schnellen Desktop-Verbindungen, und 300 landen bei 6,0s auf langsamem Mobilfunk.

Der Durchschnitt ist (700 × 0.9 + 300 × 6.0) / 1000 = 2.43s, was gegenüber dem Schwellenwert von 2,5s als gut gilt.

Der p75-Index ist ceil(0.75 × 1000) = 750. Aufsteigend sortiert liegt Stichprobe 750 in der 6,0s-Gruppe, also beträgt das p75-LCP 6,0s. Das ist schlecht, und es ist die Zahl, die Google verwendet.

Derselbe Datensatz, zwei Urteile. Der Durchschnitt hat die Seite bestehen lassen, während 300 echte Menschen sechs Sekunden gewartet haben. Deshalb ist ein Real-User-Monitoring-Bericht, der nur Mittelwerte zeigt, schlechter als gar kein Bericht, und deshalb führt jedes brauchbare Performance-Diagramm p75, p90 und p99 neben der Anzahl.

Dieselben 1.000 Stichproben, zwei Urteile

Durchschnitt: 2,43 s

• Mischt 700 schnelle Desktop-Ladevorgänge mit 300 langsamen mobilen
• Gilt gegenüber dem Schwellenwert von 2,5 s als gut

p75: 6,0 s

• Stichprobe 750 liegt in der langsamen mobilen Gruppe
• Gilt als schlecht, und das ist die Zahl, die Google verwendet

Was sammelt ein Real-User-Monitoring-Skript?

Ein RUM-Skript sammelt Timing- und Fehlerereignisse, die der Browser aussendet, plus genug Kontext, um sie zu segmentieren: die Core Web Vitals, Navigations- und Ressourcen-Timings, JavaScript-Fehler mit Stacktraces, die Route sowie grobe Geräte-, Browser- und Verbindungsattribute. Nichts davon braucht ein Cookie oder eine dauerhafte Kennung.

Das Gewicht entscheidet darüber, ob sich das Skript überhaupt lohnt, denn alles, was die gemessene Seite verzögert, verfälscht die Messung. Flowsery liefert ein Skript unter 10 KB, cookiefrei und in der EU gehostet, und wendet kein Daten-Sampling an, sodass das p75 aus jeder Sitzung berechnet wird und nicht aus einer Teilmenge. Neben den Timings zeichnet es die Sitzung selbst auf und markiert Rage Clicks, Dead Clicks, JavaScript-Fehler und Abbrüche, was aus einem langsamen p75 ein Session Replay macht, das Sie ansehen können, statt einer Zahl, die Sie erraten müssen.

Was übersieht Real User Monitoring?

Real User Monitoring übersieht alle, die nie angekommen sind, und alle, die gegangen sind, bevor das Beacon gefeuert hat. Wer eine Seite nach vier Sekunden abbricht, erzeugt gar keine LCP-Stichprobe, was den Datensatz zugunsten der Geduldigen verzerrt. Seiten ohne Traffic erzeugen keine Daten, sodass eine neue Route oder ein selten genutzter Admin-Screen unsichtbar bleibt, bis jemand ihn benutzt.

Zwei weitere Lücken fallen in der Praxis ins Gewicht. Content-Blocker verwerfen einen Teil der Analytics-Requests, sodass die erfasste Population eine Teilmenge der echten ist. Und die Metrikunterstützung unterscheidet sich je nach Browser-Engine, sodass ein Safari-lastiges Publikum für manche Vitals weniger Stichproben liefert als ein Chrome-lastiges.

Schließen Sie die Lücken bewusst: Lassen Sie synthetische Checks auf den Routen laufen, die noch keinen Traffic haben, halten Sie den Erfassungsendpunkt first-party, und lesen Sie RUM neben Web-Analytics, damit Sie sehen, ob die Sitzungen, die aus dem Performance-Diagramm verschwunden sind, auch aus dem Funnel verschwunden sind.

Häufig gestellte Fragen

Ist Real User Monitoring dasselbe wie Web-Analytics?

Nein. Web-Analytics zählt Besuche, Quellen, Funnels und Conversions, um geschäftliche Fragen zu beantworten. Real User Monitoring misst, wie schnell und wie zuverlässig diese Besuche gerendert und reagiert haben. Beide teilen sich in den meisten Tools ein Skript und eine Sitzungskennung, weshalb ein langsames p75-LCP und ein Rückgang beim Funnel-Abschluss auf derselben Zeitachse gelesen werden können.

Wie viel Traffic braucht Real User Monitoring, um nützlich zu sein?

Genug Stichproben, damit das 75. Perzentil für das Segment stabil ist, das Sie lesen. Eine Seite mit 40 Besuchen pro Woche liefert ein p75, das mit jedem ungewöhnlichen Gerät schwankt, also aggregieren Sie auf Template-Ebene oder erweitern Sie das Zeitfenster, bevor Sie Schlüsse ziehen. Segmentaufteilungen vervielfachen den Bedarf: p75 gleichzeitig nach Land und Gerät zu lesen, braucht weit mehr Traffic als seitenweit.

Verlangsamt Real User Monitoring die Website, die es misst?

Ein RUM-Skript fügt Bytes und Ausführungszeit hinzu, also entscheidet die Größe des Skripts über die Antwort. Es asynchron zu laden, klein zu halten und Beacons erst nach dem Rendern der Seite zu senden, verhindert, dass die Messung das Gemessene verändert. Ein schweres Monitoring-Skript, das das Rendering blockiert, verschlechtert jede Metrik, die es meldet.

Warum widersprechen meine RUM-Daten Lighthouse?

Lighthouse liefert Labordaten von einem simulierten Gerät auf einer gedrosselten Verbindung, RUM liefert Felddaten aus einer Verteilung echter Geräte. Ein Lighthouse-LCP von 1,8s und ein Feld-p75-LCP von 5,2s sind beide korrekt: Der Laborlauf beschreibt eine Maschine, die Sie konfiguriert haben, die Feldzahl beschreibt Ihr Publikum. Beheben Sie Regressionen im Labor, beurteilen Sie den Erfolg im Feld.

Funktioniert Real User Monitoring ohne Cookies?

Ja. Performance-Beacons tragen Timings, eine Route und grobe Geräteattribute, von denen keines eine dauerhafte Kennung braucht. Flowsery läuft aus diesem Grund cookiefrei und in der EU gehostet, was den Felddatensatz in Regionen intakt hält, in denen Consent-Banner die Erfassung sonst unterdrücken würden.

Soll ich auf p75 oder auf einzelne langsame Sitzungen alarmieren?

Alarmieren Sie auf p75 für die Website und für hochwertige Routen, denn das ist die Zahl, die am Core-Web-Vitals-Urteil hängt. Einzelne langsame Sitzungen gehören in die Triage, nicht ins Alerting: ein 12-Sekunden-Ladevorgang auf einem Telefon im Tunnel ist keine Regression. Gruppieren Sie die langsamen Sitzungen zuerst nach gemeinsamer Ursache und alarmieren Sie dann, wenn die Gruppe wächst.

Kann Real User Monitoring zeigen, ob eine Regression nur ein Land betrifft?

Real User Monitoring liefert zu jeder Stichprobe ein Land, eine Seite und ein Release, sodass sich genau diese Kombination filtern lässt. Ob ein Dienstag-Deploy die Preisseite für Nutzer in Brasilien verlangsamt hat, lässt sich nur mit Felddaten beantworten, die diesen Kontext mitbringen, denn ein synthetischer Agent läuft von einem festen Standort aus.

Zählt Real User Monitoring einen Besucher, der die Seite vor dem vollständigen Laden verlässt?

Nein, ein Besuch, der abbricht, bevor das Beacon feuert, erzeugt gar keine Stichprobe, weder eine schnelle noch eine langsame. Das verzerrt den erfassten Datensatz zugunsten der Besucher, die geduldig genug bleiben, sodass die tatsächliche Erfahrung der ungeduldigen Nutzer nie im Bericht ankommt.

Warum zeigen Safari-lastige Websites weniger RUM-Stichproben?

Browser-Engines unterscheiden sich darin, welche Core-Web-Vitals-APIs sie bereitstellen, die Metrik-Unterstützung ist also nicht über alle Engines hinweg identisch. Ein Safari-lastiges Publikum liefert bei gleichem Traffic-Volumen weniger Stichproben für manche Vitals als ein Chrome-lastiges, was eine Lücke in der Abdeckung ist und kein Zeichen besserer Performance.

Wie groß ist das Real-User-Monitoring-Skript von Flowsery?

Flowsery liefert ein einziges Skript unter 10 KB, cookiefrei und in der EU gehostet. Es wendet kein Data-Sampling an, sodass der berichtete p75-Wert aus jeder Sitzung berechnet wird statt aus einer Teilmenge, und die geringe Größe verhindert, dass die Messung die gemessene Seite verlangsamt.