Se il tuo sito è lento, perdi clienti prima ancora che leggano cosa fai: chi aspetta torna su Google e apre il risultato successivo. Per sapere quanto è lento ti bastano 2 minuti su PageSpeed Insights. Poi puoi alleggerire da solo immagini, plugin e script, oppure rifare il sito se il problema sta nelle fondamenta.
Perché un sito lento ti fa perdere clienti
Pensa a chi ti cerca dal telefono, in macchina o in pausa pranzo, con due tacche di segnale. Apre due o tre risultati. Il primo che mostra subito cosa fai e come contattarti si prende la telefonata. Gli altri restano una pagina bianca.
- Contatti persi. Chi chiude la pagina prima che si carichi non ti chiama e non compila il modulo. E tu non sai nemmeno che è passato.
- Posizioni su Google. Google misura la velocità reale delle tue pagine con i Core Web Vitals, che fanno parte dei segnali di esperienza sulla pagina. Non sono l’unico fattore: prima vengono i contenuti. Ma tra due pagine utili allo stesso modo, quella più veloce parte avvantaggiata.
- Pubblicità sprecata. Se fai campagne a pagamento, ogni clic lo paghi anche quando la persona se ne va prima di vedere la pagina.
Come misurare la velocità del sito in 2 minuti
Lo strumento gratuito di Google si chiama PageSpeed Insights e non richiede installazioni.
- Apri pagespeed.web.dev.
- Incolla l’indirizzo della pagina che ti porta più clienti: di solito la home o la pagina del servizio principale.
- Premi “Analizza” e aspetta meno di un minuto.
- Guarda prima i risultati da mobile. Google usa la versione per telefono del sito per leggerlo e posizionarlo, e il telefono è il caso più difficile.
- Leggi la parte in alto, con i dati degli utenti reali, e poi quella sotto, con il punteggio da 0 a 100 del test di laboratorio.
In cima trovi un verdetto: la valutazione dei Core Web Vitals è superata oppure no. Se non lo è, subito sotto vedi quale dei tre numeri è fuori soglia.
I tre numeri che contano: i Core Web Vitals
I Core Web Vitals sono tre misure che Google usa per capire se una pagina è comoda da usare. Eccole tradotte in parole semplici.
| Cosa misura | Nome tecnico | Buono | Da migliorare | Scarso |
|---|---|---|---|---|
| Quanto ci mette a comparire il contenuto principale | LCP (Largest Contentful Paint) | entro 2,5 s | da 2,5 a 4 s | oltre 4 s |
| Quanto è pronta a reagire quando tocchi o clicchi | INP (Interaction to Next Paint) | entro 200 ms | da 200 a 500 ms | oltre 500 ms |
| Quanto resta ferma mentre si carica | CLS (Cumulative Layout Shift) | entro 0,1 | da 0,1 a 0,25 | oltre 0,25 |
Caricamento (LCP). È il tempo che passa da quando apri la pagina a quando compare l’elemento più grande nella parte visibile: di solito la foto in apertura o il titolo principale. Entro 2,5 secondi va bene.
Reattività (INP). Tocchi il menu, premi “Chiama”, apri una domanda delle FAQ: quanto ci mette la pagina a rispondere? INP osserva tutte le interazioni della visita e in pratica riporta la più lenta. Entro 200 millisecondi, cioè un quinto di secondo, la risposta sembra immediata.
Stabilità (CLS). Stai per toccare un pulsante e all’ultimo compare un banner che lo spinge giù: tocchi la cosa sbagliata. CLS misura quanto si spostano gli elementi mentre la pagina si carica. È un punteggio senza unità di misura: entro 0,1 va bene.
Per superare la valutazione non basta una visita fortunata: Google guarda il 75° percentile, cioè almeno 3 visite su 4 devono stare dentro la soglia, contando a parte telefono e computer. Se vuoi approfondire, la spiegazione ufficiale è su web.dev.
Dati di laboratorio e dati reali: perché non coincidono
PageSpeed Insights ti mostra due cose diverse, e spesso danno numeri diversi.
I dati reali (CrUX). Arrivano dal Chrome User Experience Report: sono i tempi misurati sui telefoni e sui computer di persone vere che hanno visitato il tuo sito con Chrome negli ultimi 28 giorni. Sono questi i dati che contano per Google. Se la pagina ha poche visite, la sezione può mancare: allora guarda il dato dell’intero dominio, che somma le visite di tutte le pagine. Per seguire l’andamento nel tempo c’è il rapporto Core Web Vitals di Search Console.
I dati di laboratorio (Lighthouse). Sono un singolo caricamento simulato, fatto dai server di Google con un telefono di fascia media e una rete mobile lenta. Da qui viene il punteggio da 0 a 100: da 90 in su è verde, da 50 a 89 è arancione, sotto 50 è rosso. In laboratorio nessuno tocca la pagina, quindi la reattività non si può misurare. Al suo posto trovi il tempo di blocco totale (Total Blocking Time): quanto a lungo il telefono resta occupato a eseguire codice invece di rispondere.
La regola pratica: i dati reali ti dicono se hai un problema, il laboratorio ti dice da dove viene. Sotto il punteggio PageSpeed elenca le voci che pesano di più: parti da lì.
Le cause tipiche di un sito lento
Ecco le sette cause tipiche. Spesso se ne sommano due o tre.
Immagini enormi
È il primo posto dove guardare. Una foto scattata col telefono o con la reflex può pesare diversi megabyte ed essere larga 4.000 pixel, mentre per riempire lo schermo di un telefono ne bastano poco più di mille. Il browser scarica tutto lo stesso. In più, i formati classici come JPEG e PNG pesano più dei moderni WebP e AVIF a parità di qualità.
Troppi plugin e script
Ogni plugin aggiunge una funzione, e spesso anche i suoi file di stile e di codice JavaScript. Molti li caricano su tutte le pagine, anche dove non servono: il modulo contatti si porta dietro il suo codice pure nella pagina “Chi siamo”.
Temi pesanti e page builder
I temi tuttofare, pensati per adattarsi a qualsiasi attività, contengono il codice di decine di funzioni che non userai mai. I page builder, gli editor a trascinamento, generano tanti blocchi annidati per ogni sezione. Il risultato è una pagina che sembra semplice ma sotto è pesante. E alleggerirla senza rifare le pagine è difficile.
Hosting economico
Su un hosting condiviso economico il tuo sito divide le risorse del server con molti altri. Se il server è lento a rispondere, tutto il resto parte in ritardo. Lo vedi quando PageSpeed segnala un tempo di risposta del server alto. Come riferimento, web.dev considera buono un tempo di 0,8 secondi o meno per ricevere il primo pezzo della pagina (TTFB).
Font esterni
Molti siti caricano i caratteri da server esterni, come Google Fonts, in quattro o cinque pesi diversi. Ogni peso è un file in più, preso da un altro indirizzo. Mentre arrivano, il testo può restare invisibile o cambiare forma all’improvviso, e la pagina si sposta. Meglio pochi pesi, ospitati sullo stesso server del sito.
Slider in apertura
Lo slider con tre o quattro foto che scorrono in cima alla home è spesso l’elemento più lento della pagina: immagini grandi, codice JavaScript per farle girare e un contenuto principale che compare tardi. In più, il messaggio che conta rischia di finire nascosto in una delle slide successive.
Chat, pixel e strumenti di tracciamento
La chat in basso a destra, il pixel di Meta, le mappe di calore, i tag di Google, il banner dei cookie: sono script di terze parti, scaricati da altri server. Messi insieme rallentano il caricamento e soprattutto la reattività: tocchi il menu e la pagina risponde in ritardo.
Cosa puoi sistemare da solo
Prima di tutto fai un backup completo del sito. Poi procedi un passo alla volta e rifai il test dopo ogni modifica.
- Alleggerisci le immagini. Ridimensionale alla misura in cui vengono mostrate (raramente servono più di 2.000 pixel di larghezza) e convertile in WebP. Non rimandare il caricamento della foto in apertura con il caricamento differito (lazy loading): è proprio quella che Google misura.
- Fai pulizia nei plugin. Disattiva quelli che non usi, poi eliminali. Se due plugin fanno la stessa cosa, tienine uno.
- Togli lo slider. Al suo posto metti una sola immagine, un titolo chiaro e un pulsante.
- Fai l’inventario degli script esterni. Chat, pixel, mappe, video incorporati: tieni solo quelli che usi davvero. La chat può partire dopo qualche secondo, la mappa può comparire solo al clic.
- Attiva la cache. Su WordPress si fa con un plugin di cache o dal pannello dell’hosting. La cache salva le pagine già pronte e le consegna senza ricostruirle a ogni visita.
- Chiedi all’hosting che versione di PHP usi. Se il sito gira su una versione vecchia, passare a una recente e supportata di solito lo rende più rapido. Prima controlla che tema e plugin siano compatibili.
Se dopo questi passaggi i Core Web Vitals da mobile diventano verdi, hai risolto. Ricorda che i dati reali coprono gli ultimi 28 giorni: il miglioramento si vede per intero dopo circa 4 settimane.
Quando conviene rifare il sito invece di aggiustarlo
A volte il problema non sta nei dettagli ma nelle fondamenta. Conviene rifare quando:
- hai già fatto la pulizia e da mobile la valutazione resta non superata;
- il peso viene dal tema o dal page builder, e per toglierlo dovresti comunque rifare tutte le pagine;
- ogni aggiornamento di un plugin rompe qualcosa e ormai hai paura di toccarlo;
- oltre a essere lento, il sito è vecchio: grafica datata, testi che non spiegano cosa fai, poche richieste di contatto.
Se ti riconosci in almeno due punti, leggi la guida su quando conviene rifare il sito e fai due conti con quella su quanto costa rifare un sito web. Se il tuo sito è su WordPress, ti serve anche il confronto tra WordPress e sito a codice.
Perché un sito a codice statico parte in vantaggio
Su un sito WordPress classico, a ogni visita il server esegue il codice PHP, interroga il database, monta la pagina e solo dopo la spedisce. La cache aiuta, ma è uno strato in più da configurare e tenere in ordine.
Un sito a codice statico funziona al contrario. Le pagine vengono costruite una volta sola, quando le pubblichi. Al visitatore arriva un file già pronto, spesso da una rete di server distribuiti vicina a dove si trova (CDN). Niente database da interrogare, niente plugin da eseguire.
Con Astro, il framework che usiamo, c’è un vantaggio in più: di base al browser non arriva codice JavaScript se una sezione non ne ha bisogno. E le immagini vengono preparate nelle misure giuste e nei formati moderni al momento della pubblicazione. Il risultato sono pagine che si aprono in meno di 1 secondo.
Non è magia. Se su un sito statico carichi dieci script di tracciamento, rallenta anche lui. Ma parte da zero invece che da un tema già pesante, e resta veloce finché aggiungi solo quello che serve. Se vuoi vedere come lavoriamo, dall’analisi alla messa online in 7–14 giorni, leggi il nostro metodo. Per il rifacimento completo trovi tutto nella pagina sul rifacimento del sito web.
Vuoi sapere quanto è lento il tuo sito?
Mandaci l’indirizzo. Entro 24 ore ti diciamo quanto è lento, cosa lo rallenta e se conviene sistemarlo o rifarlo. L’analisi è gratuita. Se poi decidi di rifarlo, la prima bozza arriva in 72 ore.