Se apri PageSpeed Insights e guardi soltanto il numero dentro il cerchio colorato, stai usando una piccola parte dello strumento. Il report di Google mette infatti insieme due tipi di informazioni molto diversi: dati raccolti da utenti reali tramite CrUX e un test di laboratorio eseguito con Lighthouse. Capire questa differenza è il punto di partenza per evitare diagnosi sbagliate.
Un punteggio Lighthouse di 95 o 100 non significa automaticamente che la pagina abbia superato i Core Web Vitals. Allo stesso modo, un punteggio di laboratorio mediocre non dimostra da solo che tutti gli utenti stiano vivendo un’esperienza lenta.
Il metodo più utile è un altro: partire dai dati reali quando esistono, individuare la metrica problematica, usare Lighthouse per cercarne le cause e verificare dopo l’intervento se il problema è realmente migliorato.
Cos’è PageSpeed Insights e cosa misura davvero
PageSpeed Insights è lo strumento di Google che analizza una pagina web su mobile e desktop e restituisce informazioni sulle prestazioni insieme a indicazioni diagnostiche.
La caratteristica che lo distingue da un semplice speed test è la presenza, nello stesso report, di field data e lab data. Google spiega infatti che i dati di laboratorio sono particolarmente utili per il debugging, mentre quelli sul campo descrivono l’esperienza realmente osservata sugli utenti.
Questa distinzione cambia completamente il modo in cui va letto il report.
Cosa succede quando inserisci un URL
Quando inserisci una pagina in PageSpeed Insights, lo strumento può mostrarti due livelli di analisi.
Il primo riguarda l’esperienza degli utenti reali ed è alimentato dal Chrome User Experience Report, normalmente abbreviato in CrUX. Il secondo viene generato da Lighthouse, che carica la pagina in condizioni controllate e misura il comportamento osservato durante quella specifica simulazione.
I due risultati possono essere entrambi corretti anche quando sembrano contraddirsi.
CrUX descrive ciò che è successo nel tempo a una popolazione di utenti reali, con dispositivi, connessioni e condizioni differenti. Lighthouse esegue invece un test in un determinato momento e con condizioni definite.
Per questo PageSpeed Insights è più utile come strumento diagnostico che come semplice generatore di un voto.
PageSpeed Insights, Lighthouse e CrUX: tre nomi, tre ruoli diversi
I tre termini vengono spesso usati come se indicassero la stessa cosa, ma hanno funzioni differenti.
PageSpeed Insights è l’interfaccia che riunisce le informazioni.
CrUX fornisce i dati sull’esperienza reale disponibili per la pagina o per l’origin.
Lighthouse esegue il test di laboratorio e genera il Performance Score insieme agli Insights e alle diagnostiche.
Se vuoi approfondire il motore di laboratorio separatamente, nella guida a Google Lighthouse trovi le modalità di esecuzione e le diverse aree dell’audit. Per comprendere invece le metriche real-user nel loro contesto SEO e tecnico, conviene partire dalla guida ai Core Web Vitals.
La distinzione da ricordare è semplice:
Performance Score Lighthouse ≠ Core Web Vitals assessment CrUX.
Dati reali e dati di laboratorio: la distinzione fondamentale
È la sezione più importante del report, perché risponde a due domande differenti.
I field data cercano di dirti come la pagina si comporta per gli utenti reali.
I lab data cercano di aiutarti a capire cosa sta succedendo tecnicamente durante un caricamento controllato.
Confondere questi livelli porta facilmente a interventi inutili.
CrUX: 28 giorni, 75° percentile e dati URL/origin
I dati real-user mostrati da PageSpeed Insights arrivano da CrUX e coprono una finestra mobile dei 28 giorni precedenti. Per LCP, INP e CLS il report utilizza il 75° percentile per classificare l’esperienza in Good, Needs Improvement o Poor.
Questo ha una conseguenza pratica importante.
Se oggi ottimizzi un’immagine hero, elimini uno script pesante o migliori il server, puoi vedere subito una variazione nel test Lighthouse. Non devi invece aspettarti che il field data CrUX cambi immediatamente, perché continua a includere visite raccolte nei giorni precedenti.
C’è poi il problema della granularità.
CrUX non possiede necessariamente abbastanza dati per ogni singola URL. Quando il campione della pagina non è sufficiente, PageSpeed Insights può mostrare dati relativi all’origin, cioè all’insieme del sito. Se neppure l’origin dispone di dati sufficienti, la sezione real-user può non essere disponibile.
Prima di concludere che “questa pagina ha un LCP scarso”, controlla quindi se stai leggendo dati della URL oppure dell’origin.
È una differenza sostanziale. Una homepage con video e hero complessa può avere caratteristiche completamente diverse da un articolo, una pagina prodotto o una landing page costruita sullo stesso dominio.
Lighthouse: il test simulato usato per diagnosticare i problemi
Il test di laboratorio viene prodotto da Lighthouse.
Qui non stai osservando la storia degli utenti delle ultime settimane. Stai osservando come si è comportata la pagina durante quel test.
Questo rende Lighthouse particolarmente utile quando devi isolare una causa: una risorsa che ritarda l’LCP, molto lavoro JavaScript sul main thread, una catena di richieste critica, un’immagine sovradimensionata, risorse che bloccano il rendering o elementi responsabili di layout shift.
La simulazione rende il test controllabile, ma introduce anche un limite: un singolo run non rappresenta tutta la varietà dell’esperienza reale.
Perché field data e lab data possono dare risultati diversi
Google chiarisce esplicitamente che i field data sono un resoconto storico proveniente da utenti reali con dispositivi e reti differenti, mentre il lab test utilizza condizioni definite. È quindi normale ottenere valori diversi.
Immagina, per esempio, che Lighthouse trovi un LCP eccellente mentre CrUX continui a segnalarlo come problematico.
Non significa necessariamente che uno dei due strumenti stia sbagliando. Potrebbero essere accadute diverse cose: l’ottimizzazione è recente e non è ancora entrata pienamente nella finestra CrUX; gli utenti reali utilizzano hardware meno potente; alcune condizioni di rete sono peggiori di quelle del test; script di terze parti si comportano diversamente; oppure il test che stai guardando non riproduce il problema che si verifica in produzione.
Il confronto corretto non è quindi:
Quale dei due numeri devo credere?
La domanda utile è:
Che cosa sta misurando ciascun numero?
Come leggere il punteggio di PageSpeed Insights senza inseguire 100
Il numero 0–100 che attira immediatamente l’attenzione nel report Performance è un Performance Score Lighthouse.
Non viene calcolato facendo una media fra Core Web Vitals reali, field data e tutte le raccomandazioni che compaiono nel report.
Secondo la documentazione di Lighthouse, al punteggio Performance contribuiscono le metriche; gli audit e le diagnostiche possono aiutare a migliorarle, ma non vengono semplicemente sommati per generare il voto.
Come viene calcolato il Performance Score
La ponderazione documentata da Lighthouse utilizza queste metriche:
| Metrica di laboratorio | Peso |
|---|---|
| First Contentful Paint | 10% |
| Speed Index | 10% |
| Largest Contentful Paint | 25% |
| Total Blocking Time | 30% |
| Cumulative Layout Shift | 25% |
La documentazione corrente continua a indicare questa ponderazione e Lighthouse 13 non ha modificato il sistema di scoring: il cambiamento principale ha riguardato la riorganizzazione degli audit in nuovi Performance Insights.
Qui si vede subito un errore frequente: INP non è una delle metriche che compongono direttamente il Performance Score Lighthouse. Nel laboratorio viene invece usato TBT come indicatore della quantità di tempo in cui il main thread resta bloccato. Un TBT basso tende spesso a correlare con un INP migliore, ma non è un sostituto dell’INP misurato sugli utenti reali.
Anche Time to Interactive, presente in vecchie versioni di Lighthouse, non fa più parte della ponderazione corrente.
Perché 90/100 non significa aver superato i Core Web Vitals
Questo è probabilmente il punto che crea più confusione.
Puoi ottenere un ottimo Performance Score di laboratorio mentre CrUX segnala un Core Web Vital problematico. Oppure puoi ottenere un punteggio Lighthouse inferiore a quello che vorresti pur avendo dati real-user buoni.
Non è una contraddizione perché i due sistemi rispondono a domande differenti.
Lighthouse sta valutando quel caricamento simulato attraverso le metriche che compongono il suo score.
CrUX sta classificando l’esperienza realmente osservata nel tempo usando LCP, INP e CLS.
Portare una pagina da 97 a 100 può quindi avere pochissimo valore se non risolve un problema reale. Viceversa, vedere un buon punteggio verde non dovrebbe farti ignorare un INP o un LCP problematico nei field data.
Perché mobile e desktop possono mostrare punteggi diversi
Anche il confronto mobile/desktop va trattato con cautela.
Le due analisi non sono semplicemente la stessa misurazione visualizzata in due colonne. Lighthouse utilizza profili e curve di scoring che tengono conto delle differenze fra le condizioni desktop e mobile.
In più, anche CrUX separa le esperienze per form factor.
Se il mobile è molto più debole del desktop, non cercare quindi di “pareggiare i punteggi” per principio. Cerca la causa: quantità di JavaScript, risorse iniziali, immagini, comportamento responsive, elementi di terze parti e limiti dei dispositivi meno potenti sono spesso più interessanti del numero finale.
Core Web Vitals in PageSpeed Insights: cosa controllare
I Core Web Vitals correnti sono Largest Contentful Paint (LCP), Interaction to Next Paint (INP) e Cumulative Layout Shift (CLS). Google li descrive come metriche dell’esperienza reale relative rispettivamente a caricamento, reattività e stabilità visiva.
Le soglie mostrate nei field data di PageSpeed Insights sono:
| Metrica | Good | Needs Improvement | Poor |
|---|---|---|---|
| LCP | fino a 2,5 s | oltre 2,5 fino a 4 s | oltre 4 s |
| INP | fino a 200 ms | oltre 200 fino a 500 ms | oltre 500 ms |
| CLS | fino a 0,1 | oltre 0,1 fino a 0,25 | oltre 0,25 |
PageSpeed Insights applica queste soglie ai valori real-user selezionati al 75° percentile.
FID, che può ancora comparire in vecchi articoli o screenshot, non è più un Core Web Vital corrente: INP ne ha preso il posto. Se PSI segnala un problema di reattività, puoi diagnosticare Interaction to Next Paint partendo dai dati real-user e arrivando all’interazione e alla fase che producono la latenza.
Non serve però trasformare questa pagina in una seconda guida completa ai Web Vitals. Se devi capire meccanismi, soglie, field data, diagnosi e interventi per le tre metriche, trovi l’approfondimento dedicato sui Core Web Vitals di Google.
Quando PageSpeed mostra i dati della URL e quando quelli dell’origin
Controllare la provenienza del dato è essenziale soprattutto su siti con template molto differenti.
Se PSI dispone di campioni sufficienti per la pagina, può mostrare i valori relativi alla URL analizzata. In caso contrario può passare ai dati dell’origin. Google documenta esplicitamente questo fallback.
Questo evita una conclusione pericolosa: attribuire a una pagina un problema che, in realtà, deriva dal comportamento aggregato del sito.
PageSpeed Insights e SEO: cosa Google conferma e cosa no
PageSpeed Insights non è un “misuratore del ranking” e il Performance Score Lighthouse non è un punteggio SEO.
Google raccomanda di raggiungere buoni Core Web Vitals sia per Search sia per offrire una buona esperienza e spiega che questi segnali, insieme ad altri aspetti della page experience, sono coerenti con ciò che i suoi sistemi di ranking cercano di premiare.
Questo non autorizza però la formula:
punteggio PageSpeed più alto = posizione Google più alta.
Il Performance Score è una misura di laboratorio. Il ranking dipende da molti sistemi e segnali, mentre una pagina deve prima di tutto soddisfare l’intento di ricerca con contenuti pertinenti, affidabili e utili.
Il modo corretto di usare PSI in ottica SEO è quindi più concreto: individuare problemi prestazionali reali che peggiorano l’esperienza e risolverli, non spendere ore per spostare un numero verde di pochi punti senza un beneficio dimostrabile.
Come leggere gli Insights di Lighthouse e trovare la causa del problema
Un report utile non termina con “LCP rosso” o “Performance 62”.
Quello è il sintomo.
La parte interessante comincia quando colleghi la metrica problematica agli Insights e alle diagnostiche che spiegano cosa è accaduto durante il caricamento.
Lighthouse 13 ha consolidato molti vecchi audit Performance in una famiglia comune di Performance Insights condivisa con gli strumenti di sviluppo Chrome. Il sistema di scoring non è cambiato con questa riorganizzazione: è cambiato il modo in cui diversi problemi vengono presentati e raggruppati.
LCP lento: dove cercare
Se il problema è LCP, la domanda non dovrebbe essere genericamente “come velocizzo il sito?”.
Devi capire da quale fase nasce il ritardo.
Gli Insights recenti possono aiutare a individuare, per esempio, la scoperta tardiva della risorsa LCP, le fasi che compongono il tempo totale, una cattiva consegna delle immagini, risorse render-blocking, dipendenze di rete o latenza della richiesta iniziale. Lighthouse 13 ha riunito molti dei vecchi audit proprio in queste categorie più orientate alla causa.
Se il problema è specificamente l’elemento principale della pagina, puoi poi approfondire il Largest Contentful Paint senza trasformare questa guida in un tutorial separato sull’LCP.
INP problematico e TBT elevato: cosa indicano realmente
L’INP è una metrica real-user: ha bisogno di interazioni reali per descrivere la reattività vissuta dagli utenti.
TBT è invece una metrica di laboratorio che misura il tempo durante il quale il main thread rimane bloccato da long task dopo il First Contentful Paint. Un TBT elevato può essere un buon indizio di problemi JavaScript e di lavoro eccessivo sul main thread, ma TBT e INP non sono la stessa metrica.
Questo significa che puoi usare Lighthouse per trovare script pesanti, long task e codice di terze parti, ma la conferma del problema di responsività deve arrivare dall’INP reale quando i dati sono disponibili.
CLS: come individuare gli elementi che spostano il layout
Per il CLS il ragionamento è diverso: devi cercare gli elementi responsabili degli spostamenti imprevisti.
Immagini o iframe senza spazio riservato, banner caricati in ritardo, font, componenti dinamici e contenuti inseriti sopra elementi già visibili sono esempi tipici.
Lighthouse 13 include un CLS culprits insight, progettato proprio per rendere più semplice il passaggio dalla metrica al responsabile dello spostamento.
Se il problema riguarda WordPress, puoi approfondire le cause e le correzioni nella guida dedicata al Cumulative Layout Shift.
Un workflow pratico per usare PageSpeed Insights
Il modo più efficace di usare PageSpeed Insights è evitare l’approccio “apro il report e correggo tutto ciò che è rosso”.
Segui invece questa sequenza:
- Controlla i field data, se disponibili, e verifica se riguardano la URL o l’origin.
- Identifica la metrica reale problematica: LCP, INP o CLS.
- Passa al laboratorio Lighthouse e cerca gli Insights collegati a quella metrica.
- Isola una causa materiale, invece di modificare contemporaneamente cache, immagini, JavaScript, hosting e plugin.
- Esegui l’intervento e ripeti il test in condizioni il più possibile comparabili.
- Controlla se il laboratorio conferma il miglioramento.
- Verifica nel tempo i field data, ricordando che CrUX utilizza una finestra mobile di 28 giorni.
Questo workflow trasforma PSI da generatore di punteggi a strumento di diagnosi.
C’è anche un vantaggio metodologico: modificando una causa alla volta, diventa molto più semplice capire quale intervento ha prodotto realmente il cambiamento.
Quando PageSpeed Insights non basta
PageSpeed Insights è un ottimo punto di partenza, ma non deve rispondere a ogni domanda sulle performance.
Se vuoi capire quali gruppi di pagine del sito hanno problemi real-user, il report Core Web Vitals di Google Search Console offre una vista più adatta al monitoraggio complessivo. Google stessa lo indica tra gli strumenti da utilizzare per controllare i Web Vitals.
Se invece devi analizzare il comportamento tecnico della pagina in profondità, Chrome DevTools e Lighthouse ti permettono di lavorare più vicino alla timeline, alle richieste e all’esecuzione JavaScript.
Per confrontare scenari, località, waterfall e condizioni di rete più specifiche, strumenti come WebPageTest possono aggiungere un livello di dettaglio che PSI non nasce per offrire. Se vuoi confrontare diversi servizi di misurazione, trovi anche la guida ai principali test di velocità per siti web e l’approfondimento su GTmetrix.
E l’API PageSpeed Insights?
L’API PageSpeed Insights resta disponibile per automatizzare analisi Lighthouse e recuperare risultati strutturati.
C’è però un cambiamento da considerare se costruisci dashboard o processi automatici basati sui field data: Google dichiara di voler interrompere l’inclusione dei dati real-user CrUX nell’API PageSpeed Insights e raccomanda, per questi dati, CrUX API o CrUX History API.
Per questo non costruirei oggi un nuovo sistema di monitoraggio CrUX facendo dipendere l’architettura dall’attuale presenza dei field data nella PSI API.
Conclusione
PageSpeed Insights diventa molto più semplice da interpretare quando smetti di considerarlo un unico test.
CrUX ti dice che cosa stanno vivendo gli utenti reali. Lighthouse riproduce un caricamento controllato. Il Performance Score sintetizza alcune metriche di quel test. Gli Insights aiutano a trovare le cause tecniche.
Da qui deriva anche la priorità corretta.
Se i Core Web Vitals reali mostrano un problema, parti da quello e usa il laboratorio per diagnosticarlo. Se i dati reali sono già buoni e stai cercando di portare un Performance Score da 97 a 100, chiediti prima quale problema concreto stai risolvendo.
Il numero verde è utile come segnale. Non è l’obiettivo finale.
L’obiettivo è una pagina che carica, reagisce e rimane stabile nelle condizioni in cui viene realmente utilizzata. E quando PageSpeed Insights evidenzia problemi che richiedono interventi più profondi su codice, infrastruttura o configurazione, il passo successivo non è accumulare altri test ma trasformare la diagnosi in un piano di ottimizzazione del sito web misurabile.