Perché il tuo sito è lento: la guida per chi non è un sistemista

Un sito lento non è un dettaglio estetico: chi aspetta se ne va, e Google lo sa. Non serve essere sistemisti per capire perché succede: servono gli strumenti giusti e le domande giuste da fare a chi gestisce il server. Questa guida li dà entrambi.

Prima di tutto: come misurare la lentezza

PageSpeed Insights (pagespeed.web.dev) è lo strumento gratuito di Google: si inserisce l'indirizzo del sito e lui restituisce un punteggio da 0 a 100 più una serie di metriche tecniche, dette Core Web Vitals. Le tre che contano di più, con le soglie ufficiali di Google:

Metrica	Cosa misura	Buono	Da migliorare	Scarso
LCP (Largest Contentful Paint)	quanto tempo ci mette a comparire l'elemento più grande della pagina (di solito un'immagine o un titolo)	sotto 2,5 secondi è "buono", tra 2,5 e 4 secondi è "da migliorare", sopra 4 secondi è "scarso"
INP (Interaction to Next Paint)	quanto il sito impiega a rispondere a un clic o un tocco	inferiore a 200 millisecondi per essere considerato buono da Google. Tra 200ms e 500ms il sito necessita miglioramenti, mentre oltre 500ms l'esperienza utente è considerata scarsa
CLS (Cumulative Layout Shift)	quanto la pagina "salta" mentre carica (bottoni e testi che si spostano)	soglia "buona": sotto 0,1

PageSpeed Insights mostra due tipi di dati. I dati di laboratorio sono un test fatto sul momento, in condizioni standard: simulano le condizioni di un utente su connessione mobile 4G con dispositivo di fascia media. I dati di campo invece arrivano dai visitatori veri del sito nelle ultime settimane e sono quelli che Google usa davvero per decidere il posizionamento. Se il punteggio di laboratorio è alto ma i dati di campo sono rossi, il problema lo vedono i tuoi visitatori reali, non il test.

GTmetrix (gtmetrix.com) fa un lavoro simile e aggiunge un grafico "a cascata" (waterfall) che mostra ogni singolo file caricato dalla pagina, con i tempi. È utile per capire quale elemento rallenta tutto.

La tab Network del browser (tasto destro sulla pagina, "Ispeziona", poi la scheda "Network") è il livello più grezzo: ricarica la pagina e vedi, riga per riga, quanto ci mette ogni immagine, script o font a scaricarsi. Non serve capire il codice: basta guardare quali righe sono le più lunghe.

Cos'è il TTFB e perché è la prima cosa da controllare

In tutti e tre gli strumenti compare una sigla: TTFB, Time To First Byte. Misura il tempo che intercorre tra l'invio di una richiesta HTTP da parte del browser e la ricezione del primo byte di risposta dal server, cioè la velocità con cui il server inizia a rispondere, prima ancora che il browser possa mostrare qualcosa. In pratica: quanto ci mette il server a "svegliarsi", prima ancora che inizi a scaricare immagini o testo.

Una scala di riferimento diffusa per leggerlo: 0,1–0,2 secondi: ottimo; 0,3–0,5 secondi: buono; 0,6–0,9 secondi: nella media; 1–1,5 secondi: sopra la media; 1,6 secondi o più: molto male. Se il TTFB è alto, il problema non è nel browser di chi visita il sito: è nel server, nel database o nel codice che gira prima di rispondere. Elaborazione lato server, cache, database, infrastruttura, CDN o codice backend sono fra le aree da investigare.

Le sei cause più comuni, una per una

1. Hosting condiviso sovraffollato

Su un piano hosting condiviso il tuo sito gira sulla stessa macchina di centinaia di altri. Se uno di questi usa troppe risorse, rallenta anche il tuo.

Come riconoscerlo: TTFB alto (sopra 0,6-0,9 secondi) che varia molto da un'ora all'altra, senza che tu abbia cambiato nulla sul sito.

Cosa chiedere all'hosting: "Quanti siti ospitate sulla stessa macchina del mio piano, e quali limiti di CPU e memoria (RAM) ha il mio account?" Se non sanno rispondere con un numero, è già un segnale.

2. Plugin pesanti (o troppi plugin)

Ogni plugin aggiunge codice che il server deve eseguire a ogni visita. Non è questione di quantità in assoluto, ma di quanto lavoro fa ciascuno.

Come riconoscerlo: in PageSpeed Insights, la sezione "Diagnostica" elenca spesso gli script che bloccano il caricamento. In GTmetrix, il grafico a cascata mostra quali file (spesso nominati con il nome del plugin) pesano di più.

Cosa chiedere allo sviluppatore: "Puoi disattivare i plugin uno alla volta e rifare il test, per vedere quale fa la differenza?" È un test che si fa in pochi minuti e isola il colpevole senza bisogno di leggere codice.

3. Immagini non ottimizzate

Un'immagine scattata con uno smartphone può pesare 4-5 megabyte. Se il sito la mostra così com'è, il browser deve scaricare tutto quel peso prima di mostrarla.

Come riconoscerlo: nella tab Network del browser, ordina le righe per dimensione (colonna "Size"): se le immagini sono le righe più pesanti, è lì il problema.

Cosa chiedere: "Le immagini vengono compresse e ridimensionate automaticamente prima di essere pubblicate?" Esistono plugin e servizi che lo fanno senza intervento manuale.

4. Assenza di cache

La cache è una copia già pronta della pagina, salvata per evitare di ricalcolarla da zero a ogni visita. Senza cache, ogni visitatore fa ripartire tutto il lavoro del server: query al database, calcoli, generazione della pagina.

Come riconoscerlo: se il TTFB è alto alla prima visita e resta alto anche ricaricando subito la stessa pagina, probabilmente non c'è cache attiva (o non funziona).

Cosa chiedere: "Avete un sistema di cache lato server attivo? E se uso un plugin di cache sul CMS, è compatibile con la vostra configurazione?"

5. Distanza dal server

Se il server fisico è a Francoforte e chi visita il sito è a Palermo, i dati devono fare quel viaggio ogni volta. Più la distanza è grande, più aumenta la latenza, cioè il ritardo di rete.

Una CDN (Content Delivery Network) è una rete di server sparsi in diverse località geografiche che tengono una copia dei file del sito (soprattutto immagini, font, script) più vicino a chi li richiede, riducendo quella distanza.

Come riconoscerlo: se il sito è lento per i visitatori lontani dal server ma veloce per chi è vicino, è un problema di distanza.

Cosa chiedere: "Dove si trova fisicamente il server? Se il pubblico del sito è in più regioni o paesi, conviene attivare una CDN?"

6. Database non ottimizzato

Molti siti (WordPress, e-commerce, CMS in genere) tengono i contenuti in un database. Se le tabelle del database sono piene di dati vecchi, revisioni, spam nei commenti, o se mancano gli "indici" che velocizzano le ricerche, ogni pagina richiede più tempo per essere costruita.

Come riconoscerlo: TTFB alto soprattutto sulle pagine che mostrano molti contenuti dinamici (elenchi di prodotti, ricerche, pagine con molti commenti).

Cosa chiedere allo sviluppatore: "Il database viene pulito periodicamente dai dati vecchi e inutilizzati? Le query più lente sono state controllate?"

In sintesi: da dove partire

1. Testa il sito su PageSpeed Insights e guarda i dati di campo, non solo il punteggio.
2. Se LCP, INP o CLS sono fuori soglia, usa GTmetrix per vedere il grafico a cascata e capire quale file o richiesta pesa di più.
3. Se il TTFB è alto, il problema è lato server: porta i dati (numeri, non sensazioni) al tuo hosting o sviluppatore e fai le domande elencate sopra.
4. Rifai il test dopo ogni intervento: senza la cifra prima e dopo, non sai se hai davvero risolto.