Monitoraggio degli utenti reali e Web Vitals

Il pacchetto npm web-vitals di Google fornisce una semplice API per misurare i Core Web Vitals nei browser degli utenti reali. Lo installi con npm install web-vitals e importi i callback delle singole metriche: onLCP, onFID (deprecato), onCLS, onFCP, onTTFB e il moderno onINP per Interaction to Next Paint.

Ogni callback (onLCP, onCLS, onINP ecc.) riceve un oggetto metrica contenente: name ('LCP'), value (millisecondi o un punteggio senza unità), rating ('good', 'needs-improvement', 'poor') e id (un identificatore univoco per la deduplicazione). Il callback viene eseguito quando il valore della metrica è definitivo.

Utilizzi l'API Navigator.sendBeacon o fetch per inviare le metriche al Suo endpoint di analisi. sendBeacon è preferibile perché continua a funzionare anche dopo lo scaricamento della pagina, un aspetto fondamentale per metriche come CLS, che diventano definitive quando la pagina viene nascosta. Quando possibile, raggruppi tutti i report delle metriche in un unico beacon.

Per integrare i Web Vitals in OpenTelemetry, crei strumenti Gauge per ogni metrica: const lcp = meter.createObservableGauge('web_vitals.lcp'). In ogni callback onLCP, registri il valore con gli attributi pertinenti (percorso della pagina, tipo di dispositivo). Il Suo backend di osservabilità potrà quindi generare avvisi sulle regressioni del P75 di LCP.

Per misurare le prestazioni specifiche di React che i Web Vitals non rilevano, utilizzi la User Timing API: performance.mark('render-start') prima del rendering, performance.mark('render-end') dopo, quindi performance.measure('component-render', 'render-start', 'render-end'). Queste misurazioni vengono visualizzate nella scheda Performance di Chrome DevTools.

Il componente React Profiler avvolge un sottoalbero e chiama il callback onRender con i dati temporali: id (ID del Profiler), phase ('mount' o 'update'), actualDuration (tempo di rendering), baseDuration (tempo di rendering stimato senza memoizzazione). Utilizzi questa funzionalità in fase di sviluppo per identificare i componenti lenti.

Gli errori non gestiti e i rifiuti di Promise possono essere acquisiti come span OTel con stato di errore. Configuri listener globali: window.addEventListener('error', handler) e window.addEventListener('unhandledrejection', handler). Crei uno span, imposti span.setStatus({ code: SpanStatusCode.ERROR }), aggiunga il messaggio e lo stack trace dell'errore come attributi, quindi termini lo span.

Le React Error Boundaries intercettano gli errori di rendering nell'albero dei componenti. Nel metodo componentDidCatch, crei uno span OTel che rappresenta l'errore, ne imposti lo stato su ERROR, associ error.message e componentStack come attributi e chiami span.end(). In questo modo gli errori di rendering di React vengono inseriti nella pipeline della Sua traccia distribuita.

Il JavaScript di produzione minificato produce stack trace illeggibili come "a.b at bundle.min.js:1:84721". Carichi le source map su Sentry, Datadog o nella Sua pipeline OTel durante il processo di build CI/CD, così gli stack trace grezzi vengono automaticamente risolti nei nomi dei file TypeScript originali e nei relativi numeri di riga.

L'invio dei dati completi delle tracce per ogni sessione è costoso. Implementi il campionamento delle sessioni: assegni casualmente un flag sessionSampled al primo caricamento della pagina e lo memorizzi in sessionStorage. Inizializzi l'SDK OTel e invii le tracce solo per le sessioni campionate (ad esempio, il 10%). Campioni sempre al 100% le sessioni con errori.

I Web Vitals riportati come metriche OTel consentono di configurare avvisi basati sugli SLO: se il P75 di LCP supera 2,5 secondi in oltre il 5% delle sessioni nell'intervallo di un'ora, generi un avviso. In questo modo i team di sviluppo ricevono segnali utili direttamente correlati all'esperienza dell'utente, anziché alle sole metriche dell'infrastruttura backend.

Quando viene eseguito il callback onLCP della libreria web-vitals?

La libreria web-vitals fornisce semplici callback per misurare LCP, INP, CLS, FCP e TTFB nei browser degli utenti reali. Riporti queste metriche come metriche OTel per configurare avvisi basati sugli SLO, acquisisca gli errori tramite listener globali e React Error Boundaries come span OTel e carichi le source map per risolvere gli stack trace minificati. Campioni le sessioni per gestire il volume dei dati mantenendo una copertura del 100% degli errori.