Come misurare correttamente la velocità di un sito

Per misurare correttamente la velocità di un sito devi combinare due tipi di dati: i test di laboratorio, che caricano la pagina in condizioni controllate e ti aiutano nel debug, e i dati sul campo, che mostrano quanto è veloce il sito per i visitatori reali. Usa gli stessi strumenti, le stesse pagine e le stesse impostazioni prima e dopo ogni modifica, ripeti ogni test più volte e giudica il risultato in base alle mediane e ai dati degli utenti reali, non a un singolo punteggio. Questa guida spiega quale strumento usare per cosa e come fare un confronto prima e dopo di cui ti puoi fidare.

Dati di laboratorio e dati sul campo

Quasi tutta la confusione sulla velocità dei siti nasce dal mescolare questi due tipi di dati.

I dati di laboratorio provengono da un test eseguito su un dispositivo, con un profilo di rete e da una località. L'esempio più noto è Lighthouse. È alla base dei dati di PageSpeed Insights di Google, che corewebvitals.page utilizza, ed è integrato in Chrome DevTools. I test di laboratorio sono ripetibili e forniscono diagnosi dettagliate, quindi sono ideali per trovare le cause e verificare se un intervento funziona. Restano però una simulazione: una visita, con uno specifico profilo di rallentamento, dal luogo in cui gira il test.

I dati sul campo, detti anche real-user monitoring (RUM), provengono da visitatori reali sui loro telefoni, portatili e reti. Google li raccoglie dagli utenti di Chrome nel Chrome UX Report (CrUX). Li vedi in Search Console, e strumenti come corewebvitals.page li mostrano per qualsiasi URL. Sono i dati che Google usa per valutare l'esperienza sulla pagina, e rispecchiano la realtà, compresi dispositivi lenti e visitatori lontani. Il loro limite è la rapidità del riscontro: CrUX riporta una finestra mobile di 28 giorni, quindi una modifica fatta oggi impiega settimane a vedersi del tutto.

Usa i dati di laboratorio per lavorare e i dati sul campo per decidere se il lavoro ha dato frutti.

Lo strumento giusto per ogni compito

Non ti serve una grande cassetta degli attrezzi. Quattro strumenti coprono quasi tutto.

corewebvitals.page

corewebvitals.page mostra entrambi i tipi di dati per mobile e desktop, sulla base dei dati di PageSpeed Insights di Google: i dati sul campo di CrUX relativi agli ultimi 28 giorni, se il sito ha abbastanza traffico, e un test di laboratorio Lighthouse. Leggi prima i dati sul campo. Il punteggio di prestazioni da 0 a 100 appartiene solo alla parte di laboratorio e non è ciò che Google usa per il posizionamento.

Search Console

Il report Core Web Vitals di Google Search Console raggruppa i tuoi URL per stato (buono, da migliorare, scarso) in base ai dati sul campo. È il posto migliore per vedere quali modelli di pagina hanno problemi in tutto il sito, invece di testare gli URL uno per uno.

Chrome DevTools

I pannelli Performance e Network mostrano esattamente cosa succede durante un caricamento: quale richiesta blocca il rendering, quale script occupa il main thread, quanto impiega il server a rispondere. Il pannello Lighthouse esegue lo stesso tipo di test di laboratorio in locale. Usa una finestra in incognito, così le estensioni del browser non falsano i risultati.

Controlli da riga di comando

Per il tempo di risposta del server, curl ti dà un numero pulito e ripetibile, senza alcun carico del browser:

for i in 1 2 3 4 5; do
  curl -o /dev/null -s -w "%{time_starttransfer}\n" https://example.com/
done

Il comando stampa il Time to First Byte di cinque richieste consecutive. È particolarmente utile per verificare modifiche alla cache e al server. La guida su come ridurre il TTFB spiega come scomporre ulteriormente quel numero.

Quali metriche guardare

Concentrati su poche metriche che descrivono ciò che vivono i visitatori:

• Largest Contentful Paint (LCP): quando compare il contenuto principale. Buono significa 2,5 s o meno.
• Interaction to Next Paint (INP): quanto rapidamente la pagina reagisce a clic e tocchi. Buono significa 200 ms o meno. Misurabile solo nei dati sul campo.
• Cumulative Layout Shift (CLS): quanto salta il layout. Buono significa 0,1 o meno.
• Time to First Byte (TTFB): quanto rapidamente il server inizia a rispondere. web.dev consiglia 0,8 s o meno.

Google valuta i tre Core Web Vitals al 75° percentile dei caricamenti di pagina, separatamente per mobile e desktop. Questo significa che tre visite su quattro dovrebbero rispettare la soglia. La guida ai Core Web Vitals spiega da cosa dipende ogni metrica e come migliorarla.

Il peso totale della pagina e il tempo di "caricamento completo" sono meno utili di quanto sembrino. Una pagina può finire di caricarsi tardi per colpa di un widget di chat che nessuno nota, mentre un'immagine hero lenta, che notano tutti, incide appena sul tempo di caricamento totale.

Perché i risultati cambiano da un test all'altro

Se esegui tre volte lo stesso test di laboratorio e ottieni tre punteggi diversi, non c'è nulla di rotto. I motivi più comuni:

• Cache fredda o calda. La prima richiesta dopo un deploy o uno svuotamento della cache è spesso molto più lenta delle successive, sul tuo server e su qualsiasi CDN.
• Carico del server. Un test nelle ore di punta compete con i visitatori reali.
• Script di terze parti. Pubblicità, tag manager e widget di chat caricano ogni volta contenuti diversi.
• Località del test. I test di laboratorio basati sui dati di PageSpeed Insights di Google, compresi quelli su corewebvitals.page, partono da un data center di Google. Se il tuo server si trova su un altro continente, il test misura quella distanza.
• La macchina di test. Lighthouse in DevTools dipende dalla CPU del tuo computer e da tutto ciò che vi sta girando.

Un confronto prima e dopo affidabile

Quando cambi qualcosa, come la configurazione della cache, un nuovo tema o un CDN, segui una routine fissa perché il confronto sia corretto.

1. Scegli pagine rappresentative. Prendine una per ogni modello importante: homepage, pagina di categoria o elenco, pagina prodotto o articolo. Includi la landing page più visitata.
2. Annota le condizioni. Stesso strumento, stesso profilo di dispositivo (mobile e desktop separati), stessa località di test, se possibile stessa ora del giorno.
3. Prima riscalda, poi misura. Carica ogni pagina una volta e scarta quel risultato, a meno che tu non voglia misurare proprio le prestazioni della prima visita. Poi esegui almeno cinque test per pagina.
4. Usa la mediana. Prendi il valore centrale dei tuoi test, non il migliore. Per i test di laboratorio annota LCP, CLS, TTFB e Total Blocking Time.
5. Cambia una cosa alla volta. Se cambi hosting e tema insieme, non saprai quale dei due ha aiutato.
6. Ripeti esattamente la stessa routine dopo la modifica. Confronta le mediane pagina per pagina.
7. Conferma con i dati sul campo. Controlla nelle settimane successive i dati sul campo su corewebvitals.page e in Search Console. I miglioramenti di laboratorio che non si vedono per gli utenti reali non sono miglioramenti reali.

Se usi un CDN o una cache sull'edge, verifica che nei test "dopo" la pagina sia stata davvero servita dalla cache. Altrimenti stai misurando la tua origine, non la modifica.

Come ti aiuta fast.site

fast.site si mette davanti al tuo hosting attuale come rete edge con cache, ottimizzazione delle immagini e sicurezza. Mantieni il tuo hosting e punti i nameserver del dominio su fast.site; dopo la verifica, le richieste vengono servite attraverso l'edge.

Per le misurazioni contano due cose. Primo, ogni risposta contiene header che ti dicono cosa è successo: fs-cache mostra HIT, MISS o BYPASS, mentre fs-cache-age e fs-cache-hits indicano da quanto tempo e quante volte è stata usata la copia in cache. Così è facile confermare che il tuo test "dopo" arrivava davvero dalla cache. L'articolo su come verificare la cache ti mostra come fare.

Secondo, le statistiche nella dashboard riportano richieste, cache hit ratio, banda servita dall'edge rispetto all'origine, TTFB e tassi di errore per il tuo traffico. Insieme ai dati sul campo di corewebvitals.page, ottieni un confronto prima e dopo basato sui tuoi visitatori reali invece che su un singolo test.

Il modo migliore per giudicare l'effetto è misurarlo sul tuo sito con la routine descritta sopra. Puoi farlo per esempio durante una prova gratuita di 7 giorni. Piani e traffico incluso sono nella pagina dei prezzi.

Domande frequenti

Perché il punteggio PageSpeed è diverso ogni volta?

Il punteggio di prestazioni deriva da un singolo test di laboratorio, influenzato da carico del server, stato della cache, script di terze parti e variazioni della rete. Piccole differenze tra un test e l'altro sono normali. Esegui più test e usa la mediana, e per il quadro reale affidati alla sezione dei dati sul campo.

Serve un punteggio PageSpeed di 100?

No. Il punteggio è una sintesi di laboratorio e non viene usato come segnale di ranking. Conta che i visitatori reali ottengano buoni Core Web Vitals, e questo lo vedi nei dati sul campo. Inseguire gli ultimi punti costa spesso molta fatica senza alcuna differenza percepibile.

Perché non ci sono dati sul campo per il mio sito?

CrUX riporta dati solo quando un URL o un'origine ha ricevuto abbastanza visite da utenti di Chrome negli ultimi 28 giorni. I siti più piccoli o le pagine nuove spesso non raggiungono questa soglia. In quel caso affidati ai test di laboratorio e al tuo monitoraggio finché non ci sono dati sufficienti.

Quanto ci vuole perché i miglioramenti si vedano in Search Console?

I dati sul campo vengono raccolti in una finestra mobile di 28 giorni, quindi un intervento compare gradualmente e in modo completo solo dopo circa quattro settimane. Search Console può richiedere altro tempo per riconvalidare gli URL raggruppati. I test di laboratorio mostrano subito l'effetto, ed è per questo che li usi prima per verificare un intervento.

Devo testare da mobile o da desktop?

Entrambi, separatamente. Google li valuta separatamente, e i risultati da mobile sono di solito peggiori a causa di CPU e reti più lente. Se hai tempo per uno solo, comincia dal mobile.