Real User Monitoring und Web Vitals

Das npm-Paket web-vitals von Google bietet eine einfache API zum Messen der Core Web Vitals in den Browsern echter Nutzer. Installieren Sie es mit `npm install web-vitals` und importieren Sie einzelne Metrik-Callbacks: onLCP, onFID (veraltet), onCLS, onFCP, onTTFB und das moderne onINP für Interaction to Next Paint.

Jeder Callback (onLCP, onCLS, onINP usw.) erhält ein Metrikobjekt mit folgenden Eigenschaften: name ('LCP'), value (Millisekunden oder ein einheitenloser Wert), rating ('good', 'needs-improvement', 'poor') und id (eine eindeutige Kennung zur Deduplizierung). Der Callback wird ausgelöst, sobald der Metrikwert endgültig feststeht.

Verwenden Sie die Navigator.sendBeacon-API oder fetch, um Metriken an Ihren Analytics-Endpunkt zu melden. sendBeacon wird bevorzugt, weil die Übertragung auch nach dem Entladen der Seite fortgesetzt wird – entscheidend für Metriken wie CLS, die beim Ausblenden der Seite endgültig feststehen. Bündeln Sie nach Möglichkeit alle Metrikmeldungen in einem einzigen Beacon.

Um Web Vitals in OpenTelemetry zu integrieren, erstellen Sie für jede Metrik Gauge-Instrumente: `const lcp = meter.createObservableGauge('web_vitals.lcp')`. Zeichnen Sie in jedem onLCP-Callback den Wert mit relevanten Attributen (Seitenpfad, Gerätetyp) auf. Ihr Observability-Backend kann dann auf Regressionen des P75-LCP-Werts alarmieren.

Verwenden Sie für die Messung React-spezifischer Performance, die nicht von Web Vitals erfasst wird, die User Timing API: `performance.mark('render-start')` vor dem Rendern, `performance.mark('render-end')` danach und anschließend `performance.measure('component-render', 'render-start', 'render-end')`. Diese Messungen erscheinen im Performance-Tab der Chrome DevTools.

Die React-Profiler-Komponente umschließt einen Teilbaum und ruft ihren onRender-Callback mit Zeitdaten auf: id (Profiler-ID), phase ('mount' oder 'update'), actualDuration (Renderzeit) und baseDuration (geschätzte Renderzeit ohne Memoization). Verwenden Sie dies in der Entwicklung, um langsame Komponenten zu identifizieren.

Nicht behandelte Fehler und Promise-Ablehnungen können als OTel-Spans mit Fehlerstatus erfasst werden. Richten Sie globale Listener ein: `window.addEventListener('error', handler)` und `window.addEventListener('unhandledrejection', handler)`. Erstellen Sie einen Span, setzen Sie mit `span.setStatus({ code: SpanStatusCode.ERROR })` dessen Status, fügen Sie die Fehlermeldung und den Stacktrace als Attribute hinzu und beenden Sie den Span.

React Error Boundaries fangen Rendering-Fehler im Komponentenbaum ab. Erstellen Sie in der Methode componentDidCatch einen OTel-Span, der den Fehler repräsentiert, setzen Sie seinen Status auf ERROR, fügen Sie error.message und componentStack als Attribute hinzu und rufen Sie span.end() auf. Dadurch werden React-Rendering-Fehler in Ihre Pipeline für verteiltes Tracing geleitet.

Minifizierter JavaScript-Code aus Produktions-Builds erzeugt unlesbare Stacktraces wie "a.b at bundle.min.js:1:84721". Laden Sie Source Maps während Ihres CI/CD-Buildprozesses in Sentry, Datadog oder Ihre OTel-Pipeline hoch, damit rohe Stacktraces automatisch in die ursprünglichen TypeScript-Dateinamen und Zeilennummern aufgelöst werden.

Das Senden vollständiger Trace-Daten für jede Sitzung ist teuer. Implementieren Sie Sitzungssampling: Weisen Sie beim ersten Laden der Seite zufällig ein Flag sessionSampled zu und speichern Sie es in sessionStorage. Initialisieren Sie das OTel-SDK und senden Sie Traces nur für ausgewählte Sitzungen (z. B. 10 %). Erfassen Sie Sitzungen mit Fehlern immer zu 100 %.

Als OTel-Metriken gemeldete Web Vitals ermöglichen SLO-basiertes Alerting: Überschreitet P75 LCP für mehr als 5 % der Sitzungen über ein einstündiges Zeitfenster 2,5 Sekunden, lösen Sie einen Alarm aus. So erhalten Engineering-Teams verwertbare Signale, die direkt an die Nutzererfahrung statt an Backend-Infrastrukturmetriken gekoppelt sind.

Wann wird der onLCP-Callback aus der web-vitals-Bibliothek ausgelöst?

Die Bibliothek web-vitals bietet einfache Callbacks zum Messen von LCP, INP, CLS, FCP und TTFB in den Browsern echter Nutzer. Melden Sie diese als OTel-Metriken für SLO-basiertes Alerting, erfassen Sie Fehler über globale Listener und React Error Boundaries als OTel-Spans und laden Sie Source Maps hoch, um minifizierte Stacktraces aufzulösen. Führen Sie Sampling für Sitzungen durch, um das Datenvolumen zu verwalten und gleichzeitig eine vollständige Fehlerabdeckung von 100 % zu gewährleisten.