Dati CrUX: il campo reale dietro i Core Web Vitals

Se hai mai sentito dire "il sito è veloce, l'ho testato" e poi hai visto il rapporto Core Web Vitals di Search Console dire il contrario, il problema quasi mai è la metrica: è la fonte. Il Chrome User Experience Report, il CrUX, è l'insieme di misurazioni raccolte davvero dai browser Chrome di utenti reali che hanno visitato la tua pagina, con il loro dispositivo, la loro connessione, nel loro contesto quotidiano. Un test di laboratorio, che sia Lighthouse, la sezione lab di PageSpeed Insights o WebPageTest, simula invece una singola visita, su una singola macchina, con condizioni di rete fissate a tavolino. Sono due esperimenti diversi che rispondono a domande diverse, e confonderli è la causa più comune delle discussioni infinite tra chi dice "per me è veloce" e chi guarda i numeri di Google e non lo è.

La distinzione conta perché Google valuta i Core Web Vitals ai fini del ranking usando il dato di campo, non quello di laboratorio. Un punteggio 100 nella sezione lab di PageSpeed Insights non garantisce nulla di per sé: quella sezione misura una singola esecuzione simulata, in un istante preciso. La sezione field della stessa pagina, quando esiste, mostra invece cosa hanno effettivamente vissuto gli utenti reali nelle settimane precedenti. Quando le due sezioni raccontano storie diverse, è il campo che decide l'argomento, non il laboratorio.

Cos'è realmente il CrUX

Il CrUX è un dataset pubblico gestito da Google che raccoglie metriche di performance ed esperienza utente da un campione di utenti Chrome che hanno acconsentito alla sincronizzazione della cronologia e alla raccolta anonima di statistiche d'uso. Non è ogni singolo visitatore del sito, ma un campione ampio a sufficienza da risultare statisticamente utile per le origini con traffico adeguato.

Per ogni origine, e quando il volume lo consente anche per la singola URL, il CrUX aggrega metriche come Largest Contentful Paint, Interaction to Next Paint e Cumulative Layout Shift così come sono state misurate durante visite reali, non simulate in laboratorio. È esattamente questo il dato che alimenta la valutazione dei Core Web Vitals che vedi in Search Console e nella sezione field di PageSpeed Insights.

• Nasce da visite reali di utenti Chrome che hanno acconsentito alla raccolta anonima dei dati
• Copre l'origine intera, o la singola pagina quando il volume di traffico è sufficiente
• È la fonte che Google dichiara di usare per valutare i Core Web Vitals ai fini SEO

Perché il laboratorio da solo non basta

Un test di laboratorio è prezioso per il debug proprio perché è controllato e ripetibile: stessa macchina, stessa rete simulata, stesso istante. Ma per questo racconta solo una possibilità tra le tante che i visitatori reali sperimentano davvero. Se sviluppi e testi da un portatile recente su fibra, il tuo laboratorio userà condizioni molto migliori di quelle di buona parte del pubblico reale, specialmente su mobile o in aree con rete debole.

Il risultato tipico è questo: PageSpeed Insights o Lighthouse restituiscono un punteggio lab verde, mentre il rapporto Core Web Vitals di Search Console segnala URL classificati come da migliorare o scarsi. Non è un errore di misurazione, sono due esperimenti diversi con premesse diverse. Il laboratorio dice cosa succede in condizioni controllate e ripetibili; il campo dice cosa succede davvero, mediato su dispositivi e reti che nessuno controlla a tavolino.

Il ritardo che genera confusione

Il CrUX non è in tempo reale. I dati pubblicati oggi sono aggregati su una finestra mobile di circa 28 giorni di traffico reale, con un certo ritardo tra il momento in cui le visite avvengono e il momento in cui il dato viene reso disponibile. Questo produce l'equivoco più comune tra chi lavora sulla performance: rilasciare una correzione e aspettarsi che il rapporto Core Web Vitals cambi il giorno dopo, o addirittura la settimana dopo.

In pratica, dopo un intervento reale come comprimere immagini, eliminare un font che blocca il rendering o differire uno script non essenziale, servono settimane prima che la finestra dei 28 giorni si sia ripulita dai dati precedenti al fix e il miglioramento emerga con chiarezza nei report basati su CrUX. Nel frattempo, il modo corretto di verificare che la correzione funzioni è tornare al laboratorio: uno strumento come Lighthouse ne mostra l'effetto quasi subito, proprio perché misura un'esecuzione singola e non un aggregato storico.

• Il dato pubblicato riflette una finestra di circa 28 giorni, non l'ultima visita in assoluto
• Un intervento reale impiega settimane a farsi vedere nei report basati sul CrUX
• Per una verifica immediata dopo una modifica, il laboratorio resta lo strumento giusto

Percentili, non medie

Il CrUX non riporta una media delle esperienze: riporta percentili, tipicamente il 75esimo, per le metriche usate nella valutazione dei Core Web Vitals. È una scelta deliberata. Una media viene salvata dalla maggioranza di visite veloci e nasconde la coda di esperienze lente; il 75esimo percentile dice invece che almeno tre visite su quattro devono passare la soglia perché la metrica venga considerata buona.

La conseguenza pratica è che il CrUX risulta strutturalmente più severo di un test di laboratorio eseguito in buone condizioni, ed è corretto che lo sia: l'obiettivo della metrica non è descrivere l'esperienza dell'utente medio, ma garantire che anche l'utente sfortunato, con un telefono più vecchio, una rete più lenta o l'ora di punta sulla rete mobile, abbia comunque un'esperienza accettabile.

Quando il CrUX semplicemente non esiste

Il CrUX richiede un volume minimo di visite Chrome nella finestra di raccolta prima di pubblicare un dato con sufficiente confidenza statistica. Sotto quella soglia, l'origine o la pagina non ha semplicemente dati di campo: in Search Console e in PageSpeed Insights comparirà l'indicazione che i dati non sono disponibili, non uno zero né un punteggio negativo.

È una situazione comune per siti nuovi, per progetti di nicchia con poco traffico o per singole pagine profonde di un sito altrimenti grande. In questi casi ragionare esclusivamente su laboratorio più giudizio tecnico, come le dimensioni delle immagini, la struttura del CSS critico o l'ordine di caricamento degli script, è l'unica strada disponibile, ed è comunque un ragionamento valido: le stesse cause tecniche che degradano la performance in laboratorio la degraderebbero anche sul campo, se solo ci fosse traffico sufficiente a misurarla.

Dove leggere i dati di campo

Il posto più diretto è il rapporto Core Web Vitals dentro Google Search Console, che raggruppa gli URL della proprietà per stato, scarso, da migliorare o buono, sulla base del CrUX, sia per mobile sia per desktop, con la possibilità di ispezionare gruppi di URL con problemi simili.

PageSpeed Insights mostra, quando il dato esiste, una sezione Field Data separata da quella di laboratorio, sia per l'origine intera sia per l'URL specifico appena testato: è il modo più rapido per capire se si sta guardando la realtà o una simulazione.

Per un'analisi più ampia o competitiva, il dataset CrUX è pubblicato anche come tabella pubblica su BigQuery e attraverso una API dedicata, che permettono di interrogare lo storico di qualunque origine con traffico sufficiente, inclusi i siti dei concorrenti, per confrontare l'andamento nel tempo o tra domini diversi.

• Il rapporto Core Web Vitals in Search Console, per la proprietà verificata
• La sezione Field Data di PageSpeed Insights, quando il traffico è sufficiente
• Il dataset pubblico CrUX su BigQuery e la relativa API, per confronti storici o competitivi

Campo e laboratorio rispondono a domande diverse

Il dato di campo dice che esiste un problema, per quali utenti e con quale gravità reale: è la prova che chiude una discussione su cosa contare come priorità. Non dice però perché il problema succede. Un LCP scarso al 75esimo percentile non indica di per sé quale immagine, quale font o quale script sta bloccando il rendering.

Il laboratorio fa esattamente il contrario. Uno strumento come Lighthouse o WebPageTest scompone il caricamento passo per passo, indica quale risorsa ritarda quale metrica e permette di sperimentare una correzione vedendone l'effetto quasi immediato, senza aspettare settimane. Usato da solo, però, resta un'ipotesi su un singolo scenario controllato, non una prova di ciò che vivono davvero gli utenti.

Il flusso di lavoro corretto le mette in sequenza: si parte dal campo per sapere dove guardare e con quale urgenza, si passa al laboratorio per capire la causa tecnica e verificare la correzione, poi si torna al campo, con la pazienza della finestra di circa 28 giorni, per confermare che il miglioramento è arrivato davvero agli utenti reali.

Segmentare per dispositivo e connessione

Il numero aggregato per un'intera origine può risultare buono e nascondere comunque un gruppo di utenti che soffre. Mobile e desktop hanno quasi sempre profili di performance molto diversi, perché CPU, memoria e variabilità di rete non sono le stesse: un LCP accettabile su desktop può essere ben oltre soglia su mobile per la stessa identica pagina.

Il CrUX espone anche una dimensione legata al tipo effettivo di connessione, non solo al tipo di dispositivo. Guardare solo il numero complessivo dell'origine equivale a lasciare che la maggioranza silenziosa nasconda la minoranza che, magari con una rete più lenta, sta vivendo l'esperienza peggiore, proprio quella che la logica del 75esimo percentile dovrebbe far notare e che una lettura solo aggregata rischia di far perdere di vista.

Prima di dichiarare un problema risolto vale la pena controllare la segmentazione per dispositivo dentro Search Console o PageSpeed Insights: un miglioramento reale sul desktop che non tocca il mobile lascia intatta la parte di pubblico che più probabilmente ha determinato il giudizio da migliorare o scarso in origine.