> Il sito e lento: come trovare il problema e risolverlo davvero

Il 53% degli utenti se ne va dopo 3 secondi

Un sito lento non e solo fastidioso: e un danno economico misurabile. Ogni secondo di ritardo nel caricamento riduce le conversioni, peggiora il posizionamento su Google e fa percepire il brand come poco affidabile. Secondo i dati di Google, un sito che passa da 1 a 3 secondi di caricamento vede aumentare il tasso di abbandono del 32%. Sopra i 5 secondi, la probabilita che il visitatore se ne vada supera il 90%.

Il problema e che "il sito e lento" non e una diagnosi — e un sintomo. Le cause possono essere decine e vanno cercate con metodo. Un approccio sistematico alla diagnosi delle performance e l unico modo per intervenire in modo efficace senza perdere tempo su ottimizzazioni che non spostano nulla.

Fase 1: misurare prima di toccare qualsiasi cosa

La prima regola delle performance web e: mai ottimizzare senza dati. Intervenire "a sensazione" porta quasi sempre a sprecare ore su problemi marginali mentre il vero collo di bottiglia resta intatto. Ecco gli strumenti da usare e cosa cercare in ciascuno:

Google PageSpeed Insights e Core Web Vitals

PageSpeed Insights analizza il sito sia con dati di laboratorio che con dati reali degli utenti Chrome. I tre Core Web Vitals da tenere sotto controllo sono:

• LCP (Largest Contentful Paint): quanto tempo ci mette l elemento piu grande visibile a caricarsi. Deve stare sotto i 2.5 secondi. Se e alto, il problema e quasi sempre un immagine hero non ottimizzata, un web font che blocca il rendering o un server lento a rispondere
• INP (Interaction to Next Paint): misura la reattivita del sito alle interazioni dell utente. Deve stare sotto i 200 millisecondi. Se e alto, di solito c e JavaScript pesante che blocca il main thread
• CLS (Cumulative Layout Shift): quanto si spostano gli elementi durante il caricamento. Deve stare sotto 0.1. Immagini senza dimensioni esplicite e font che si caricano in ritardo sono le cause piu comuni

Il pannello Network del browser

Apri i DevTools del browser (F12), vai sulla tab Network e ricarica la pagina. Qui vedi ogni singola risorsa scaricata, il suo peso e il tempo di download. Ordina per dimensione: spesso trovi subito il colpevole. Un immagine da 4 MB, un file JavaScript da 800 KB non minificato, un font caricato da un CDN lento.

Query log e profiling backend

Se il sito e dinamico (PHP, WordPress, Laravel, qualsiasi CMS), una parte significativa della lentezza potrebbe venire dal backend. Attiva il slow query log di MySQL con SET GLOBAL slow_query_log = 1; SET GLOBAL long_query_time = 0.5; per identificare le query che impiegano piu di mezzo secondo. Spesso una singola query senza indice e responsabile del 70% del tempo di risposta.

Fase 2: le cause piu comuni e come intervenire

Nella maggior parte dei casi il rallentamento viene da un mix di problemi, non da uno solo. Ecco i piu frequenti in ordine di impatto tipico, con le soluzioni concrete per ciascuno:

Immagini non ottimizzate — il colpevole numero uno

Nel 60-70% dei siti lenti che analizzo, le immagini sono il problema principale. Un file JPEG da 3 MB dove basterebbero 80 KB in WebP. Foto caricate direttamente dalla fotocamera a 4000x3000 pixel per essere mostrate in un riquadro da 400x300. La soluzione e un processo in tre passi:

• Convertire in formati moderni: WebP offre la stessa qualita di JPEG con il 25-35% di peso in meno. AVIF fa ancora meglio ma ha supporto browser leggermente inferiore. Strumenti come cwebp o squoosh.app rendono la conversione banale
• Ridimensionare alla risoluzione effettiva: se l immagine viene mostrata a 600px di larghezza, non serve caricarla a 3000px. Usare l attributo srcset per servire la dimensione corretta in base al dispositivo
• Lazy loading per le immagini sotto la piega: aggiungere loading="lazy" a tutte le immagini che non sono visibili nel primo viewport. Il browser le carichera solo quando l utente scrolla verso di esse

Troppe richieste HTTP e risorse non ottimizzate

Ogni file CSS, JavaScript, font e immagine richiede una connessione HTTP separata. Un sito con 40 file separati perde tempo solo nell overhead delle connessioni. Le soluzioni:

• Minificare e concatenare: unire piu file CSS in uno, piu file JS in uno, rimuovere spazi e commenti. Strumenti come Vite, Webpack o anche un semplice script con terser e cssnano
• Attivare la compressione Gzip o Brotli: aggiungere in .htaccess o nella config Nginx le direttive di compressione. Un file JS da 200 KB viene trasmesso come 40 KB compresso
• Cache del browser: impostare header Cache-Control con durata lunga per le risorse statiche (immagini, CSS, JS) e usare il cache busting con hash nel filename quando si aggiornano

Query SQL lente — il killer silenzioso del backend

Una singola query senza indice puo bloccare la pagina per secondi. I segnali tipici: la pagina e lenta anche quando le risorse statiche sono gia in cache, il Time To First Byte (TTFB) e superiore a 600ms, e il server ha carico CPU alto. Interventi concreti:

• Attivare il slow query log e analizzarlo con mysqldumpslow o pt-query-digest
• Usare EXPLAIN su ogni query lenta per verificare che usi gli indici corretti
• Aggiungere indici compositi sui campi usati in WHERE, ORDER BY e JOIN
• Evitare SELECT * e selezionare solo i campi necessari
• Implementare il caching dei risultati per query che cambiano raramente

Hosting inadeguato

Un shared hosting da 3 euro al mese non regge un sito con traffico reale. Se il TTFB e alto anche con una pagina statica HTML, il problema e il server. Un VPS con PHP-FPM e OPcache configurato bene cambia tutto. La differenza tra un hosting da 3 euro e uno da 20 euro si misura in centinaia di millisecondi per ogni richiesta — che moltiplicati per migliaia di visitatori fanno una differenza enorme.

Nessun caching applicativo

Rigenerare la stessa pagina identica a ogni visita e uno spreco di risorse. Una cache anche solo di 5 minuti riduce il carico del server drasticamente. Le opzioni vanno dalla cache full-page (salvare l HTML generato e servirlo direttamente) alla cache parziale (memorizzare i risultati di query pesanti o blocchi di pagina che cambiano raramente). In PHP, soluzioni come Redis o APCu rendono il caching veloce e affidabile.

Fase 3: verificare i risultati e monitorare nel tempo

Dopo ogni intervento, misura di nuovo con gli stessi strumenti della fase 1. Confronta i numeri prima e dopo. Le performance non sono un intervento una tantum: servono monitoraggio continuo e check periodici. Strumenti come Google Search Console segnalano automaticamente quando i Core Web Vitals peggiorano, e un test PageSpeed al mese tiene tutto sotto controllo.

L intervento piu efficace e quasi sempre partire dalle immagini e dal caching: sono i due fattori che da soli coprono il 60-70% dei problemi di lentezza nella maggior parte dei siti. Una volta risolti quelli, si affrontano le query lente e le ottimizzazioni del frontend. L obiettivo realistico e un LCP sotto i 2 secondi e un TTFB sotto i 400ms: raggiungibile su qualsiasi sito con gli interventi giusti.