Cos'è Google PageSpeed Insights?
Google PageSpeed Insights (PSI) è uno strumento gratuito su pagespeed.web.dev che analizza le prestazioni di caricamento di qualsiasi pagina web. Inserite un URL, lo strumento esegue una serie di test e vi restituisce un punteggio da 0 a 100, insieme a metriche dettagliate e raccomandazioni.
Sotto il cofano, PSI usa Google Lighthouse — lo stesso motore che Shopify usa per il punteggio di velocità nel pannello admin. I due punteggi sono collegati ma non identici; spieghiamo esattamente come differiscono nel nostro confronto tra punteggio di velocità Shopify e PageSpeed. PSI simula un dispositivo mobile con CPU rallentata (4x slowdown) e una connessione 4G simulata, per testare come la pagina si carica in condizioni mobili realistiche.
PSI vi fornisce due tipi di dati:
🔬 Dati di laboratorio (sezione inferiore)
Risultati di test simulati con Lighthouse. Il punteggio, le 5 metriche e raccomandazioni specifiche. Utili per il debug, ma variano da un'esecuzione all'altra.
👥 Dati sul campo (sezione superiore)
Dati di utenti reali raccolti dagli utenti Chrome che hanno visitato il sito negli ultimi 28 giorni. Mostrano i Core Web Vitals (LCP, INP, CLS). È ciò che Google usa per il ranking SEO.
Per i merchant Shopify, PSI è lo strumento di velocità più importante, perché riflette direttamente le metriche che Google usa per il posizionamento nei risultati di ricerca. Il punteggio di velocità dell'admin di Shopify è essenzialmente una versione semplificata di questo stesso test. Volete un punto di partenza rapido prima di entrare nei dettagli? Eseguite un test di velocità gratuito sul vostro negozio per vedere a che punto siete adesso.
La soluzione rapida: migliorate tutte e 5 le metriche insieme
Ogni metrica qui sotto ha una correzione specifica — ma se volete migliorarle tutte senza passare ore in ottimizzazioni manuali, Thunder Page Speed Optimizer applica in automatico le correzioni più incisive per ogni metrica.
Come Thunder migliora ogni metrica PageSpeed:
Piano gratuito disponibile · Nessuna carta di credito richiesta · In media: +27 punti
Capire il punteggio complessivo (0-100)
Il grande numero in cima al report di PageSpeed Insights è una media ponderata di 5 metriche di prestazione. Non è un voto arbitrario — viene calcolato con una formula precisa, basata su dati di prestazione reali di milioni di siti web. Se cercate una panoramica più ampia su come Google valuta specificamente i negozi Shopify, la nostra guida Google PageSpeed Insights per Shopify copre il quadro completo.
Buono (verde)
Il 10% migliore dei siti web. Prestazioni eccellenti. Raro per i negozi Shopify con app, ma raggiungibile con Thunder + un tema leggero.
Da migliorare (arancione)
Margine di ottimizzazione, ma funzionale. Un obiettivo realistico per la maggior parte dei negozi Shopify. Thunder porta di norma i negozi in questa fascia.
Scarso (rosso)
Problemi significativi che danneggiano l'esperienza utente e potenzialmente la SEO. È dove finisce la maggior parte dei negozi Shopify non ottimizzati. Serve una correzione prioritaria.
Come viene calcolato il punteggio
Il punteggio complessivo è una combinazione ponderata di 5 metriche:
In base al sistema di punteggio di Lighthouse 12 (2026). I pesi potrebbero cambiare nelle versioni future.
LCP — Largest Contentful Paint
Cosa misura: il tempo che passa prima che l'elemento visibile più grande venga renderizzato nella viewport. Sui negozi Shopify di solito è l'immagine hero, una foto prodotto grande o il titolo principale.
Perché conta: l'LCP rappresenta il momento in cui il cliente percepisce che la pagina è "caricata". Un LCP veloce significa che vede subito i vostri prodotti. Un LCP lento significa che fissa uno spazio vuoto e potenzialmente se ne va. Per un approfondimento su come correggere questa metrica, leggete la nostra guida all'ottimizzazione dell'LCP su Shopify.
≤ 2.5s
Buono
2.5–4.0s
Da migliorare
> 4.0s
Scarso
Problemi LCP comuni su Shopify
- • Immagini hero da 2-5MB non ottimizzate per il web
- • CSS che blocca il rendering e impedisce al browser di disegnare qualsiasi cosa
- • Nessun preload dell'immagine LCP — il browser la scopre tardi
- • Risposta lenta del server (TTFB) che ritarda tutto ciò che segue
- • Web font che bloccano il rendering del testo finché non vengono caricati
⚡ La soluzione Thunder
Precarica l'immagine LCP così il browser inizia subito a scaricarla. Inserisce inline il CSS critico, così nulla blocca il rendering. Aggiunge font-display: swap per evitare ritardi legati ai font. Miglioramento tipico dell'LCP: 1-3 secondi.
🔧 Soluzione manuale
Aggiungete <link rel="preload"> per l'immagine hero. Comprimete le immagini sotto i <200KB. Estraete e inserite inline il CSS critico (complesso — diverso per ogni template di pagina). Ottimizzate la risposta del server semplificando i template Liquid. Preventivate 6-12 ore.
TBT — Total Blocking Time
Cosa misura: il tempo totale in cui il thread principale del browser è bloccato da task JavaScript di lunga durata. Durante il tempo di blocco la pagina è congelata — gli utenti non possono cliccare, scorrere o digitare.
Perché conta: il TBT ha il peso più alto (30%) nel calcolo del punteggio. Se il vostro TBT è alto, il punteggio complessivo sarà basso a prescindere da quanto siano buone le altre metriche. È direttamente correlato a quanto il negozio sembra "scattoso" o "bloccato". Su Shopify, un TBT alto è quasi sempre causato dal JavaScript — di app, temi e script di tracciamento di terze parti.
≤ 200ms
Buono
200–600ms
Da migliorare
> 600ms
Scarso
Problemi TBT comuni su Shopify
- • Script delle app eseguiti durante il caricamento della pagina (recensioni, pop-up, widget di chat)
- • JavaScript del tema eseguito in modo sincrono nell'<head>
- • Google Analytics, Meta Pixel e altri script di tracciamento eseguiti al caricamento
- • Bundle JavaScript grandi che richiedono 500ms+ per parsing ed esecuzione
💡 Punto chiave: la maggior parte dei negozi Shopify con TBT sopra i 600ms ha 10+ app che iniettano JavaScript. Ogni app può aggiungere solo 100-200ms di tempo di blocco singolarmente, ma insieme creano un collo di bottiglia enorme. Non potete rinviare a mano la maggior parte degli script delle app senza romperle — hanno dipendenze interne che non potete vedere. È il punto di forza numero 1 di Thunder: mappa queste dipendenze e rinvia in sicurezza.
⚡ La soluzione Thunder
Rinvia tutto il JavaScript che blocca il rendering — script delle app, script del tema e codice di tracciamento inclusi. Mappa le catene di dipendenze per garantire che nulla si rompa. Riduzione tipica del TBT: 60-80%. Questa singola ottimizzazione migliora spesso il punteggio complessivo di 15-25 punti.
🔧 Soluzione manuale
Aggiungete defer o async ai tag script. Rimuovete le app inutilizzate e fate un audit del codice residuo. Caricate gli script di tracciamento tramite Google Tag Manager con trigger ritardati. Preventivate 8-16 ore. Alto rischio di rompere le funzionalità delle app — la maggior parte degli script delle app non funziona se rinviata in modo ingenuo.
CLS — Cumulative Layout Shift
Cosa misura: quanto i contenuti visibili si spostano in modo inatteso durante il caricamento della pagina. È quella fastidiosa esperienza in cui state per cliccare un pulsante e tutto salta, perché sopra si è caricata un'immagine o una pubblicità.
Perché conta: il CLS vale il 25% del punteggio ed è uno dei tre Core Web Vitals che Google usa per il ranking SEO. Un CLS alto frustra gli utenti — cliccano dove non volevano, perdono il segno e percepiscono il sito come "rotto". È anche una delle metriche che Google misura sugli utenti reali, il che la rende particolarmente importante.
≤ 0.1
Buono
0.1–0.25
Da migliorare
> 0.25
Scarso
Problemi CLS comuni su Shopify
- • Immagini senza attributi width e height espliciti
- • Web font caricati tardi che fanno "rifluire" il testo (FOUT/FOIT)
- • Widget delle app che iniettano contenuti dopo il caricamento (pop-up, banner, badge di recensioni)
- • Contenuti dinamici caricati above the fold (barre di annuncio, selettori di valuta)
⚡ La soluzione Thunder
Aggiunge in automatico gli attributi width/height alle immagini che ne sono prive, applica font-display: swap per evitare il testo invisibile e ottimizza il preload dei font. La maggior parte dei negozi raggiunge un CLS sotto 0.1 dopo Thunder — spesso vicino allo zero.
🔧 Soluzione manuale
Aggiungete width e height a tutti i tag <img>. Usate font-display: swap nelle dichiarazioni @font-face. Riservate spazio ai contenuti dinamici con la proprietà CSS min-height. Precaricate i font critici. Preventivate 2-4 ore per un audit accurato.
FCP — First Contentful Paint
Cosa misura: il tempo che passa prima che il browser renderizzi il primo elemento di contenuto — qualsiasi testo, immagine, colore di sfondo o SVG. È il momento in cui lo schermo passa da completamente vuoto a mostrare qualcosa.
Perché conta: l'FCP è il primo segnale per l'utente che la pagina funziona. Un FCP veloce lo rassicura che il sito si sta caricando. Un FCP lento (3+ secondi di schermo bianco) gli fa pensare che il sito sia rotto e lo spinge a premere il pulsante indietro. Vale solo il 10% del punteggio, ma è la base — tutto il resto dipende dal fatto che il contenuto appaia per primo.
≤ 1.8s
Buono
1.8–3.0s
Da migliorare
> 3.0s
Scarso
Cosa blocca l'FCP su Shopify
I due blocchi principali sono il CSS che blocca il rendering (il browser non disegna nulla finché tutto il CSS nell'<head> non è caricato) e il JavaScript che blocca il rendering (gli script senza defer/async mettono in pausa il parsing dell'HTML). Su un tipico negozio Shopify, 200-500KB di CSS e diversi script devono essere scaricati prima che appaia il primo pixel.
⚡ La soluzione Thunder
Inserisce inline il CSS critico above the fold direttamente nell'HTML e rinvia il foglio di stile completo. Rinvia tutto il JavaScript che blocca il rendering. Risultato: il browser può disegnare i contenuti quasi subito dopo aver ricevuto l'HTML. Miglioramento tipico dell'FCP: 40-60% più veloce.
🔧 Soluzione manuale
Estraete il CSS critico per ogni template di pagina e inseritelo inline (molto complesso — esistono strumenti come Critical CSS, ma richiedono tooling di build). Rinviate tutti gli script. Riducete la dimensione del file CSS eliminando le regole inutilizzate. Aggiungete hint di preconnect per i domini esterni. Preventivate 8-12 ore, più manutenzione continua a ogni aggiornamento del tema.
SI — Speed Index
Cosa misura: quanto rapidamente il contenuto visibile della pagina riempie la viewport. A differenza dell'FCP (primo pixel) o dell'LCP (elemento più grande), lo Speed Index cattura la progressione visiva complessiva — quanto in fretta e con quanta fluidità la pagina passa da vuota a completamente renderizzata.
Perché conta: lo Speed Index è una misura olistica della velocità di caricamento percepita. Una pagina che si renderizza progressivamente (contenuti che appaiono pezzo per pezzo) avrà uno Speed Index migliore di una pagina vuota per 4 secondi che poi renderizza tutto in una volta. Vale solo il 10% del punteggio, ma riflette l'esperienza che i clienti provano davvero.
≤ 3.4s
Buono
3.4–5.8s
Da migliorare
> 5.8s
Scarso
Lo Speed Index migliora quando correggete le altre metriche. Un FCP più veloce fa partire prima la progressione visiva. Un LCP migliore fa apparire prima il contenuto principale. Un TBT più basso significa che la pagina non è congelata a metà del rendering. Pensate allo Speed Index come al "voto complessivo" del caricamento visivo — beneficia di ogni altra ottimizzazione.
⚡ La soluzione Thunder
Migliorando l'FCP (CSS critico inline), l'LCP (preload delle immagini) e il TBT (rinvio degli script), Thunder migliora naturalmente anche lo Speed Index. La pagina si renderizza in modo progressivo invece di aspettare il caricamento di tutte le risorse.
🔧 Soluzione manuale
Non esiste una singola "correzione dello Speed Index" — migliora quando intervenite su FCP, LCP e colli di bottiglia del rendering. Concentratevi sull'eliminazione delle risorse che bloccano il rendering e assicuratevi che il contenuto above the fold si carichi per primo. Tutte le correzioni manuali delle altre metriche contribuiscono a migliorare lo Speed Index.
Dati di laboratorio vs dati sul campo: quali contano di più?
PageSpeed Insights mostra due sezioni di dati distinte, e capire la differenza è fondamentale per prendere decisioni di ottimizzazione intelligenti.
🔬 Dati di laboratorio
- • Test simulato su un dispositivo controllato
- • CPU rallentata (4 volte più lenta) + 4G simulato
- • Misurazione singola in un dato momento
- • Varia di 5-10 punti tra un'esecuzione e l'altra
- • Mostra le 5 metriche + le opportunità
- • Ideale per: il debug di problemi specifici
👥 Dati sul campo (CrUX)
- • Utenti Chrome reali su dispositivi reali
- • Condizioni di rete reali in tutto il mondo
- • Media mobile su 28 giorni — molto stabile
- • Mostra i Core Web Vitals (LCP, INP, CLS)
- • Richiede traffico sufficiente per generare i dati
- • Ideale per: capire la vera esperienza utente
🎯 Per la SEO vincono i dati sul campo. Google usa i dati sul campo (Core Web Vitals) come segnale di ranking — non il punteggio di laboratorio. Se i dati sul campo mostrano LCP, INP e CLS superati (verde), le prestazioni reali sono a posto, a prescindere da cosa dice il punteggio di laboratorio. Il punteggio di laboratorio resta utile per capire cosa correggere, ma i dati sul campo vi dicono se è davvero un problema per gli utenti reali. Per un'analisi completa di ogni Core Web Vital e di come superarli, consultate la nostra guida ai Core Web Vitals su Shopify.
Non vedete dati sul campo? Significa che il negozio non ha abbastanza traffico Chrome perché Google possa generare un report (di norma servono alcune migliaia di visitatori mensili). In questo caso, basate le decisioni di ottimizzazione sui dati di laboratorio — e valutate il monitoraggio quotidiano di Thunder come sostituto per tracciare le prestazioni nel tempo.
Per un confronto di tutti gli strumenti di test della velocità oltre a PSI — inclusi GTmetrix, WebPageTest e Lighthouse — consultate la nostra guida ai migliori strumenti di test della velocità per Shopify. E se vi chiedete a quale punteggio puntare, guardate i nostri benchmark del punteggio di velocità Shopify per tema.
Leggere Opportunities e Diagnostics
Sotto le metriche, PSI vi offre due sezioni pratiche. Sono la vostra roadmap di miglioramento:
🎯 Opportunities (ordinate per risparmio stimato)
Sono raccomandazioni specifiche e concrete, con il risparmio di tempo stimato. Le più comuni per i negozi Shopify:
"Eliminate render-blocking resources"
Molto comuneFile CSS e JS nell'<head> che bloccano il rendering. La correzione principale di Thunder — rinvia gli script e inserisce inline il CSS critico.
"Reduce the impact of third-party code"
Molto comuneScript di app, analytics e tracciamento. Mostra il tempo di blocco totale per ciascun dominio di terze parti. Thunder li rinvia automaticamente.
"Properly size images"
ComuneImmagini scaricate a dimensioni maggiori di quelle visualizzate. Usate il filtro image_url di Shopify con parametri di dimensione per servire immagini della dimensione giusta.
"Reduce unused JavaScript"
ComuneCodice JS che viene scaricato ma non eseguito nella pagina corrente. Spesso da temi con bundle JS ricchi di funzionalità o app che caricano SDK completi.
"Serve images in next-gen formats"
OccasionaleUso di JPEG/PNG invece di WebP/AVIF. Il CDN di Shopify serve WebP automaticamente quando possibile, ma alcune immagini caricate a mano aggirano questo meccanismo.
🔍 Diagnostics (informazioni, non conteggiate nel punteggio)
Non influiscono direttamente sul punteggio, ma forniscono contesto utile:
- → "Avoid enormous network payloads" — Peso totale della pagina. Oltre i 3MB è un problema.
- → "Avoid an excessive DOM size" — Oltre 1,500 elementi segnala una pagina gonfia.
- → "Minimize main-thread work" — Tempo CPU totale per l'esecuzione del JS.
- → "Reduce JavaScript execution time" — Gli script che girano più a lungo.
Non cercate di correggere tutto in una volta. Concentratevi sulle prime 2-3 opportunità con il risparmio stimato più alto. Per la maggior parte dei negozi Shopify significa risorse che bloccano il rendering e codice di terze parti — entrambi gestiti in automatico da Thunder. Installate prima Thunder, ripetete il test, poi affrontate a mano le opportunità rimanenti. Per una procedura passo passo di ogni tecnica di ottimizzazione, consultate la nostra guida completa all'ottimizzazione della velocità.
Migliorate ogni metrica PageSpeed in 30 secondi
Thunder ottimizza TBT, LCP, CLS, FCP e Speed Index in automatico. Niente codice. Niente rischi. Miglioramento medio: +27 punti.
Aumentate il mio punteggio PageSpeed →Piano gratuito disponibile · Nessuna carta di credito richiesta · Compatibile con tutti i temi
Domande frequenti
Cos'è Google PageSpeed Insights?
Google PageSpeed Insights (PSI) è uno strumento gratuito su pagespeed.web.dev che analizza le prestazioni delle pagine web. Esegue Google Lighthouse per generare un punteggio di laboratorio (0-100) e mostra anche dati di utenti reali dal Chrome User Experience Report. Per i negozi Shopify è lo strumento di test della velocità più importante, perché Google usa gli stessi dati alla base dei segnali di ranking SEO.
Qual è un buon punteggio PageSpeed Insights per Shopify?
Un punteggio mobile di 50-70 è realistico per la maggior parte dei negozi Shopify con app installate. Punteggi di 70-90 sono raggiungibili con l'ottimizzazione (ad esempio con Thunder). Punteggi di 90+ sono eccellenti ma rari per i negozi con più app. Il negozio Shopify medio segna 30-50 su mobile. Non confrontatevi con i siti statici — i negozi Shopify hanno un overhead intrinseco dovuto alla piattaforma, alle app e ai contenuti dinamici.
Il punteggio di PageSpeed Insights influisce sulla SEO di Shopify?
Indirettamente sì. Google non usa il punteggio PSI direttamente come fattore di ranking. Usa invece i Core Web Vitals (LCP, INP, CLS) misurati su utenti reali come segnali di posizionamento. Queste metriche sono strettamente legate al punteggio PSI — migliorare una in genere migliora anche l'altra. Un negozio molto lento aumenta anche la frequenza di rimbalzo, che indirettamente danneggia il ranking. Thunder migliora sia i punteggi di laboratorio sia i Core Web Vitals reali.
Perché il mio punteggio PageSpeed mobile è molto più basso di quello desktop?
Il test mobile simula condizioni severe: un telefono di fascia media con CPU rallentata 4 volte e una connessione 4G simulata. Il JavaScript che richiede 200ms su desktop ne richiede 800+ su mobile simulato. La maggior parte dei negozi Shopify segna 20-40 punti in meno su mobile rispetto al desktop. È normale. Poiché Google usa l'indicizzazione mobile-first, il punteggio mobile è quello su cui concentrarsi.
Ogni quanto dovrei eseguire PageSpeed Insights sul mio negozio Shopify?
Eseguitelo dopo ogni modifica significativa (nuova app, aggiornamento del tema, aggiunta di sezioni/immagini). Per il monitoraggio di routine, Thunder traccia il punteggio ogni giorno in automatico. Se testate a mano, fate 3-5 test e usate la media — i singoli test possono variare di 5-10 punti per via delle condizioni di rete e del carico dei server. Un controllo mensile è una buona cadenza minima.
Qual è la differenza tra dati di laboratorio e dati sul campo in PageSpeed Insights?
I dati di laboratorio provengono da un test Lighthouse simulato — condizioni controllate, esecuzione singola, più severa della realtà. I dati sul campo provengono da utenti Chrome reali che hanno visitato il negozio negli ultimi 28 giorni — dispositivi veri, reti reali, comportamento autentico. Google usa i dati sul campo (Core Web Vitals) per il ranking SEO. I dati di laboratorio servono per il debug di problemi specifici. Contano entrambi, ma i dati sul campo riflettono la vera esperienza utente.
Thunder può migliorare tutte le metriche di PageSpeed Insights?
Thunder migliora direttamente il TBT (rinviando gli script), l'LCP (precaricando le immagini hero e inserendo inline il CSS critico), l'FCP (eliminando le risorse che bloccano il rendering), il CLS (impostando le dimensioni delle immagini e ottimizzando il caricamento dei font) e lo Speed Index (accelerando il caricamento visivo). L'unica metrica che Thunder non può migliorare direttamente è il tempo di risposta del server (TTFB), controllato dall'infrastruttura di Shopify e dalla complessità dei vostri template Liquid.
Perché ottengo punteggi PageSpeed diversi a ogni test?
PageSpeed Insights usa Lighthouse, che gira su infrastruttura cloud condivisa con una variabilità intrinseca. I tempi di risposta degli script di terze parti, il carico dei server di Shopify, il carico CPU dell'infrastruttura di test e le condizioni di rete fluttuano tra un test e l'altro. Differenze di 5-10 punti sono del tutto normali. Fate sempre 3-5 test e usate la media. Per un tracciamento affidabile, Thunder monitora il punteggio ogni giorno e mostra una media mobile.