Sito lento: quali sono le cause e come risolverle

Un sito lento non ha una sola causa. Può aspettare il server prima di mostrare qualsiasi cosa, caricare un’immagine enorme, bloccare il browser con JavaScript oppure diventare instabile soltanto quando aumentano le visite. Applicare cache, comprimere file o cambiare hosting senza capire il sintomo rischia di spostare il problema e rende difficile verificare il risultato.

La soluzione parte da una diagnosi ripetibile: identificare quali pagine sono lente, per quali utenti, in quale momento e a causa di quale risorsa. Questa guida organizza i controlli per sintomo, così da collegare ogni rallentamento all’intervento più adatto e distinguere i problemi del server da quelli del browser o di servizi esterni.

Prima domanda: dove si manifesta la lentezza?

Non testate soltanto la homepage. Scegliete pagine rappresentative: articolo, servizio, categoria, prodotto, ricerca, modulo e checkout. Provatele da mobile e desktop, come utenti anonimi e autenticati, con cache calda e fredda. Annotate ora, dispositivo, rete, URL e azione compiuta: “il sito è lento” diventa così un problema osservabile.

Confrontate test di laboratorio e dati degli utenti reali. Il laboratorio riproduce condizioni controllate ed è utile per trovare una causa; i dati reali mostrano cosa accade su dispositivi e connessioni differenti nel tempo. Se i due risultati divergono, non scegliete quello più favorevole: investigate cache, posizione geografica, campione, periodo e template analizzato.

Sintomo 1: la pagina resta vuota prima di iniziare

Quando il browser attende a lungo il primo byte, la causa è spesso a monte del rendering: hosting saturo, PHP lento, query inefficienti, chiamate API bloccanti, cache assente o DNS problematico. Controllate tempi lato server, log, utilizzo di CPU e memoria, processi disponibili e comportamento nelle ore di picco.

Una cache di pagina può ridurre il lavoro per contenuti pubblici, ma non sostituisce la correzione di query o plugin inefficienti. Se il rallentamento riguarda solo amministrazione, ricerca o checkout, una cache generica potrebbe non intervenire. Profilate la richiesta lenta e verificate database, API e attività programmate prima di aumentare risorse alla cieca.

Sintomo 2: il contenuto principale appare tardi

Se intestazione e sfondo compaiono ma immagine o titolo principale arrivano dopo, esaminate la risorsa più grande visibile nella prima schermata. Un’immagine sovradimensionata, caricata in ritardo o scoperta troppo tardi dal browser può rallentare il Largest Contentful Paint. Lo stesso accade con slider, video di sfondo e blocchi generati da script.

Ridimensionate e comprimete l’immagine in base all’uso, fornite varianti responsive e non applicate caricamento differito alla risorsa principale. Evitate di nasconderla dentro fogli di stile o script quando può essere dichiarata chiaramente nella pagina. Ottimizzate anche il tempo del server: una risorsa leggera non può iniziare presto se l’HTML arriva tardi.

Sintomo 3: la pagina si vede ma risponde in ritardo

Pulsanti che reagiscono lentamente, menu bloccati e campi che scattano indicano spesso troppo lavoro sul thread principale del browser. Script del tema, page builder, tracciamenti, chat e animazioni possono essere eseguiti tutti insieme. Individuate le attività lunghe e collegatele al file o al servizio che le genera.

Rimuovete codice inutilizzato, suddividete le funzioni pesanti e caricate gli script soltanto dove servono. Ritardare tutto indiscriminatamente può rompere menu, consenso, moduli o misurazione. Dopo ogni modifica provate le interazioni importanti, inclusi tastiera, touch, validazione e navigazione indietro.

Sintomo 4: gli elementi cambiano posizione

Quando testo e pulsanti si spostano durante il caricamento, l’utente può cliccare l’elemento sbagliato. Le cause comuni sono immagini senza dimensioni riservate, banner inseriti sopra il contenuto, font che cambiano metrica e componenti caricati dopo. Il Cumulative Layout Shift misura questi spostamenti inattesi.

Dichiarate larghezza e altezza o proporzioni delle immagini, riservate spazio ai componenti dinamici e non aggiungete contenuti sopra ciò che è già visibile. Per i font scegliete fallback compatibili e una strategia di caricamento coerente. Verificate l’intera sessione, non soltanto l’avvio: cookie banner, form e messaggi possono causare spostamenti successivi.

Sintomo 5: il sito è lento soltanto su mobile

Un layout responsive non rende automaticamente leggero il sito. Telefoni meno potenti e reti instabili amplificano JavaScript, immagini, font e richieste esterne. Elementi nascosti con CSS possono comunque essere scaricati; video e animazioni tollerabili su desktop possono bloccare l’interazione mobile.

Testate dispositivi reali oltre all’emulazione. Controllate peso trasferito, numero di richieste, attività del processore e comportamento con risparmio dati o rete lenta. Riducete ciò che non aiuta il compito principale e progettate la prima schermata attorno all’informazione o azione più importante.

Sintomo 6: rallenta solo in alcune ore

Picchi di traffico, backup, scansioni, importazioni, cron e bot possono saturare risorse condivise. Se il test eseguito al mattino è buono e il sito cede durante una campagna, serve correlare i tempi di risposta con utilizzo del server, errori e numero di richieste. Un controllo occasionale non descrive un problema intermittente.

Programmate i lavori pesanti fuori dalle ore critiche, limitate bot aggressivi e verificate che le attività programmate non si accumulino. Per eventi prevedibili eseguite prove di carico autorizzate in staging o con il supporto dell’hosting. Non lanciate test aggressivi sul sito pubblico: potreste creare proprio il disservizio che state cercando di prevenire.

Sintomo 7: una funzione esterna blocca la pagina

Mappe, chat, recensioni, video, font, sistemi pubblicitari e API possono diventare lenti o indisponibili indipendentemente dal vostro server. Nel pannello di rete cercate richieste lunghe, errori e catene di reindirizzamento. Verificate anche se il servizio viene caricato su tutte le pagine pur servendo soltanto in una sezione.

Caricate le integrazioni dopo il contenuto essenziale, su richiesta o solo dove necessarie. Prevedete un comportamento alternativo quando il fornitore non risponde: un modulo principale non dovrebbe dipendere da una funzione decorativa. Ogni terza parte aggiunge anche implicazioni di privacy, sicurezza e continuità operativa.

Sintomo 8: WordPress peggiora dopo aggiornamenti o modifiche

Se la lentezza compare dopo un rilascio, confrontate data e ora con aggiornamenti di tema, plugin, PHP, contenuti e configurazioni della cache. Log applicativi e monitoraggio delle modifiche riducono il campo di ricerca. In staging riproducete l’ambiente e isolate il componente senza disattivazioni casuali sul sito pubblico.

Prima di aggiornare servono backup verificato, elenco delle funzioni da provare e rollback. Dopo il rilascio controllate pagine, moduli, ricerca, login, email e conversioni, non soltanto l’assenza di errori visibili. Un sito può sembrare funzionante mentre processi in background restano bloccati.

Immagini, font e CSS: ridurre senza danneggiare

Le immagini vanno generate nelle dimensioni necessarie, compresse e associate a descrizioni alternative quando informative. I font dovrebbero avere pochi pesi e stili, essere caricati in modo prevedibile e rispettare licenze e privacy. Nel CSS individuate ciò che blocca la prima visualizzazione, ma evitate estrazioni automatiche che eliminano regole usate dopo un clic o su template meno visitati.

Minificazione e unione dei file non sono obiettivi in sé: con protocolli moderni, un unico file enorme può ritardare codice non necessario. Misurate prima e dopo, svuotate le cache interessate e controllate visivamente più risoluzioni. La riduzione efficace nasce dall’eliminazione del superfluo, non soltanto dalla compressione.

Cache e CDN: quando aiutano davvero

La cache evita di rigenerare contenuti identici, mentre una CDN avvicina risorse statiche agli utenti e può assorbire traffico. Entrambe richiedono invalidazione corretta: dopo un aggiornamento, vecchie copie possono mostrare CSS, immagini o contenuti incoerenti. Documentate livelli e tempi di cache per sapere quale svuotare.

Pagine personalizzate, aree riservate, carrelli e risultati di ricerca richiedono regole dedicate. Provate cookie, utenti autenticati, geolocalizzazione e varianti linguistiche. Una configurazione aggressiva che serve dati personali o prezzi sbagliati è un incidente, non un miglioramento prestazionale.

Come verificare che il problema sia risolto

Ripetete lo stesso test con pagina, dispositivo, rete e stato della cache comparabili. Conservate data, versione e modifica effettuata. Poi monitorate i dati reali per un periodo sufficiente, separando template e dispositivi. Un singolo risultato PageSpeed può variare e non dimostra da solo un miglioramento stabile.

Verificate anche il risultato operativo: moduli inviati, telefonate, acquisti, errori, bounce e richieste di assistenza. La velocità serve alle persone e agli obiettivi del sito. Se un numero migliora ma una funzione smette di lavorare o il contenuto diventa meno leggibile, l’intervento deve essere corretto.

Checklist diagnostica

• Definire URL, dispositivo, rete e momento del rallentamento.
• Confrontare laboratorio, utenti reali e log del server.
• Distinguere attesa del server, caricamento, interazione e stabilità.
• Identificare la risorsa, query, script o servizio responsabile.
• Creare backup e riprodurre il problema in staging.
• Applicare una modifica alla volta con possibilità di rollback.
• Provare funzioni e conversioni dopo ogni intervento.
• Monitorare il risultato nel tempo e durante i picchi.

Per un intervento specifico su WordPress leggete come migliorare la velocità di WordPress. Se il problema riguarda le metriche di esperienza, consultate la guida ai Core Web Vitals; per un negozio online approfondite l’ottimizzazione tecnica di WooCommerce. LBCOMPANY esegue diagnosi e interventi per siti in tutta Italia: scoprite i servizi.