PageSpeed Insights è lo strumento gratuito di Google per misurare le performance web. Mostra due tipi di dati: dati di campo reali degli utenti Chrome (CrUX) e dati di laboratorio Lighthouse. Per migliorare il punteggio prioritizza le "Opportunità" che mostrano la stima di risparmio in secondi: le immagini non ottimizzate, il render-blocking CSS/JS, e il JavaScript non utilizzato coprono l'80% dei guadagni ottenibili. La versione mobile è sempre quella che conta di più per il ranking Google.
Dati di campo vs dati di laboratorio: qual è la differenza
La sezione superiore di PageSpeed Insights (se disponibile) mostra i dati reali degli ultimi 28 giorni raccolti dagli utenti Chrome tramite il CrUX (Chrome User Experience Report). Questi sono i dati che Google usa per il ranking. La sezione Lighthouse, invece, è una simulazione su dispositivo emulato con connessione throttled: utile per il debugging in sviluppo, ma non riflette necessariamente l'esperienza dei tuoi utenti reali.
Una discrepanza comune: il sito ha punteggio Lighthouse di 92 ma i dati CrUX mostrano LCP "Needs Improvement". Questo accade perché Lighthouse misura su rete simulata con CPU throttled, mentre CrUX cattura il range completo di dispositivi e connessioni degli utenti reali — inclusi gli smartphone lenti su 3G precario. I dati CrUX sono la verità; Lighthouse è il simulatore. Usa Lighthouse per diagnosticare e iterare rapidamente, usa CrUX per valutare il risultato finale.
Il punteggio di performance: cosa rappresenta davvero
Il punteggio 0-100 di Lighthouse è una media pesata delle metriche di laboratorio: LCP (25%), TBT (30%, proxy per INP), CLS (15%), FCP (10%), Speed Index (10%), TTI (10%). Non è direttamente il punteggio che Google usa per il ranking (quello usa i dati di campo), ma è un indicatore utile dello stato del sito. Un punteggio sopra 90 è "Good", 50-89 "Needs Improvement", sotto 50 "Poor". Mobile e desktop hanno punteggi separati: spesso il mobile è significativamente più basso.
Il Total Blocking Time (TBT) è la metrica con il peso maggiore nel punteggio (30%). TBT è la somma del tempo di blocco di tutte le long task sul main thread durante il caricamento: ogni task sopra 50ms contribuisce con la porzione eccedente. Un TBT di 500ms abbatte il punteggio anche se LCP e CLS sono perfetti. Questo è il motivo per cui siti con JavaScript pesante hanno punteggi bassi anche con immagini ottimizzate: il problema è il thread, non le immagini.
Sezione Opportunità: gli interventi con il massimo impatto
Le "Opportunità" mostrano gli interventi con la stima di risparmio in secondi sul LCP. Le più comuni: "Serve images in next-gen formats" (converti in WebP/AVIF), "Properly size images" (dimensiona per la viewport), "Eliminate render-blocking resources" (ottimizza CSS/JS critici), "Reduce unused JavaScript" (rimuovi dipendenze inutili). Ordina per risparmio stimato e inizia dalla voce più alta: spesso una singola ottimizzazione vale più di tutte le altre insieme.
La stima di risparmio è conservativa: indica il miglioramento minimo garantito nell'ambiente simulato. Nella realtà, specialmente su connessioni mobili reali, i miglioramenti sono spesso maggiori. Abbiamo visto casi in cui PageSpeed Insights stimava 0,8 secondi di risparmio per l'ottimizzazione delle immagini, ma i dati CrUX reali dopo l'ottimizzazione mostravano un miglioramento LCP di 2 secondi. Usa le stime come prioritizzazione relativa, non come previsione assoluta.
Sezione Diagnostica: problemi strutturali
Le "Diagnostiche" non hanno un risparmio stimato ma segnalano problemi strutturali: DOM troppo grande (>1500 nodi peggiora l'INP), catene di richieste critiche lunghe, mancanza di cache policy per le risorse statiche, dipendenze legacy da formati obsoleti. Non ignorarle: spesso sono le cause radice di problemi che si manifestano come metriche Core Web Vitals degradate.
Le diagnostiche che vediamo più spesso nei siti italiani: "Avoid chaining critical requests" (catene di CSS che importano altri CSS), "Avoid an excessive DOM size" (siti WordPress con builder che generano DOM da 5.000+ nodi), "Serve static assets with an efficient cache policy" (mancanza di Cache-Control su hosting economici). Ognuno di questi ha una soluzione tecnica specifica e un impatto misurabile sulle metriche.
Come usare PageSpeed Insights nel processo di sviluppo
L'uso più efficace è durante il ciclo di sviluppo: testa l'URL di staging dopo ogni ottimizzazione significativa, non solo a progetto finito. Crea un baseline all'inizio del progetto, traccia le metriche in un foglio di calcolo, e verifica che ogni sprint migliori o mantenga il punteggio. Nella nostra pratica di realizzazione siti web impostiamo un target minimo di 90/100 su mobile come criterio di accettazione.
Un workflow pratico: prima di iniziare il progetto, testa i competitor sui loro URL principali per capire il benchmark del settore. Durante lo sviluppo, testa ogni feature principale su staging prima di mergiare. Prima del go-live, testa tutte le URL critiche (homepage, pagina prodotto, categoria, checkout) sia su mobile che desktop. Dopo il go-live, monitora settimanalmente per intercettare regressioni. Google Search Console invierà automaticamente alert se le metriche degradano significativamente.
Errori comuni nell'interpretazione del report
- Ottimizzare solo per desktop ignorando il punteggio mobile: Google usa mobile-first indexing, il mobile è quello che conta
- Considerare Lighthouse come dati reali: è una simulazione su Moto G4 con 3G lento, non misura i tuoi utenti
- Ossessionarsi con il punteggio 100 invece di guardare le metriche Core Web Vitals: un 95 con tutti i CWV "Good" è meglio di un 100 senza dati CrUX
- Non distinguere tra dati CrUX assenti ("No data available") e metriche "Poor": senza dati il sito non è necessariamente buono, semplicemente ha poco traffico Chrome
- Testare da rete aziendale veloce senza throttling: la simulazione mobile va fatta con le condizioni reali degli utenti mobile
- Ignorare la differenza tra "Opportunità" (impatto diretto sul LCP) e "Diagnostiche" (problemi strutturali): entrambe contano
Alternative e complementi a PageSpeed Insights
GTmetrix offre waterfall dettagliata, confronto storico e test da location specifica (compresa Milano). WebPageTest è lo strumento professionale con video filmstrip del caricamento, test multi-step, e metriche avanzate come TTFB per ogni risorsa. Lighthouse CLI permette l'integrazione nel CI/CD per bloccare deploy che peggiorano le performance. Per i siti che seguiamo nel piano di gestione siti web usiamo tutti e tre in combinazione.
Una combinazione che funziona bene nella nostra pratica: PageSpeed Insights per il monitoring rapido e i dati CrUX (lo apriamo sempre per primo), GTmetrix per analizzare il waterfall e identificare le risorse problematiche specifiche, WebPageTest per testare su dispositivi e location reali e produrre video filmstrip da mostrare al cliente. Lighthouse CLI in GitHub Actions come gatekeeper nei deploy: se il punteggio scende sotto 85 su mobile, il deploy viene bloccato finché il team non approva esplicitamente.
Report automatizzati: tieni il punteggio sotto controllo
Testare manualmente una volta al mese non è sufficiente: le performance peggiorano silenziosamente con ogni aggiornamento di plugin, nuovo script di marketing, o cambio di immagini. Configura Lighthouse CI nel tuo pipeline GitHub Actions per testare ad ogni PR. Usa PageSpeed Insights API (gratuita) per creare report settimanali automatizzati. E monitora Google Search Console per intercettare degradazioni nei dati reali prima che impattino il ranking.
Uno script Python che usiamo internamente: ogni domenica mattina chiama PageSpeed Insights API per le 20 URL principali di ogni cliente, confronta con la settimana precedente, e invia un report Slack se qualcosa è peggiorato di più di 5 punti. Questo sistema ha intercettato problemi in 3 occasioni nell'ultimo anno: un plugin aggiornato che aveva reintrodotto un CSS da 600 KB, uno script Hotjar caricato in modo sincrono da un errore di configurazione GTM, e una galleria immagini aggiunta senza ottimizzazione. Ciascuno è stato risolto prima che impattasse il ranking. Contattaci se vuoi un sistema simile per il tuo sito.
