Guide

Lanci Lighthouse, ottieni 100, pubblichi. Un mese dopo Search Console ti dice che quella stessa URL non supera la valutazione Core Web Vitals. Nel frattempo non si è rotto nulla, e nessuno dei due strumenti mente. Rispondono a domande diverse.

La documentazione di Google traccia la linea senza ambiguità. I dati di laboratorio sono **«dati raccolti in un ambiente controllato, con impostazioni di dispositivo e di rete predefinite»**. I dati sul campo sono **«dati raccolti dagli utenti reali che visitano il tuo sito»**, quello che si chiama anche Real User Monitoring; per i Core Web Vitals provengono dal Chrome User Experience Report.

I dati sul campo sono una distribuzione, non un numero

La conseguenza più importante è strutturale, ed è quella che sfugge più spesso: i dati sul campo **non sono un numero unico**. Sono una distribuzione. Gli strumenti che pubblicano un punteggio sul campo dei Core Web Vitals prendono il **75° percentile** dei caricamenti reali su una finestra mobile di **28 giorni**. La tua prova in laboratorio è un caricamento, su un dispositivo, su una connessione. Il tuo punteggio sul campo è ciò che tre quarti dei tuoi visitatori hanno vissuto o meglio, nell'arco di un mese.

Questo da solo spiega gran parte dello scarto. Ma le cause cambiano a seconda della metrica, e sapere quale stai guardando indica dove cercare.

Perché divergono, metrica per metrica

Per il [Largest Contentful Paint](/it/articles/cos-e-il-largest-contentful-paint-lcp), lo stesso elemento LCP può non essere il medesimo. Dimensione del viewport, contenuti personalizzati, test A/B, font installati e frammenti di URL possono tutti cambiare quale elemento conta come il più grande. Anche lo stato della cache differisce: una prova di laboratorio parte a freddo, mentre chi torna può avere risorse in cache. E il ripristino dalla cache avanti/indietro è quasi istantaneo per un utente reale, cosa che nessuna prova di laboratorio riproduce.

• Laboratorio: ambiente controllato, dispositivo e rete predefiniti, una esecuzione, riproducibile
• Campo: utenti reali, dispositivi reali, connessioni reali, pubblicato al 75° percentile su 28 giorni mobili
• Metriche solo di laboratorio: Speed Index, Total Blocking Time (diagnostiche, non Core Web Vitals)
• Stato della cache, cache avanti/indietro, viewport e personalizzazione differiscono tra i due
• Google: quando si dispone di entrambi, dare priorità ai dati sul campo

Per l'[Interaction to Next Paint](/it/articles/cos-e-inp-interaction-to-next-paint) la ragione è più profonda: una prova di laboratorio **non può sapere quando un utente deciderà di interagire**, né con che cosa. Per questo esiste il [Total Blocking Time](/it/articles/cos-e-il-total-blocking-time) come approssimazione dal lato laboratorio, e sempre per questo tale approssimazione è imperfetta. Il TBT non cattura il ritardo di 300 ms al tocco che colpisce ancora le pagine prive di un viewport ottimizzato per il mobile.

Per il [Cumulative Layout Shift](/it/articles/che-cos-e-il-cls), il laboratorio di norma osserva solo gli spostamenti sopra la piega e durante il caricamento. Gli utenti reali scorrono. Immagini e iframe a caricamento differito senza dimensioni riservate spostano la pagina molto dopo che la prova di laboratorio ha smesso di guardare, e le pubblicità come i blocchi personalizzati si posano in modo diverso per ciascuno.

Quale pubblica davvero Google

Su quale agire, allora? Google risponde in modo netto: **se disponi di entrambi, sono i dati sul campo a dover guidare le tue priorità.** Sono quelli che riporta la valutazione Core Web Vitals, e i Core Web Vitals fanno parte del segnale di esperienza sulla pagina. Un punteggio di laboratorio verde è un'ipotesi. I dati sul campo sono il verdetto.

Il laboratorio non è inutile, è diagnostico

Questo non rende inutile il laboratorio, e crederlo è l'errore speculare. I dati sul campo ti dicono **che** un problema esiste e per chi; non ti diranno quale script ha bloccato il thread principale. Gli strumenti di laboratorio sono riproducibili e attribuibili, ed è esattamente ciò che serve una volta che il campo ha indicato una pagina. Alcune metriche, tra cui lo [Speed Index](/it/articles/cos-e-lo-speed-index) e il Total Blocking Time, esistono solo in laboratorio e sono diagnostiche per costruzione.

Il punto cieco: quando CrUX non ha nulla su di te

Vale la pena conoscere un limite prima di affidarsi interamente al campo. CrUX raccoglie solo da Chrome, e non da Chrome su iOS né dalle WebView Android. Conta solo gli utenti che hanno attivato l'invio delle statistiche di utilizzo, sincronizzano la cronologia di navigazione e non hanno impostato una passphrase di sincronizzazione. La pagina deve essere pubblicamente rilevabile e deve superare un numero minimo di visitatori che Google deliberatamente non pubblica. Una pagina sotto quella soglia semplicemente non ha dati sul campo, e un sito giovane o con poco traffico può non averne da nessuna parte. È questa la lacuna che colma il tuo Real User Monitoring: le tue pagine, ogni browser, dalla prima visita e non dalla millesima.

L'ordine che funziona

L'ordine pratico è quindi: leggere il campo per decidere **dove** lavorare, usare il laboratorio per scoprire **che cosa** cambiare, e tornare al campo ventotto giorni dopo per verificare che si sia davvero mosso. Tutto il resto è ottimizzare un numero che nessuno vive. Per le leve concrete, una volta che sai dove scavare, comincia dal [migliorare i tuoi Core Web Vitals](/it/articles/migliorare-i-core-web-vitals).