Succede di continuo: il cliente apre PageSpeed Insights e vede 62, lo sviluppatore lancia Lighthouse dai DevTools di Chrome e ottiene 88, e la riunione successiva diventa una discussione su quale dei due numeri sia “quello vero”. La risposta breve è che nessuno dei due è sbagliato. La risposta completa richiede di capire che cosa sono questi strumenti, che cosa hanno in comune e perché, pur usando lo stesso motore, arrivano spesso a risultati diversi.
Lighthouse: il motore di analisi
Lighthouse è uno strumento open source sviluppato da Google che carica una pagina in un browser Chrome controllato, ne registra il comportamento e produce un report con quattro categorie: Performance, Accessibilità, Best practice e SEO. È un’analisi di laboratorio: una singola visita, in condizioni simulate, senza alcun utente reale coinvolto.
Lo si può eseguire in molti modi: dal pannello Lighthouse dei DevTools di Chrome, dalla riga di comando con Node.js, come modulo all’interno di altri programmi e nelle pipeline di integrazione continua con Lighthouse CI. In tutti i casi il test gira sulla macchina che lo lancia, con il suo processore, la sua connessione e, nel caso dei DevTools, il suo profilo del browser.
# Profilo mobile predefinito, solo la categoria Performance
npx lighthouse https://www.iltuosito.it/ --only-categories=performance --view
# Profilo desktop, report JSON per confronti automatici
npx lighthouse https://www.iltuosito.it/ --preset=desktop --output=json --output-path=report.jsonPageSpeed Insights: un servizio che usa Lighthouse
PageSpeed Insights, spesso abbreviato in PSI, è invece un servizio web di Google. Quando inseriamo un indirizzo, esegue Lighthouse sui propri server e mostra il risultato nella sezione “Diagnostica i problemi di prestazioni”. Ma aggiunge qualcosa che Lighthouse da solo non può offrire: i dati degli utenti reali provenienti dal Chrome UX Report, per l’URL analizzato e per l’intera origine, nella sezione “Scopri cosa provano i tuoi utenti reali”.
PageSpeed Insights è quindi due strumenti in uno: un’esecuzione di Lighthouse in un ambiente gestito da Google e una finestra sui dati di campo degli ultimi 28 giorni. È disponibile anche tramite API, utile per monitorare molte pagine in modo automatico:
curl "https://www.googleapis.com/pagespeedonline/v5/runPagespeed?url=https://www.iltuosito.it/&strategy=mobile&category=performance"Cosa hanno in comune
La parte di laboratorio è la stessa. Entrambi misurano First Contentful Paint, Largest Contentful Paint, Total Blocking Time, Cumulative Layout Shift e Speed Index, e calcolano il punteggio Performance con la stessa formula: nelle versioni attuali di Lighthouse il Total Blocking Time pesa il 30%, LCP e CLS il 25% ciascuno, FCP e Speed Index il 10%. Anche il profilo mobile predefinito è lo stesso: uno smartphone di fascia media emulato, una connessione 4G lenta simulata e un processore rallentato.
È importante notare che il punteggio Performance non include l’INP: nel laboratorio non ci sono interazioni reali, e il suo posto è preso dal Total Blocking Time, che ne è solo un indicatore indiretto. L’INP compare invece in PageSpeed Insights, ma solo nella sezione dei dati reali.
Le differenze che contano
| PageSpeed Insights | Lighthouse | |
|---|---|---|
| Dove viene eseguito | Server di Google | La tua macchina o il tuo server |
| Dati degli utenti reali | Sì, da CrUX (28 giorni) | No, solo laboratorio |
| Pagine raggiungibili | Solo URL pubbliche | Anche staging, locale e aree riservate |
| Configurazione | Solo mobile o desktop | Rete, CPU, dispositivo, categorie, script di navigazione |
| Strumenti di diagnosi | Report sintetico | Report completo, trace di Performance, treemap del JavaScript |
| Automazione | API PageSpeed Insights | CLI, Node.js, Lighthouse CI |
| Versione di Lighthouse | Scelta da Google | Quella installata |
La differenza più rilevante per un’azienda è la seconda riga della tabella: solo PageSpeed Insights mostra come stanno andando davvero gli utenti. Lighthouse spiega come si comporta la pagina in una singola visita controllata, PageSpeed Insights affianca a questa spiegazione il giudizio del campo. Sono le due prospettive che descriviamo in perché CrUX e LABS servono entrambi.
Perché lo stesso motore dà numeri diversi
Se la formula è identica, da dove nascono le differenze? Dalle condizioni in cui il test viene eseguito. Le cause più frequenti sono:
- L’hardware. Il rallentamento del processore è un moltiplicatore applicato alla CPU reale: su un portatile potente e su un server condiviso lo stesso “quattro volte più lento” produce tempi molto diversi, soprattutto per il Total Blocking Time.
- La rete e la posizione. PageSpeed Insights raggiunge il sito da un datacenter di Google, i DevTools dalla tua connessione. Latenza, percorso di rete e vicinanza al server cambiano il TTFB e, di conseguenza, tutte le metriche successive.
- Lo stato del browser. In Chrome estensioni, cookie, sessioni attive e cache possono alterare il risultato. Un test con un blocco pubblicità attivo, o da utente loggato, misura una pagina diversa da quella dei visitatori.
- La versione. PageSpeed Insights usa la versione di Lighthouse scelta da Google, i DevTools quella inclusa nella tua versione di Chrome, la riga di comando quella installata. Cambi nel calcolo delle metriche tra versioni spostano i punteggi.
- La variabilità naturale. Due esecuzioni consecutive dello stesso strumento danno raramente lo stesso numero: pubblicità, test A/B, cache del server e carico del momento cambiano da un caricamento all’altro.
C’è poi un caso particolare: alcune configurazioni riconoscono i tester in base allo User-Agent o all’indirizzo IP e servono loro una pagina diversa. In quel caso la differenza tra i due strumenti non è rumore statistico, ma il segnale che il test non sta vedendo lo stesso sito degli utenti, come abbiamo mostrato analizzando il caso di LiteSpeed Cache.
Quando usare PageSpeed Insights
PageSpeed Insights è lo strumento giusto per il colpo d’occhio e per la comunicazione. Permette a chiunque, senza installare nulla, di vedere come Google valuta una pagina pubblica, sia sul campo sia in laboratorio, e produce un risultato condivisibile con un link. È anche il modo più rapido per controllare i dati CrUX di una pagina o di un concorrente, e con la sua API diventa la base di un monitoraggio periodico su un elenco di URL.
Ha però dei limiti evidenti: non raggiunge ambienti di staging o pagine protette da accesso, non consente di cambiare le condizioni del test e offre strumenti di diagnosi più essenziali. E il suo punteggio di laboratorio, come quello di qualsiasi singola esecuzione, va letto con cautela.
Quando usare Lighthouse
Lighthouse è lo strumento di lavoro dello sviluppatore. Nei DevTools permette di aprire la trace completa nel pannello Performance, esplorare il peso del JavaScript con la treemap, verificare una modifica in locale prima ancora di pubblicarla e analizzare pagine che richiedono l’accesso, come l’area clienti o il checkout. Da riga di comando e con Lighthouse CI entra nelle pipeline di sviluppo: ogni rilascio può essere confrontato con soglie di prestazione, i cosiddetti performance budget, bloccando le regressioni prima che arrivino agli utenti.
Il prezzo di questa flessibilità è la responsabilità: i risultati dipendono dalla macchina e dalla configurazione, quindi vanno eseguiti sempre nello stesso ambiente per essere confrontabili. Per test da località geografiche diverse o su dispositivi reali esistono strumenti complementari, come WebPageTest.
Gli errori più comuni
- Confrontare punteggi di strumenti diversi. Un 62 su PageSpeed Insights e un 88 nei DevTools non indicano un miglioramento o un peggioramento: indicano due ambienti diversi.
- Fidarsi di una singola esecuzione. Una sola misura può cadere in un momento fortunato o sfortunato. Tre o cinque esecuzioni, considerando la mediana, danno un’indicazione molto più stabile.
- Testare con il proprio browser di tutti i giorni. Estensioni e sessioni attive falsano il risultato: meglio una finestra in incognito o un profilo pulito.
- Confondere mobile e desktop. Il profilo desktop è molto più indulgente: un buon punteggio desktop dice poco su un sito visitato soprattutto da smartphone.
- Trattare il punteggio come obiettivo di business. Il numero da 0 a 100 è una sintesi utile, ma le decisioni vanno prese sulle singole metriche e, soprattutto, sui dati degli utenti reali.
Come ottenere misure affidabili
Un metodo semplice evita la maggior parte delle discussioni. Si sceglie uno strumento e una configurazione di riferimento, per esempio Lighthouse da riga di comando sempre sulla stessa macchina con profilo mobile, oppure l’API di PageSpeed Insights. Si eseguono più test e si registra la mediana delle singole metriche, non solo del punteggio. Si annota la versione di Lighthouse usata. E si confrontano i risultati di laboratorio con l’andamento dei dati reali, ricordando che questi ultimi si aggiornano su una finestra di 28 giorni.
Nei nostri report indichiamo sempre strumento, versione, profilo e numero di esecuzioni accanto a ogni valore. Può sembrare un eccesso di precisione, ma è l’unico modo per rendere confrontabili misure prese in momenti diversi e da persone diverse, e per trasformare un numero in una decisione.
In sintesi
Lighthouse è il motore di analisi: open source, configurabile, eseguibile ovunque, ideale per diagnosticare i problemi e prevenire le regressioni. PageSpeed Insights è un servizio che esegue Lighthouse sui server di Google e vi affianca i dati reali di CrUX: ideale per una valutazione rapida, condivisibile e per sapere come vivono il sito gli utenti. Usano la stessa formula, ma girano in ambienti diversi, e per questo i loro punteggi non vanno confrontati tra loro.
La domanda giusta, quindi, non è quale dei due numeri sia vero, ma quale domanda stiamo facendo. Per sapere come stanno andando gli utenti si guardano i dati reali di PageSpeed Insights. Per capire perché, e per verificare che una correzione funzioni, si usa Lighthouse, sempre nelle stesse condizioni.
