Quando un sito è lento bisogna prima identificare dove nasce l’attesa: server, risorse dell’account, PHP, database, plugin, tema, cache, servizi esterni o rete del visitatore. Cambiare piano hosting o disattivare plugin a caso può mascherare il problema senza risolverlo. La procedura corretta consiste nel misurare, confrontare e modificare un solo elemento alla volta.
Un sito può essere veloce per alcuni utenti e lento per altri, rallentare solamente nel pannello di amministrazione oppure mostrare prestazioni scarse durante importazioni e picchi di traffico. Per questo motivo la frase “il sito è lento” non è ancora una diagnosi: bisogna stabilire quale pagina, in quale momento e in quale fase si verifica il ritardo.
Prima distinzione: il sito è lento o non risponde?
Un rallentamento e un’interruzione completa richiedono controlli diversi. Se il browser attende diversi secondi ma alla fine mostra la pagina, il processo potrebbe essere occupato da PHP, database o chiamate esterne. Se invece compaiono errori 500, 503, 504 o 508, bisogna partire dal codice visualizzato e dai log.
| Sintomo | Possibile area | Primo controllo |
|---|---|---|
| Pagina lenta ma raggiungibile | PHP, database, plugin, cache | Tempo di risposta e log |
| Errore 508 | Entry Processes | Resource Usage in cPanel |
| Errore 500 o 503 | PHP, memoria, processi, applicazione | Error log e Resource Usage |
| Errore 504 | Richiesta troppo lunga | Processo, query e servizi esterni |
| Solo immagini lente | Peso file, formati, CDN o cache | Dimensione e richieste di rete |
| Solo amministrazione lenta | Plugin, Heartbeat, cron, query | Dashboard e attività pianificate |
Se compare il messaggio Resource Limit Is Reached, consulta anche la guida Errore 508 Resource Limit Is Reached.
Raccogli i dati prima di modificare il sito
Annota almeno dominio, URL lento, data, ora, durata, dispositivo, connessione e operazione eseguita. Prova una pagina pubblica e una pagina non memorizzabile, come un’area riservata o il carrello, senza effettuare decine di ricaricamenti consecutivi.
Confronta inoltre:
- homepage e pagina interna;
- utente autenticato e visitatore anonimo;
- browser normale e finestra privata;
- connessione fissa e rete mobile;
- pagina HTML e file statico, per esempio un’immagine;
- orario normale e momento del rallentamento.
Se un file statico viene scaricato rapidamente ma una pagina PHP impiega molti secondi, è ragionevole concentrare la diagnosi sull’applicazione e sul database. Se tutto è lento soltanto da una singola rete, possono entrare in gioco DNS, percorso di rete, browser o dispositivo.
Controlla lo stato dei servizi e gli avvisi
Prima di intervenire sul sito verifica se è presente una manutenzione o un disservizio generale. Se il problema riguarda un solo dominio mentre altri siti sullo stesso account funzionano correttamente, è più probabile una causa applicativa o specifica della configurazione.
Non basarti solamente su un test eseguito da una località lontana. Gli strumenti esterni sono utili per confrontare le richieste, ma possono essere influenzati dalla distanza, dal DNS, dalla rete di prova e da eventuali protezioni contro i bot.
Controlla Resource Usage in cPanel
Apri cPanel → Metriche → Resource Usage. Controlla Dashboard, Current Usage e, se disponibile, Snapshot. Le principali risorse CloudLinux sono CPU, memoria fisica, I/O, IOPS, numero di processi ed Entry Processes.
- CPU alta: PHP, elaborazioni, plugin, bot o query possono essere intensivi;
- I/O alto: backup, scansioni, log, cache e molti file possono rallentare letture e scritture;
- PMEM alta: uno o più processi stanno usando molta memoria;
- EP con Fault: troppe richieste dinamiche sono contemporaneamente attive;
- NPROC con Fault: l’account ha raggiunto il numero di processi consentito.
Controlla la colonna Fault nell’intervallo esatto del problema. Un grafico vicino al limite non dimostra da solo che il limite sia stato raggiunto. Se i valori sono normali durante il rallentamento, prosegui con applicazione, database e servizi esterni.
Leggi il registro degli errori
In cPanel apri lo strumento degli errori oppure controlla il file di log dell’applicazione. Cerca messaggi registrati nello stesso minuto del rallentamento. Gli avvisi ripetuti migliaia di volte possono riempire i log e aumentare l’I/O, mentre fatal error, timeout e memoria esaurita indicano un problema più diretto.
Non pubblicare log completi contenenti percorsi, indirizzi email, token o dati personali. Nel ticket è sufficiente riportare le righe pertinenti e l’orario.
Verifica plugin e tema WordPress
Se il problema è iniziato dopo un aggiornamento o una nuova installazione, l’ultimo componente modificato è un candidato importante. Tuttavia la disattivazione indiscriminata sul sito pubblico può interrompere moduli, pagamenti, sicurezza e funzionalità essenziali.
La procedura consigliata è:
- creare un backup recente;
- riprodurre il problema in un ambiente di staging quando possibile;
- controllare aggiornamenti e compatibilità PHP;
- disattivare un solo componente alla volta;
- ripetere la stessa misurazione;
- riattivare il componente se non cambia nulla.
I plugin più pesanti non appartengono necessariamente a una categoria precisa. Un plugin leggero può diventare lento per configurazione, quantità di dati, chiamate API o conflitti. Verifica soprattutto builder, filtri avanzati, statistiche interne, backup, sicurezza, importatori, feed e sincronizzazioni.
Controlla il database
Un database grande non è automaticamente lento: contano struttura, indici, query e dati caricati a ogni richiesta. In WordPress possono incidere opzioni autoload eccessive, tabelle di log, sessioni, transients, revisioni e code di attività.
Segnali frequenti:
- frontend accettabile ma pannello molto lento;
- ricerche, filtri o report che richiedono diversi secondi;
- rallentamento progressivo nel tempo;
- query lente durante importazioni o modifiche massive;
- database che cresce rapidamente per log o code.
Non cancellare tabelle o opzioni sulla base del solo nome. Prima identifica quale plugin le utilizza, crea un backup e prova la pulizia in modo controllato.
Controlla cache e LiteSpeed Cache
La cache può ridurre notevolmente il lavoro di PHP e database sulle pagine pubbliche. Nei siti WordPress su Xlogic è possibile usare LiteSpeed Cache, ma l’attivazione di tutte le ottimizzazioni contemporaneamente rende difficile capire quale impostazione provoca un problema.
Verifica:
- che le pagine pubbliche memorizzabili producano una risposta cache;
- che carrello, checkout, account e contenuti personalizzati siano esclusi correttamente;
- che non siano presenti due plugin di page cache in conflitto;
- che la cache venga svuotata dopo aggiornamenti importanti;
- che minificazione e combinazione dei file siano testate separatamente;
- che la cache non nasconda temporaneamente un errore.
Un sito veloce da anonimo ma lento da autenticato può indicare che la cache pubblica funziona e che il problema si trova nelle richieste dinamiche non memorizzate.
Individua chiamate verso servizi esterni
Plugin e temi possono contattare gateway di pagamento, API, font, mappe, sistemi antispam, CRM, feed e servizi di licenza. Se il servizio remoto risponde lentamente, PHP può attendere fino al timeout mantenendo occupato il processo.
Controlla se il ritardo compare soltanto durante invio moduli, checkout, sincronizzazioni o apertura di una specifica schermata. La soluzione può essere ridurre il timeout, usare code asincrone, memorizzare i risultati o correggere l’integrazione; non è sempre necessario aumentare le risorse hosting.
Controlla WP-Cron e attività pianificate
WP-Cron può avviare aggiornamenti, pubblicazioni, pulizie, invii, sincronizzazioni e processi dei plugin. Attività troppo frequenti o bloccate possono accumularsi e partire insieme.
- verifica eventi duplicati;
- controlla code con molte attività fallite;
- programma backup e importazioni nelle ore meno trafficate;
- non impostare cron ogni minuto senza necessità;
- evita che più sistemi eseguano la stessa attività.
Immagini, CSS e JavaScript
Una risposta iniziale veloce non garantisce che la pagina sia visivamente pronta. Immagini molto pesanti, font esterni, script pubblicitari e JavaScript che blocca il thread principale possono peggiorare l’esperienza anche con hosting reattivo.
Ridimensiona le immagini alle dimensioni realmente mostrate, usa formati moderni quando compatibili, evita video caricati automaticamente e limita script non essenziali. Prima di applicare lazy loading o ritardi agli script, verifica moduli, menu, cookie banner e tracciamenti.
Come capire se serve un piano superiore
Valuta un upgrade quando le risorse vengono raggiunte con frequenza durante traffico legittimo e il sito è già stato ottimizzato. Un singolo picco causato da bot, backup o plugin difettoso non giustifica automaticamente un cambio piano.
Considera insieme:
- Fault CloudLinux ripetuti;
- numero di siti nello stesso account;
- traffico simultaneo reale;
- e-commerce e aree personalizzate non memorizzabili;
- attività cron e integrazioni;
- crescita prevista.
Consulta anche Come scegliere il piano hosting.
Checklist per il ticket Xlogic
Apri un ticket quando il problema è riproducibile ma non riesci a individuarne la causa, quando sono presenti Fault ripetuti o quando più servizi risultano coinvolti. Invia:
- dominio e URL esatto;
- data e ora con fuso orario;
- durata del rallentamento;
- schermata Resource Usage;
- messaggi di errore pertinenti;
- modifiche recenti;
- passaggi per riprodurre il problema.
Non inviare password, codici 2FA, chiavi private o credenziali API.
Fonti tecniche ufficiali
Domande frequenti sui siti lenti
Un sito lento significa che il server è sovraccarico?
No. Il ritardo può dipendere da PHP, database, plugin, tema, cache, servizi esterni, immagini, JavaScript, DNS o rete. Bisogna confrontare i dati nell’orario esatto del problema.
Devo disattivare tutti i plugin WordPress?
No. È preferibile creare un backup, usare uno staging e provare un solo componente alla volta. Disattivare tutto sul sito pubblico può interrompere funzioni importanti e non identifica con precisione la causa.
La cache risolve sempre un sito lento?
No. La cache aiuta soprattutto le pagine pubbliche memorizzabili. Non corregge query lente, checkout, aree riservate, cron, chiamate API o errori applicativi.
Come capisco se il database è il problema?
Confronta pagine e operazioni, controlla log e query, verifica crescita delle tabelle e attività pianificate. La sola dimensione del database non basta per stabilire che sia lento.
Quando conviene aumentare le risorse hosting?
Quando CPU, memoria, I/O, processi o Entry Processes raggiungono regolarmente il limite durante traffico legittimo anche dopo l’ottimizzazione del sito.