C'è un momento, in ogni progetto, in cui lo sviluppatore dice "il sito è veloce, ho testato" e il cliente dice "sul mio telefono ci mette una vita". Hanno ragione entrambi. Stanno guardando dati diversi.

La performance web ha due principali fonti di misurazione, lab data e field data, e rispondono a domande diverse. Confonderle porta a sistemare la cosa sbagliata.

Lab data: l'esperimento controllato

Un test di lab esegue il sito in condizioni note e controllate. L'esempio classico è Lighthouse: apri DevTools di Chrome, clicchi "Lighthouse", scegli un profilo dispositivo (Mobile, Desktop), e lo strumento simula quel device, throttla la rete a una banda e a una latenza fissa, misura come la pagina si carica.

Gli altri strumenti di lab funzionano allo stesso modo: PageSpeed Insights (che fa girare Lighthouse sui server di Google), WebPageTest, GTmetrix, Calibre.

L'output è una lista di metriche (LCP, INP, CLS, TBT, FCP, TTI) più un punteggio da 0 a 100. Il punteggio è una media pesata che Google aggiorna di tanto in tanto. Un 95 di oggi non significa la stessa cosa di un 95 del 2022.

A cosa serve il dato di lab:

  • Confrontare due versioni dello stesso sito in condizioni identiche. La mia ottimizzazione è servita? Test prima, test dopo, guardo la differenza.
  • Catturare regressioni in sviluppo. Lancia Lighthouse a ogni deploy, fai fallire la build se il punteggio scende più di X.
  • Diagnosticare cosa è lento su una specifica pagina. La vista a cascata mostra quali risorse bloccano il rendering.
  • Riprodurre un problema segnalato da un utente. Con DevTools puoi fare il match del suo profilo dispositivo e ricreare la lentezza.

A cosa non serve:

  • Predire cosa vedono gli utenti veri. Il tuo laptop è più veloce dell'80% dei telefoni. La connessione del tuo ufficio è più veloce del 60% delle reti mobili. I test in lab applicano throttling, ma il throttling non è la stessa cosa di un telefono di 4 anni fa con la cache piena di robaccia.
  • Dirti se Google considera veloce il tuo sito ai fini del ranking. Google ranka sui dati di field, non sui dati di lab.
  • Misurare l'impatto delle interazioni a lungo termine. Un test che dura 30 secondi non può catturare come si comporta la pagina dopo 5 minuti di scroll.

Field data: cosa vedono gli utenti veri

Il field data, chiamato anche RUM (Real User Monitoring), viene raccolto dagli utenti reali con i loro dispositivi, le loro reti, le loro location, lo stato del loro browser. È sporco, vario, riflette la realtà.

Le due fonti principali:

CrUX (Chrome User Experience Report): Google raccoglie dati di performance dagli utenti reali di Chrome che hanno fatto opt-in (quasi tutti, di default). I dati sono anonimi, aggregati per URL o per origin, pubblicati. PageSpeed Insights li mostra sotto "Origin Summary" o "URL Performance", espressi come 75esimo percentile sugli ultimi 28 giorni. È il dataset che Google usa per i Core Web Vitals come segnale di ranking.

RUM self-hosted: strumenti tipo SpeedCurve, Sentry, DataDog, Cloudflare Web Analytics installano un piccolo snippet JavaScript sul sito che riporta le metriche di performance per ogni page load a un endpoint di raccolta. Hai più granularità (segment per paese, dispositivo, pagina, gruppo A/B) ma lo paghi.

A cosa serve il field data:

  • Sapere se gli utenti veri sono soddisfatti. Il 75esimo percentile è la soglia che usa Google; il 75% dei tuoi utenti ha un'esperienza almeno così buona.
  • Cogliere problemi che il lab non vede: un widget di terze parti che carica lento solo sugli ISP residenziali italiani, un font che fallisce su iOS Safari 14, un server lento solo alle 9 del lunedì mattina.
  • Capire la distribuzione. L'utente mediano potrebbe stare bene, il 90esimo percentile potrebbe stare a fuoco. Il lab ti dà un numero; il field ti dà una curva.

A cosa non serve:

  • Iterazione rapida. Il field data si aggiorna in giorni o settimane. Non puoi fare un cambio e vedere l'effetto 30 secondi dopo.
  • Pagine con poco traffico. Il field data ha bisogno di abbastanza campioni per essere statisticamente significativo. Una pagina con 50 visite al mese non comparirà su CrUX.
  • Diagnosticare una causa specifica. Il field data ti dice "il 5% degli utenti ha un LCP lento". Non ti dice perché. Per quello torni al lab.

Come si usano entrambi

Il workflow sano alterna lab e field.

Il field trova il problema: Search Console mostra che l'LCP al 75esimo percentile è 4,2 secondi. Hai un problema.

Il lab lo diagnostica: riproduci la lentezza in DevTools con throttling 4G e profilo Moto G4. Lighthouse dice che l'elemento LCP è l'immagine hero, che l'immagine pesa 2,3 MB e che è caricata come background CSS.

Sistemi: converti in AVIF a 220 KB, sposti dal background CSS a un vero <img> con fetchpriority="high".

Il lab valida il fix: Lighthouse ora mostra LCP a 1,2s nelle stesse condizioni. Conferma che il cambio va nella direzione giusta.

Il field conferma nel tempo: in 7-10 giorni l'LCP di field al 75esimo percentile scende a 2,1s. Il fix ha funzionato per gli utenti veri, non solo sul tuo laptop.

Se salti il field, ottimizzi cose che agli utenti veri non interessano. Se salti il lab, ottimizzi al buio.

Una confusione frequente: il punteggio non è la metrica

Lighthouse ti dà un punteggio (un numero da 0 a 100, riassunto da un cerchio colorato) e le metriche sottostanti (LCP in secondi, CLS come frazione, ecc.). La gente si fissa sul punteggio e ignora le metriche.

Il punteggio è una media pesata decisa da Google. I pesi cambiano nel tempo. Le metriche sono quello che conta per l'utente. Un sito può fare 95 in lab e avere un LCP di 4 secondi in field, perché le condizioni di lab sono favorevoli e la realtà no.

Se devi tenere d'occhio un solo numero, tieni d'occhio l'LCP di field al 75esimo percentile, l'INP di field al 75esimo percentile, il CLS di field al 75esimo percentile. Sono quelli che Google usa per ranking. Il punteggio Lighthouse è per uso interno, non per la SEO.

Strumenti da aprire davvero

Se questa settimana fai solo questo, apri questi tre:

  1. PageSpeed Insights: incolla il tuo URL, scorri fino a "Origin Summary" o "URL Performance" se il tuo traffico basta. Leggi le metriche di field.
  2. Search Console, sezione Esperienza. Stessi dati, strutturati per gruppo di URL, con storico.
  3. Lighthouse in DevTools: prendi l'URL con l'LCP di field peggiore, lancia un test di lab, guarda la cascata per trovare la causa.

L'ordine conta. Il field ti dice se hai un problema e dove. Il lab ti dice perché. Usa entrambi.