Google PageSpeed Insights: cos’è e perché serve in un audit SEO
Google PageSpeed Insights è uno strumento gratuito che analizza una singola pagina e restituisce due prospettive utili: dati raccolti su utenti reali quando disponibili e un test in ambiente controllato. Nell’audit SEO tecnico è prezioso perché aiuta a capire se l’esperienza percepita dagli utenti è fluida e quali aspetti tecnici stanno rallentando il caricamento o la reattività. La chiave è leggere i risultati nel contesto di obiettivi, stack tecnologico e pubblico del sito.
Un errore comune è concentrarsi solo sul punteggio complessivo. Quel numero è indicativo, ma non racconta da solo come si muovono le metriche che contano davvero per l’utente. Nell’audit si ragiona prima su come performano Core Web Vitals e sulle opportunità concrete di miglioramento, poi sullo score.
Come funziona PageSpeed Insights: lettura dei blocchi del report
Dati “field” da utenti reali
Quando esiste sufficiente traffico pubblico, PageSpeed mostra dati “sul campo” derivati da utenti reali. Questi valori rappresentano un periodo mobile di 28 giorni e sono segmentati per mobile e desktop. Sono il riferimento per capire se la pagina offre un’esperienza scorrevole agli utenti veri, con dispositivi, reti e località diverse.
Dati “lab” in ambiente controllato
Accanto ai dati reali, PageSpeed esegue un test in laboratorio su una macchina di riferimento. Questo test evidenzia colli di bottiglia tecnici e suggerisce interventi. Il risultato si presenta anche come punteggio complessivo su 100 e include metriche aggiuntive utili per il debug.
Perché lab e field possono differire
Il test in laboratorio usa condizioni fisse e un dispositivo emulato. I dati sul campo invece raccolgono esperienze su tante combinazioni reali. È normale che differiscano. In audit si usa il laboratorio per diagnosticare problemi e i dati reali per validare l’impatto sui visitatori.
Metriche da conoscere: Core Web Vitals e indicatori diagnostici
Core Web Vitals: LCP, INP e CLS
Largest Contentful Paint (LCP): misura quando l’elemento principale della pagina diventa visibile. Obiettivo realista: restare entro 2,5 secondi nel 75° percentile delle visite.
Interaction to Next Paint (INP): valuta la reattività complessiva agli input dell’utente. Per un’ottima esperienza è consigliabile stare a 200 millisecondi o meno al 75° percentile.
Cumulative Layout Shift (CLS): quantifica gli spostamenti imprevisti del layout. Valori a 0,1 o inferiori indicano stabilità visiva accettabile.
Altre metriche utili nel report
First Contentful Paint (FCP) aiuta a capire l’avvio del rendering; Total Blocking Time (TBT) fotografa quanto la pagina rimane bloccata da JavaScript; Speed Index e Time to Interactive completano la diagnosi. TBT è spesso un buon surrogato di problemi che impattano la reattività sul campo.
Interpretare lo score senza farsi ingannare
Il punteggio di PageSpeed varia perché dipende da condizioni di test, aggiornamenti del motore di analisi e peso delle metriche nel tempo. Usalo come termometro per capire se gli interventi vanno nella direzione giusta, non come traguardo assoluto. Nell’audit SEO si fissano target basati su LCP, INP e CLS al 75° percentile e si misura in modo continuativo.
È normale trovare siti con ottime posizioni organiche e punteggi PageSpeed non perfetti, o viceversa. Quello che conta è l’esperienza reale e il contributo al business: conversioni, engagement, percorso dell’utente. L’equilibrio corretto è migliorare ciò che incide sulla UX e sulla SEO, senza inseguire forzatamente il 100/100.
Procedura pratica: come usare PageSpeed in un audit SEO
1) Seleziona URL e varianti critiche
Categorizza template e pagine ad alto impatto. Per esempio: homepage, pagine categoria, schede prodotto, pagine contenuto. Su ciascuna analizza versione mobile e desktop, preferendo i giorni e le ore con traffico nella media.
2) Esegui i test e salva le evidenze
Esegui più run per contenere la variabilità del punteggio, quindi conserva screenshot e JSON del report. Per l’audit è utile trascrivere le soglie e i valori di LCP, INP e CLS, oltre alle “Opportunità” suggerite.
3) Confronta field e lab
Se i dati reali mostrano problemi, approfondisci nel laboratorio fino a isolare le cause. Se il laboratorio segnala rallentamenti ma sul campo tutto è positivo, verifica il pubblico: hardware, rete, geografie e cache potrebbero spiegare lo scarto.
4) Incrocia con Search Console e CrUX
Usa il report Core Web Vitals di Search Console per capire se l’insieme delle pagine simili passa l’assessment. Per il confronto storico sull’origine, aggiungi dashboard dedicate basate su dati reali quando disponibili.
5) Prioritizza gli interventi
Ordina le attività per impatto e sforzo. Tipicamente: ridurre JavaScript bloccante, migliorare TTFB e dimensione dell’hero image, controllare font e layout per evitare spostamenti. Collega ogni intervento a una metrica bersaglio e a un template.
Ottimizzazioni tecniche guidate dalle metriche
Ridurre LCP
Individua l’elemento “più grande” che diventa visibile per primo, spesso l’immagine hero o un blocco titolo. Riduci il peso dell’immagine con formati moderni, pre-carica la risorsa critica con preload, applica Critical CSS e posticipa il resto. Ottimizza il TTFB con caching a livello di server e CDN.
Abbassare INP
Scomponi i compiti JavaScript lunghi, elimina listeners non necessari, adotta tecniche di input responsiveness come scheduler e priorità agli aggiornamenti visivi. Per interfacce complesse rimanda l’idratazione, carica in modo differito parti non interattive e usa componenti senza overhead dove possibile.
Stabilizzare CLS
Riserva sempre spazio a immagini e embed con attributi di dimensione. Evita l’iniezione di banner sopra il contenuto già renderizzato. Carica i font con fallback coerenti usando font-display e evita variazioni impreviste di dimensione testo.
Dispositivi mobili, desktop e pubblico reale
La maggior parte dei problemi critici nasce su mobile perché le reti sono più variabili e l’hardware è più debole. Quando pianifichi gli interventi, metti il focus su mobile e valida su desktop. Se il sito ha pubblico internazionale, considera un CDN e ottimizzazioni di rete come preconnect verso domini terzi pesanti.
Strumenti esterni che completano PageSpeed Insights
Dentro Chrome puoi lanciare audit con Lighthouse e diagnosticare nel dettaglio il main thread. Per monitorare l’andamento nel tempo dai dati reali puoi usare soluzioni basate su CrUX o sistemi RUM proprietari. Per un’analisi “a raggi X” dei caricamenti è utile testare anche con strumenti di profilazione della rete e con verifiche dal server di produzione.
Prevedi una pipeline di test ripetibili in CI per evitare regressioni: integra controlli sulle pagine chiave e soglie minime di performance prima dei rilasci importanti.
PageSpeed Insights e CMS: linee guida pratiche
Temi, plugin e script
Scegli temi leggeri e mantieni solo le dipendenze strettamente necessarie. Evita librerie duplicate, carica script in modulo quando possibile e differisci quelli non essenziali. Per il tracciamento, usa un solo tag manager e consolida i pixel.
Immagini, font e iconografia
Automatizza la conversione a formati moderni e il resize per i breakpoints del layout. Per i font, limita le varianti, self-host quando opportuno e applica il fallback coerente per ridurre sfarfallii. Valuta icone in SVG inline per eliminare round-trip esterni.
Cache, CDN e rete
Abilita cache server-side e client-side con scadenze adeguate. Imposta un CDN con compressione, HTTP/2 o HTTP/3 e ottimizzazione del TLS. Preconnetti domini terzi impegnativi e anticipa le risorse critiche con prefetch mirati.
Una checklist essenziale per l’audit con PageSpeed Insights
- Conferma obiettivi: definisci target per LCP, INP, CLS al 75° percentile e per le pagine chiave.
- Mappa template critici: homepage, categorie, schede, pillar content, landing.
- Esegui test multipli mobile e desktop, salva JSON e screenshot.
- Incrocia risultati con il report Core Web Vitals e con dashboard su dati reali.
- Prioritizza interventi per impatto su LCP, INP e CLS, poi valuta lo score.
Errori da evitare quando leggi PageSpeed Insights
Non confrontare punteggi tra siti che servono pubblici diversi e stack distanti. Non fissarti su “100/100” sacrificando UX, accessibilità o brand. Non ignorare l’assetto mobile. Non applicare in blocco ogni suggerimento senza test A/B. Ogni sito ha priorità e vincoli propri.
Casi tipici di colli di bottiglia e soluzioni
Se il problema è LCP alto, verifica dimensione dell’hero image, decomposizione del CSS e TTFB del server. Se INP è alto, guarda i task lunghi nel main thread, l’eccesso di script, la latenza dei terzi. Se CLS è alto, assegna dimensioni a immagini e slot pubblicitari, blocca gli spostamenti sopra il contenuto già visibile.
Per siti con molte dipendenze, valuta lo splitting dei bundle, il lazy import di componenti non critici e la riduzione di polyfill caricati inutilmente su browser moderni.
Due tabelle mentali per decidere le priorità
- Problema che impatta l’utente reale e appare tra le Opportunità: alta priorità.
- Problema che peggiora solo lo score, senza riscontro nel campo: media o bassa priorità.
- Intervento che migliora più template contemporaneamente: priorità anticipata.
- Intervento che rompe cache o SEO criticamente: richiede test e rollout graduale.
FAQ
PageSpeed Insights influisce direttamente sul ranking su Google?
No. PSI è uno strumento di misurazione e diagnosi. Ciò che può incidere sul ranking è la qualità dell’esperienza misurata dai Core Web Vitals e da molti altri fattori SEO. Usa PSI per migliorare l’esperienza, non come fattore diretto di ranking.
Qual è un buon obiettivo per LCP, INP e CLS?
Punta a LCP entro 2,5 secondi, INP a 200 millisecondi o meno e CLS a 0,1 o meno, tutti al 75° percentile per mobile e desktop. Sono soglie accettate a livello internazionale e danno un obiettivo chiaro al team.
Perché il mio punteggio cambia da un test all’altro?
La variabilità dipende da rete, hardware, latenza della regione di test e aggiornamenti del motore di analisi. Esegui più run, calcola una media e guarda soprattutto ai pattern nelle metriche, non al singolo numero.
Cosa significa “dati insufficienti” nel riquadro dei dati reali?
Vuol dire che l’URL non ha ancora abbastanza visite pubbliche per mostrare valori affidabili. In questo caso PSI può mostrare il riepilogo a livello di dominio o solo i dati di laboratorio. Nel frattempo monitora con strumenti sul tuo sito.
Devo ottimizzare prima mobile o desktop?
Metti al primo posto il mobile. Reti e device meno performanti fanno emergere più facilmente colli di bottiglia. Una volta risolti su mobile, la versione desktop in genere beneficia in modo naturale.
Che differenza c’è tra TBT e INP?
TBT è una metrica di laboratorio che somma il tempo in cui la pagina è bloccata dai task JavaScript. INP è una metrica sul campo che misura quanto la pagina risponde davvero agli input. Ridurre TBT tende a migliorare anche INP ma non sempre in modo automatico.
Gli script di terze parti quanto pesano?
Molto, soprattutto su mobile. Ogni script aggiunge lavoro al main thread e richieste in rete. Carica solo ciò che serve, differisci il superfluo e preferisci integrazioni leggere. Controlla regolarmente tag manager e pixel non usati.
Quando ha senso usare un CDN?
Se il pubblico è distribuito su più aree geografiche o se il TTFB è alto, un CDN riduce la latenza e alleggerisce il server di origine. È spesso uno dei modi più rapidi per migliorare LCP.
Come gestire i font senza peggiorare la stabilità del layout?
Limita le varianti, usa formati moderni, attiva font-display per un fallback coerente, valuta il self-host per controllare la cache. Evita font che cambiano troppo le dimensioni rispetto al fallback.
Quali pagine analizzare per prime in un sito ampio?
Parti da quelle con più traffico o valore economico: homepage, categorie ad alto traffico, schede bestseller, pagine che trainano lead. Migliorare i template condivisi propaga il beneficio su molte pagine in poco tempo.
Risorse esterne consigliate
Approfondimenti utili: PageSpeed Insights, Web Vitals, CrUX su PageSpeed, Guida a INP, Guida a LCP, Guida a CLS, Report Core Web Vitals.
