Sito lento: come misurare la velocità e cosa fare, con i Core Web Vitals spiegati semplici

Apri il tuo sito dal telefono, in macchina o in un bar, e la pagina resta bianca qualche istante di troppo. Poi compare il testo, ma la foto grande arriva dopo e sposta tutto verso il basso, proprio mentre stavi per toccare il pulsante "Chiama". Se succede a te, succede ai tuoi clienti, e molti non aspettano: tornano indietro e aprono il risultato successivo. La buona notizia è che la velocità di un sito non è una sensazione: si misura con strumenti gratuiti, con numeri precisi che Google stesso usa e documenta. In questa guida vediamo come leggere quei numeri senza essere tecnici, quali sono le cause più frequenti di lentezza nei siti delle piccole e medie imprese e cosa conviene correggere per primo.

Perché la velocità conta, per le persone e per Google

Il primo motivo è commerciale. Chi cerca un'impresa dal telefono ha fretta e spesso una connessione non perfetta. Un sito che si apre in fretta e non "balla" mentre carica dà subito un'impressione di cura; uno che si blocca fa pensare che anche l'azienda lavori così.

Il secondo motivo riguarda la ricerca. Google raccomanda ai proprietari dei siti di ottenere buoni valori nei Core Web Vitals, le metriche con cui misura l'esperienza di caricamento, la reattività e la stabilità di una pagina, e scrive che questi segnali sono in linea con ciò che i suoi sistemi di classificazione cercano di premiare. Attenzione però a non esagerare: un sito velocissimo con testi poveri non supera una pagina più lenta che risponde meglio alla domanda. La velocità è una condizione per giocarsela, non il risultato da sola.

I tre numeri di Google, spiegati semplici

I Core Web Vitals sono tre. Ognuno risponde a una domanda che si farebbe chiunque guardi la pagina.

Fra "buono" e "scarso" c'è una fascia intermedia, che Google chiama "da migliorare". Due dettagli aiutano a non fraintendere i risultati:

• Conta il 75° percentile. Una pagina è considerata buona quando almeno tre visite su quattro rispettano la soglia. Non basta che vada veloce sul tuo computer in ufficio: deve andare bene anche per chi apre il sito con un telefono economico e il segnale debole.
• Telefono e computer si valutano separatamente. Spesso il sito è ottimo da computer e scarso da telefono. Il dato da guardare per primo è quello del telefono.

Se hai letto vecchie guide che parlano di FID (First Input Delay), sappi che dal 2024 Google lo ha sostituito con l'INP, che misura la reattività in modo più completo, durante tutta la visita e non solo al primo tocco.

Come misurare: dati reali e dati di laboratorio

Gli strumenti di Google mostrano due tipi di dati, ed è importante non confonderli.

• Dati reali (o "di campo"). Sono raccolti dalle visite vere di utenti di Chrome che hanno acconsentito a condividerli, e finiscono nel Chrome User Experience Report. Dicono come va il sito nella vita reale. Sono i dati che contano per i Core Web Vitals.
• Dati di laboratorio. Sono il risultato di un test simulato, fatto in quel momento su un dispositivo e una rete standard. Servono a trovare le cause e a provare le correzioni, ma non sono la "pagella" ufficiale.

PageSpeed Insights

Vai su PageSpeed Insights, incolla l'indirizzo di una pagina e avvia l'analisi. In alto, se il sito ha abbastanza visite, trovi i dati reali con LCP, INP e CLS e la scritta che indica se la valutazione è superata. Più in basso c'è il test di laboratorio, con il famoso punteggio da 0 a 100 e l'elenco dei suggerimenti. Se in alto compare un messaggio di dati insufficienti, è normale per molti siti piccoli: Chrome non ha raccolto abbastanza visite per dare un giudizio, e ti restano i dati di laboratorio come guida.

Il rapporto di Search Console

In Search Console, alla voce Core Web Vitals, Google raggruppa le pagine simili e le classifica come buone, da migliorare o scarse, separando telefono e computer. È lo strumento migliore per tenere d'occhio il sito nel tempo e per verificare, dopo una correzione, che il gruppo di pagine passi da "scarso" a "buono". Anche qui servono un po' di visite perché compaiano i dati.

Un dettaglio tecnico: il test di laboratorio, basato su Lighthouse, non può misurare l'INP, perché nessuno tocca davvero la pagina; al suo posto usa una misura vicina, il Total Blocking Time.

Cinque regole per misurare senza ingannarti

1. Prova più pagine, non solo la home. Spesso la home è curata e la pagina del servizio più cercato è lentissima, perché ha una galleria di quaranta foto.
2. Ripeti il test due o tre volte. I risultati di laboratorio variano da una prova all'altra. Guarda la tendenza, non il singolo numero.
3. Non inseguire il 100. Il punteggio di laboratorio è un indicatore. Passare da 92 a 100 raramente cambia qualcosa per i clienti; passare da un LCP di 6 secondi a uno di 2 cambia molto.
4. Annota il prima e il dopo. Prima di ogni modifica salva i risultati, con data. Senza confronto è facile convincersi di un miglioramento che non c'è.
5. Aspetta per i dati reali. I dati raccolti da Chrome riguardano un periodo di 28 giorni: dopo una correzione, il quadro reale si aggiorna gradualmente, non il giorno dopo.

Le cause più comuni e come si correggono

Nei siti di piccole aziende i problemi si ripetono. Li dividiamo secondo la metrica che peggiorano, così puoi partire dal numero rosso che vedi nel tuo test.

Se l'LCP è lento: la pagina principale arriva tardi

• Foto troppo pesanti. È la causa numero uno. Una foto scattata con il telefono può pesare diversi megabyte ed essere larga il triplo dello schermo su cui verrà vista. Va ridimensionata alla misura reale e salvata in un formato moderno come WebP o AVIF, che a parità di qualità pesa meno di un JPEG.
• Lo slider in apertura. Cinque immagini che scorrono in cima alla pagina significano cinque immagini grandi da scaricare, e un testo che nessuno legge perché cambia ogni tre secondi. Una sola foto ben scelta funziona meglio.
• L'immagine principale caricata "in ritardo". Il caricamento differito (lazy loading) è utile per le foto più in basso, ma web.dev sconsiglia di applicarlo all'immagine principale in alto: il browser la scaricherebbe per ultima. Alla foto principale si può anzi dare priorità alta.
• Un server che risponde piano. Se anche una pagina quasi vuota impiega molto a iniziare il caricamento, il problema sta prima della grafica: spazio online sottodimensionato, sito costruito con molte richieste al database, assenza di cache.
• Caratteri e fogli di stile che bloccano. Tre famiglie di caratteri, ognuna in sei spessori, scaricate da server esterni prima di mostrare il testo: si può quasi sempre ridurre a due caratteri e pochi spessori.

Se l'INP è alto: la pagina reagisce in ritardo

• Troppi programmi di terze parti. Finestra della chat, codici delle campagne pubblicitarie, mappe, widget delle recensioni, contatori, banner dei cookie molto pesanti: ognuno esegue codice sul telefono del visitatore. Fai l'inventario e chiediti, per ciascuno, se porta davvero qualcosa.
• Temi e componenti "tuttofare". Alcuni modelli grafici caricano su ogni pagina le funzioni di tutte le pagine, anche quelle che non usi.

Se il CLS è alto: gli elementi si spostano

• Immagini senza dimensioni dichiarate. Se il codice non dice quanto spazio occuperà la foto, il browser lo scopre solo quando arriva, e sposta il testo. Indicare larghezza e altezza risolve.
• Banner che compaiono in cima. Avvisi di promozioni o di spedizione gratuita inseriti dopo il caricamento spingono giù tutta la pagina. Meglio riservare loro uno spazio fisso dall'inizio.
• Video e mappe incorporati senza un riquadro di dimensione già definita.
• Caratteri che cambiano all'ultimo. Quando il carattere scelto arriva dopo e ha misure diverse da quello provvisorio, le righe si riallineano.

Il caso dei siti WordPress

WordPress è diffusissimo e può essere veloce, ma nei siti costruiti in fretta si accumulano tre problemi. Il primo è il numero di plugin: ognuno aggiunge codice, e capita di trovarne attivi trenta, metà dei quali installati per una prova anni fa. Il secondo sono i costruttori di pagine visuali, comodi per chi impagina ma spesso generosi di codice superfluo. Il terzo è l'assenza di una cache, cioè di copie già pronte delle pagine da servire senza rigenerarle a ogni visita.

Prima di aggiungere un ennesimo plugin "per la velocità", conviene togliere quelli inutili, verificare tema e versione del PHP con chi gestisce lo spazio online e attivare una cache configurata con criterio. E ricordare che gli aggiornamenti vanno fatti comunque, per sicurezza: un sito veloce ma vulnerabile non è un buon affare.

Un esempio: la home di un'azienda di serramenti

È un caso costruito per mostrare il metodo, non un cliente reale. Un'azienda di serramenti ha un sito con, in apertura, uno slider di cinque foto dei lavori, ognuna di circa 4 MB, un video di presentazione incorporato, la finestra di una chat e il widget delle recensioni. Da telefono PageSpeed Insights segnala un LCP di oltre 6 secondi e un CLS alto.

1. Lo slider diventa una sola foto, ridimensionata e salvata in WebP, con priorità di caricamento alta e dimensioni dichiarate.
2. Il video non si carica più all'apertura: al suo posto c'è un'anteprima con il tasto play, e il lettore arriva solo se qualcuno lo avvia.
3. Il widget delle recensioni, che spostava il contenuto, viene sostituito da tre recensioni scritte come testo e un link alla scheda Google.
4. La chat resta, ma si carica dopo che la pagina è pronta.

Il test di laboratorio successivo mostra un LCP intorno ai 2 secondi e la pagina ferma durante il caricamento. Nelle settimane seguenti si controlla in Search Console che anche i dati reali seguano.

Cosa non fare

• Togliere i testi per alleggerire. Il testo pesa pochissimo. Sono le immagini e i programmi esterni a rallentare, mentre i testi sono ciò che Google legge per capire la pagina.
• Cambiare spazio online alla cieca. Un server più potente non risolve una foto da 8 MB. Prima misura, poi decidi dove intervenire.
• Rifare tutto da capo per un problema di velocità. Spesso bastano interventi mirati. Se invece decidi davvero di rifare il sito, leggi prima la guida sul restyling senza perdere le posizioni.

E se il sito, oltre a essere lento, non compare proprio nelle ricerche, la velocità probabilmente non è il primo problema: parti dalla guida perché il sito non appare su Google.

Siti veloci con Faberweb

I siti delle nostre formule pronte nascono leggeri: le tue fotografie le inseriamo già alleggerite, le pagine sono pensate prima per il telefono e preparate per i motori di ricerca, con il lucchetto di sicurezza SSL compreso. Web Four costa 450 € + IVA e Six Four 550 € + IVA, con il primo anno tutto incluso: dominio, spazio online, caselle email, statistiche e la gestione per un anno di Search Console e degli strumenti di Bing, proprio dove si leggono i dati di velocità.

Se il sito ce l'hai già ed è lento, il lavoro dipende da come è costruito, da quante pagine e immagini ha e da quali servizi esterni carica: per questo lo valutiamo caso per caso e ti facciamo un preventivo. Con un canone di manutenzione possiamo poi seguire noi aggiornamenti, sicurezza e piccole modifiche. Tutti i dettagli sono nella pagina Siti web con Intelligenza Artificiale.

Scrivici dal modulo contatti o chiama il 0371 464 186, anche su WhatsApp. Lavoriamo con attività del Nord e del Centro Italia.

Domande frequenti