Le Core Web Vitals che contano, quelle che Google usa e che descrivono l’esperienza reale di un sito, vengono dal Chrome UX Report: i dati raccolti dai browser Chrome degli utenti che hanno acconsentito a condividerli. Sono dati preziosi, ma hanno limiti precisi. Arrivano con ritardo, su una finestra di 28 giorni; riguardano solo le pagine con traffico sufficiente; non dicono nulla su quale modello di pagina, quale tipo di utente o quale elemento causi un problema. Per questo, prima o poi, chi si occupa seriamente di prestazioni si trova davanti a una domanda: come misuro le Core Web Vitals direttamente sui miei utenti?
La risposta si chiama Real User Monitoring, o RUM: raccogliere le metriche dai browser dei visitatori reali, inviarle a un sistema di analisi e studiarle come si studiano gli altri dati del sito. In questo articolo vediamo cosa offre rispetto a CrUX, come si implementa con la libreria ufficiale di Google, cosa raccogliere oltre ai numeri e come leggere i risultati.
Cosa aggiunge il RUM al Chrome UX Report
CrUX è il riferimento ufficiale, ed è bene continuare a usarlo per sapere come Google vede il sito, come spiegato nell’articolo sul motivo per cui CrUX e test di laboratorio servono entrambi. Il RUM non lo sostituisce, ma colma quattro lacune importanti.
- Tempestività. I dati di CrUX si aggiornano su una finestra mobile di 28 giorni: l’effetto di un intervento si vede per intero solo dopo un mese. Con il RUM si vede il giorno dopo, e un peggioramento dovuto a un aggiornamento si nota in poche ore.
- Segmentazione. CrUX fornisce dati per pagina o per origine, divisi per tipo di dispositivo. Il RUM permette di dividere i dati per modello di pagina, per categoria, per paese, per tipo di connessione, per utenti anonimi o collegati, per variante di un test A/B: qualsiasi informazione disponibile al momento della misura.
- Copertura. Le pagine con poco traffico non compaiono in CrUX. Con il RUM anche la pagina di un prodotto di nicchia ha i suoi dati, e soprattutto si possono aggregare pagine simili anche quando nessuna ha abbastanza visite da sola.
- Attribuzione. CrUX dice che l’INP è scarso; il RUM può dire su quale elemento avviene l’interazione lenta, quale fase pesa di più e quale script è responsabile. È la differenza tra sapere di avere un problema e sapere dove intervenire.
La libreria web-vitals
Misurare correttamente le Core Web Vitals nel browser non è banale. Il CLS va calcolato per finestre di sessione, l’INP richiede di osservare tutte le interazioni e scegliere quella rappresentativa, l’LCP si ferma alla prima interazione dell’utente, e tutte vanno gestite correttamente quando la pagina viene nascosta, ripristinata dalla back/forward cache o attivata da un prerender. Per evitare di reimplementare queste regole, Google mantiene una piccola libreria open source, web-vitals, che le applica esattamente come fa Chrome per CrUX.
L’uso di base richiede poche righe. Per ogni metrica si registra una funzione che riceve il valore quando è disponibile, e lo si invia al server con navigator.sendBeacon, che funziona anche quando la pagina si sta chiudendo:
import { onLCP, onINP, onCLS } from 'web-vitals/attribution';
function invia( metrica ) {
const dati = JSON.stringify( {
nome: metrica.name,
valore: metrica.value,
stato: metrica.rating, // good, needs-improvement, poor
id: metrica.id, // univoco per pagina vista
navigazione: metrica.navigationType,
modello: document.body.dataset.modello, // es. "scheda-prodotto"
pagina: location.pathname,
} );
navigator.sendBeacon( '/rum', dati );
}
onLCP( invia );
onINP( invia );
onCLS( invia );Alcuni dettagli sono importanti. CLS e INP possono cambiare durante tutta la vita della pagina, per cui la libreria li riporta quando la pagina viene nascosta; alcune visite, per esempio quando il browser viene chiuso bruscamente, non invieranno mai i dati, ed è normale. Una stessa metrica può essere riportata più volte per la stessa pagina, per esempio dopo un ripristino dalla bfcache: il campo id permette di distinguere le misure e di conservare solo l’ultima per ciascuna pagina vista.
L’attribuzione: sapere perché
La versione della libreria con attribuzione, quella importata nell’esempio, aggiunge a ogni metrica le informazioni diagnostiche. Per l’LCP indica l’elemento, l’URL della risorsa e la scomposizione del tempo in quattro fasi: TTFB, ritardo prima dell’inizio del download, durata del download e ritardo di rendering. Per l’INP indica l’elemento su cui è avvenuta l’interazione, il tipo di evento e la divisione tra attesa iniziale, elaborazione e disegno, oltre agli script coinvolti rilevati dalla Long Animation Frames API. Per il CLS indica l’elemento che si è spostato di più e il momento dello spostamento.
Queste informazioni trasformano il RUM da termometro a strumento diagnostico. Se sulle schede prodotto la fase dominante dell’LCP è il ritardo prima del download, il problema è la scoperta tardiva dell’immagine, e la soluzione riguarda priorità e caricamento differito; se è il TTFB, il problema è il server. Se l’INP peggiore avviene sempre sullo stesso pulsante e l’elaborazione è dominata da uno script, si sa esattamente da dove partire. Conviene inviare solo le informazioni essenziali, come un selettore sintetico dell’elemento e il nome dello script, per mantenere i dati leggeri e privi di informazioni personali.
Dove inviare i dati
Le strade principali sono tre. La prima è un servizio di RUM specializzato: diversi fornitori offrono raccolta, archiviazione e cruscotti pronti, con segmentazione e attribuzione già organizzate. È la soluzione più rapida, a fronte di un costo che cresce con il traffico. La seconda è inviare le metriche come eventi a un sistema di analytics già in uso, per esempio Google Analytics 4, e analizzarle con le esportazioni dei dati grezzi: si sfrutta un’infrastruttura esistente, ma servono competenze per l’analisi. La terza è un endpoint proprio, che scrive i dati in un database o in un sistema di log: massimo controllo, ma tutto il lavoro di archiviazione e visualizzazione è a carico del sito.
Qualunque sia la scelta, conviene considerare il campionamento. Su un sito con molto traffico non serve misurare ogni visita: una percentuale fissa, per esempio il dieci per cento delle pagine viste, dà già risultati statisticamente solidi e riduce costi e volume di dati. Il campionamento va deciso per pagina vista, non per singola metrica, per mantenere coerenti i dati di una stessa visita.
Il RUM su WordPress
Su un sito WordPress l’informazione più utile da aggiungere alle metriche è il modello di pagina: articolo, pagina, archivio, prodotto, carrello. Il tema la conosce già, e può esporla con un attributo sull’elemento body, che lo script di misura legge al momento dell’invio. Per la raccolta, una rotta della REST API o un servizio esterno sono entrambe soluzioni praticabili; l’importante è che l’endpoint sia leggero e non passi per la generazione completa di una pagina.
// Espone il modello di pagina allo script di misura
add_filter(
'body_class',
function ( $classi ) {
$modello = is_singular() ? get_post_type() : ( is_archive() ? 'archivio' : 'altro' );
$classi[] = 'modello-' . sanitize_html_class( $modello );
return $classi;
}
);Lo script di misura va caricato in modo non bloccante, come modulo o con defer: la libreria pesa pochi kilobyte e non deve diventare essa stessa un costo per le prestazioni che misura.
Oltre le Core Web Vitals
Una volta impostata la raccolta, è naturale estenderla. La stessa libreria misura anche TTFB e First Contentful Paint, utili per separare i problemi del server da quelli del front-end. Ma il RUM permette anche di misurare ciò che conta per il singolo sito: il tempo per mostrare i risultati di una ricerca interna, per aprire il mini carrello, per completare un passaggio del checkout. Con le API User Timing, un paio di marcatori nel codice bastano per trasformare un’interazione importante per il business in una metrica da seguire nel tempo, accanto a quelle standard.
Privacy e consenso
Le metriche di prestazione sono dati tecnici, ma vengono raccolti dai dispositivi degli utenti e inviati insieme a informazioni come la pagina visitata. È buona pratica non raccogliere nulla che identifichi la persona, evitare identificativi persistenti, non inviare URL con parametri che possano contenere dati personali e valutare con il proprio consulente la base giuridica della raccolta e il rapporto con il banner dei cookie. Una raccolta minimale, anonima e limitata alle prestazioni è in genere più semplice da gestire di un tracciamento completo, ma la valutazione va fatta caso per caso.
Come leggere i dati
Il primo errore da evitare è guardare la media. Le Core Web Vitals si valutano al 75° percentile, e le distribuzioni dei tempi di caricamento sono asimmetriche: pochi valori molto alti spostano la media senza dire molto sull’esperienza tipica. Il 75° percentile, calcolato separatamente per mobile e desktop, è la misura da confrontare con le soglie di Google e con i dati di CrUX.
Il secondo è confrontare popolazioni diverse. I dati RUM includono spesso browser diversi da Chrome, dove alcune metriche non sono disponibili o sono misurate in modo diverso, visite con la cache calda e visite di utenti che CrUX non include. È normale che i valori non coincidano con quelli di Search Console; ciò che conta è la coerenza delle tendenze e la capacità di spiegare le differenze. Per un confronto diretto conviene filtrare i dati RUM sui soli browser Chromium.
Il terzo è leggere i dati senza segmentarli. Il valore complessivo del sito dice poco; lo stesso valore diviso per modello di pagina e per dispositivo dice quasi tutto. Un cruscotto utile mostra, per ogni modello di pagina importante, il 75° percentile delle tre metriche nel tempo, la quota di visite nello stato buono e, per le metriche fuori soglia, gli elementi e le fasi più frequenti nell’attribuzione.
Infine, oltre al percentile vale la pena osservare la distribuzione. Un istogramma dei valori di LCP o di INP mostra se il problema riguarda tutti gli utenti in modo uniforme, oppure un gruppo preciso: una seconda gobba nella parte alta della distribuzione indica spesso un segmento specifico, come una connessione lenta, un paese lontano dal server, un modello di smartphone o una pagina con un widget particolare. Individuare quel gruppo è spesso la strada più breve per migliorare il 75° percentile di tutto il sito.
Un caso d’uso: verificare un rilascio
Il valore del RUM emerge chiaramente in occasione dei rilasci. Un aggiornamento del tema, un nuovo plugin o una campagna con un nuovo pixel possono peggiorare le prestazioni senza che nessuno se ne accorga nei test manuali. Con CrUX il problema emergerebbe settimane dopo, diluito nella finestra di 28 giorni; con il RUM, un confronto del 75° percentile tra il giorno prima e il giorno dopo il rilascio lo mostra subito, e l’attribuzione indica spesso direttamente lo script o l’elemento responsabile. Allo stesso modo, un intervento di ottimizzazione può essere verificato in pochi giorni invece che in un mese.
In sintesi
Il Real User Monitoring misura le Core Web Vitals sui visitatori reali del sito e colma i limiti del Chrome UX Report: dati immediati invece che su 28 giorni, segmentazione per modello di pagina e per tipo di utente, copertura anche delle pagine con poco traffico e, soprattutto, attribuzione delle cause. La libreria web-vitals applica le stesse regole di Chrome e, nella versione con attribuzione, indica elementi, fasi e script responsabili.
Implementarlo richiede poche righe di codice, una destinazione per i dati e qualche attenzione su campionamento, privacy e lettura dei risultati: 75° percentile, segmentazione, confronto con CrUX sulle stesse popolazioni. CrUX resta il riferimento per sapere come Google valuta il sito; il RUM è lo strumento per capire perché, e per accorgersi in tempo quando qualcosa cambia.
