Lighthouse verde e Search Console rosso: non è un bug

In sintesi

• Lighthouse misura in un ambiente controllato: rete stabile, dispositivo di riferimento, condizioni ideali che il cliente reale raramente incontra.
• CrUX, il Chrome User Experience Report, prende dati da milioni di visite vere: reti lente, telefoni datati, schede grafiche sotto sforzo con contenuti 3D.
• Approvare un progetto 3D solo su Lighthouse significa validare uno scenario che il mercato non riproduce mai.
• Search Console mostra il divario reale tra pagine: è lì che si vede se il configuratore 3D penalizza il traffico da mobile o da zone con connessione debole.

Un configuratore 3D che prende 95 su Lighthouse e poi viene segnalato da Search Console per Core Web Vitals insufficienti non ha un bug. Ha due strumenti che misurano scene diverse: uno testa in laboratorio, l’altro osserva utenti reali. Il divario tra i due numeri è la fotografia di quanto il pubblico reale sia più eterogeneo del banco di prova su cui è stato validato il progetto.

Perché il 3D amplifica il problema

Un sito con testo e immagini statiche tollera bene le differenze tra laboratorio e mondo reale: il carico di lavoro sul dispositivo è basso, quindi il margine di errore resta piccolo. Con i contenuti tridimensionali cambia tutto, perché ogni fotogramma viene calcolato dalla GPU del dispositivo dell’utente, non dal server.

Un configuratore 3D per un e-commerce di arredamento può girare fluido sul portatile di sviluppo dove gira Lighthouse, e diventare pesante su uno smartphone di fascia media appena arriva traffico reale. Nel test di laboratorio il modello 3D è spesso già in cache sulla macchina, mentre l’utente reale lo scarica da zero, magari su rete 4G instabile. Lo stesso identico asset produce un LCP (Largest Contentful Paint) sotto la soglia di 2,5 secondi considerata buona da Google in un caso, e un’attesa ben oltre i 4 secondi, soglia che classifica l’esperienza come scarsa, nell’altro.

Se il criterio di accettazione del progetto è “Lighthouse verde”, si sta collaudando qualcosa che non racconta nulla dell’esperienza vissuta da chi apre la pagina dal telefono con quattro tacche di campo e la batteria al 20%.

Cosa dicono davvero CrUX e Search Console

Lighthouse apre la pagina una volta, su una macchina di riferimento, in condizioni di rete simulate a tavolino. CrUX raccoglie invece dati aggregati da milioni di visite reali fatte con Chrome, con le reti e i dispositivi che le persone hanno davvero in tasca. Search Console mostra questi dati nella sezione Core Web Vitals, organizzati per gruppo di pagine simili tra loro.

Il blog Chrome Developers, nella documentazione dedicata a CrUX aggiornata nel 2024, specifica che il report include solo utenti che hanno attivato la sincronizzazione del browser, la cronologia web e le statistiche di utilizzo, ed esclude dispositivi con permessi diversi. Un altro limite tecnico: CrUX pubblica un dato pubblico per URL o per origine solo quando raccoglie un numero minimo di sessioni qualificate nel periodo di riferimento; sotto quella soglia, il dato semplicemente non compare in Search Console, e per pagine di nicchia questo può voler dire settimane di silenzio dopo il lancio.

Ed è qui che si apre un punto scomodo, spesso ignorato in questo tipo di discorsi: anche Search Console non è un oracolo neutro. Il campione CrUX esclude di default Safari e Firefox, quindi qualunque quota di traffico che arriva da iPhone con Safari o da desktop con Firefox non entra mai nel calcolo. Trattare i numeri di Search Console come la verità assoluta contro cui giudicare Lighthouse è un errore speculare a quello che si vuole correggere: si sostituisce un banco di prova limitato con un altro, più realistico ma comunque parziale.

Il valore sta nello scarto tra le due misurazioni, non nell’assolutizzare una delle due fonti.

L’esempio che chiarisce tutto

Il caso del configuratore 3D per l’arredamento mostra bene dove si annida l’errore di metodo. In fase di sviluppo, il modello 3D viene testato sulla stessa macchina che lo ospita: la cache locale nasconde il costo reale del primo caricamento, e Lighthouse restituisce un punteggio che misura, di fatto, quanto è veloce quella macchina, non quanto sarà veloce l’esperienza del cliente. Il problema emerge solo quando arriva traffico vero, spesso con settimane di ritardo rispetto al lancio, nel momento in cui Search Console comincia a popolare il report Core Web Vitals con un campione sufficiente di sessioni mobile.

A quel punto il dato che conta non è il punteggio medio, ma la distribuzione per tipo di dispositivo: se il peggioramento si concentra sui telefoni di fascia media o bassa, la causa è quasi sempre il costo di calcolo grafico scaricato sul client, non un problema di rete o di server. Nessuno ha collaudato la scena che il cliente vive davvero, fuori dall’ambiente in cui il progetto è stato approvato.

Chi deve guardare quale numero

Chi approva budget e tempistiche, che sia il titolare, il direttore operativo o il project manager, non deve diventare esperto di metriche tecniche. Deve sapere quale domanda fare. “Lighthouse è verde” non basta per un progetto con contenuti 3D: è una risposta parziale che nasconde proprio la parte più rischiosa del lavoro. La domanda giusta è cosa dice Search Console sulle stesse pagine, nelle ultime settimane, e per quale tipo di dispositivo.

Questo non rende Lighthouse inutile. Resta lo strumento giusto per individuare colli di bottiglia durante lo sviluppo, prima che il traffico reale arrivi a testare tutto sul campo. Ma il collaudo finale, quello che decide se un progetto entra in produzione o torna in lavorazione, deve appoggiarsi ai dati di campo, letti con la consapevolezza dei loro limiti, non al banco di prova.

L’azione concreta da inserire nel processo di approvazione è una sola: nessun rilascio di contenuti 3D senza aver confrontato il punteggio Lighthouse con l’estratto Core Web Vitals di Search Console per lo stesso indirizzo, anche su una finestra di traffico breve. Se i due numeri raccontano storie diverse, il problema non è nel codice: è nel criterio con cui lo si sta giudicando.

Domande correlate

Perché Lighthouse e Search Console danno risultati diversi?

Lighthouse simula un unico scenario controllato in laboratorio, mentre Search Console aggrega dati CrUX raccolti da utenti reali con dispositivi e connessioni eterogenee. Con contenuti 3D lo scarto si amplifica, perché il carico di calcolo grafico varia molto tra un portatile da sviluppo e uno smartphone medio.

Quanto tempo serve prima che Search Console mostri dati affidabili?

Search Console richiede tipicamente alcune settimane di traffico continuo prima di popolare il report Core Web Vitals con un campione statisticamente utile, dato che CrUX pubblica un dato pubblico solo sopra una soglia minima di sessioni qualificate. Per pagine con volumi bassi, come un configuratore 3D di nicchia, il segnale può risultare parziale o assente nei primi giorni dopo il lancio, e va interpretato con cautela anche quando compare.

Come si simulano condizioni reali prima del lancio di un 3D?

Gli strumenti di sviluppo del browser permettono di attivare il rallentamento simulato di rete e processore, impostando profili che replicano una connessione instabile e un hardware di fascia media. Questo avvicina il test di laboratorio alle condizioni che il traffico reale mostrerà poi in Search Console, pur senza sostituirle.

Il problema riguarda solo siti con contenuti 3D?

No, ma i contenuti 3D amplificano il divario perché spostano il carico di lavoro dal server al dispositivo dell’utente, rendendo la potenza hardware reale una variabile decisiva. Su siti testuali lo scarto tra laboratorio e campo esiste comunque, ma resta generalmente più contenuto.

Fonti:

• Core Web Vitals e performance (accesso settembre 2026)