Google Lighthouse è uno strumento open source di Google che esegue audit automatici sulle pagine web per individuare problemi relativi a performance, accessibilità, best practice tecniche e alcuni requisiti SEO di base.
Il punto importante, però, è capire cosa rappresentano davvero i risultati di Google Lighthouse.
Un punteggio Lighthouse non è il voto complessivo del tuo sito, non misura tutta l’esperienza degli utenti reali e soprattutto non è un punteggio di ranking Google. Lighthouse lavora principalmente in laboratorio: crea condizioni di test controllate, osserva ciò che accade durante il caricamento della pagina e restituisce metriche, insight e controlli tecnici utili per capire dove intervenire. La stessa documentazione ufficiale lo presenta come uno strumento per usare gli audit falliti come indicatori delle possibili aree di miglioramento. (developer.chrome.com)
È proprio qui che Lighthouse diventa utile: non quando insegui il 100, ma quando lo usi per passare da un problema generico a una causa tecnica verificabile.
Cos’è Google Lighthouse e a cosa serve davvero
Google Lighthouse analizza una singola pagina attraverso una serie di test automatici e costruisce un report organizzato per categorie.
Le aree principali che incontrerai normalmente sono:
- Performance, dedicata a caricamento, rendering e blocchi che rallentano la pagina;
- Accessibility, che intercetta numerosi problemi rilevabili automaticamente relativi all’accessibilità;
- Best Practices, con controlli su sicurezza, tecnologie obsolete, errori browser e qualità tecnica;
- SEO, che verifica alcuni requisiti tecnici essenziali per crawling, indicizzazione e comprensione della pagina.
Queste categorie rispondono a domande differenti. Avere 100 in Performance, per esempio, non significa automaticamente avere una pagina accessibile; allo stesso modo, un SEO score elevato non dimostra che il contenuto soddisfi l’intento di ricerca o che possa posizionarsi bene.
Cosa Lighthouse può misurare e cosa non può dirti
Lighthouse è molto efficace quando deve analizzare ciò che può osservare automaticamente in una determinata esecuzione.
Può individuare, per esempio:
- risorse che rallentano il caricamento;
- JavaScript che blocca il main thread;
- problemi relativi a LCP o CLS;
- immagini e risorse inefficienti;
- errori tecnici rilevati dal browser;
- problemi di contrasto o semantica accessibile rilevabili automaticamente;
- assenza di alcuni elementi SEO essenziali;
- configurazioni tecniche che meritano attenzione.
Non può invece stabilire da solo:
- se il contenuto è migliore di quello dei concorrenti;
- se risponde davvero all’intento dell’utente;
- se il sito è completamente accessibile;
- se l’esperienza reale di tutti gli utenti è buona;
- se una modifica aumenterà conversioni o traffico;
- se una pagina salirà nelle SERP.
Questa distinzione evita uno degli errori più comuni: trasformare un audit automatico in un verdetto sul sito.
Come eseguire un audit con Google Lighthouse
Per la maggior parte degli utenti il punto di partenza migliore è Chrome DevTools.
Apri la pagina da analizzare in Chrome, quindi:
- apri gli strumenti per sviluppatori;
- seleziona la scheda Lighthouse;
- scegli le categorie e il tipo di test disponibili;
- avvia Analyze page load;
- attendi la generazione del report.
Google raccomanda questo workflow rispetto all’estensione Chrome nella maggior parte dei casi, anche perché DevTools permette di lavorare con pagine locali e contenuti che richiedono autenticazione. L’estensione continua a esistere: non è corretto definirla semplicemente “deprecata”. (developer.chrome.com)
CLI e Node.js per analisi più avanzate
Quando devi ripetere il test, analizzare più URL o integrare Lighthouse in un processo di sviluppo, puoi passare alla riga di comando.
L’installazione globale avviene tramite npm:
npm install -g lighthouse
Per analizzare una URL:
lighthouse https://www.example.com/
E per vedere le opzioni disponibili:
lighthouse --help
La CLI permette di controllare maggiormente configurazione, output e automazione. Lighthouse può inoltre essere utilizzato come modulo Node, soluzione più adatta quando l’audit entra direttamente nella logica di un’applicazione o di una pipeline.
Come leggere un report Google Lighthouse senza inseguire il punteggio
Il numero più evidente del report è anche quello che rischia più facilmente di essere interpretato male.
Il Performance Score è una sintesi costruita a partire dalle metriche misurate durante quell’esecuzione. Non deriva dalla semplice quantità di problemi presenti nelle sezioni successive.
In particolare, la documentazione di Lighthouse chiarisce che sono principalmente le metriche a contribuire al Performance Score; insight e diagnostica aiutano a capire come migliorare quelle metriche, ma non aggiungono o sottraggono direttamente punti come una checklist. (developer.chrome.com)
Questo cambia il modo in cui conviene usare il report.
Se Lighthouse segnala dieci problemi, non significa necessariamente che devi correggerli in ordine dal primo all’ultimo. Devi prima chiederti quale problema sta influenzando la metrica che realmente ti interessa.
Come viene costruito il Performance Score
Il Performance Score di Google Lighthouse deriva attualmente da cinque metriche principali:
| Metrica | Peso nel Performance Score |
|---|---|
| First Contentful Paint (FCP) | 10% |
| Speed Index | 10% |
| Largest Contentful Paint (LCP) | 25% |
| Total Blocking Time (TBT) | 30% |
| Cumulative Layout Shift (CLS) | 25% |
I singoli valori vengono trasformati in score utilizzando distribuzioni statistiche basate su dati HTTP Archive e poi combinati secondo i rispettivi pesi. Lighthouse 13 ha modificato diversi audit e insight, ma Google ha specificato che tale passaggio non ha modificato il meccanismo del Performance Score. (developer.chrome.com)
Da qui deriva anche un effetto poco intuitivo: migliorare una metrica già eccellente può richiedere molto lavoro per guadagnare pochissimi punti.
Per questo 93 → 100 non è automaticamente una priorità migliore di correggere un problema reale vissuto dagli utenti.
Perché il punteggio Lighthouse può cambiare
Un test Lighthouse non produce una misura immutabile.
Fra un’esecuzione e l’altra possono cambiare:
- dispositivo e potenza della CPU;
- routing della rete;
- script pubblicitari o test A/B;
- estensioni del browser;
- software di sicurezza;
- contenuti o risorse dinamiche.
Google suggerisce quindi di considerare le prestazioni come una distribuzione di risultati, non come un singolo numero assoluto. (developer.chrome.com)
Se esegui un test e ottieni 82, poi 88 e successivamente 84, non significa necessariamente che il sito sia migliorato, peggiorato e migliorato di nuovo in pochi minuti.
Per confrontare due modifiche servono condizioni il più possibile coerenti e, quando il risultato è importante, più esecuzioni.
Le metriche Performance misurate da Google Lighthouse
Le metriche del normale audit di caricamento descrivono aspetti differenti dell’esperienza.
First Contentful Paint
FCP indica quando il browser mostra il primo contenuto proveniente dal DOM: testo, immagine, SVG o altro elemento pertinente.
È soprattutto un segnale dell’inizio della risposta visiva della pagina. Non indica che il contenuto principale sia già disponibile.
Largest Contentful Paint
LCP misura quando viene renderizzato il più grande elemento di contenuto rilevante visibile nella viewport iniziale.
Può essere un’immagine hero, un grande blocco testuale o un altro elemento. Se vuoi affrontare diagnosi e ottimizzazione in modo specifico, trovi il processo completo nella guida al Largest Contentful Paint.
LCP è particolarmente utile perché mette in relazione rete, server, priorità delle risorse e rendering: un valore alto non significa automaticamente che “l’immagine è troppo pesante”.
Speed Index
Lo Speed Index valuta quanto rapidamente il contenuto visibile compare durante il caricamento.
Due pagine possono completare il caricamento in tempi simili ma costruire l’interfaccia in modo molto diverso. Una può mostrare subito buona parte del contenuto e completare successivamente i dettagli; l’altra può lasciare lo schermo quasi vuoto più a lungo.
È questa progressione visiva che Speed Index cerca di rappresentare.
Total Blocking Time
TBT misura quanto tempo il main thread rimane bloccato da attività sufficientemente lunghe da impedire una risposta tempestiva agli input durante la fase osservata.
È spesso una delle metriche più sensibili alla quantità e al costo del JavaScript eseguito durante il caricamento.
Un TBT alto è quindi un segnale utile per cercare:
- long task;
- JavaScript eccessivo;
- esecuzione di script di terze parti;
- rendering complesso;
- lavoro non necessario sul main thread.
Cumulative Layout Shift
CLS misura gli spostamenti inattesi del layout.
Un’immagine che compare senza spazio preventivamente riservato, un banner inserito sopra il contenuto o un font che altera improvvisamente le dimensioni del testo possono spostare ciò che l’utente stava osservando o tentando di selezionare.
CLS aiuta a diagnosticare questa instabilità.
Perché il normale audit Lighthouse non misura INP come i dati reali
Qui serve una distinzione importante.
INP, Interaction to Next Paint, è uno dei tre Core Web Vitals, insieme a LCP e CLS. Ma il normale audit Lighthouse che carica una pagina senza effettuare interazioni reali non può osservare la distribuzione delle interazioni dell’utente necessaria a calcolare INP.
Per questo nei normali test lab viene utilizzato soprattutto TBT come proxy diagnostico della reattività, senza considerarlo un sostituto di INP. Google lo specifica chiaramente nella documentazione Web Vitals. (web.dev)
C’è però un’eccezione utile: Lighthouse può entrare in workflow e user flow in cui vengono effettivamente eseguite interazioni. In quel contesto è possibile produrre misurazioni INP di laboratorio legate proprio alle interazioni effettuate durante il test. (developer.chrome.com)
Il modello mentale corretto è quindi:
audit di caricamento standard → TBT per diagnosticare potenziali problemi di responsiveness
interazioni reali / field data → INP per capire cosa vivono gli utenti
Lighthouse e Core Web Vitals non sono la stessa cosa
È probabilmente la distinzione più importante dell’intera guida.
I Core Web Vitals descrivono l’esperienza reale degli utenti attraverso:
- LCP;
- INP;
- CLS.
Google li definisce metriche di real-world user experience. (developers.google.com)
Google Lighthouse, nel suo normale utilizzo, lavora invece soprattutto in laboratorio.
Quindi:
Lighthouse lab data ≠ Core Web Vitals field data
Non è una contraddizione se i risultati sono diversi.
Puoi avere:
- ottimo Performance Score Lighthouse ma INP reale problematico;
- test Lighthouse mediocre ma Core Web Vitals reali buoni;
- LCP ottimo nel lab e peggiore per utenti con reti o dispositivi differenti;
- un problema che emerge soltanto dopo una specifica interazione che il normale page-load audit non esegue.
Il laboratorio ti aiuta soprattutto a riprodurre e diagnosticare. I dati sul campo ti dicono invece che cosa sta realmente succedendo alla popolazione degli utenti.
Lighthouse score e ranking Google: qual è il rapporto reale
Anche qui conviene eliminare un equivoco frequente su Google Lighthouse.
Google conferma che i Core Web Vitals sono utilizzati dai suoi ranking system, ma chiarisce contemporaneamente che non esiste un singolo “page experience signal” e che ottenere risultati eccellenti nei tool non garantisce le prime posizioni. (developers.google.com)
Questo significa che:
Lighthouse Performance Score ≠ ranking score
e anche:
Lighthouse SEO Score ≠ ranking score
Portare una pagina da 70 a 95 può corrispondere a miglioramenti tecnici importanti, ma non esiste una formula per trasformare quei 25 punti in un aumento di posizioni.
La rilevanza del contenuto, l’intento, la qualità delle informazioni, l’architettura, i link e gli altri sistemi utilizzati da Google continuano a esistere indipendentemente da Lighthouse.
Il modo più sensato di usare lo strumento in ottica SEO è quindi diagnosticare problemi tecnici che possono compromettere crawling, fruibilità o esperienza, non ottimizzare il numero in quanto tale.
Cosa controllano SEO, Accessibility e Best Practices
Performance è la categoria più osservata, ma Lighthouse non nasce come semplice speed test.
SEO: un controllo tecnico di base, non un SEO audit completo
Gli audit SEO verificano alcuni requisiti che una pagina dovrebbe soddisfare per essere correttamente leggibile e accessibile ai motori di ricerca.
Possono rilevare, per esempio, l’assenza della meta description o problemi nel file robots.txt. Nel caso della meta description, Lighthouse controlla essenzialmente che esista e non sia vuota: non valuta la qualità persuasiva o strategica della descrizione. (developer.chrome.com)
Questa è una buona rappresentazione del limite dell’intera categoria.
Lighthouse può dirti:
questo requisito tecnico non è soddisfatto.
Non può dirti:
questa pagina è la risposta migliore alla query.
Un vero audit SEO comprende molto altro: intent, indicizzazione, architettura, internal linking, contenuti, query reali, concorrenza, dati strutturati, performance organica e molti altri livelli.
Accessibility: gli audit automatici non bastano
Lighthouse utilizza controlli automatici molto utili per intercettare problemi di accessibilità e calcola il relativo score attraverso audit con pesi differenti. (developer.chrome.com)
Ma l’accessibilità non può essere certificata interamente da un test automatico.
Ci sono situazioni che richiedono test manuali, navigazione da tastiera, screen reader e valutazione del contesto. La stessa documentazione Lighthouse separa infatti gli audit automatici dai manual checks.
Un 100 in Accessibility significa quindi che gli audit automatici previsti sono stati superati, non che qualunque persona, con qualunque tecnologia assistiva e in qualunque scenario, avrà necessariamente un’esperienza perfetta.
Best Practices: errori, sicurezza e tecnologie web
La categoria Best Practices intercetta diversi problemi relativi alla qualità tecnica della pagina.
Può segnalare, fra le altre cose:
- errori registrati nella console;
- librerie JavaScript note come vulnerabili;
- API o tecnologie obsolete;
- configurazioni non consigliate;
- aspetti collegati alla sicurezza e al comportamento del browser.
Nelle versioni recenti Lighthouse include anche informazioni sulle Baseline Features, che aiutano a capire lo stato di disponibilità delle funzionalità web utilizzate nella pagina. (developer.chrome.com)
Anche qui, però, il principio resta lo stesso: un audit automatico segnala un problema osservabile; non sostituisce un security audit o una code review completa.
Google Lighthouse vs PageSpeed Insights: quale usare
Lighthouse e PageSpeed Insights vengono spesso confrontati come se fossero due alternative.
In realtà lavorano bene insieme.
PageSpeed Insights utilizza Lighthouse per la parte di laboratorio, ma può mostrare anche dati CrUX relativi agli utenti reali.
Questo crea due livelli nello stesso report:
Field data → cosa stanno vivendo gli utenti reali
Lighthouse lab data → cosa accade durante il test controllato
Lighthouse eseguito direttamente da DevTools o CLI è particolarmente utile quando:
- stai sviluppando o modificando una pagina;
- vuoi ripetere rapidamente un test;
- devi diagnosticare una regressione;
- vuoi analizzare una pagina autenticata o locale;
- devi integrare il controllo nel workflow di sviluppo.
PageSpeed Insights è invece molto comodo quando vuoi verificare rapidamente se esistono dati reali CrUX e confrontarli con l’analisi di laboratorio.
Non devi decidere quale dei due strumenti “ha ragione”. Devi capire quale fenomeno sta misurando ciascuno.
Come trasformare un report Lighthouse in interventi utili
Un buon workflow con Google Lighthouse non parte dal colore dello score.
Parte dalla domanda:
Qual è il problema che sto cercando di risolvere?
Se hai un LCP elevato, devi individuare cosa consuma il tempo: risposta del documento, scoperta tardiva della risorsa, download o ritardo di rendering.
Se il problema è TBT, devi osservare main thread, long task e JavaScript.
Se il problema è CLS, devi cercare gli elementi che cambiano posizione.
Questo approccio evita la classica sequenza:
Lighthouse segnala qualcosa → applico automaticamente la raccomandazione.
Una raccomandazione può essere tecnicamente valida ma poco prioritaria per la situazione che stai analizzando.
Ripeti i test in condizioni coerenti
Quando vuoi confrontare prima e dopo una modifica:
- usa lo stesso ambiente;
- evita estensioni che interferiscono con la pagina;
- mantieni coerente il tipo di audit;
- esegui più test;
- osserva le metriche, non soltanto lo score complessivo;
- annota ciò che hai modificato.
Se il risultato cambia di pochi punti ma LCP, TBT e CLS rimangono sostanzialmente stabili, probabilmente non hai davanti un cambiamento rivoluzionario.
Se invece correggi la causa tecnica e la relativa metrica migliora in maniera consistente su più esecuzioni, hai un segnale molto più utile.
Verifica il risultato anche sui dati reali
Il lavoro non dovrebbe terminare con Lighthouse.
Per problemi che riguardano l’esperienza reale:
field data → individua il problema
lab data → diagnostica la causa
modifica → corregge
nuovi lab test → verificano tecnicamente
nuovi field data → confermano nel tempo l’effetto sugli utenti
È un processo più lento dell’inseguimento del punteggio, ma produce informazioni molto migliori.
Lighthouse CI: prevenire le regressioni invece di scoprirle dopo
Quando un progetto cambia frequentemente, ripetere manualmente lo stesso audit diventa poco pratico.
Qui entra in gioco Lighthouse CI.
Google lo indica esplicitamente come soluzione per prevenire regressioni nei siti. (developer.chrome.com)
Puoi integrarlo nel processo di continuous integration e controllare automaticamente determinate pagine quando viene pubblicato nuovo codice.
Il vantaggio non è semplicemente “avere Lighthouse automatico”.
Il vantaggio è poter intercettare scenari come:
- un nuovo script aumenta sensibilmente il TBT;
- una modifica alla hero peggiora LCP;
- un componente introduce layout shift;
- una release fa fallire un audit che prima passava.
In questo modo Lighthouse smette di essere uno strumento aperto occasionalmente dopo un problema e diventa parte del controllo qualità del progetto.
Le soglie vanno però interpretate come guardrail interni, non come requisiti universali del web.
Cosa è cambiato nelle versioni recenti di Lighthouse
Una parte consistente delle guide a Google Lighthouse ancora presenti online descrive una struttura che non corrisponde più allo strumento attuale.
La categoria PWA è stata rimossa
Per anni Lighthouse è stato descritto attraverso cinque categorie: Performance, Accessibility, Best Practices, SEO e Progressive Web App.
Questo modello non è più corretto.
Chrome ha deciso di rimuovere la categoria PWA da Lighthouse in seguito ai cambiamenti nei criteri di installabilità delle Progressive Web App. La rimozione è arrivata con Lighthouse 12. (developer.chrome.com)
Le PWA non sono scomparse e Lighthouse non ha “disattivato temporaneamente” la categoria: la vecchia categoria PWA è stata rimossa.
Lighthouse 13 ha sostituito molti vecchi audit con Performance Insights
Con Lighthouse 13 Google ha completato un cambiamento importante nella parte Performance.
Numerosi audit storici sono stati rimossi o consolidati nei nuovi Performance Insights, condivisi maggiormente con il Performance panel di DevTools. Fra gli esempi ci sono l’analisi delle risorse render-blocking, della consegna delle immagini, della latenza del documento e delle dipendenze di rete. (developer.chrome.com)
Per chi legge vecchi tutorial c’è una conseguenza pratica:
se cerchi nel report esattamente il nome di una vecchia voce “Opportunities” o “Diagnostics”, potresti non trovarla più nello stesso formato.
Il problema tecnico esiste ancora; è cambiato il modo in cui Lighthouse lo organizza e lo presenta.
Agentic Browsing e WebMCP: una funzione sperimentale, non un nuovo ranking score
Nella documentazione corrente compare anche una categoria dedicata all’Agentic Browsing, pensata per valutare alcuni aspetti dell’interazione fra pagine web e agenti software.
Qui è importante non anticipare troppo la realtà.
Google la definisce esplicitamente sperimentale, basata anche su standard ancora proposti. I test richiedono ambienti Chrome compatibili e gli audit WebMCP hanno ulteriori requisiti. Inoltre la categoria non produce il classico score ponderato da 0 a 100. (developer.chrome.com)
Fra i controlli descritti compaiono aspetti come:
- WebMCP;
- struttura dell’accessibility tree;
- stabilità del layout;
- presenza di
llms.txt.
Questo non significa che llms.txt sia diventato un ranking factor né che sia necessario ottimizzare immediatamente ogni sito per ottenere un fantomatico “Agentic Lighthouse score”.
Al momento va considerato soprattutto un segnale dell’evoluzione degli strumenti di sviluppo verso scenari di interazione machine-to-web, da seguire senza confonderlo con i normali audit SEO.
Conclusione
Google Lighthouse resta uno degli strumenti più utili per capire perché una pagina presenta determinati problemi tecnici.
Il valore di Google Lighthouse diminuisce, invece, quando lo riduci a una gara per ottenere quattro numeri verdi.
Usalo per:
- riprodurre problemi in laboratorio;
- individuare cause tecniche;
- confrontare modifiche in condizioni coerenti;
- prevenire regressioni;
- integrare performance, accessibilità e controlli tecnici nel processo di sviluppo.
Poi collega i risultati al dato corretto.
Se vuoi sapere cosa vivono realmente gli utenti, guarda i field data e i Core Web Vitals. Se vuoi capire perché una metrica è problematica, scendi nel laboratorio con Lighthouse e DevTools. Se vuoi capire perché una pagina non si posiziona, devi allargare l’analisi ben oltre il suo SEO score.
Il numero è una sintesi. La diagnosi è il vero lavoro.
E quando il problema riguarda contemporaneamente performance, crawling, struttura, contenuti e visibilità, Lighthouse diventa uno degli strumenti da inserire in un SEO audit, non il sostituto dell’analisi completa.