Test Velocità Sito Web - Page Speed Checker

Inserisci l’indirizzo della pagina da analizzare: otterrai il punteggio Google PageSpeed, i Core Web Vitals e la lista completa dei problemi con le soluzioni pratiche.

Indirizzo della pagina

Dispositivo simulato

Mobile Desktop

Google usa la versione mobile per il posizionamento: è quella consigliata.

Analizza la velocità

Test Velocità Sito Web – Analisi completa delle prestazioni con Google PageSpeed Insights

Il Test Velocità Sito Web di AnalisiSEO.org analizza qualsiasi pagina web tramite l'API ufficiale di Google PageSpeed Insights v5 e restituisce un report completo sulla velocità di caricamento: punteggio complessivo, metriche degli utenti reali, metriche di laboratorio, opportunità di miglioramento ordinate per impatto e diagnostica tecnica. Ogni voce è accompagnata da una spiegazione pratica e da istruzioni concrete su come intervenire. Funziona su qualsiasi sito, senza bisogno di accesso al codice o verifica di proprietà.

Perché la velocità è un fattore di posizionamento

I Core Web Vitals sono un fattore di ranking confermato da Google dal giugno 2021. Le tre metriche che li compongono — Largest Contentful Paint (LCP) per la velocità di caricamento, Interaction to Next Paint (INP) per la reattività e Cumulative Layout Shift (CLS) per la stabilità visiva — misurano l'esperienza reale degli utenti e vengono valutate al 75° percentile delle visite registrate dal Chrome User Experience Report (CrUX). Google non nasconde che la pertinenza dei contenuti, l'autorevolezza e i backlink restano i fattori primari, ma nelle SERP competitive dove più pagine offrono contenuti di qualità comparabile, i Core Web Vitals funzionano come un discriminante concreto: a parità di rilevanza, la pagina più veloce e stabile ha il vantaggio.

I numeri del Web Almanac 2025 rendono chiara la portata del problema: solo il 48% delle pagine mobile supera tutte e tre le soglie dei Core Web Vitals. Il LCP è la metrica più difficile, con appena il 62% dei siti mobile nella zona "buona". L'INP, che da marzo 2024 ha sostituito il vecchio First Input Delay, è la metrica su cui più siti falliscono: il 43% non raggiunge la soglia dei 200 millisecondi. Questo significa che oltre la metà del web mobile sta offrendo un'esperienza che Google classifica come "da migliorare" o "scarsa", e che intervenire sulla velocità posiziona il tuo sito nella metà migliore del web prima ancora di toccare i contenuti.

Analisi mobile e desktop

Lo strumento ti permette di scegliere il dispositivo simulato prima di avviare l'analisi. La modalità mobile è predefinita e consigliata, perché Google dal 2021 utilizza la versione mobile di un sito per determinare il posizionamento nei risultati di ricerca, sia per le query da mobile sia per quelle da desktop. È il cosiddetto mobile-first indexing: la versione mobile del tuo sito è la versione che conta per Google, anche quando l'utente cerca da un computer. Questo rende l'analisi mobile prioritaria in qualsiasi strategia di ottimizzazione.

L'analisi desktop è disponibile per chi vuole confrontare le prestazioni tra i due ambienti. Il confronto è spesso rivelatore: un sito può ottenere un punteggio eccellente su desktop grazie alla potenza hardware e alla connessione veloce, e crollare su mobile dove le risorse del dispositivo e la latenza di rete amplificano ogni problema di ottimizzazione. Lavorare sulle criticità evidenziate dall'analisi mobile migliora automaticamente anche l'esperienza desktop, mentre il contrario non è vero.

Il punteggio prestazioni: come leggerlo

Il report apre con il punteggio complessivo da 0 a 100 visualizzato in un indicatore circolare colorato: verde da 90 in su indica una pagina veloce, ambra tra 50 e 89 segnala margini di miglioramento, rosso sotto 50 indica una pagina lenta con problemi significativi. Il punteggio è calcolato da Google Lighthouse combinando tutte le metriche di laboratorio con pesi differenti. Il Largest Contentful Paint e il Total Blocking Time hanno il peso maggiore nella formula, il che significa che la velocità con cui appare il contenuto principale e la reattività della pagina sono i due aspetti che più incidono sul giudizio complessivo.

È importante capire che il punteggio Lighthouse è un indicatore diagnostico di laboratorio, non la valutazione ufficiale che Google utilizza per il ranking. Il posizionamento dipende dai dati di campo (CrUX), ovvero dalle misurazioni raccolte sui visitatori reali. Un punteggio Lighthouse di 95 è incoraggiante, ma se i dati CrUX al 75° percentile mostrano un LCP di 4 secondi perché i tuoi utenti reali navigano prevalentemente con smartphone economici su reti 4G instabili, è il dato CrUX a contare per Google. Lo strumento mostra entrambi i livelli di analisi proprio per permetterti di confrontarli e capire dove concentrare gli interventi.

Dati degli utenti reali (CrUX)

Se Google ha raccolto abbastanza dati di navigazione reale sulla pagina analizzata, il report mostra le metriche misurate sui visitatori veri degli ultimi 28 giorni. Sono i numeri che contano davvero per il posizionamento, perché riflettono l'esperienza reale e non una simulazione. I dati possono essere riferiti alla singola pagina o, se il traffico è insufficiente per quella URL specifica, all'intero dominio. Se il sito non ha ancora abbastanza traffico per i dati CrUX, viene mostrato un avviso onesto e l'analisi prosegue con i soli dati di laboratorio.

Le cinque metriche degli utenti reali sono le seguenti. Il Largest Contentful Paint (LCP) misura il tempo necessario perché compaia l'elemento più grande della schermata visibile — di solito l'immagine principale o il titolo. Per l'utente è il momento in cui sente che la pagina è carica. È uno dei tre Core Web Vitals con soglie a 2,5 secondi (buono) e 4 secondi (scarso). L'Interaction to Next Paint (INP) misura quanto velocemente la pagina risponde quando l'utente clicca, tocca o digita qualcosa. A differenza del vecchio FID che misurava solo la prima interazione, l'INP valuta tutte le interazioni durante l'intera visita e riporta la peggiore, rendendolo molto più rappresentativo dell'esperienza reale. Le soglie sono 200 millisecondi (buono) e 500 millisecondi (scarso). Il Cumulative Layout Shift (CLS) misura quanto gli elementi della pagina si spostano da soli durante il caricamento — il classico bottone che scappa via un attimo prima del clic, o il testo che salta in basso perché sopra è comparso un banner. È un valore numerico puro, non un tempo, con soglie a 0,1 (buono) e 0,25 (scarso).

Completano il quadro il First Contentful Paint (FCP), che misura il tempo di comparsa del primo elemento visibile sulla pagina — la prima conferma per l'utente che il sito sta rispondendo — con soglie a 1,8 secondi e 3 secondi, e il Time to First Byte (TTFB), che misura il tempo che il server impiega a inviare il primo byte di risposta. Se il TTFB è alto, tutto il resto del caricamento parte in ritardo, indipendentemente da quanto sia ottimizzata la pagina lato frontend. Le soglie sono 0,8 secondi (buono) e 1,8 secondi (scarso).

Metriche di laboratorio (Lighthouse)

Il test di laboratorio viene eseguito nel momento dell'analisi da Google Lighthouse su una connessione simulata standardizzata. È perfetto per individuare problemi tecnici specifici e per testare pagine con poco traffico che non dispongono di dati CrUX. Le metriche di laboratorio includono FCP, LCP e CLS con le stesse definizioni della sezione utenti reali ma misurate nella simulazione, più due metriche esclusive.

Il Total Blocking Time (TBT) misura la somma di tutti i momenti in cui la pagina è bloccata e non può rispondere all'utente perché il browser è occupato a eseguire JavaScript. È l'equivalente di laboratorio dell'INP: Lighthouse non può simulare interazioni reali, quindi misura il tempo totale di blocco del thread principale come indicatore della potenziale reattività. Le soglie sono 200 millisecondi (buono) e 600 millisecondi (scarso). Lo Speed Index misura la velocità con cui il contenuto si popola visivamente sullo schermo. Due pagine con lo stesso tempo totale di caricamento possono dare sensazioni diverse: quella che mostra prima i contenuti sembra più veloce, e lo Speed Index cattura esattamente questa percezione. Le soglie sono 3,4 secondi (buono) e 5,8 secondi (scarso).

Opportunità di miglioramento: la sezione più importante

Questa è la sezione più utile dell'intero report, quella che trasforma i numeri in azioni concrete. Le opportunità sono gli interventi che farebbero guadagnare più velocità alla pagina, ordinate per impatto decrescente: in cima sta quello che farebbe risparmiare più secondi. Per ogni voce viene mostrato il risparmio stimato in tempo e in peso, e in cima alla sezione appare il totale dei secondi recuperabili.

Lo strumento analizza 16 opportunità distinte, ciascuna con una spiegazione espandibile che spiega cos'è il problema e come risolverlo in pratica. Le risorse che bloccano la visualizzazione — file CSS o JavaScript che devono essere scaricati ed eseguiti prima che il browser mostri qualsiasi cosa — sono spesso la prima voce della lista. La soluzione è spostare gli script in fondo alla pagina o caricarli con gli attributi defer o async, e incorporare il CSS critico direttamente nell'HTML.

Le immagini non ottimizzate compaiono sotto diverse voci: formati obsoleti (JPEG e PNG anziché WebP o AVIF, che pesano il 25-50% in meno a parità di qualità), immagini non compresse, immagini sovradimensionate che inviano al telefono file pensati per schermi desktop, e immagini fuori schermo che vengono caricate subito anziché con lazy loading. Complessivamente, ottimizzare le immagini è quasi sempre l'intervento con il maggiore impatto singolo su LCP e peso della pagina.

Il CSS e JavaScript non utilizzato è un problema particolarmente diffuso sui siti basati su CMS come WordPress, dove ogni plugin aggiunge i propri fogli di stile e script a ogni pagina, anche quando quella pagina non ne ha bisogno. Eliminare i plugin superflui e caricare le risorse solo dove servono può ridurre drasticamente il peso e il tempo di blocco. Il CSS e JavaScript non minificato — file che contengono spazi, commenti e codice leggibile ma inutile per il browser — si risolve attivando la minificazione nel plugin di cache.

La compressione del testo (gzip o brotli) è spesso l'intervento con il miglior rapporto sforzo-risultato: attivare la compressione server-side riduce il peso di HTML, CSS e JavaScript del 60-80% durante il trasferimento, e sulla maggior parte degli hosting si configura con un singolo switch nel pannello di controllo. Il tempo di risposta del server, quando è troppo alto, indica un problema che si risolve con cache lato server, aggiornamento della versione PHP o, nei casi più gravi, un cambio di hosting. I redirect multipli aggiungono latenza a ogni passaggio intermedio, e la soluzione è far puntare i link direttamente all'URL finale, come descritto nella pagina del Redirect Checker.

Tra le opportunità meno ovvie ma potenzialmente molto impattanti, lo strumento segnala anche le GIF animate pesanti (sostituibili con video MP4 in autoplay muto), il JavaScript duplicato (la stessa libreria caricata più volte da plugin diversi), il JavaScript obsoleto tradotto per browser che nessuno usa più, e la mancata prioritizzazione dell'immagine LCP, risolvibile con l'attributo fetchpriority="high" e rimuovendo il lazy loading dall'elemento principale.

Diagnostica tecnica

La sezione diagnostica fornisce indicatori aggiuntivi che aiutano a capire perché la pagina si comporta in un certo modo. Non sono opportunità dirette con un risparmio stimato, ma informazioni di contesto che orientano l'analisi.

Il peso totale della pagina indica quanti dati il visitatore deve scaricare, con una soglia pratica di 3-4 MB oltre la quale il caricamento su rete mobile diventa problematico. La dimensione del DOM — il numero di elementi HTML nella pagina — segnala un problema quando supera i 1.500 elementi, perché un DOM molto grande rallenta il browser in ogni operazione di rendering, scroll e interazione. Il lavoro del processore e il tempo di esecuzione JavaScript mostrano quanto il browser spende a eseguire script e calcolare stili anziché mostrare contenuti, con un dettaglio dei file più costosi. Su smartphone di fascia media, questi tempi possono raddoppiare o triplicare rispetto a un laptop, rendendo critico un aspetto che su desktop potrebbe sembrare trascurabile.

La diagnostica include anche la cache dei file statici (se immagini, CSS e JavaScript hanno intestazioni di cache troppo brevi o assenti, vengono riscaricati a ogni visita), il caricamento dei font (se durante il download dei font personalizzati il testo resta invisibile — il cosiddetto "testo fantasma"), gli script di terze parti che aggiungono peso e attese non controllabili, l'identificazione dell'elemento LCP per concentrare le ottimizzazioni sul componente che determina la metrica più importante, e l'elenco degli spostamenti di layout specifici che contribuiscono al CLS.

Cache intelligente e gestione degli errori

I risultati dell'analisi vengono memorizzati nella cache per 12 ore. Questo significa che la seconda analisi dello stesso dominio con la stessa strategia (mobile o desktop) è istantanea, senza dover attendere nuovamente i 30-40 secondi dell'elaborazione Google. Se il test viene rieseguito entro questo intervallo, il report viene servito dalla cache con un avviso che indica la data e l'ora dell'analisi originale. Se Google PageSpeed è temporaneamente non raggiungibile, lo strumento mostra l'ultimo risultato disponibile dalla cache con un avviso, invece di presentare un errore.

Se la pagina non è raggiungibile, l'URL non è valido o il servizio Google è momentaneamente sovraccarico, viene mostrato un messaggio chiaro in italiano che suggerisce le possibili cause e invita a riprovare, anziché restituire un codice di errore tecnico incomprensibile.

Come sfruttare al meglio i risultati

L'errore più comune nell'utilizzo di uno strumento come questo è concentrarsi sul punteggio numerico e ignorare le sezioni che realmente fanno la differenza. Il punteggio è un orientamento rapido, ma sono le opportunità ordinate per impatto a dirti cosa fare e in che ordine farlo. Se la prima opportunità della lista ti farebbe guadagnare 2,3 secondi e la seconda solo 0,1, sai esattamente dove investire il tuo tempo.

Un altro approccio efficace è ragionare per template anziché per singola pagina. Google Search Console raggruppa gli URL con struttura simile e assegna al gruppo lo stato del peggior URL: se il template del blog ha un problema di LCP, quel problema si riflette su tutti gli articoli. Correggere il template una volta corregge centinaia di pagine contemporaneamente, ed è la leva con il massimo impatto e il minimo sforzo.

Analizza prima le pagine che generano traffico organico, sono quelle su cui Google sta attivamente misurando le prestazioni, e poi le landing page delle campagne a pagamento, dove un LCP lento riduce le conversioni e aumenta il costo per acquisizione. Confronta i risultati del tuo sito con quelli dei competitor diretti: se le loro pagine ottengono 90 su mobile e le tue 45, hai identificato un gap tecnico concreto che sta contribuendo alla differenza di posizionamento.