Cosa sono field data e lab data
Quando si parla di Core Web Vitals e performance WordPress, la prima distinzione fondamentale da fare è tra field data (dati reali) e lab data (dati sintetici). Sono due approcci completamente diversi alla misurazione delle prestazioni, e confonderli può portare a ottimizzazioni sbagliate.
I field data (o Real User Monitoring, RUM) sono metriche raccolte da utenti reali che visitano il tuo sito. Google li raccoglie attraverso il Chrome User Experience Report (CrUX), che alimenta PageSpeed Insights e Search Console. Questi dati riflettono l’esperienza effettiva dei visitatori: dispositivi diversi, connessioni variabili, estensioni browser, cache attive.
I lab data sono invece misurazioni sintetiche eseguite in un ambiente controllato. Strumenti come Lighthouse, PageSpeed Insights (nella sua componente lab), GTmetrix e WebPageTest simulano il caricamento della pagina con parametri fissi: stesso device, stessa connessione, nessuna cache.
Le differenze tecniche che contano
Le differenze tra i due approcci non sono solo filosofiche, ma hanno implicazioni pratiche immediate per chi gestisce siti WordPress client.
Campionamento e rappresentatività
I field data di CrUX richiedono un volume minimo di traffico per essere disponibili. Google raccoglie dati solo da utenti Chrome che hanno attivato la sincronizzazione e l’invio delle statistiche. Per vedere i dati a livello di singola pagina servono almeno 1.000 visite nei 28 giorni precedenti.
Questo significa che:
- Siti con poco traffico vedranno solo dati a livello di origine (dominio), non per singola URL
- Pagine nuove o poco visitate non avranno field data per settimane
- I dati sono sempre in ritardo di almeno 24-48 ore rispetto alle modifiche implementate
- Il campione è limitato agli utenti Chrome desktop e mobile (circa 65% del traffico web globale nel 2026)
I lab data invece sono disponibili immediatamente per qualsiasi URL, anche in staging o locale. Ogni test è deterministico e ripetibile.
Condizioni di misurazione
I field data riflettono condizioni reali e variabili:
- Utenti con connessioni 4G, 5G, WiFi veloce o lento, anche 3G in alcune regioni
- Dispositivi dal flagship Samsung all’iPhone vecchio di 4 anni, fino ad Android economici con 2GB di RAM
- Browser con estensioni (adblocker, privacy tool) che modificano il caricamento
- Cache già popolate per utenti di ritorno
- Orari diversi con carico server variabile
I lab data usano condizioni standardizzate:
- Lighthouse simula un Moto G4 (device Android del 2016) con CPU throttling 4x
- Connessione 4G simulata (1.6 Mbps download, 150ms RTT)
- Sempre cache vuota (cold cache)
- Nessuna estensione browser
- Server idealmente non sotto carico
Per un sito WordPress tipico, questo si traduce in lab data spesso peggiori dei field data, specialmente per LCP e FID/INP, perché l’ambiente di test è volutamente più stringente.
Core Web Vitals: quali metriche guardare dove
Non tutte le metriche CWV hanno lo stesso peso nei due contesti.
LCP (Largest Contentful Paint)
Nei field data, LCP cattura l’esperienza reale di caricamento. Su WordPress, valori tipici per un sito ben ottimizzato sono 1.8-2.2s su mobile, 1.2-1.6s su desktop. Fattori come CDN, cache browser e velocità hosting influenzano pesantemente questa metrica.
Nei lab data, LCP tende a essere più alto (2.5-3.5s è comune) a causa dell’ambiente throttled. È utile per identificare risorse bloccanti, ma non rappresenta l’esperienza reale se hai utenti su connessioni moderne.
INP (Interaction to Next Paint)
INP ha sostituito FID come metrica ufficiale a marzo 2024. Misura la reattività durante l’intera sessione utente, non solo la prima interazione.
Nei field data, INP è critico perché cattura interazioni reali: click su menu, apertura modale, form submit. Su siti WordPress con pagebuilder pesanti (Elementor, Divi), valori sopra 200ms sono comuni e problematici.
Nei lab data, INP è difficile da misurare accuratamente perché richiede interazioni simulate. Lighthouse usa script di simulazione, ma non può replicare comportamenti utente complessi. Strumenti come WebPageTest con script custom sono più affidabili.
CLS (Cumulative Layout Shift)
CLS è forse la metrica più consistente tra field e lab data, ma con differenze importanti.
Nei field data, CLS misura shift durante l’intera sessione di navigazione, inclusi scroll e interazioni. Caroselli, lazy loading mal implementato, e font non ottimizzati causano shift reali.
Nei lab data, CLS copre solo il caricamento iniziale (circa 5 secondi). Non cattura shift causati da interazioni utente o contenuti caricati dopo lo scroll. Un sito può avere CLS 0.05 in lab e 0.18 in field a causa di shift fuori viewport iniziale.
Quando fidarsi dei field data
I field data sono la fonte di verità per Google e dovrebbero essere la tua metrica principale per decisioni strategiche.
Fidati dei field data quando:
- Il sito ha almeno 1.000 visite mensili (soglia minima CrUX)
- Devi valutare l’impatto reale di ottimizzazioni già implementate
- Stai decidendo se un sito passa o meno i Core Web Vitals (Google usa questi per il ranking)
- Vuoi confrontare performance su device reali (75% mobile vs 25% desktop è tipico)
- Hai implementato strategie di cache aggressive e vuoi verificarne l’efficacia
Un caso pratico: abbiamo ottimizzato un sito WooCommerce per un cliente di AgencyPilot. Lab data mostrava LCP 3.2s, field data 2.1s. Perché? Gli utenti reali erano 70% desktop con buone connessioni, e la cache browser funzionava ottimamente per visite di ritorno. Abbiamo scelto di non aggiungere ulteriori ottimizzazioni aggressive.
Limitazioni dei field data
I field data hanno però dei limiti operativi importanti:
- Non sono disponibili per siti nuovi o in staging
- Latenza di 24-48 ore rende impossibile testare iterazioni rapide
- Non puoi controllare le variabili per test A/B precisi
- Dati aggregati su 28 giorni mascherano problemi intermittenti
- Nessun dettaglio su cause specifiche dei problemi (waterfall, JS blocking, etc.)
Quando usare i lab data
I lab data sono insostituibili per debugging, sviluppo e test pre-produzione.
Usa i lab data quando:
- Stai sviluppando un sito nuovo o testando in staging
- Hai bisogno di diagnosticare la causa specifica di un problema (waterfall, chain requests, render blocking)
- Vuoi testare rapidamente l’impatto di modifiche (plugin, tema, CDN)
- Devi confrontare configurazioni diverse in modo deterministico
- Il sito ha troppo poco traffico per avere field data affidabili
Per WordPress, lab data sono essenziali nella fase di sviluppo tema o quando testi plugin di caching. Puoi eseguire 10 test in un’ora con configurazioni diverse e avere risposte immediate.
Come interpretare discrepanze grandi
Se vedi differenze significative (>30%) tra lab e field data, indaga:
- Lab peggiore del field: normale se hai buon caching, CDN efficace, o utenti su device/connessioni migliori del test Lighthouse. Fidati del field.
- Field peggiore del lab: problematico. Possibili cause: server lento sotto carico reale, problemi specifici mobile, JavaScript che causa problemi solo su device reali, contenuti third-party variabili (ads, chat widget).
- Lab buono ma field assente: traffico insufficiente per CrUX. Usa lab come proxy, ma valida con RUM privato (Cloudflare Web Analytics, SpeedCurve).
Strategia pratica per agenzie
Per gestire decine di siti WordPress client, serve un approccio strutturato che combini entrambe le fonti.
Workflow consigliato
- Sviluppo/staging: lab data esclusivamente. Target: LCP <2.5s, CLS <0.1, TBT <200ms (proxy per INP). Usa Lighthouse CI per test automatici ad ogni deploy.
- Post-lancio (prime 4 settimane): monitoraggio lab settimanale manuale per assenza di field data. Controlla trend nei log analytics (bounce rate, time on page) come proxy.
- A regime: field data da Search Console come metrica primaria, controllata ogni 2 settimane. Lab data mensile per verificare che configurazione base sia stabile.
- Debug problemi: sempre lab data per diagnostica tecnica approfondita. WebPageTest con waterfall completo è gold standard.
- Reportistica cliente: field data quando disponibili (sono quelli che Google usa per ranking). Evidenzia sempre la fonte.
Tool essenziali per entrambi
Per monitorare efficacemente entrambe le tipologie di dati:
- Field data: Google Search Console (gratis, dati ufficiali), PageSpeed Insights API (automazione), CrUX API (dati raw), Cloudflare Web Analytics (alternativa privacy-friendly)
- Lab data: Lighthouse CI (automazione), WebPageTest (diagnostica approfondita), Chrome DevTools (debug locale), GTmetrix (monitoring schedulato)
- Hybrid: strumenti come DebugBear o SpeedCurve che combinano entrambi con alerting
In AgencyPilot stiamo integrando monitoring automatico che aggrega field data da Search Console API e confronta con test lab settimanali, allertando quando la discrepanza supera soglie configurabili. Questo permette di gestire 50+ siti client senza controlli manuali costanti.
FAQ
Quale dato usa Google per il ranking?
Google usa esclusivamente i field data da CrUX per il ranking nei risultati di ricerca. I lab data di PageSpeed Insights non hanno alcun impatto diretto sul posizionamento. Se il tuo sito ha field data “buoni” (75° percentile passa le soglie CWV), sei a posto per il ranking, anche se i lab data sono peggiori. Questo è esplicitamente confermato da Google nella documentazione ufficiale sui Page Experience signals.
Perché i miei lab data sono molto peggiori dei field data?
È una situazione comune e generalmente positiva. I lab data usano condizioni più stringenti (device lento, CPU throttling, connessione 4G simulata, cache vuota) per garantire che il sito funzioni anche negli scenari peggiori. Se i tuoi utenti reali hanno device più recenti, connessioni migliori, o beneficiano di cache browser, i field data saranno naturalmente migliori. Verifica la distribuzione device e connessione nei tuoi analytics per confermare.
Quanto traffico serve per avere field data affidabili?
CrUX richiede un minimo di circa 1.000 visite mensili da utenti Chrome per mostrare dati a livello di origine (dominio intero). Per dati a livello di singola URL servono almeno 1.000 visite su quella specifica pagina nei 28 giorni precedenti. Sotto queste soglie, Google non pubblica i dati. Per siti con traffico insufficiente, considera implementare una soluzione RUM privata come Cloudflare Web Analytics o New Relic Browser per avere comunque field data proprietari.
I field data includono bot e crawler?
No. CrUX raccoglie dati solo da utenti Chrome reali che hanno attivato la sincronizzazione e l’invio di statistiche di utilizzo. Bot, crawler (incluso Googlebot), traffico da browser non-Chrome, e utenti con privacy settings restrittivi non sono inclusi. Questo significa che i field data rappresentano un campione del tuo traffico reale, non la totalità. Tipicamente questo campione è rappresentativo, ma per siti con demografia utente particolare (es. alto uso Safari) potrebbe essere distorto.
Come testo INP in ambiente lab se richiede interazioni reali?
INP è difficile da misurare accuratamente in lab perché dipende da interazioni utente reali durante tutta la sessione. Lighthouse fornisce una stima basata su simulazioni, ma non è affidabile quanto i field data. Le alternative migliori sono: usare WebPageTest con script custom che simulano click e interazioni specifiche del tuo sito (menu, modali, form); in sviluppo, usa Chrome DevTools per misurare manualmente il tempo tra click e aggiornamento visivo durante test manuali; considera TBT (Total Blocking Time) in lab come proxy parziale per responsiveness. Per valutazione definitiva di INP, i field data sono indispensabili.