Real User Monitoring mit Core Web Vitals und Backend-Traces

Was ist Real User Monitoring?

Real User Monitoring (RUM) misst Performance und Zuverlässigkeit einer Webanwendung so, wie echte Nutzer sie in ihrem eigenen Browser erleben. Ein kleiner JavaScript-Agent zeichnet Seitenaufrufe, Routenwechsel, Interaktionen, Netzwerk-Requests und Fehler auf und sendet sie an ein Observability-Backend. Anders als Labortests erfasst RUM die ganze Vielfalt realer Bedingungen: langsame Mobilfunknetze, ältere Geräte, Browser-Erweiterungen, entfernte Regionen und ungewöhnliche Navigationspfade.

RUM ist eine Form des passiven Monitorings. Es berichtet nur, was Nutzer tatsächlich getan haben, und ist damit die genaueste Quelle für Fragen wie „Wie schnell ist unser Checkout für Android-Nutzer in Österreich?“ Ergänzt wird RUM durch synthetisches Monitoring, das die Verfügbarkeit proaktiv prüft, auch wenn gerade niemand die Anwendung nutzt.

Warum Real User Monitoring wichtig ist

Backend-Dashboards können völlig unauffällig aussehen, während Nutzer leiden. Ein zu großes JavaScript-Bundle, ein langsames Drittanbieter-Skript, ein Layout Shift durch ein spät geladenes Banner oder ein CDN-Problem in einer Region tauchen in Server-Metriken nie auf. RUM zeigt die Erfahrung aus der einzigen Perspektive, die am Ende zählt.

• Sichtbarkeit in der Suche: Core Web Vitals sind Teil der Page-Experience-Signale von Google, und dafür zählen Felddaten echter Nutzer.
• Conversion: Langsame und instabile Seiten führen zu Abbrüchen. Mit RUM segmentieren Sie die Performance nach Funnel-Schritt.
• Schnelleres Debugging: Frontend-Fehler kommen mit Browser, Betriebssystem, Release und Klickpfad an, statt als vages Support-Ticket.
• Sicherheit bei Releases: Vergleichen Sie die Performance vor und nach einem Frontend-Deployment mit echtem Traffic.

Core Web Vitals und weitere wichtige RUM-Metriken

Metrik	Was sie misst	Guter Wert (p75)
Largest Contentful Paint (LCP)	Laden: wann der Hauptinhalt sichtbar wird	höchstens 2,5 s
Interaction to Next Paint (INP)	Reaktionsfähigkeit: Verzögerung zwischen Interaktion und sichtbarer Reaktion	höchstens 200 ms
Cumulative Layout Shift (CLS)	Visuelle Stabilität: unerwartete Layout-Verschiebungen	höchstens 0,1

Google bewertet Core Web Vitals am 75. Perzentil der Seitenaufrufe. Über diese drei Werte hinaus sind Time to First Byte, First Contentful Paint, Long Tasks, Resource Timing für Skripte, Bilder und API-Calls, die JavaScript-Fehlerrate und Zufriedenheitswerte im Stil von Apdex hilfreich. Betrachten Sie immer Verteilungen und Perzentile statt Durchschnittswerten, denn eine schnelle Mehrheit kann eine große Gruppe frustrierter Nutzer verdecken.

Real User Monitoring mit Obseria

Der RUM-Agent von Obseria erfasst Core Web Vitals, Navigation und Resource Timing, Routenwechsel in Single-Page-Apps, Nutzeraktionen und JavaScript-Fehler. Er ergänzt fetch- und XHR-Requests um W3C-Trace-Context-Header, sodass jeder Frontend-Request mit seinem Distributed Trace im Backend verbunden ist. Ist eine Seite langsam, sehen Sie, ob die Zeit im Browser, im Netzwerk oder in einem bestimmten Backend-Service verloren ging.

RUM-Events landen in Obseria Lake neben Traces, Logs und Metriken. Obseria Pipeline maskiert personenbezogene Daten wie E-Mail-Adressen oder IDs in URLs vor der Speicherung. Sie segmentieren nach beliebigen Attributen wie Seite, Land, Browser, Release oder Kundentarif und fragen mit OQL ab, etwa fetch rum.events | filter page == "/checkout" | summarize p75(lcp), by:{country}. JavaScript-Fehler erscheinen in der Errors Inbox, und jede Session ist mit ihrer Session-Aufzeichnung verknüpft. RUM-Web-Events kosten $0.060 pro Million ingestiert und $0.540 pro Million gespeichert.

Auf Basis dieser Daten definieren Sie SLOs direkt auf die Nutzererfahrung, etwa „95 Prozent der Checkout-Aufrufe erreichen einen LCP unter 2,5 Sekunden“. Verschlechtert sich ein Wert nach einem Frontend-Release, vergleicht Obseria Intelligence die Versionen und zeigt, ob ein neues Skript, ein größeres Bundle oder ein langsamer Backend-Call die Ursache ist.

Best Practices für Real User Monitoring

1. Den Agent früh laden, damit er den vollständigen Seitenaufbau und frühe Fehler erfasst.
2. Releases und Umgebungen taggen, um Frontend-Versionen zu vergleichen und Staging-Traffic sauber zu trennen.
3. Source Maps aus der CI hochladen, damit JavaScript-Fehler lesbar sind.
4. SLOs auf die Nutzererfahrung setzen, etwa p75-LCP auf zentralen Seiten, statt nur auf Backend-Latenz.
5. Erst segmentieren, dann optimieren. Ein globaler Durchschnitt verbirgt Probleme, die bestimmte Geräte, Länder oder Seiten betreffen.
6. Datenschutz ernst nehmen: Nur erfassen, was Sie brauchen, personenbezogene Daten beim Ingest maskieren und Einwilligungsanforderungen beachten.