Test di velocità del sito: leggere i numeri senza panico

Il momento è noto: qualcuno incolla l'indirizzo del sito in PageSpeed Insights, vede un numero rosso e scrive al fornitore. A volte il numero segnala un problema vero, altre volte misura una pagina che per i visitatori funziona benissimo. Questa guida spiega come distinguere i due casi in cinque minuti, e cosa conviene sistemare quando il problema c'è davvero.

Che cosa significa per voi

• Avete ricevuto un punteggio basso — qui trovate come capire se riguarda i vostri visitatori reali.
• State valutando un fornitore — i numeri aiutano, a patto di leggere quelli giusti.
• Volete migliorare le conversioni — la velocità incide prima del contenuto: chi chiude la pagina resta senza l'offerta.

Nella stessa schermata ci sono due misure diverse

La riga più importante è l'ultima. Il numero colorato che fa discutere appartiene alla simulazione, mentre la valutazione che Google usa guarda i dati reali. Un sito può avere un punteggio modesto e passare comunque la valutazione sui visitatori veri, o il contrario.

Quando la sezione dei dati reali resta vuota significa che la pagina ha troppo poco traffico per essere rappresentata: in quel caso restano la simulazione e il buon senso.

Le tre metriche, in una riga ciascuna

Il dettaglio che cambia la lettura: i valori si riferiscono al 75% delle visite. Passare la soglia significa che tre visitatori su quattro vivono quell'esperienza, quindi un risultato «quasi buono» nasconde una minoranza che sta decisamente peggio, spesso chi naviga con rete lenta o telefono datato.

Perché il numero balla

Chi ripete il test tre volte in dieci minuti ottiene tre punteggi diversi, e la cosa ha spiegazioni concrete: la rete del momento, il carico del server, le risposte dei servizi esterni, la cache fredda o calda. La regola pratica è semplice: tre prove e si guarda la mediana, oppure si guardano direttamente i dati reali, che per loro natura stanno fermi.

Cosa guardare, in ordine

1. Dati reali, scheda mobile: è il verdetto che conta.
2. Quale delle tre metriche resta fuori fascia: ognuna porta a cause diverse.
3. Le opportunità della simulazione, ordinate per risparmio stimato.
4. I servizi di terze parti elencati nel rapporto: spesso valgono metà del problema.
5. La stessa prova su due o tre pagine tipo: home, scheda prodotto, articolo. Una sola pagina racconta poco.

Le cause più frequenti, metrica per metrica

Due osservazioni dal lavoro quotidiano. La prima: il banner dei cookie incide spesso su due metriche insieme, perché arriva tardi e sposta il contenuto; progettarlo con uno spazio riservato risolve metà dei problemi di stabilità. La seconda: chat, mappe, video incorporati e pixel pubblicitari restano la causa più comune di reattività scadente, e il rimedio è caricarli dopo l'interazione invece che all'apertura.

Il percorso di lavoro che funziona

1. Misurate lo stato attuale su tre pagine tipo, dati reali e simulazione, annotando i valori.
2. Scegliete una metrica per volta, partendo da quella fuori fascia con più traffico coinvolto.
3. Intervenite sulle cause grosse: immagini, servizi esterni, risposta del server. Le microtimizzazioni vengono dopo.
4. Rimisurate in laboratorio subito, per la conferma tecnica.
5. Aspettate il mese e rileggete i dati reali: è lì che si vede il risultato.

Gli strumenti, e a cosa servono

Per un'impresa i primi due bastano quasi sempre: il rapporto in Search Console dice quante pagine stanno fuori fascia, e PageSpeed Insights dice perché. La prova si fa da pagespeed.web.dev: si incolla l'indirizzo, si attende mezzo minuto e si leggono le due schede, telefono e computer.

Un esempio concreto: questo sito

Per mostrare come si legge il risultato, ecco la misurazione della nostra pagina iniziale, rilevata a ottobre 2026.

Tre letture, utili più del punteggio in sé.

Il divario fra telefono e computer è normale. La scheda mobile simula una rete e un dispositivo più modesti: la stessa pagina passa da 0,4 a 2,2 secondi sull'elemento principale. Il numero da guardare resta quello del telefono, perché corrisponde a come arriva la maggior parte dei visitatori.

Lo zero sullo spostamento vale quanto la velocità. Un banner dei cookie, un'immagine senza dimensioni dichiarate o un carattere che cambia a caricamento avrebbero alzato quel valore: resta a zero perché ogni elemento ha il proprio spazio riservato fin dal primo disegno, banner compreso.

«Dati utenti reali assenti» è una condizione, invece che un errore. Un sito pubblicato da poco raccoglie troppe poche visite per entrare nella base dei dati reali: fino ad allora restano la simulazione e il confronto con sé stessi, prima e dopo ogni intervento.

Errori di lettura che costano tempo

• Inseguire il 100 su una pagina ricca, quando la fascia verde è già raggiunta.
• Giudicare dalla scheda desktop mentre il pubblico arriva dal telefono.
• Misurare una sola volta, con il risultato di una prova sfortunata.
• Misurare la home e concludere sul sito intero.
• Cambiare dieci cose insieme, senza sapere quale ha funzionato.
• Aspettarsi i dati reali il giorno dopo: la finestra è di 28 giorni.

Quando conviene farsi aiutare

Immagini da sistemare e qualche script da rimandare sono alla portata di chi gestisce il sito. Il lavoro diventa nostro quando il problema sta nella risposta del server, nel tema grafico, nel numero di servizi esterni o nella struttura del negozio: in quei casi misuriamo prima, interveniamo e rimisuriamo, consegnando i numeri di partenza e quelli di arrivo. È quello che descriviamo nella pagina restyling e manutenzione.

Se volete capire da dove nasce la lentezza del vostro sito, scriveteci dalla pagina preventivo con l'indirizzo delle pagine che vi interessano di più.

Fonti

• Google, documentazione su PageSpeed Insights e dati dell'esperienza utente di Chrome
• web.dev, definizioni e soglie di LCP, INP e CLS
• Google Search Central, rapporto Core Web Vitals in Search Console
• Lighthouse, documentazione delle verifiche di laboratorio

Verificato il 23.06.2026.