Il rilascio è andato bene: il laboratorio conferma un LCP dimezzato, il monitoraggio interno mostra pagine molto più rapide. Eppure, il giorno dopo, PageSpeed Insights riporta ancora nella sezione dei dati reali gli stessi numeri rossi di una settimana prima. Non è un errore e non significa che l’intervento non abbia funzionato: è l’effetto della finestra di 28 giorni con cui il Chrome UX Report aggrega i dati degli utenti. Capire come funziona evita decisioni sbagliate, aspettative irrealistiche e più di una discussione inutile con clienti e colleghi.
Che cos’è il Chrome UX Report
Il Chrome UX Report, per tutti CrUX, è il dataset pubblico con cui Google raccoglie le prestazioni vissute dagli utenti reali di Chrome. Contribuiscono i browser di chi ha attivato la sincronizzazione della cronologia e l’invio delle statistiche di utilizzo, su desktop e su Android. I dati vengono aggregati per origine, cioè per l’intero sito, e per singolo URL quando la pagina ha abbastanza traffico, distinguendo tra dispositivi mobili, desktop e tablet.
Per ogni metrica, come LCP, INP, CLS o TTFB, CrUX riporta la distribuzione delle esperienze e il valore al 75° percentile: una pagina supera la valutazione solo se almeno tre visite su quattro rientrano nella soglia “buona”. Sono questi i dati che compaiono nella sezione “Scopri cosa provano i tuoi utenti reali” di PageSpeed Insights, nel rapporto Core Web Vitals di Search Console e che Google utilizza come segnale di esperienza della pagina.
Due limiti vanno tenuti presenti fin da subito. Il primo: non tutti gli utenti sono rappresentati. Chrome su iOS non contribuisce, così come gli altri browser, quindi il pubblico iPhone di un e-commerce di moda o di una testata è di fatto assente dal campione. Il secondo: sotto una certa soglia di traffico CrUX non pubblica dati per l’URL, e PageSpeed Insights ripiega sui valori dell’intera origine oppure dichiara che i dati sono insufficienti.
Come funziona la finestra mobile
I dati di CrUX mostrati da PageSpeed Insights e restituiti dalla CrUX API non descrivono una giornata, ma gli ultimi 28 giorni. Ogni giorno la finestra avanza: entra la giornata più recente, esce quella di quattro settimane prima, e percentili e distribuzioni vengono ricalcolati sull’insieme. È una media mobile, e come tutte le medie mobili ha un pregio e un difetto.
Il pregio è la stabilità: un picco di traffico lento in una singola giornata, un problema temporaneo di un fornitore esterno o un fine settimana con un pubblico diverso non stravolgono la valutazione. Il difetto è l’inerzia: qualsiasi cambiamento, in meglio o in peggio, impiega settimane per manifestarsi del tutto.
Esistono anche altre viste sugli stessi dati, con tempi diversi. Il dataset pubblicato su BigQuery è mensile e riguarda il mese di calendario precedente. La CrUX History API restituisce invece una serie storica di finestre di 28 giorni campionate ogni settimana, utile per osservare l’andamento nel tempo. Search Console, infine, usa gli stessi dati raggruppando gli URL simili.
Conta anche il livello a cui si leggono i dati. Il valore dell’origine somma tutte le pagine del sito in proporzione al loro traffico: in un e-commerce sarà dominato da home, categorie e schede prodotto, in una testata dagli articoli del giorno. Un intervento su un modello di pagina poco visitato può quindi migliorare molto il singolo URL e quasi per niente il dato complessivo. Viceversa, un rallentamento del solo modello di pagina più visitato sposta l’intera origine. Prima di valutare un risultato conviene sempre chiedersi quale quota del traffico quell’intervento ha realmente toccato.
Perché i miglioramenti arrivano gradualmente
Immaginiamo un intervento che porta l’LCP delle visite da mobile da 3,8 a 2,0 secondi al 75° percentile, rilasciato in un solo giorno e con un traffico costante. Il giorno dopo il rilascio, nella finestra c’è una sola giornata “nuova” e ventisette “vecchie”. Dopo una settimana il rapporto è un quarto contro tre quarti. Solo al ventottesimo giorno la finestra contiene esclusivamente visite successive all’intervento.
Il 75° percentile di una distribuzione mista non scende in modo intuitivo. Con distribuzioni realistiche l’andamento è simile a questo:
| Giorni dal rilascio | Visite nuove nella finestra | LCP p75 riportato |
|---|---|---|
| 0 | 0% | 3,8 s |
| 7 | 25% | 3,4 s |
| 14 | 50% | 3,0 s |
| 21 | 75% | 2,4 s |
| 28 | 100% | 2,0 s |
Il dato più importante è nella terza colonna: la soglia “buona” di 2,5 secondi viene superata solo intorno alla terza settimana, anche se dal primo giorno ogni visita è già veloce. Per due settimane abbondanti il report continuerà a mostrare una pagina “da migliorare”. Chi non conosce il meccanismo rischia di concludere che l’intervento non ha avuto effetto, di cercare cause inesistenti o, peggio, di annullare una modifica corretta.
Le regressioni seguono la stessa regola
L’inerzia vale in entrambe le direzioni, ed è qui che la finestra diventa pericolosa. Un nuovo plugin, uno script di marketing aggiunto in fretta o un aggiornamento del tema che peggiora l’INP non si vedono nei dati di CrUX il giorno dopo. La valutazione resta verde per giorni mentre una quota crescente di utenti vive un sito più lento. Quando la regressione diventa evidente nel report, il problema è in produzione da due o tre settimane, e la sua correzione richiederà altre quattro settimane per essere pienamente visibile.
In termini di business significa fino a due mesi in cui conversioni e visibilità possono essere penalizzate da un problema nato in un pomeriggio. Per questo CrUX non può essere l’unico strumento di controllo: è il giudice finale, ma arriva sempre in ritardo.
Quando i numeri cambiano senza toccare il codice
C’è un altro effetto che sorprende spesso: i valori di CrUX possono peggiorare o migliorare senza alcun rilascio. Il motivo è che la finestra misura le esperienze del pubblico reale, e il pubblico cambia. Una campagna social che porta molte visite da smartphone economici, un periodo di saldi con picchi di carico sul server, l’arrivo di traffico da un paese lontano dal datacenter o una stagionalità particolare modificano la distribuzione anche a parità di sito.
Leggere i dati senza conoscere il calendario commerciale porta a conclusioni sbagliate. Un peggioramento dell’LCP che coincide con una campagna su un pubblico nuovo non è necessariamente un problema tecnico; un miglioramento durante un mese di traffico prevalentemente desktop non è necessariamente merito di un intervento.
Search Console e la convalida delle correzioni
Il rapporto Core Web Vitals di Search Console eredita la stessa logica. Raggruppa gli URL con esperienze simili e assegna a ciascun gruppo lo stato “buono”, “da migliorare” o “scadente”. Quando si interviene su un problema è possibile avviare la convalida della correzione: da quel momento Search Console osserva i dati per un periodo di 28 giorni e solo alla fine conferma, o respinge, la risoluzione.
Il consiglio pratico è avviare la convalida solo quando la correzione è davvero completa e verificata, perché un nuovo rilascio durante il periodo di osservazione può rimettere in discussione il risultato. E, nel frattempo, evitare di interpretare come un fallimento le settimane in cui lo stato resta invariato.
Come lavorare con la finestra, invece che contro
La finestra di 28 giorni non è un ostacolo da aggirare, ma un vincolo di cui tenere conto nel metodo di lavoro. Nella pratica usiamo tre livelli di osservazione, ciascuno con il proprio tempo di risposta:
- Laboratorio, prima del rilascio. Lighthouse e i test sintetici verificano in pochi minuti che la modifica produca l’effetto atteso e non introduca regressioni evidenti. Non dicono nulla sugli utenti reali, ma sono il filtro più rapido.
- Monitoraggio degli utenti reali, dal giorno stesso. Un sistema RUM, anche basato sulla libreria open source
web-vitals, raccoglie le metriche dai browser dei visitatori, compresi quelli che CrUX non vede, e permette di confrontare le visite prima e dopo un rilascio già nelle prime ore. È il livello che intercetta le regressioni prima che diventino un problema di business. - CrUX, come verifica finale. Il dato ufficiale conferma il risultato quando la finestra si è rinnovata. La CrUX History API permette di seguirne l’andamento settimana per settimana e di confrontare finestre omogenee, senza affidarsi alla singola lettura di PageSpeed Insights.
A questi tre livelli si aggiunge un’abitudine semplice ma preziosa: annotare le date di ogni rilascio, di ogni nuovo script di terze parti e delle principali campagne. Quando una curva cambia pendenza, sapere che cosa è successo tre settimane prima fa risparmiare ore di indagine.
Come comunicarlo a chi decide
Buona parte delle frizioni nei progetti di performance nasce da un’aspettativa sbagliata: “abbiamo rilasciato, perché PageSpeed è ancora rosso?”. Chiarire in anticipo i tempi della finestra trasforma un momento di tensione in un passaggio previsto del progetto. Nei nostri piani di lavoro indichiamo sempre tre date: quella del rilascio, quella del primo riscontro sui dati RUM e quella, almeno quattro settimane dopo, in cui presenteremo il confronto ufficiale su CrUX.
Lo stesso vale per i risultati: un confronto corretto mette a paragone due finestre complete, una interamente precedente e una interamente successiva all’intervento, sullo stesso tipo di dispositivo. Confrontare uno screenshot di PageSpeed Insights del giorno prima con uno del giorno dopo, in un senso o nell’altro, non dimostra nulla.
In sintesi
I dati sul campo di CrUX sono la misura più affidabile dell’esperienza reale, ma descrivono sempre gli ultimi 28 giorni. Un miglioramento si vede per intero solo dopo quattro settimane e supera la soglia spesso intorno alla terza; una regressione resta nascosta per giorni e pesa sui risultati per settimane. Il pubblico, inoltre, cambia anche quando il codice non cambia, e una parte degli utenti, a partire da quelli su iPhone, non compare affatto.
Lavorare bene con questa finestra significa combinare laboratorio, monitoraggio degli utenti reali e CrUX, ciascuno con il proprio ruolo, e dare a chi decide aspettative chiare sui tempi. Il risultato arriva: basta sapere quando guardarlo.
