Lighthouse di Google

TL;DR — Lighthouse è uno strumento gratuito di Google che assegna a una pagina web un punteggio da 0 a 100 su aspetti come velocità e accessibilità. Esegue la pagina in un ambiente di laboratorio rallentato — un telefono simulato di fascia bassa su una rete lenta — quindi il punteggio è spesso più basso di quanto il tuo sito sembri. È un’ottima lista di cose da fare per i miglioramenti, ma un punteggio alto non ti fa salire nelle classifiche di Google.

Cos’è Lighthouse

Google Lighthouse è uno strumento gratuito e open-source del team responsabile di Chrome. Gli fornisci un URL, lo strumento esegue una serie di controlli sulla pagina e restituisce una pagella con punteggi in quattro aree: Performance (quanto velocemente si carica la pagina), Accessibilità (le persone con disabilità possono usarla?), Best Practices (buone pratiche generali per il web) e SEO (controlli di base per i motori di ricerca).

Ogni punteggio va da 0 a 100, con fasce di colore per capire a colpo d’occhio come sei andato:

• 0–49 è rosso — scarso
• 50–89 è arancione — da migliorare
• 90–100 è verde — buono

La prima cosa da capire

Lighthouse testa la tua pagina in condizioni finte e rallentate — circa un telefono di fascia media su una connessione 4G lenta. Lo fa di proposito, così può cogliere problemi che gli utenti reali su dispositivi più lenti sentirebbero.

Ecco perché puoi eseguire Lighthouse su un sito che si carica all’istante sul tuo portatile veloce e vedere comunque un punteggio Performance di 55. Non stai vedendo ciò che tu speri — stai vedendo ciò che un telefono economico su una rete mediocre sperimenterebbe. Informazioni utili, ma non la stessa cosa.

Lighthouse non è PageSpeed Insights (esattamente)

Probabilmente hai visto Lighthouse senza saperlo. Quando esegui una pagina attraverso PageSpeed Insights (lo strumento web su pagespeed.web.dev), i punteggi “lab” che mostra sono Lighthouse. PageSpeed Insights avvolge semplicemente Lighthouse e aggiunge un secondo set di numeri da utenti reali (chiamati dati di campo, o Chrome UX Report). Maggiori dettagli su questa distinzione nella versione Advanced.

Il grande mito da sfatare

Un punteggio Lighthouse perfetto non significa prime posizioni. Lighthouse è uno strumento utile per trovare cose da sistemare, ma il punteggio in sé non è ciò che Google usa per classificarti. I numeri di performance che Google considera davvero per il ranking provengono da utenti reali, non dal lab di Lighthouse. Inseguire un 100 è ottimo per i tuoi visitatori — semplicemente non aspettarti che sia un trucco per il ranking.

Vuoi i pesi delle metriche, perché i punteggi variano tra un’esecuzione e l’altra, e esattamente come Lighthouse si relaziona a Core Web Vitals? Passa alla scheda Advanced.

TL;DR — Lighthouse è uno strumento open-source e automatizzato che controlla una pagina in condizioni di laboratorio (Slow 4G simulato + rallentamento CPU 4×) e assegna punteggi a Performance, Accessibilità, Best Practices e SEO — PWA è stata rimossa in Lighthouse 12. Il punteggio Performance è una media ponderata di cinque metriche di laboratorio: TBT 30%, LCP 25%, CLS 25%, FCP 10%, Speed Index 10%. Fasce: 0–49 rosso, 50–89 arancione, 90–100 verde. Sono dati lab, quindi non sono il segnale di ranking di Core Web Vitals, non possono misurare INP come fa il campo (usa TBT come proxy), e variano da un’esecuzione all’altra. Alimenta la metà lab di PageSpeed Insights; PSI aggiunge dati di campo CrUX in cima. Un 100 non compra posizioni in classifica.

Cosa è realmente Lighthouse

La definizione in una riga di Google è la più chiara: “Lighthouse is an open-source, automated tool to help you improve the quality of web pages.” (traduzione) «Lighthouse è uno strumento open-source e automatizzato che aiuta a migliorare la qualità delle pagine web.» La meccanica è altrettanto semplice: “give Lighthouse a URL to audit, it runs a series of audits against the page, and then it generates a report on how well the page performed.” (traduzione) «Fornisci a Lighthouse un URL da controllare: esegue una serie di audit sulla pagina e genera un report sulle sue prestazioni.»

Oggi assegna punteggi a quattro categorie: Performance, Accessibilità, Best Practices e SEO. Se hai letto guide più vecchie che dicono cinque, sono obsolete — la categoria PWA è stata rimossa in Lighthouse 12 (intorno al 2024), seguendo i criteri aggiornati di installabilità di Chrome. Quindi se un post di un blog cita ancora un punteggio PWA, questo è il segno che è precedente alla versione attuale.

Il punto cruciale è una parola: laboratorio. Lighthouse carica la tua pagina in un ambiente controllato e simulato, non dai tuoi visitatori reali. Questo singolo fatto spiega quasi tutta la confusione che le persone hanno al riguardo.

Come funziona Lighthouse — le condizioni di laboratorio

Per impostazione predefinita, Lighthouse utilizza un rallentamento simulato e lo applica in modo aggressivo. Le impostazioni predefinite emulano approssimativamente un dispositivo mobile di fascia media su una connessione Slow 4G:

• Rete: il preset mobile Slow 4G — circa 150 ms di latenza e 1,6 Mbps in download / 750 Kbps in upload. Google lo descrive come emulazione della “the ~85th percentile mobile connection speed even when run on much faster fiber connections.” (traduzione) «velocità di connessione mobile intorno all’85° percentile, anche quando il test viene eseguito su connessioni in fibra molto più veloci».
• CPU: un moltiplicatore 4× CPU costante, che simula il processore di un telefono di fascia media sulla tua hardware desktop più veloce.

Questo è voluto. Lighthouse non sta cercando di dirti “questa è la velocità del tuo sito per tutti”. Sta sottoponendo la pagina a uno stress test contro una coorte più lenta della media, così che emergano problemi che il tuo laptop veloce nasconde. È il motivo per cui un sito che per te è istantaneo può ottenere un punteggio di 60 — tu sei un MacBook ad alte prestazioni su fibra; il test è un Android economico su una rete mediocre.

Una sfumatura da tenere a mente: il rallentamento simulato (quello predefinito) non è lo stesso del rallentamento applicato da DevTools. Quello simulato modella come la pagina sarebbe caricata in quelle condizioni basandosi su un’osservazione iniziale senza rallentamento; Google nota che questo approccio è “both very fast and deterministic.” (traduzione) «sia molto veloce sia deterministico». Il rallentamento applicato da DevTools agisce effettivamente sulle richieste, cosa che Google descrive come “not a sufficient model of a slow connection.” (traduzione) «un modello non sufficiente di una connessione lenta». Per misurazioni ripetibili, la modalità simulata predefinita è preferita.

Il punteggio Performance — come viene calcolato

Il punteggio Performance è “a weighted average of the metric scores.” (traduzione) «una media ponderata dei punteggi delle metriche». Questi pesi sono stati impostati in Lighthouse 10 e rimangono la tabella pubblicata attuale. Lighthouse 13 (rilasciato nel 2026) lo dice esplicitamente: ha consolidato una serie di audit di performance non valutati in “Insights” condivisi, usati anche dal pannello Performance di DevTools, ma afferma che non ci sono “no changes to the performance scoring” (traduzione) «modifiche al calcolo del punteggio Performance» in quella versione — il punteggio si basa sulle metriche sottostanti, non sui nomi degli audit, e quelle non sono cambiate. Cinque metriche compongono il punteggio:

Alcune cose da interiorizzare qui:

• TBT ha il peso maggiore (30%). È il proxy di laboratorio per la reattività. First Input Delay (FID) è sparita, e così anche metriche più vecchie come Time to Interactive e First Meaningful Paint — sono state ritirate.
• Speed Index è una metrica di Lighthouse, non una Core Web Vital. Conta ancora per il 10% del punteggio Performance di Lighthouse anche se non è una delle CWV rilevanti per il ranking di Google.
• Ogni metrica viene valutata su una curva, non su una soglia fissa. Lighthouse prende il valore grezzo (di solito in millisecondi) e lo mappa su una distribuzione log-normale costruita dai dati reali dell’HTTP Archive. I punti di controllo di Google: il 25° percentile di quei dati corrisponde a un punteggio di 50, e l’8° percentile a 90. Quindi un 90+ significa che sei approssimativamente nel top ~8% delle pagine su quella metrica — ecco perché gli ultimi punti sono così difficili da ottenere.
• Solo i punteggi delle metriche muovono il numero. Le sezioni Opportunities e Diagnostics del report sono indicazioni — ti dicono cosa correggere — ma non cambiano direttamente il punteggio Performance. Correggerle migliora le metriche, e le metriche muovono il punteggio.

Perché il tuo punteggio cambia tra le esecuzioni

Questo è il reclamo che sento più spesso: “L’ho eseguito due volte e ho ottenuto 84 e poi 91 — è rotto?” No. Google è esplicito: “Molta della variabilità nel tuo punteggio complessivo di Performance e nei valori delle metriche non è dovuta a Lighthouse.” Quando il numero salta, di solito sono le condizioni sottostanti a cambiare:

• Test A/B o annunci diversi serviti a ogni caricamento
• Cambiamenti di routing Internet — sia la tua rete locale che il percorso più lungo tra regioni che una richiesta compie
• Il server web stesso che risponde a velocità inconsistenti
• Test su hardware diverso (un desktop veloce vs. un laptop stanco) — il throttling della CPU è relativo alla macchina host, quindi un moltiplicatore “4×” significa qualcosa di diverso su una macchina veloce rispetto a una lenta
• Estensioni del browser che iniettano JavaScript o richieste di rete aggiuntive
• Software antivirus o altri processi in background che competono per le risorse

Per esempio: esegui lo stesso URL due volte e una passata capita di caricare una creatività pubblicitaria più pesante o di incontrare una risposta del server più lenta — gli audit di quella passata riflettono quel singolo caricamento, non un difetto che hai introdotto. Trattalo come un singolo campione, non come un verdetto.

Il modello mentale giusto, direttamente dalla documentazione, è trattare le prestazioni come una distribuzione di punteggi, piuttosto che un singolo numero. Eseguilo alcune volte — idealmente in una finestra di navigazione in incognito con le estensioni disattivate, su hardware e condizioni di rete corrispondenti — e guarda l’intervallo o la mediana, non un singolo risultato. Quando devi confrontare esecuzioni in seguito, annota la versione di Lighthouse, la modalità di esecuzione e il metodo di throttling insieme al punteggio; un punteggio di una versione o configurazione diversa non è un confronto alla pari, anche se il numero sembra simile.

Come eseguire Lighthouse in modo responsabile

Usa Lighthouse come un diagnostico controllato, non come un verdetto con un clic:

1. Testa l’URL esatto distribuito, non un modello diverso o una build locale non pubblicata.
2. Abbina il profilo del dispositivo, il metodo di throttling, la versione di Lighthouse, lo stato della cache, l’autenticazione, lo stato del consenso e la geografia del test per ogni confronto.
3. Inizia ogni esecuzione con una nuova navigazione. Ridimensionare una pagina desktop già caricata in un viewport mobile non riproduce una navigazione mobile, la sequenza di richieste o la risposta del server.
4. Esegui almeno tre volte. Riporta la mediana come risultato principale e conserva le singole esecuzioni, l’intervallo, i timestamp, gli avvisi e le tracce così che un valore anomalo sia visibile piuttosto che scartato silenziosamente.
5. Confronta prima e dopo nelle stesse condizioni. Se il servizio di test viene eseguito da un’altra regione, registralo: una maggiore distanza di rete o un edge CDN diverso possono cambiare i tempi del server e di caricamento senza una modifica al codice.
6. Controlla CrUX separatamente prima di fare un’affermazione sugli utenti reali. Una mediana di laboratorio migliore supporta “questa modifica ha migliorato questo test controllato”, non “gli utenti ora superano i Core Web Vitals”.

Le evidenze supportano conclusioni diverse:

Questo segue il modello basato sulla distribuzione di Lighthouse per la variabilità dei punteggi e mantiene intatta la distinzione laboratorio/campo. Evidence for this claim Lighthouse performance scores are weighted from lab metrics; 90–100 is good, 50–89 needs improvement, and 0–49 is poor. Scope: Current published Lighthouse performance-scoring model; metric weights can change by Lighthouse version. Confidence: high · Verified: 2026-07-14 Chrome Developers: Performance scoring

Lighthouse vs. PageSpeed Insights — la distinzione che conta

Questi vengono confusi costantemente, quindi sii preciso:

• Lighthouse è il motore. Produce dati di laboratorio — i punteggi Performance, Accessibility, Best Practices e SEO.
• PageSpeed Insights è un’interfaccia web che esegue Lighthouse e aggiunge i dati sul campo del Chrome UX Report (CrUX) — Core Web Vitals reali da utenti reali anonimizzati, mostrati quando ci sono abbastanza dati per l’URL o l’origine.

Quindi in PSI stai guardando due diversi set di dati fianco a fianco. La sezione “dati sul campo” in alto (utenti reali, da CrUX) è separata dalla sezione dei dati di laboratorio di Lighthouse sotto — e spesso sono in disaccordo. Quando qualcuno dice “il mio punteggio PageSpeed Insights”, quasi sempre intende il punteggio Performance di Lighthouse, non i dati sul campo.

Lighthouse e Core Web Vitals — come si relazionano

Lighthouse misura alcuni Core Web Vitals in laboratorio: riporta LCP e CLS come metriche di laboratorio. Ma c’è un limite rigido:

Lighthouse non può misurare INP come fa il campo. Interaction to Next Paint richiede interazioni utente reali per essere misurato — non c’è un utente reale che clicca in giro in un’esecuzione di laboratorio. Quindi Lighthouse usa Total Blocking Time come proxy di laboratorio per la reattività. TBT è correlato con INP, ma un TBT superato non garantisce un INP superato per gli utenti reali. Sono correlati, non la stessa cosa.

Questo è il cuore del divario tra laboratorio e campo. I dati sul campo — da CrUX, mostrati in Search Console e in cima a PageSpeed Insights — sono ciò che riflette gli utenti reali e ciò che alimenta i segnali di page experience di Google. I dati di laboratorio di Lighthouse servono per il debug e per individuare regressioni prima di pubblicare. La guida di Google è di “dare priorità ai dati sul campo per comprendere le esperienze utente reali” e usare “dati di laboratorio per il debug, testando le funzionalità prima della distribuzione.”

Dove eseguirlo

Stesso motore, superfici diverse:

• Chrome DevTools — integrato nel browser (il pannello Lighthouse). Ideale per pagine dietro un login, poiché puoi controllare pagine autenticate.
• PageSpeed Insights — l’interfaccia web senza installazione su pagespeed.web.dev; esegue Lighthouse e aggiunge i dati sul campo di CrUX.
• CLI — npm install -g lighthouse, poi lighthouse <url>; scriptabile.
• Modulo Node — importalo programmaticamente nei tuoi strumenti e nella tua CI.
• Lighthouse CI — la configurazione ufficiale per individuare regressioni di performance a ogni deploy. Il flusso di lavoro è collect → assert → upload: collect esegue Lighthouse più volte su un URL (tre esecuzioni di default) e prende il report mediano piuttosto che fidarsi di una singola esecuzione; assert controlla quel report rispetto a soglie che configuri — impostate su warn o error per categoria o metrica; upload salva il report così puoi tracciare le linee di tendenza tra le build. Tratta le soglie come la politica di regressione del tuo team, non come un verdetto sui dati sul campo o una garanzia di ranking — stanno individuando “questo è peggiorato”, non certificando “questo è veloce per gli utenti”.
• Estensione Chrome — esiste, ma DevTools è il percorso consigliato nel browser.

I flussi di lavoro CLI e Node richiedono un’installazione locale di Chrome per funzionare.

I miti da sfatare

• “Un punteggio Lighthouse di 100 = ranking migliori.” No. Il punteggio Performance è dato di laboratorio; non è un segnale di ranking. I segnali di page experience di Google usano i dati sul campo dei Core Web Vitals (CrUX), e anche quello è un segnale leggero tra molti — pertinenza e qualità dei contenuti dominano. Punta a un punteggio alto perché è buono per gli utenti, non perché è una leva di ranking.
• “Lighthouse = dati sul campo / ciò che gli utenti reali sperimentano.” No. Sono condizioni di laboratorio limitate peggiori di quelle che la maggior parte degli utenti reali vede. Gli utenti reali hanno cache calde, bfcache e dispositivi vari. Lighthouse è uno stress test da caso peggiore, non una lettura dell’utente medio.
• “PageSpeed Insights è Lighthouse.” In parte. PSI esegue Lighthouse per la sezione di laboratorio e aggiunge CrUX per la sezione sul campo. I numeri sul campo — quelli legati alla page experience — sono CrUX, non Lighthouse.
• “La categoria PWA conta ancora.” Non è vero. PWA è stata rimossa come categoria con punteggio in Lighthouse 12.

In conclusione

Lighthouse è uno degli strumenti gratuiti più utili nella SEO tecnica e nelle prestazioni web: un modo rapido e ripetibile per scoprire cosa rallenta una pagina e per proteggersi dalle regressioni nella CI. Basta tenerlo all’altitudine giusta: è una diagnosi di laboratorio, non un verdetto sull’esperienza degli utenti reali e non un punteggio di ranking. Usalo per trovare e correggere; usa i dati sul campo (CrUX, Core Web Vitals in Search Console) per giudicare se gli utenti reali stanno davvero avendo una buona esperienza.

Riepilogo AI

Una sintesi della versione Advanced:

• Lighthouse = strumento di audit automatizzato e open-source di laboratorio del team di Chrome. Fornisci un URL; esegue l’audit della pagina e assegna punteggi a Performance, Accessibilità, Best Practices, SEO. PWA è stato rimosso in Lighthouse 12 (~2024).
• Laboratorio, non campo. Carica la pagina con rallentamento simulato — circa Slow 4G + 4× CPU — di proposito, per evidenziare ciò che sperimentano dispositivi e reti più lenti. Ecco perché un sito “veloce” può ottenere un punteggio basso.
• Punteggio Performance = media ponderata di cinque metriche di laboratorio: TBT 30%, LCP 25%, CLS 25%, FCP 10%, Speed Index 10%. FID e First Meaningful Paint sono spariti.
• Bande: 0–49 rosso (scarso), 50–89 arancione (da migliorare), 90–100 verde (buono). I punteggi delle metriche sono mappati su una curva log-normale di HTTP Archive, quindi i punti più alti sono i più difficili. Opportunità/Diagnostica guidano le correzioni ma non cambiano direttamente il punteggio.
• I punteggi variano da esecuzione a esecuzione — annunci, test A/B, estensioni, condizioni di rete/server e carico della macchina (il throttling della CPU è relativo all’host). Trattalo come una distribuzione, non come un numero singolo; esegui in incognito con le estensioni disattivate, e registra la versione di Lighthouse e le impostazioni che hai usato.
• Lighthouse CI automatizza questo: raccoglie più esecuzioni (tre di default), prende la mediana e verifica le soglie del tuo team — una politica per catturare le regressioni, non un verdetto sui dati sul campo.
• Lighthouse ≠ PageSpeed Insights: PSI esegue Lighthouse (laboratorio) e aggiunge dati sul campo CrUX (utenti reali). Spesso sono in disaccordo.
• Lighthouse misura LCP/CLS in laboratorio ma non può misurare INP come fa il campo — usa TBT come proxy. I dati sul campo (CrUX) sono ciò che riflette gli utenti reali e alimenta i segnali di esperienza della pagina.
• Non è un segnale di ranking. Un 100 non significa posizionamenti migliori, e un punteggio di laboratorio basso non significa una brutta esperienza utente reale. Usa Lighthouse per il debug; usa i dati sul campo per giudicare.

Documentazione ufficiale

Documentazione di fonte primaria del team di Google Chrome.

• Panoramica di Lighthouse — cos’è Lighthouse, le categorie di audit e ogni modo per eseguirlo (DevTools, CLI, Node, PageSpeed Insights, estensione, Lighthouse CI).
• Punteggio delle prestazioni di Lighthouse — i pesi delle metriche, le bande di colore 0–49 / 50–89 / 90–100 e la curva di punteggio log-normale.
• Audit PWA di Lighthouse — contiene l’avviso di deprecazione per la categoria PWA rimossa.
• Rallentamento in Lighthouse (GitHub) — confronto tra modalità simulata e applicata, preset Slow 4G e moltiplicatore CPU 4×.
• Changelog di Lighthouse (GitHub) — le modifiche della v12: rimozione PWA, rimozione First Meaningful Paint, INP elevato.
• Calcolatore di punteggio Lighthouse — inserisci i valori delle metriche e vedi il punteggio Performance risultante; utile per impostare gli obiettivi.

Laboratorio vs. campo (web.dev)

• Metriche di prestazione incentrate sull’utente — perché i test di laboratorio “non sono necessariamente rappresentativi di come gli utenti reali sperimentano il tuo sito.”

Citazioni dalla fonte

Dichiarazioni ufficiali dalla documentazione di Lighthouse di Google. Ogni link è un link profondo che salta al passaggio citato nella pagina di origine.

Cos’è Lighthouse e come funziona

• “Lighthouse is an open-source, automated tool to help you improve the quality of web pages.” (traduzione) «Lighthouse è uno strumento open-source e automatizzato che ti aiuta a migliorare la qualità delle pagine web.» — developer.chrome.com, Panoramica di Lighthouse. Vai alla citazione
• “Give Lighthouse a URL to audit, it runs a series of audits against the page, and then it generates a report on how well the page performed.” (traduzione) «Fornisci a Lighthouse un URL da controllare: esegue una serie di audit sulla pagina e poi genera un report sulle prestazioni della pagina.» — developer.chrome.com, Panoramica di Lighthouse. Vai alla citazione

Come funziona il punteggio Performance

• “The Performance score is a weighted average of the metric scores.” (traduzione) «Il punteggio Performance è una media ponderata dei punteggi delle metriche.» — developer.chrome.com, punteggio delle performance di Lighthouse. Vai alla citazione
• “Once Lighthouse has gathered the performance metrics (mostly reported in milliseconds), it converts each raw metric value into a metric score from 0 to 100 by looking where the metric value falls on its Lighthouse scoring distribution.” (traduzione) «Una volta che Lighthouse ha raccolto le metriche delle performance (per lo più riportate in millisecondi), converte ogni valore grezzo della metrica in un punteggio da 0 a 100, osservando dove il valore della metrica si colloca nella sua distribuzione di punteggio.» — developer.chrome.com, punteggio delle performance di Lighthouse. Vai alla citazione
• Sulle fasce di punteggio: “0 to 49 (red): Poor” (traduzione) «Da 0 a 49 (rosso): Scarso» — con 50–89 arancione (da migliorare) e 90–100 verde (buono). Vai alla citazione

Perché i punteggi variano

• “A lot of the variability in your overall Performance score and metric values is not due to Lighthouse. When your Performance score fluctuates it’s usually because of changes in underlying conditions.” (traduzione) «Gran parte della variabilità nel punteggio Performance complessivo e nei valori delle metriche non è dovuta a Lighthouse. Quando il tuo punteggio Performance fluttua, di solito è a causa di cambiamenti nelle condizioni sottostanti.» — developer.chrome.com, punteggio delle performance di Lighthouse. Vai alla citazione

Lab vs. campo

• “While testing in the lab is a reasonable proxy for performance, it isn’t necessarily reflective of how actual users experience your site.” (traduzione) «Sebbene testare in laboratorio sia un proxy ragionevole per le performance, non riflette necessariamente come gli utenti reali vivono il tuo sito.» — web.dev, Metriche delle performance incentrate sull’utente. Vai alla citazione

Ottenere una lettura Lighthouse affidabile — lista di controllo

Prima di agire su un punteggio Lighthouse, assicurati che il numero significhi qualcosa:

• Eseguilo in una finestra di navigazione in incognito con le estensioni disattivate (le estensioni iniettano JS e alterano il punteggio).
• Eseguilo più volte e osserva l’intervallo — trattalo come una distribuzione, non come un singolo numero.
• Conferma di confrontare lo stesso fattore di forma ogni volta (mobile vs. desktop — il throttling è diverso).
• Sappi quale set di dati stai leggendo: lab (Lighthouse) vs. field (CrUX) in PageSpeed Insights. Non mescolarli.
• Per domande su ranking/esperienza di pagina, guarda i dati di campo (Core Web Vitals in Search Console / CrUX), non il punteggio lab di Lighthouse.
• Ricorda che Lighthouse non può misurare INP come fa il campo — TBT è un proxy, non una garanzia.
• Correggi partendo dalle liste Opportunities/Diagnostics, ma verifica la modifica osservando il movimento della metrica (solo le metriche cambiano il punteggio).
• Per misurazioni ripetibili in automazione, usa Lighthouse CI con budget piuttosto che controllare a occhio esecuzioni singole.
• Controlla cosa mostra la pagina al caricamento: banner cookie/consenso, stato di login e cache (fredda vs. calda) cambiano tutti gli audit che vengono eseguiti — scegli uno stato e sii coerente.
• Fai attenzione ai contenuti non deterministici — test A/B, annunci rotanti e altri script di terze parti possono servire un payload diverso a ogni esecuzione e far oscillare il punteggio indipendentemente da ciò che hai modificato.
• Lascia che la pagina finisca effettivamente di caricarsi prima di attivare l’audit (o usa una modalità che attenda) — interrompere un’esecuzione troppo presto interpreta male la pagina.
• Registra la versione di Lighthouse e le impostazioni di esecuzione (modalità, metodo di throttling, dispositivo) insieme al punteggio — un punteggio “uguale” da una versione o configurazione diversa non è realmente confrontabile.
• Ignora qualsiasi guida che assegni ancora un punteggio alla categoria PWA — è stata rimossa in Lighthouse 12.

Punteggio Performance di Lighthouse — cheat sheet

Le cinque metriche e i loro pesi (ponderazione Lighthouse 10)

Ritirate / rimosse: FID, Time to Interactive, First Meaningful Paint.

Fasce di colore del punteggio

Mappato su una curva log-normale di HTTP Archive: ~25° percentile → 50, ~8° percentile → 90. Gli ultimi punti sono i più difficili da conquistare.

Condizioni lab predefinite

• Rete: mobile Slow 4G (~150 ms di latenza, ~1,6 Mbps in download / 750 Kbps in upload)
• CPU: moltiplicatore 4× costante (mobile di fascia media su hardware desktop)
• Throttling: simulato di default (veloce, deterministico), non applicato da DevTools

Lighthouse vs. PageSpeed Insights

Fatti rapidi

• Categorie attuali: Performance, Accessibility, Best Practices, SEO (PWA rimossa in Lighthouse 12).
• Non è un segnale di ranking. Un 100 ≠ prime posizioni.
• Non può misurare INP come fa il campo — usa TBT come proxy.
• I punteggi variano da esecuzione a esecuzione — è normale.

Modi per eseguire Lighthouse (e strumenti correlati)

• Chrome DevTools — pannello Lighthouse — integrato in Chrome; ideale per controllare pagine dietro un login.
• PageSpeed Insights (pagespeed.web.dev) — nessuna installazione; esegue Lighthouse e aggiunge i dati sul campo CrUX.
• Lighthouse CLI — npm install -g lighthouse, poi lighthouse <url>; scriptabile, richiede un Chrome locale.
• Modulo Node di Lighthouse — integralo nei tuoi strumenti a livello di codice.
• Lighthouse CI (@lhci/cli) — esegui Lighthouse a ogni deploy, imposta budget e fai fallire la build in caso di regressioni. Lo strumento giusto per evitare che un punteggio scivoli silenziosamente.
• Calcolatore di punteggio Lighthouse (scorecalc) — inserisci i valori delle metriche per vedere il punteggio Performance risultante e impostare obiettivi realistici.
• Estensione Chrome — disponibile, ma DevTools è il percorso consigliato nel browser.

Per i dati reali (sul campo) da abbinare a questi strumenti di laboratorio, consulta il report Core Web Vitals in Google Search Console e la sezione sul campo CrUX in PageSpeed Insights.

Abitudini di Lighthouse che creano falsa fiducia

• Puntare a 100 come obiettivo di business. Un punteggio di laboratorio perfetto non è un boost di ranking e può distrarre dai Core Web Vitals sul campo e dai risultati reali degli utenti. Usa il report per trovare i colli di bottiglia, poi verifica che gli utenti ne abbiano beneficiato.
• Trattare una singola esecuzione come un verdetto. Lighthouse è un test simulato e varia naturalmente. Eseguilo più volte nelle stesse condizioni e cerca un pattern coerente piuttosto che reagire a un singolo punteggio.
• Chiamare il TBT di laboratorio la stessa cosa dell’INP sul campo. Il TBT è un utile proxy di laboratorio per il blocco del thread principale; l’INP misura le interazioni reali sul campo. Un buon TBT è una prova, non una conferma, che l’INP sia buono.
• Correggere ogni audit nell’ordine elencato. Le stime delle opportunità si sovrappongono e alcuni audit hanno poco impatto sul collo di bottiglia effettivo della pagina. Inizia dalla traccia, dalle metriche con peso maggiore e dalle risorse responsabili.
• Confrontare direttamente i punteggi mobile e desktop. I loro profili di emulazione e le distribuzioni di punteggio differiscono. Confronta cose simili.

Variazioni del punteggio Lighthouse tra le esecuzioni

Sintomo: La stessa pagina cambia fascia di colore senza un deploy.

Causa probabile: Risposta variabile del server, script di terze parti, carico della macchina condivisa o impostazioni di test diverse hanno modificato l’esecuzione sintetica.

Correzione e conferma: Abbina URL, profilo dispositivo, throttling, stato della cache e posizione del test; esegui più test; poi confronta la traccia mediana e i tempi delle metriche.

I Core Web Vitals sul campo passano ma Lighthouse è rosso

Sintomo: I dati sul campo di PSI passano mentre il punteggio Performance di Lighthouse è scarso.

Causa probabile: Le due sezioni misurano popolazioni diverse: CrUX riassume gli utenti reali nel tempo, mentre Lighthouse esegue un singolo caricamento di pagina simulato.

Correzione e conferma: Tratta la valutazione sul campo come il risultato per l’utente e usa la traccia di laboratorio per riprodurre e diagnosticare uno scenario con dispositivo lento. Conferma ogni correzione sia in esecuzioni di laboratorio ripetute sia nella prossima finestra di reportistica dei dati sul campo.

Lighthouse non può misurare l’INP

Sintomo: Il report mostra il TBT ma nessun valore INP di laboratorio.

Causa probabile: L’INP richiede interazioni reali durante una visita alla pagina; un’esecuzione Lighthouse solo di navigazione non ha una cronologia di interazioni rappresentativa.

Correzione e conferma: Usa TBT e la traccia per trovare attività lunghe in laboratorio, poi misura l’INP con dati sul campo o una registrazione incentrata sulle interazioni.

Un audit persiste dopo la correzione ovvia

Sintomo: Lighthouse segnala ancora una risorsa dopo che è stata ottimizzata o rimossa.

Causa probabile: Una risposta in cache, un altro template, una copia di terze parti o una richiesta diversa nella catena attiva ancora l’audit.

Correzione e conferma: Testa l’URL esatto pubblicato con cache fredda, apri l’elenco delle risorse interessate dell’audit e mappa ogni richiesta elencata al suo proprietario.

Mettiti alla prova: Google Lighthouse

Cinque domande rapide su dati e punteggio di Lighthouse. Scegli una risposta per ciascuna, poi controlla.

Risorse che meritano il tuo tempo

Ufficiali

• Panoramica di Lighthouse — il riferimento definitivo su cosa, come e dove eseguirlo.
• Punteggio delle prestazioni di Lighthouse — pesi, fasce e curva di punteggio.
• Documentazione sul rallentamento di Lighthouse (GitHub) — le condizioni di laboratorio in dettaglio.
• Calcolatore del punteggio Lighthouse — ricostruisci gli obiettivi delle metriche per un punteggio.
• Metriche di prestazione incentrate sull’utente — il confronto di Google tra laboratorio ed esperienza degli utenti reali.

Dove si colloca Lighthouse

• Abbina il punteggio di laboratorio con i dati di campo: il report Core Web Vitals in Google Search Console e la sezione CrUX di PageSpeed Insights. Il laboratorio trova i problemi; il campo ti dice se gli utenti reali li percepiscono.

Dal settore

• Differenze tra dati sul campo e dati di laboratorio (web.dev) — la spiegazione di Google su quando fidarsi dei numeri di laboratorio o sul campo e perché divergono.
• Core Web Vitals (web.dev) — il riferimento canonico su quali metriche CWV Lighthouse può e non può misurare, incluso il divario INP.
• Largest Contentful Paint (web.dev) — approfondimento sulle soglie LCP e sul perché le letture di laboratorio e campo spesso discordano.
• Lighthouse CI su GitHub — repository ufficiale e guida all’installazione per integrare Lighthouse in pipeline CI/CD automatizzate.
• HTTP Archive Web Almanac — Capitolo sulle prestazioni — dati annuali sui punteggi Lighthouse reali e sui tassi di superamento dei Core Web Vitals su milioni di pagine; utile per confrontare i tuoi punteggi con il web in generale.
• web.dev — Misura le prestazioni della pagina — il punto di partenza consigliato da Google per abbinare i risultati di Lighthouse con gli strumenti di dati di campo.

Numeri da citare

• Pesi del punteggio delle prestazioni (Lighthouse 10): TBT 30%, LCP 25%, CLS 25%, FCP 10%, Speed Index 10%. Fonte
• Fasce di punteggio: 0–49 rosso (scarso), 50–89 arancione (da migliorare), 90–100 verde (buono). Un 90 corrisponde all’incirca all’8° percentile dei dati HTTP Archive; un 50 al 25° percentile. Fonte
• Rallentamento predefinito: mobile Slow 4G (~150 ms di latenza, ~1,6 Mbps in download) più un moltiplicatore CPU 4× — emulando all’incirca il ~85° percentile della connessione mobile. Fonte
• Categorie: quattro oggi (Performance, Accessibility, Best Practices, SEO) — PWA rimossa in Lighthouse 12 (~2024). Fonte

Cronologia modifiche