Hosting: controlli rapidi quando il sito è lento senza errori

Quando il sito non è giù, ma sembra fermo

Un sito lento è spesso più insidioso di un errore evidente: l’utente aspetta, ricarica, abbandona. Dal punto di vista operativo, la lentezza va trattata come un problema di catena: DNS, connessione, web server, PHP, database, cache, storage e rete esterna. Se si salta il metodo e si tocca tutto insieme, si rischia di peggiorare la situazione senza capire la causa reale.

La regola utile è semplice: misura prima, cambia poi. In hosting condiviso, VPS, cPanel, Plesk o FastPanel, la lentezza può arrivare da un singolo plugin, da query lente, da una cache mancante, da un limite di CPU o da un provider esterno. In questa guida trovi un percorso rapido, ordinato e verificabile per isolare il collo di bottiglia e applicare il fix più sicuro.

1. Diagnosi probabile

Le cause più frequenti sono queste:

1. PHP o applicazione lenta: codice pesante, plugin, temi, hook, chiamate esterne bloccanti.
2. Database saturo o query lente: MySQL/MariaDB con tabelle grandi, indici mancanti, lock, connessioni eccessive.
3. Cache assente o inefficace: niente page cache, object cache o CDN, quindi ogni visita genera lavoro completo.
4. Risorse server sotto pressione: CPU alta, RAM insufficiente, swap, I/O disco, processi limitati dal pannello o dall’hosting.
5. Ritardi esterni: API di pagamento, mappe, font, tracker, embed social o DNS lenti verso terze parti.

Se la lentezza è intermittente, il sospetto principale è spesso la saturazione di risorse o una query/servizio esterno che a volte risponde e a volte no. Se invece il sito è sempre lento, la causa tende a essere strutturale: cache mancante, database pesante o codice inefficiente.

2. Verifiche immediate

1. Controlla se il problema è generale o solo su alcune pagine. Apri homepage, una pagina interna e una pagina con funzionalità dinamiche come ricerca, carrello o login. Se solo alcune pagine sono lente, il problema è quasi sempre applicativo o database. Se tutto è lento, guarda prima server e rete.
2. Misura il tempo di risposta reale. Da browser usa gli strumenti sviluppatore o un test esterno come PageSpeed Insights o un test di waterfall. Cerca il TTFB: se è alto, il ritardo è prima del rendering, quindi lato server o backend.
3. Verifica lo stato delle risorse. Su VPS o server dedicato, controlla CPU, RAM, swap e load average. Un carico alto con CPU satura o swap attivo indica pressione di sistema, non solo “sito lento”.
4. Controlla se il database è il collo di bottiglia. Se hai accesso a MySQL/MariaDB, osserva query lente, lock o connessioni in attesa. Se il database risponde lentamente anche in orari di basso traffico, il problema è quasi certamente lì.
5. Escludi la cache. Se il sito va lento solo per utenti non loggati o solo al primo accesso, probabilmente la cache non è attiva, è stata bypassata o si svuota troppo spesso.

Se hai accesso SSH, questi controlli danno un quadro veloce:

top -o %CPU

Esito atteso: nessun processo PHP, database o web server dovrebbe restare stabilmente al 100% su CPU senza un motivo preciso.

free -h

Esito atteso: RAM libera o gestita senza swap costante; uno swap usato in modo continuo è un segnale di saturazione.

uptime

Esito atteso: il load average non deve restare molto più alto del numero di core per lunghi periodi, soprattutto se il sito è poco visitato.

3. Soluzione consigliata passo-passo

1. Stabilisci il perimetro dal pannello di controllo. In cPanel, Plesk o FastPanel verifica prima metriche, log e risorse del dominio o della subscription. Cerca sezioni come Statistics, Resource usage, Logs, Error log o Monitoring. Se il pannello segnala limiti raggiunti, hai già un’indicazione forte: non partire dal tema o dai plugin.
2. Controlla i log del web server e dell’applicazione. Apri i log errori del sito e cerca timeout, richieste lente, errori PHP, connessioni al database fallite o chiamate esterne che impiegano troppo tempo. Un log pulito ma con TTFB alto sposta l’attenzione su cache, database o rete esterna.
3. Attiva o verifica la cache pagina. Se usi WordPress, controlla che sia presente una cache compatibile e che non sia esclusa in modo errato. Se il sito è su pannello con LiteSpeed, Nginx reverse proxy o cache integrata, verifica che sia effettivamente in uso. La cache è spesso il fix più sicuro quando il sito è sano ma troppo pesante da rigenerare a ogni visita.
4. Riduci il peso delle richieste esterne. Disattiva temporaneamente font esterni, mappe, widget social, statistiche invasive e script di terze parti. Se il sito migliora subito, il problema è fuori dal server. In quel caso conviene caricare in locale ciò che è critico o rinviare gli script non essenziali.
5. Ottimizza il database solo dopo la diagnosi. Prima di toccare tabelle o indici, fai un backup. Poi verifica tabelle molto grandi, query lente e plugin che generano troppe letture. In WordPress, spesso il rallentamento nasce da plugin di statistiche, backup, page builder pesanti o ricerca interna senza cache.
6. Controlla PHP e il limite dei worker. Se il server usa PHP-FPM, un numero troppo basso di worker può creare coda; un numero troppo alto può saturare RAM e CPU. La soluzione non è “alzare tutto”, ma trovare il punto in cui il sito regge il traffico senza andare in sofferenza. Se il provider impone limiti, resta dentro quei margini e lavora sulla cache.
7. Riduci i plugin o le funzioni non necessarie. Su WordPress, disattiva in prova i plugin più pesanti uno per volta e verifica il tempo di caricamento dopo ogni modifica. Se il miglioramento è netto, hai trovato il colpevole o almeno la classe di problemi.

Se vuoi un controllo tecnico rapido lato database, un comando utile è questo:

mysqladmin processlist -u root -p

Esito atteso: non devono comparire molte query in stato Locked, Sending data o con tempi anomali. Se non hai accesso root, usa l’utente MySQL consentito dal provider.

Per verificare le query lente, se hai accesso ai log:

ls -lh /var/log/mysql/

Esito atteso: individuare il file del slow log, se attivo. Se non esiste, può essere utile abilitarlo temporaneamente per capire quale query rallenta.

Se il problema è un hosting condiviso, spesso il fix vero non è “tuning aggressivo”, ma snellire il sito: meno plugin, cache attiva, immagini ottimizzate, script esterni ridotti e cron meno rumorosi. In quel contesto la stabilità conta più dell’ottimizzazione estrema.

Approccio pratico per WordPress

1. Disattiva temporaneamente plugin di cache, sicurezza, statistiche e builder pesanti uno alla volta.
2. Controlla il TTFB prima e dopo ogni modifica.
3. Verifica se il backend wp-admin è lento quanto il frontend: se sì, il problema è più spesso database o PHP; se no, è più spesso cache o frontend.
4. Ottimizza immagini e script solo dopo aver escluso server e database.

Approccio pratico per cPanel, Plesk e FastPanel

1. Apri la sezione log del dominio e cerca errori ripetuti o timeout.
2. Controlla l’uso risorse della subscription o del sito.
3. Verifica eventuali cache integrate, proxy o ottimizzazioni HTTP attive.
4. Se il pannello mostra limiti di CPU o memoria, riduci il lavoro generato dal sito invece di aumentare solo la frequenza dei refresh.

4. Controlli finali / rollback

1. Rifai il test di velocità dopo ogni fix importante. L’esito atteso è un TTFB più basso e una pagina più stabile nelle prove ripetute, non solo nella singola misurazione fortunata.
2. Confronta prima e dopo su homepage e pagina interna. Se la homepage migliora ma le pagine dinamiche restano lente, il problema residuo è quasi certamente database o codice applicativo.
3. Se una modifica peggiora la situazione, fai rollback subito. Disattiva l’ultimo plugin, ripristina la configurazione cache precedente o torna al backup del file modificato. Non accumulare più cambiamenti insieme.
4. Monitora per almeno 24 ore se il sito è in produzione. Il vero successo non è solo il picco migliore, ma l’assenza di lentezza ricorrente in orari diversi.

Regola utile: se non sai ancora dov’è il collo di bottiglia, non “ottimizzare tutto”. Prima isola il punto lento, poi intervieni solo lì.

Checklist finale rapida: log controllati, cache verificata, risorse server osservate, database misurato, test ripetuto dopo ogni modifica. Se vuoi, il passo successivo può essere una guida pratica dedicata a WordPress, cPanel o VPS con i controlli già pronti da copiare.