Monitorowanie rzeczywistych użytkowników i Web Vitals

Pakiet npm web-vitals firmy Google udostępnia prosty interfejs API do pomiaru Core Web Vitals w prawdziwych przeglądarkach użytkowników. Należy zainstalować go za pomocą npm install web-vitals i importować osobne callbacki metryk: onLCP, onFID (przestarzały), onCLS, onFCP, onTTFB oraz nowoczesny onINP dla Interaction to Next Paint.

Każdy callback (onLCP, onCLS, onINP itd.) otrzymuje obiekt metryki zawierający: name ('LCP'), value (milisekundy lub wynik bez jednostki), rating ('good', 'needs-improvement', 'poor') oraz id (unikatowy identyfikator służący do usuwania duplikatów). Callback jest wywoływany po ustaleniu ostatecznej wartości metryki.

Do raportowania metryk do endpointu analitycznego należy użyć interfejsu Navigator.sendBeacon lub fetch. sendBeacon jest preferowany, ponieważ kontynuuje działanie nawet po rozładowaniu strony — ma to kluczowe znaczenie w przypadku metryk takich jak CLS, których wartość końcowa jest ustalana po ukryciu strony. Jeśli to możliwe, należy grupować wszystkie raporty metryk w jednym beaconie.

Aby zintegrować Web Vitals z OpenTelemetry, należy utworzyć instrumenty Gauge dla każdej metryki: const lcp = meter.createObservableGauge('web_vitals.lcp'). W każdym callbacku onLCP należy zarejestrować wartość wraz z odpowiednimi atrybutami (ścieżka strony, typ urządzenia). Backend obserwowalności może wtedy generować alerty dotyczące regresji P75 LCP.

Do pomiaru wydajności specyficznej dla Reacta, której nie obejmują Web Vitals, należy użyć User Timing API: performance.mark('render-start') przed renderowaniem, performance.mark('render-end') po renderowaniu, a następnie performance.measure('component-render', 'render-start', 'render-end'). Pomiary te pojawią się na karcie Performance w Chrome DevTools.

Komponent React Profiler opakowuje poddrzewo i wywołuje callback onRender z danymi pomiarowymi: id (identyfikator Profilera), phase ('mount' lub 'update'), actualDuration (czas renderowania), baseDuration (szacowany czas renderowania bez memoizacji). Należy używać tego rozwiązania w fazie tworzenia aplikacji, aby identyfikować wolne komponenty.

Nieobsłużone błędy i odrzucenia obietnic Promise można przechwytywać jako spany OTel ze statusem błędu. Należy skonfigurować globalne listenery: window.addEventListener('error', handler) i window.addEventListener('unhandledrejection', handler). Następnie należy utworzyć span, ustawić jego status za pomocą span.setStatus({ code: SpanStatusCode.ERROR }), dodać komunikat błędu i stack trace jako atrybuty, a na końcu zakończyć span.

React Error Boundaries przechwytują błędy renderowania w drzewie komponentów. W metodzie componentDidCatch należy utworzyć span OTel reprezentujący błąd, ustawić jego status na ERROR, dołączyć error.message i componentStack jako atrybuty, a następnie wywołać span.end(). Dzięki temu błędy renderowania React trafiają do potoku rozproszonych trace.

Zminifikowany produkcyjny JavaScript generuje nieczytelne stack trace, takie jak "a.b at bundle.min.js:1:84721". Podczas procesu kompilacji CI/CD należy przesłać mapy źródeł do Sentry, Datadog lub potoku OTel, aby surowe stack trace były automatycznie odwzorowywane na oryginalne nazwy plików TypeScript i numery wierszy.

Wysyłanie pełnych danych trace dla każdej sesji jest kosztowne. Należy zaimplementować próbkowanie sesji: przy pierwszym załadowaniu strony losowo przypisać flagę sessionSampled i zapisać ją w sessionStorage. OTel SDK należy inicjalizować i wysyłać trace tylko dla próbkowanych sesji (np. 10%). Sesje, w których wystąpiły błędy, należy zawsze próbkować w 100%.

Web Vitals raportowane jako metryki OTel umożliwiają tworzenie alertów opartych na SLO: jeśli P75 LCP przekracza 2,5 sekundy dla ponad 5% sesji w ciągu godziny, należy wygenerować alert. Zapewnia to zespołom inżynieryjnym praktyczne sygnały bezpośrednio związane z doświadczeniem użytkownika, a nie tylko z metrykami infrastruktury backendu.

Kiedy jest wywoływany callback onLCP z biblioteki web-vitals?

Biblioteka web-vitals udostępnia proste callbacki do pomiaru LCP, INP, CLS, FCP i TTFB w prawdziwych przeglądarkach użytkowników. Należy raportować te wartości jako metryki OTel na potrzeby alertów opartych na SLO, przechwytywać błędy za pomocą globalnych listenerów i React Error Boundaries jako spany OTel oraz przesyłać mapy źródeł, aby rozwiązywać zminifikowane stack trace. Należy próbkować sesje w celu kontrolowania ilości danych, zachowując jednocześnie 100% pokrycia błędów.