Lighthouse vs field data: verifica che il fix abbia funzionato

Lighthouse dice che è risolto. Perché Search Console è ancora rossa?

Lighthouse carica la pagina una sola volta, su un telefono simulato, e rileva LCP e CLS per quel caricamento. I Core Web Vitals sono field data: il 75° percentile di 28 giorni di visite reali con Chrome, su telefoni e reti veloci e lenti, con cache vuota e piena, compreso ogni click. Per questo un fix può passare su Lighthouse oggi e metterci quattro settimane a comparire in Search Console. Confronta tre run di Lighthouse, poi segui i field data.

Come eseguire Lighthouse per confrontare prima e dopo?

Esegui Lighthouse nello stesso modo prima e dopo la modifica:

1. Svuota le cache. Svuota la cache del plugin di caching e della CDN dopo la modifica, altrimenti Lighthouse testerà la vecchia pagina.
2. Scegli un solo strumento e usa sempre quello. Senza codice: PageSpeed Insights, nella scheda Mobile. Da sviluppatore: il pannello Lighthouse in Chrome DevTools con Device impostato su Mobile, in una finestra in incognito, perché le estensioni del browser aggiungono i propri script alla pagina.
3. Testa l'URL che aveva la segnalazione. Se la modifica riguarda il template di prodotto, testa una pagina prodotto.
4. Esegui il test tre volte e prendi il risultato intermedio.
5. Guarda prima la segnalazione e la relativa metrica. La segnalazione passa sotto Passed audits e la metrica corrispondente (LCP, CLS, Total Blocking Time) scende. Il punteggio viene per ultimo.

Perché il punteggio cambia se non è cambiato nulla?

Ogni run è un singolo caricamento, e non esistono due caricamenti identici: il server risponde più o meno velocemente, la rete varia, e annunci, banner di consenso e test A/B possono cambiare da una run all'altra. Su una delle mie pagine di test il primo testo o immagine (FCP) è comparso 1,5 s prima in una run rispetto a un'altra, e su una seconda pagina il punteggio è uscito a 96 o 80 senza che fosse cambiato nulla. Qualche punto in più dopo un fix dice poco, finché non confronti il valore intermedio di tre run.

Sei run consecutive sullo stesso URL, www.bbc.com, hanno totalizzato 38, 44, 41, 73, 60 e 53 nell'arco di due minuti. Lighthouse 13.5.0, mobile, throttling simulato come in PageSpeed Insights.

Registrare una traccia in DevTools

Apri la pagina in Chrome, apri i DevTools e vai al pannello Performance. In Capture settings (l'icona dell'ingranaggio), imposta Network su Slow 4G e CPU su 4x slowdown, valori simili a ciò che Lighthouse simula su mobile, poi clicca su Record e ricarica. La scheda Insights nella barra laterale elenca gli stessi insight di Lighthouse, ciascuno con le richieste e gli elementi correlati. Prima di avviare la registrazione, il pannello mostra LCP, CLS e INP in tempo reale (l'INP non appena clicchi nella pagina). Clicca su Set up sotto Field metrics per affiancare i dati CrUX dei visitatori reali per lo stesso URL.

Perché Lighthouse dice una cosa e Search Console un'altra?

Lighthouse fornisce lab data: un singolo caricamento della pagina su un telefono di fascia media simulato con connessione 4G lenta e cache vuota. Si ferma poco dopo il caricamento, quindi non scorre la pagina, non fa tap e non apre una seconda pagina. Ottieni LCP e CLS per quel singolo caricamento, e nessun valore di INP, perché l'INP ha bisogno di un visitatore che clicchi.

I field data sono ciò che Chrome ha misurato sui visitatori reali: telefoni veloci e lenti, reti buone e scarse, una prima visita a cache vuota e la decima con tutto in cache, con utenti che scorrono, fanno tap e passano da una pagina all'altra. Google li raccoglie nel Chrome UX Report (CrUX), tramite gli utenti Chrome su Android e desktop che condividono le statistiche d'uso. I Core Web Vitals sono quelle visite negli ultimi 28 giorni, calcolate per ogni metrica al 75° percentile (p75): tre visite su quattro hanno ottenuto almeno questo risultato.

Per il posizionamento Google si basa sui field data. Lighthouse serve a capire perché una pagina è lenta e se una modifica è efficace. Quando i due non concordano, è perché hanno misurato caricamenti diversi. Un punteggio verde su Lighthouse con field data scarsi indica spesso telefoni più lenti della simulazione, risposte lente ai click (INP) o contenuti che si spostano mentre i visitatori scorrono la pagina. Un punteggio rosso con buoni field data significa spesso che i visitatori hanno telefoni e reti più veloci del 4G lento di Lighthouse, e tornano sul sito con i file già in cache.

Un report di PageSpeed Insights per www.bbc.com su mobile, 26 ottobre 2026. Le visite reali superano tutti e tre i Core Web Vitals con un LCP di 1,2 s; la run di Lighthouse nello stesso report ottiene 37 con un LCP di 9,5 s.

PageSpeed Insights mostra i field data per l'URL testato se riceve abbastanza visite, oppure per l'intero sito sotto Origin se non ne ha a sufficienza. Search Console raggruppa gli URL simili e valuta ogni gruppo in base alla sua metrica peggiore.

Dove vedere i dati reali dei visitatori?

Quattro strumenti gratuiti mostrano CrUX, i field data usati da Google:

• PageSpeed Insights: la sezione in alto, "Scopri cosa sperimentano i tuoi utenti reali", con LCP, INP e CLS al p75 per gli ultimi 28 giorni, per l'URL o per l'origin.
• Search Console: il report Core Web Vitals, per mobile e desktop, mostra quali gruppi di URL simili risultano scadenti sull'intero sito.
• CrUX History report: una barra a settimana per il sito o per un URL, utile per seguire il trend.
• DevTools: il pannello Performance affianca gli stessi numeri al tuo caricamento (basta configurarlo una volta).

Un sito con troppe poche visite da Chrome non ha dati CrUX: PageSpeed Insights mostra "No Data" nella sezione in alto. CoreDash misura comunque quelle visite.

CoreDash: quale pagina, quale elemento

CrUX, i field data di Google, fornisce un solo p75 per URL o per sito. CoreDash, il real user monitoring che ho sviluppato, è uno script sulle tue pagine che misura ogni visita e individua l'elemento dietro a ogni LCP, INP e CLS. Puoi filtrare per pagina, dispositivo ed elemento, e qualsiasi modifica si riflette nella serie temporale fin dalle visite successive. Inserisci lo script prima di modificare qualsiasi cosa, così da poter confrontare prima e dopo.

CoreDash, acme-pagespeed.com, mobile, p75 per pagina: una pagina ha un CLS di 0,92 dove le altre hanno 0.

Quanto tempo ci vuole prima che Search Console mostri il fix?

PageSpeed Insights e Search Console mostrano gli ultimi 28 giorni, e quella finestra temporale scorre ogni giorno. Su PageSpeed Insights i dati hanno circa due giorni di ritardo, su Search Console qualche giorno in più. A due settimane dal fix, metà delle visite in quella finestra risale ancora a prima della modifica. Dopo quattro settimane conterrà solo visite successive al fix. L'articolo sulla finestra di 28 giorni, giorno per giorno riporta la cronologia completa.

Search Console, report Core Web Vitals, mobile, 26 ottobre 2026: ultimo aggiornamento il 21 ottobre.

Il CrUX History report mostra la stessa finestra per settimana: ogni barra copre i 28 giorni precedenti, quindi servono circa quattro barre perché l'effetto di un fix si veda per intero.

CrUX History report per ado-goldkante.de, telefoni, LCP: quota settimanale di caricamenti validi, da migliorare e scadenti. Dopo una modifica a metà agosto la quota di validi sale nell'arco di quattro barre dal 59% al 76%, 83%, 90% e 93%, e il p75 di LCP passa da 3,6 s a 1,5 s.

Quando il fix è online, apri la segnalazione nel report Core Web Vitals di Search Console e clicca su Start Tracking (chiamato anche Validate fix). In questo modo Search Console avvia la propria verifica di 28 giorni su tutti gli URL con quel problema, basandosi sugli stessi field data. Durante l'elaborazione lo stato è Started, poi passa a Looking good non appena tutti gli URL controllati fino a quel momento risultano a posto. Si conclude con Passed quando nessun URL presenta più il problema per 28 giorni, o con Failed se anche uno solo lo presenta ancora; in tal caso correggi l'errore e clicca su Start new validation.

Come sapere se un fix ha funzionato per i visitatori reali?

Controlla in questo ordine, dal più rapido al più lento:

1. La modifica è online. Guarda il sorgente della pagina o cerca il file o l'header nel pannello Network dei DevTools. Se vedi ancora la vecchia versione, un plugin di caching o la CDN sta servendo la pagina precedente.
2. Lighthouse passa. Mobile, tre run, prendi quella intermedia (come sopra): la segnalazione passa sotto Passed audits.
3. Arriva ai visitatori. In CoreDash, fin dalle visite successive: filtra per la pagina o il template modificato, imposta il dispositivo su mobile e segui la metrica giorno per giorno insieme all'elemento responsabile.
4. CrUX si allinea. I field data in PageSpeed Insights e le barre nel CrUX History report si muovono un po' alla volta. L'effetto completo si vede dopo quattro settimane (perché ci vuole così tanto).
5. Search Console conferma. Nel report Core Web Vitals, clicca su Start Tracking sulla segnalazione e attendi lo stato Passed.

Lighthouse passa, sono trascorse quattro settimane e i field data non si sono ancora mossi? Allora le visite lente sono quelle che Lighthouse non effettua mai: un telefono più economico, un click lento, uno shift a metà pagina. In una Core Web Vitals power hour analizzo i field data insieme a te, gruppo di pagine per gruppo di pagine, finché non individuiamo quale pagina e quale elemento frenano il tuo p75.