Una delle domande che ricevo più spesso è: «Lighthouse mi dà 95, ma il rapporto sui Core Web Vitals dice che le pagine sono lente. Chi ha ragione?». Hanno ragione entrambi, perché misurano cose diverse. Capire la differenza tra dati di laboratorio e dati sul campo evita settimane di lavoro nella direzione sbagliata.
Che cosa sono i dati di laboratorio
Un test di laboratorio carica la pagina una volta, in condizioni controllate: un dispositivo simulato, una CPU rallentata di un certo fattore, una rete con banda e latenza fissate, una cache vuota. Strumenti come Lighthouse, il pannello Performance di DevTools o servizi di test sintetici rientrano in questa famiglia.
I vantaggi sono chiari:
- ripetibilità: le stesse condizioni permettono di confrontare una modifica con la versione precedente;
- diagnosi: si ottengono la cascata delle richieste, le tracce del main thread, i suggerimenti;
- disponibilità immediata: si può testare una pagina che nessuno ha ancora visitato, anche in ambiente di prova.
Il limite è che quella singola visita simulata non rappresenta nessun utente reale in particolare.
Che cosa sono i dati sul campo
I dati sul campo, detti anche RUM (Real User Monitoring), vengono raccolti dai browser delle persone che visitano davvero il sito. Esistono due fonti principali: il Chrome User Experience Report, che aggrega in modo anonimo i dati degli utenti di Chrome che hanno acconsentito e alimenta i rapporti dei motori di ricerca, e la raccolta in proprio tramite uno script nella pagina.
I dati sul campo riflettono la varietà reale: telefoni vecchi e nuovi, Wi-Fi domestici e reti mobili in movimento, cache piene o vuote, visitatori che arrivano da una pubblicità o che tornano per la decima volta. Il valore che conta per i Core Web Vitals è il 75° percentile: significa che tre visite su quattro devono essere almeno così veloci.
Perché i numeri divergono
Le ragioni tipiche per cui laboratorio e campo raccontano storie diverse:
- Dispositivi: il profilo mobile di Lighthouse simula un telefono di fascia media; il pubblico reale può avere dispositivi molto più lenti o molto più veloci.
- Cache: il laboratorio parte quasi sempre a cache vuota; molti utenti reali tornano e trovano già in cache CSS, font e script.
- Interazioni: l'INP richiede interazioni reali. Un test che si limita a caricare la pagina non tocca nulla, quindi in laboratorio si usa al massimo il Total Blocking Time come indicatore indiretto.
- Durata della visita: il CLS sul campo include spostamenti durante lo scorrimento e dopo il caricamento, che il test iniziale non vede.
- Pagine diverse: il rapporto sul campo raggruppa spesso URL simili; il test misura un solo indirizzo.
- Contenuti personalizzati: banner dei consensi, utenti autenticati, varianti di test A/B cambiano la pagina rispetto a quella vista dallo strumento.
Quale usare, e quando
La regola che seguo è semplice: i dati sul campo dicono se c'è un problema, quelli di laboratorio aiutano a capire perché.
| Domanda | Fonte |
|---|---|
| Gli utenti hanno un'esperienza buona? | Campo |
| Quale metrica è fuori soglia? | Campo |
| Quale risorsa rallenta l'LCP? | Laboratorio |
| Questa modifica ha migliorato le cose? | Laboratorio, poi conferma sul campo |
| Quale pagina o modello è peggiore? | Campo, segmentato per URL |
Un punteggio Lighthouse di 100 non è un obiettivo in sé: è un riassunto pesato di metriche di laboratorio. Ottimizzare per il numero, ignorando i dati reali, porta a volte a interventi cosmetici che non spostano l'esperienza delle persone.
Rendere il laboratorio più realistico
Si può avvicinare il test alla realtà:
- impostare il rallentamento della CPU in base ai dispositivi più comuni del proprio pubblico, che si ricavano dagli analytics;
- testare anche con cache calda, ricaricando la pagina una seconda volta;
- eseguire più ripetizioni e guardare la mediana, perché un singolo test può variare parecchio;
- testare le pagine nello stato reale, con il banner dei consensi visibile e, se serve, da utente autenticato.
Il ritardo dei dati sul campo
C'è un'ultima differenza da tenere presente. I dati aggregati del Chrome User Experience Report si basano su una finestra mobile di 28 giorni: dopo una correzione, il miglioramento appare gradualmente nell'arco di alcune settimane. Chi raccoglie i propri dati RUM vede invece l'effetto quasi subito, ed è uno dei motivi per cui conviene farlo.
In sintesi
- I test di laboratorio sono ripetibili e diagnostici; i dati sul campo rappresentano gli utenti reali.
- Divergono per dispositivi, cache, interazioni, durata della visita e personalizzazioni.
- Il campo dice se c'è un problema, il laboratorio aiuta a trovarne la causa.
- Il punteggio Lighthouse è un riassunto, non l'obiettivo finale.
- I dati aggregati reagiscono in settimane; un RUM proprio mostra subito l'effetto delle modifiche.
