Sito lento solo a volte? 9 cause che rendono difficile trovare il problema

Un sito lento solo a volte è spesso molto più difficile da diagnosticare rispetto a un sito costantemente lento.

Quando il problema è permanente basta aprire una pagina, misurare i tempi di risposta e controllare PHP, database, cache e risorse. Quando invece il rallentamento compare soltanto per pochi secondi o alcuni minuti, può essere già scomparso nel momento in cui inizi l’analisi.

Il sito può essere veloce per ore, rallentare improvvisamente e poi tornare normale senza che venga effettuata alcuna modifica.

Le cause possono essere molto diverse: cache scaduta, picchi di traffico, bot, cron WordPress, backup, query database, processi PHP occupati, API esterne lente oppure problemi temporanei di rete.

Vediamo quindi le 9 cause principali di un sito lento solo a volte e soprattutto quali dati raccogliere per riuscire a individuare un problema intermittente.

Sito lento solo a volte: perché è così difficile trovare il problema?

Il motivo principale è semplice:

quando inizi il controllo, il rallentamento potrebbe essere già terminato.

Immaginiamo questa situazione:

14:30 → sito veloce
14:32 → sito molto lento
14:34 → sito nuovamente veloce
14:40 → inizia il controllo tecnico
14:40 → tutto appare normale

Se si osserva il server soltanto alle 14:40, CPU, RAM e database potrebbero sembrare perfettamente normali.

Ma il dato realmente utile è capire cosa stesse accadendo alle 14:32.

Per diagnosticare correttamente un sito lento solo a volte servono quindi log, monitoraggio e soprattutto un orario preciso del problema.

1. Cache HIT e cache MISS possono cambiare completamente la velocità

La cache è una delle prime cose da verificare quando un sito lento solo a volte alterna risposte rapidissime a richieste molto più lente.

Quando una pagina viene servita direttamente dalla cache, il server può evitare di eseguire nuovamente gran parte della logica applicativa.

In molti casi non è necessario interrogare nuovamente:

• WordPress;
• plugin;
• tema;
• PHP;
• database.

La differenza può essere notevole.

Cache HIT  → 90 ms
Cache MISS → 950 ms

Per il visitatore la stessa pagina può quindi apparire velocissima una volta e molto più lenta quella successiva.

Quando una pagina va in cache MISS?

Le cause dipendono dal sistema utilizzato, ma possono comprendere:

• cache appena svuotata;
• TTL scaduto;
• pagina appena modificata;
• aggiornamento plugin;
• aggiornamento tema;
• variazioni WooCommerce;
• utente autenticato;
• cookie che impediscono la cache;
• URL dinamico.

Dopo un purge, le prime richieste devono spesso ricostruire il contenuto prima che possa essere nuovamente memorizzato.

WooCommerce: non tutte le pagine possono essere trattate allo stesso modo

Su un eCommerce è normale avere comportamenti differenti tra una pagina pubblica e una pagina dinamica.

Per esempio:

Homepage → cache → molto veloce
Categoria → cache → veloce
Prodotto → cache → veloce
Carrello → dinamico
Checkout → dinamico
Area cliente → dinamica

Testare soltanto la homepage può quindi nascondere un problema che riguarda carrello, checkout o utenti autenticati.

2. Picchi di traffico che durano pochi minuti

Un sito può funzionare perfettamente durante il normale traffico e rallentare soltanto durante un improvviso aumento delle richieste.

Il picco può essere provocato da:

• newsletter;
• campagna pubblicitaria;
• post diventato virale;
• promozione;
• lancio di un prodotto;
• crawler;
• bot;
• scanner automatici.

Quando il traffico diminuisce, anche i tempi possono tornare rapidamente normali.

Non guardare soltanto il numero dei visitatori

Il numero di utenti non racconta necessariamente tutto.

Migliaia di richieste servite dalla cache possono pesare meno di poche centinaia di richieste dinamiche particolarmente costose.

Bisogna quindi distinguere tra:

• visitatori;
• richieste HTTP;
• URL visitate;
• pagine cacheabili;
• richieste verso PHP;
• query database generate.

3. Bot e crawler possono arrivare a ondate

Un visitatore reale apre normalmente poche pagine.

Un crawler può invece effettuare centinaia o migliaia di richieste in sequenza.

Tra gli accessi automatici possono esserci:

• motori di ricerca;
• crawler AI;
• scanner di sicurezza;
• tool SEO;
• scraper;
• bot malevoli;
• monitor automatici.

Anche bot legittimi possono generare carico se effettuano molte richieste in poco tempo.

Come capire se un bot coincide con il rallentamento?

Il punto fondamentale è confrontare il momento esatto del problema con l’access log.

Se il rallentamento si è verificato alle 03:15, analizza per esempio:

03:10 → 03:20

Cerca:

• IP con moltissime richieste;
• User-Agent ripetitivi;
• URL richieste continuamente;
• accessi a pagine dinamiche;
• scansioni di URL inesistenti;
• picchi improvvisi di richieste.

Non conviene però bloccare automaticamente ogni crawler: bisogna prima capire chi è, cosa sta richiedendo e quale impatto sta realmente provocando.

4. WP-Cron e attività pianificate

WordPress dispone di un sistema di pianificazione chiamato WP-Cron.

Plugin e tema possono utilizzarlo per eseguire attività come:

• invio email;
• pulizia cache;
• sincronizzazioni;
• aggiornamenti feed;
• generazione report;
• pulizia database;
• elaborazione code;
• controlli automatici.

Se un task particolarmente pesante parte in determinati momenti, il sito può rallentare soltanto durante la sua esecuzione.

Come controllare gli eventi WP-Cron

Con WP-CLI puoi visualizzare gli eventi programmati:

wp cron event list

Il comando permette di individuare eventi molto frequenti o attività che non sembrano coerenti con il normale funzionamento del sito.

Per approfondire puoi consultare anche la documentazione ufficiale WordPress sul sistema Cron.

WP-Cron non è automaticamente un problema

Le attività pianificate fanno parte del normale funzionamento di WordPress.

Il problema può emergere quando:

• un task è troppo pesante;
• un plugin registra migliaia di eventi;
• un processo rimane bloccato;
• molti job partono contemporaneamente;
• un evento viene eseguito troppo frequentemente.

5. Backup che utilizzano temporaneamente molte risorse

I backup sono indispensabili, ma la loro creazione comporta lavoro per il sistema.

Durante un backup possono essere eseguite operazioni come:

• lettura di migliaia di file;
• compressione;
• dump del database;
• scrittura su disco;
• trasferimento remoto;
• calcolo di checksum.

Se un sito lento solo a volte peggiora sempre nella stessa fascia oraria, una delle prime cose da verificare è se in quel momento sia attivo un backup.

Backup corretto non significa backup senza costo

Il fatto che un backup utilizzi CPU o I/O non significa necessariamente che il sistema sia configurato male.

È però utile valutare:

• durata;
• orario;
• quantità di dati;
• compressione;
• destinazione;
• impatto sul traffico reale.

Quando possibile, le attività più pesanti vengono normalmente pianificate nei periodi di minore traffico.

6. Query database lente soltanto in determinate condizioni

Un database può essere veloce quasi sempre e rallentare soltanto durante alcune operazioni.

Per esempio:

• ricerche complesse;
• filtri WooCommerce;
• report;
• importazioni;
• query su tabelle molto grandi;
• lock;
• molte query contemporanee.

Una homepage rapida non dimostra quindi che tutte le query del sito siano efficienti.

WooCommerce può evidenziare rallentamenti molto specifici

Un negozio può avere tempi differenti tra:

• homepage;
• pagina prodotto;
• ricerca;
• filtri;
• carrello;
• checkout;
• wp-admin;
• report;
• Action Scheduler.

È importante sapere esattamente quale URL fosse lenta.

Database lento solo durante alcune operazioni

Per diagnosticare correttamente il problema occorre correlare:

• orario;
• URL;
• query;
• carico database;
• processi contemporanei;
• eventuali lock.

Senza questa correlazione è molto facile attribuire il rallentamento al componente sbagliato.

7. Processi PHP temporaneamente occupati

Le pagine dinamiche richiedono processi PHP disponibili.

Se tutti i processi stanno già elaborando richieste lente, quelle successive possono dover attendere.

In forma semplificata:

PHP 1 → occupato
PHP 2 → occupato
PHP 3 → occupato
PHP 4 → occupato

Nuova richiesta → attesa

Quando uno dei processi termina, la situazione può tornare normale quasi istantaneamente.

Aumentare i PHP worker non risolve necessariamente il problema

Se la causa è una funzione che impiega 30 secondi, aumentare semplicemente il numero dei processi può consentire a più richieste lente di essere eseguite contemporaneamente.

Prima bisogna capire:

perché i processi rimangono occupati così a lungo?

CloudLinux e limiti temporanei delle risorse

Negli ambienti hosting che utilizzano sistemi di isolamento come CloudLinux possono esistere limiti specifici per account.

Un sito potrebbe essere velocissimo quasi sempre e rallentare soltanto quando raggiunge temporaneamente un limite.

Pochi minuti dopo, quando il consumo diminuisce, il problema può non essere più visibile.

8. API esterne e servizi di terze parti lenti

Non sempre il problema si trova sul server che ospita il sito.

WordPress può dipendere da servizi esterni come:

• gateway di pagamento;
• API di spedizione;
• CRM;
• servizi antispam;
• feed;
• licenze;
• mappe;
• marketing automation.

Se PHP attende una risposta esterna prima di completare la pagina, un rallentamento del servizio remoto può rallentare anche il tuo sito.

Il server può essere veloce ma la pagina comunque lenta

Esempio:

PHP locale   → 0,2 secondi
Database     → 0,1 secondi
API esterna  → 4,5 secondi

Totale       → quasi 5 secondi

CPU e RAM locali potrebbero apparire perfettamente normali.

Il collo di bottiglia si trova fuori dall’infrastruttura.

Timeout e servizi esterni

Il problema diventa ancora più evidente quando l’API non risponde.

Se il timeout è impostato a 30 secondi, una singola richiesta potrebbe rimanere in attesa per tutto quel tempo.

Questo può far sembrare WordPress improvvisamente lentissimo anche con server scarico.

9. DNS, CDN, rete o routing intermittente

Non tutti i rallentamenti avvengono dentro WordPress.

Il percorso reale è più simile a:

Browser
   ↓
DNS
   ↓
rete utente
   ↓
CDN / proxy
   ↓
rete datacenter
   ↓
Web server
   ↓
PHP
   ↓
database

Un problema temporaneo in qualsiasi punto del percorso può essere percepito come “sito lento”.

Se il problema riguarda soltanto alcuni utenti

È un indizio importante.

Se la lentezza compare soltanto:

• da uno specifico provider Internet;
• da una determinata rete;
• da un Paese;
• tramite IPv6;
• da una particolare area geografica;

è opportuno analizzare anche rete, CDN e routing.

Sito lento solo da smartphone

Quando il problema viene segnalato soltanto da mobile bisogna separare:

• tempo del server;
• peso della pagina;
• JavaScript;
• immagini;
• latenza della rete;
• servizi esterni.

Un server può generare l’HTML in 200 millisecondi mentre il browser impiega molti secondi a scaricare ed elaborare una pagina molto pesante.

TTFB alto significa sempre server lento?

No.

Il percorso che precede il primo byte può comprendere più fasi:

• DNS;
• connessione;
• TLS;
• proxy;
• rete;
• elaborazione lato server.

Per questo è utile separare i diversi tempi invece di guardare soltanto un numero finale.

PageSpeed è veloce ma gli utenti segnalano rallentamenti

È perfettamente possibile.

Un test rappresenta soltanto il comportamento osservato in quel momento.

Se il problema compare cinque minuti ogni due ore, PageSpeed potrebbe semplicemente non incontrarlo.

Un test singolo non è sufficiente per diagnosticare un problema intermittente.

Quando un sito lento solo a volte torna veloce il problema non è necessariamente risolto

Questo è uno degli errori di valutazione più comuni.

Il fatto che il sito sia tornato rapido può semplicemente significare che:

• il backup è terminato;
• il bot ha smesso di effettuare richieste;
• il cron è finito;
• l’API esterna è tornata disponibile;
• la cache è stata ricostruita;
• il picco di traffico è terminato.

La causa può quindi ripresentarsi.

Segna l’orario esatto del problema

Per diagnosticare un sito lento solo a volte è fondamentale conoscere il momento esatto del rallentamento.

Invece di:

Stamattina il sito era lento.

è molto più utile:

10:42:15 → prodotto lento
10:42:30 → checkout lento
10:44:00 → tutto normale

Con un timestamp preciso puoi confrontare access log, PHP, database, cron e monitoraggio.

Annota anche l’URL esatta

Dire:

“il sito è lento”

fornisce poche informazioni.

Meglio sapere:

/ → veloce
/categoria/ → veloce
/prodotto-x/ → lento
/checkout/ → lento
/wp-admin/ → veloce

Se la lentezza riguarda soltanto determinate pagine, la diagnosi cambia radicalmente.

Frontend lento o wp-admin lento?

Un sito può essere veloce per i visitatori e lento nel pannello amministrativo.

Oppure il contrario.

Se soltanto /wp-admin/ è lento, controlla in particolare:

• plugin;
• query amministrative;
• dashboard widget;
• cron;
• API;
• Action Scheduler;
• controlli aggiornamenti.

Sito lento dopo il login ma veloce da anonimo

Gli utenti autenticati possono bypassare la page cache.

Può quindi accadere:

Visitatore anonimo → cache HIT → 100 ms

Utente autenticato → PHP + database → 1,5 s

In questo scenario la cache potrebbe nascondere un problema applicativo che appare soltanto agli utenti autenticati.

Sito lento dopo una modifica o un purge

Se il rallentamento compare dopo:

• aggiornamento pagina;
• modifica prodotto;
• svuotamento cache;
• aggiornamento WordPress;
• deploy;

verifica se l’operazione invalida cache o altre risorse che devono successivamente essere ricostruite.

Sito lento sempre alla stessa ora

Questo è uno degli indizi migliori.

Se il rallentamento compare sistematicamente alle 03:00, cerca un’attività pianificata nello stesso momento.

Possibili cause:

• backup;
• cron;
• scanner malware;
• report;
• sincronizzazioni;
• importazioni;
• crawler programmati.

Una periodicità regolare difficilmente è casuale.

Anche bot, backup e cron possono spiegare perché il sito rallenta in fasce precise

Un sito lento solo a volte che peggiora sempre negli stessi intervalli dovrebbe essere analizzato confrontando gli orari con tutte le attività automatiche.

Una timeline può essere estremamente utile:

02:59 → sito 180 ms
03:00 → inizia backup
03:01 → aumenta I/O
03:02 → sito 2,8 secondi
03:06 → backup terminato
03:07 → sito 190 ms

Una correlazione di questo tipo vale molto più di una semplice impressione.

404 massive e scanner automatici

Uno scanner può richiedere continuamente URL inesistenti.

Se ogni 404 arriva fino a WordPress e viene generata dinamicamente, anche richieste apparentemente inutili possono utilizzare PHP e database.

Controlla quindi anche la distribuzione dei codici HTTP:

200
301
403
404
500

Non riavviare tutto prima di raccogliere i dati

Quando il sito rallenta, una reazione comune consiste nel riavviare immediatamente PHP, database o Web server.

Il problema può scomparire.

Ma in questo modo rischi anche di perdere la condizione che volevi analizzare.

Quando possibile:

1. annota l’orario;
2. controlla le risorse;
3. salva i log;
4. controlla processi e query;
5. solo dopo intervieni.

Non disattivare tutti i plugin senza una strategia

La disattivazione dei plugin può essere utile durante un test controllato.

Ma se il problema compare una volta ogni sei ore, il fatto che non si ripresenti nei successivi venti minuti non dimostra nulla.

Per problemi intermittenti bisogna cercare correlazioni ripetibili.

Come monitorare un sito lento intermittente

Quando il problema non è facilmente riproducibile, il monitoraggio continuo può essere molto più utile di un test manuale.

Puoi registrare periodicamente:

• HTTP status;
• DNS time;
• connect time;
• TLS time;
• TTFB;
• tempo totale;
• CPU;
• RAM;
• I/O;
• PHP;
• database.

In questo modo il rallentamento lascia una traccia anche se nessuno lo sta osservando direttamente.

curl può aiutare a separare i vari tempi

Da terminale è possibile misurare diverse fasi della richiesta.

Questo permette di capire se il ritardo avviene:

• durante il DNS;
• durante la connessione;
• durante TLS;
• prima del primo byte;
• durante il trasferimento.

Separare queste fasi evita di attribuire automaticamente ogni rallentamento a PHP o WordPress.

LiteSpeed e LSCache: cosa controllare

Negli ambienti che utilizzano LiteSpeed e LSCache è utile distinguere le richieste:

• cache HIT;
• cache MISS;
• bypassate;
• non cacheabili;
• dinamiche.

Una page cache efficace riduce notevolmente il lavoro necessario per molte richieste pubbliche, ma carrello, checkout, utenti autenticati e altre pagine dinamiche continuano a utilizzare PHP e database.

Prima di cambiare hosting identifica la causa

Un sito lento solo a volte non dimostra automaticamente che l’hosting sia insufficiente.

Se il problema dipende da:

• plugin;
• API esterna;
• query;
• cron;
• bot;

una migrazione potrebbe semplicemente trasferire lo stesso problema su un altro server.

Prima di cambiare hosting per un sito lento solo a volte, conviene quindi raccogliere dati su PHP, database, cache, traffico e risorse.

Se i rallentamenti diventano frequenti e l’infrastruttura risulta realmente insufficiente, puoi leggere anche la nostra guida su quando cambiare hosting e quali segnali valutare.

Quando invece le risorse possono essere realmente insufficienti?

Se durante ogni rallentamento osservi contemporaneamente:

• CPU costantemente satura;
• processi disponibili esauriti;
• database congestionato;
• I/O elevato;
• code crescenti;
• tempi di risposta sempre maggiori;

allora il dimensionamento dell’ambiente può essere realmente una parte della causa.

La decisione dovrebbe però essere basata su misure raccolte durante il problema.

Checklist: 9 cause di un sito lento solo a volte

• ☑ cache HIT, MISS e purge;
• ☑ picchi temporanei di traffico;
• ☑ bot e crawler;
• ☑ WP-Cron e task pianificati;
• ☑ backup e operazioni I/O;
• ☑ query database intermittenti;
• ☑ processi PHP o limiti delle risorse;
• ☑ API esterne lente;
• ☑ DNS, CDN, rete o routing.

Checklist: cosa annotare quando il sito diventa lento

• ☑ data e ora esatta;
• ☑ URL interessata;
• ☑ durata del rallentamento;
• ☑ utente autenticato o anonimo;
• ☑ rete e dispositivo;
• ☑ cache HIT o MISS;
• ☑ CPU;
• ☑ RAM;
• ☑ I/O;
• ☑ processi PHP;
• ☑ query database;
• ☑ access log;
• ☑ error log;
• ☑ cron attivi;
• ☑ backup in corso.

Domande frequenti su un sito lento solo a volte

Perché il mio sito è lento soltanto ogni tanto?

Un sito lento solo a volte può dipendere da cache MISS, picchi di traffico, bot, cron, backup, query database lente, processi PHP occupati, servizi esterni o problemi temporanei di rete.

Se il sito torna veloce significa che il problema è risolto?

No. Un problema intermittente può semplicemente essere terminato e ripresentarsi quando si verifica nuovamente la condizione che lo provoca.

PageSpeed può trovare un rallentamento intermittente?

Soltanto se il problema è presente durante il test. Per fenomeni che compaiono casualmente è molto più utile il monitoraggio continuo.

La cache può far sembrare il sito veloce una volta e lento quella dopo?

Sì. Una richiesta servita dalla cache può essere molto più rapida della stessa pagina quando deve essere generata da PHP e database.

Un bot può rallentare WordPress?

Sì. Un numero elevato di richieste automatiche può aumentare il carico, soprattutto quando vengono richieste pagine dinamiche o URL che devono essere elaborate da WordPress.

I backup possono rallentare il sito?

Possono aumentare temporaneamente l’utilizzo di CPU, storage e I/O. L’impatto dipende dall’infrastruttura e dal tipo di backup.

Il database può essere lento soltanto in determinati momenti?

Sì. Query concorrenti, lock, report, importazioni e attività automatiche possono causare rallentamenti temporanei.

Aumentare il PHP memory_limit rende il sito più veloce?

Non necessariamente. Il memory limit determina quanta memoria può utilizzare un processo PHP, ma non è un parametro generale di velocità.

Se la CPU è libera significa che il server non ha problemi?

No. Il collo di bottiglia potrebbe riguardare database, I/O, processi PHP, API esterne, rete o un limite specifico dell’ambiente.

Cambiare hosting risolve sempre un sito lento solo a volte?

No. Se la causa è un plugin, una query inefficiente, un cron o una API esterna, lo stesso problema può continuare anche dopo la migrazione.

Conclusioni

Un sito lento solo a volte è difficile da diagnosticare proprio perché il problema può scomparire prima che qualcuno riesca ad analizzarlo.

Dire semplicemente:

“Adesso è veloce”

non significa necessariamente che tutto sia risolto.

Bisogna ricostruire ciò che stava succedendo nell’istante del rallentamento.

Le principali aree da verificare sono:

• cache;
• traffico;
• bot;
• cron;
• backup;
• database;
• PHP e risorse;
• API esterne;
• rete e CDN.

La cosa più utile da fare quando il problema compare è annotare immediatamente:

orario preciso, URL interessata e durata.

Con questi tre dati puoi confrontare nello stesso intervallo access log, error log, utilizzo delle risorse, cron, backup, query e traffico.

È così che un rallentamento apparentemente casuale può diventare un problema misurabile e finalmente diagnosticabile.