Perché il mio sito è lento? Le 6 cause e cosa le risolve

Un sito è lento quando una di sei cose richiede troppo tempo: la prima risposta del server, l'immagine principale, il momento in cui il browser la trova, il JavaScript da eseguire, gli script di altre aziende, oppure i font e un layout che continua a spostarsi. Ognuna ha la sua soluzione, e un intervento sulla causa sbagliata non cambia niente. Il limite che Google considera veloce è il Largest Contentful Paint (LCP), il momento in cui compare il contenuto principale: 2,5 secondi o meno per almeno il 75% delle visite, come lo definisce web.dev.

Questo articolo è per chi ha il sito e si chiede perché sia lento: un founder, un responsabile marketing, un titolare che se l'è sentito dire da un cliente. Qui trovi le sei cause, come capire in una decina di minuti qual è la tua e cosa risolve ciascuna.

Quanto è comune un sito lento?

Molto, soprattutto da smartphone. Il Web Almanac 2025 di HTTP Archive ha rilevato che il 48% dei siti su mobile supera tutti e tre i Core Web Vitals, contro il 36% del 2023. La metrica che fallisce più spesso è proprio il caricamento: da telefono il 62% dei siti ha un LCP buono, il 25% va migliorato e il 13% è scarso.

Le pagine poi pesano sempre di più. Nel 2025 la home page desktop mediana è arrivata a 2,9 MB, il 7,3% in più dell'anno prima, secondo il capitolo del Web Almanac sul peso delle pagine. La home page mobile mediana porta con sé 911 KB di immagini e 632 KB di JavaScript.

E la velocità si vede nei ricavi. Nello studio Milliseconds Make Millions, condotto da Deloitte e 55 per Google su 37 brand europei e americani e oltre 30 milioni di sessioni, un guadagno di 0,1 secondi sulla velocità mobile è andato di pari passo con un aumento del 9,1% degli utenti retail che passavano dalla scheda prodotto al carrello. Gli stessi utenti hanno speso il 9,2% in più.

Perché un server più veloce da solo raramente basta

La prima mossa di molti è passare a un piano di hosting più potente. Così si interviene su una sola causa su sei. Web.dev divide l'LCP in quattro parti: il tempo fino al primo byte, il ritardo prima che l'immagine principale inizi a caricarsi, il tempo per scaricarla e il ritardo prima che venga disegnata. In una pagina ben fatta, secondo web.dev, circa il 40% del tempo va alla risposta del server e il 40% al download della risorsa principale, con meno del 10% ciascuno per i due ritardi. Un server nuovo accorcia la prima parte. Se il tempo se ne va in una foto hero da 1,4 MB o in uno script che blocca il rendering, il piano nuovo costa di più e la pagina resta lenta.

L'ordine giusto quindi è: misurare, trovare la causa, intervenire su quella.

Come capisco perché il mio sito è lento?

Apri PageSpeed Insights, incolla l'indirizzo della pagina che conta di più (la home e la landing a cui puntano le campagne) e leggi il report in quest'ordine:

1. Il blocco in alto, i dati sul campo. È quello che hanno vissuto i visitatori reali di Chrome negli ultimi 28 giorni, al 75° percentile. Se dice che non ci sono dati, la pagina ha poco traffico e ti affidi al test di laboratorio più sotto.
2. Prima il mobile. È la scheda che di solito non passa.
3. Quale metrica è rossa. LCP rosso vuol dire caricamento lento. INP (Interaction to Next Paint) rosso vuol dire che la pagina reagisce in ritardo a tocchi e clic. CLS (Cumulative Layout Shift) rosso vuol dire che gli elementi saltano mentre la pagina si carica.
4. La scomposizione dell'LCP nella diagnostica. Mostra quanti millisecondi vanno a ciascuna delle quattro parti. La più grande indica la causa.

Dieci minuti bastano per sapere dove guardare. Le sei cause qui sotto sono nell'ordine in cui le controlliamo.

Causa 1: il server risponde troppo tardi

Il Time to First Byte (TTFB) è l'attesa prima che al browser arrivi qualcosa. Web.dev lo considera buono entro 0,8 secondi e scarso oltre 1,8. I motivi più frequenti: la pagina viene ricostruita dal database a ogni visita, un hosting condiviso è impegnato a servire altri siti, il server sta su un altro continente rispetto a chi visita, oppure una catena di redirect (da http a https, poi a www) aggiunge passaggi prima ancora che la pagina parta.

Cosa la risolve: servire le pagine da una cache, o generarle in anticipo quando il contenuto lo permette. Mettere davanti una CDN, così la risposta arriva da una città vicina a chi visita. Togliere i redirect inutili. Solo dopo valutare un server più grande.

Causa 2: l'immagine principale pesa troppo

Sulla maggior parte delle pagine marketing l'elemento visibile più grande è una foto hero. Caricata così com'esce dalla fotocamera o dal programma di grafica, può pesare diversi megabyte per un banner mostrato a 1.200 pixel di larghezza. Nella scomposizione, è la durata del caricamento della risorsa.

Cosa la risolve: esportare l'immagine alla misura in cui viene mostrata, con più versioni per i diversi schermi tramite srcset. Usare AVIF o WebP e comprimere. Poi fissare un limite di peso per la hero e controllarlo ogni volta che qualcuno cambia la foto, perché è lì che il problema torna.

Causa 3: l'immagine principale parte troppo tardi

Anche un'immagine leggera arriva tardi se il browser la scopre tardi. Il colpevole tipico è il lazy loading applicato a tutte le immagini, hero compresa: il browser aspetta il layout prima di richiederla. Il Web Almanac 2025 ha rilevato che tra il 16% e il 17% delle pagine carica in lazy loading proprio l'immagine dell'LCP. Lo stesso succede con le hero impostate come sfondo CSS o inserite via JavaScript, perché nell'HTML il browser non le vede.

Cosa la risolve: tenere loading="lazy" solo per le immagini sotto la piega. Mettere la hero nell'HTML come normale img e segnarla con fetchpriority="high", così il browser la scarica per prima.

Causa 4: troppo JavaScript

Un'immagine si scarica e si disegna. Il JavaScript si scarica, si analizza e si esegue, e mentre gira la pagina non risponde. Il Web Almanac lo dice in una riga: 100 KB di immagine sono pixel, 100 KB di JavaScript sono lavoro. La pagina mobile mediana si porta dietro 251 KB di JavaScript non compresso che non usa mai. Il JavaScript pesante si vede in un INP scarso, in un lungo ritardo di rendering, o in entrambi. Page builder, slider, librerie di animazione e temi che caricano ogni funzione su ogni pagina sono le fonti più comuni.

Cosa la risolve: togliere quello che la pagina non usa. Caricare il resto solo dove serve e rimandare tutto ciò di cui la prima schermata può fare a meno. Generare il contenuto sul server, così il testo non aspetta uno script per comparire. Il lato codice lo trovi nel dettaglio negli errori frontend che affossano il punteggio Lighthouse.

Causa 5: gli script di altre aziende

Analytics, tag manager, chat, heatmap, strumenti di A/B test, pixel pubblicitari, mappe e video incorporati. Ognuno è codice che arriva dal server di qualcun altro: non decidi tu quanto pesa né quando cambia. Secondo il capitolo del Web Almanac sulle terze parti, almeno il 90% delle pagine usa una o più terze parti. Si accumulano senza far rumore: ogni campagna aggiunge un pixel e nessuno toglie quello della campagna precedente.

Cosa la risolve: fare l'elenco di tutti i tag e di chi li ha chiesti. Togliere quelli i cui dati non legge nessuno. Caricare gli altri dopo che la pagina è utilizzabile, e sostituire gli embed pesanti (una chat, un player video) con un segnaposto leggero che carica quello vero al clic. Gli strumenti di A/B test che nascondono la pagina finché non scelgono la variante rallentano tutto: conviene verificare se c'è davvero un test in corso.

Causa 6: i font e un layout che si sposta

La home page mobile mediana carica 122 KB di font, sempre secondo il Web Almanac. Più pesi di un carattere personalizzato, presi da un altro dominio, possono trattenere il testo o farlo cambiare all'ultimo. Immagini senza dimensioni, banner inseriti in alto e pubblicità caricate tardi spingono giù il contenuto mentre lo si legge. Quello spostamento è ciò che misura il CLS, e sopra 0,25 il valore è scarso.

Cosa la risolve: caricare solo i pesi che il design usa e ospitarli sul proprio dominio. Usare font-display: swap con un font di riserva dimensionato in modo simile. Dare in anticipo le dimensioni a ogni immagine, embed e spazio pubblicitario, così lo spazio è riservato prima che il contenuto arrivi.

Un esempio concreto

Una scomposizione illustrativa, non di un cliente. Una home page ha un LCP di 4,2 secondi su mobile. PageSpeed Insights lo divide in 0,6 secondi di TTFB, 2,1 di ritardo nel caricamento della risorsa, 1,2 di durata del caricamento e 0,3 di ritardo di rendering. Il server va bene. La hero è in lazy loading e pesa 1,4 MB. Caricarla subito con priorità alta elimina gran parte dei 2,1 secondi; esportarla alla misura giusta in AVIF elimina gran parte dell'1,2. Due interventi su una sola immagine, nessun hosting nuovo, e la pagina può scendere sotto i 2,5 secondi.

La stessa pagina con un TTFB di 2 secondi chiederebbe il lavoro opposto: prima cache e CDN, poi l'immagine. Per questo la scomposizione viene prima di qualsiasi intervento.

Come tenere il sito veloce dopo l'intervento

La velocità si perde un poco alla volta: un tag nuovo, una sezione in più, una foto più pesante. La mantengono tre abitudini. Fissare un limite di peso per le pagine chiave e controllarlo prima di ogni rilascio. Rivedere il tag manager ogni trimestre con chi segue il marketing. Tenere d'occhio il report Core Web Vitals di Search Console, che legge gli stessi dati sul campo di PageSpeed Insights; dato che coprono 28 giorni, un miglioramento si vede lì circa un mese dopo.

Se dopo un redesign sono calati insieme velocità e posizionamento, la guida su perché il sito non compare più su Google dopo il redesign copre la parte di indicizzazione. Per il budget necessario a mantenere un sito in forma c'è quanto costa mantenere un sito web nel 2026. Per i siti in Next.js, Core Web Vitals su Next.js passa in rassegna gli strumenti del framework.