Sito lento: come capire in dieci minuti se è il server, il database o un plugin

Il sito risponde a scatti o non risponde affatto. Prima domanda, prima di toccare qualunque impostazione: il problema è lato server o lato rete/browser di chi guarda? Si risolve in meno di un minuto misurando il TTFB (time to first byte, il tempo che passa dalla richiesta alla prima risposta del server) da un posto esterno al server.

Da riga di comando, su qualunque sistema con curl installato:

curl -o /dev/null -s -w "TTFB: %{time_starttransfer}s - Totale: %{time_total}s\n" https://ilsito.it/

Se il valore di time_starttransfer è alto (sopra 1 secondo) il tempo si perde sul server. Se è basso ma time_total è alto, il problema è nel trasferimento dei contenuti (immagini pesanti, assenza di compressione), non nel server applicativo. Vale la pena ripetere la prova da due o tre reti diverse (casa, mobile, un VPS in un'altra zona) prima di concludere qualcosa: un TTFB alto solo da una rete specifica indica un problema di instradamento o CDN, non del server.

Caso 1: il tempo è nel server web

Su Ubuntu 24.04 con Nginx e PHP-FPM, il primo posto da guardare è il log degli errori di Nginx. Le path sono /var/log/nginx/access.log e /var/log/nginx/error.log su Ubuntu, Debian, RHEL, CentOS e Fedora quando Nginx è installato dal pacchetto della distribuzione o dal repository ufficiale. Se il pacchetto o un amministratore precedente ha cambiato il percorso, il modo per saperlo con certezza senza indovinare è chiedere al binario stesso:

nginx -V 2>&1 | tr ' ' '\n' | grep error-log-path

Per guardare gli errori in tempo reale mentre si ricarica la pagina:

sudo tail -f /var/log/nginx/error.log

La riga che conta è quella con un timestamp vicino al momento della richiesta lenta: se compaiono errori "upstream timed out" il problema è nel passaggio a PHP-FPM, non in Nginx stesso.

Su cPanel i log di Apache/Nginx per singolo account si trovano normalmente in /usr/local/apache/domlogs/ (o percorso equivalente mostrato in WHM sotto "Apache Status" e "Error Log"); su Plesk il pannello espone i log per dominio da Siti web e domini > Logs, senza bisogno di SSH. In entrambi i casi la logica è identica: si cerca la richiesta lenta nel log del vhost, non in quello globale.

Se il TTFB resta alto anche con un sito statico di prova (una pagina HTML vuota caricata nello stesso vhost), il problema non è nell'applicazione ma nel server stesso: CPU satura, I/O del disco al limite, troppi processi PHP-FPM in coda. Qui serve guardare il carico (uptime, top, iostat -x 1) prima di continuare a cercare nel codice.

Caso 2: il tempo è nel database

Se il sito statico è veloce ma le pagine dinamiche no, il sospetto si sposta su MySQL/MariaDB. Lo strumento giusto è lo slow query log, che non è attivo di default. Il MySQL slow query log registra le query che superano una soglia specificata (long_query_time) ed è lo strumento principale per individuare colli di bottiglia nelle prestazioni e query da ottimizzare.

Per attivarlo senza riavviare il servizio (valido su MySQL e MariaDB):

SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 1;
SET GLOBAL slow_query_log_file = '/var/log/mysql/slow.log';

Queste impostazioni hanno effetto immediato ma vengono perse al riavvio. Per renderle permanenti vanno scritte nel file di configurazione (/etc/mysql/my.cnf o un file in /etc/mysql/mysql.conf.d/) sotto la sezione [mysqld].

Sulla soglia, la documentazione ufficiale è chiara: per impostazione predefinita MySQL registra ogni query che impiega più di 10 secondi per essere eseguita, e sul piano tecnico il valore minimo e predefinito di long_query_time sono rispettivamente 0 e 10. Dieci secondi è un valore inutile per capire perché una pagina che dovrebbe rispondere in 300 millisecondi ne impiega 3: per il lavoro di diagnosi quotidiano conviene abbassare la soglia a 1 secondo, guardare cosa compare per un paio d'ore, poi rialzarla. Attenzione: il parametro log_queries_not_using_indexes di default è OFF, quindi una query lenta perché non usa un indice potrebbe non comparire affatto se non si attiva esplicitamente anche questo parametro.

Dopo aver raccolto qualche decina di righe, il comando mysqldumpslow -s t -t 10 /var/log/mysql/slow.log ordina le query per tempo totale e mostra le dieci peggiori: è lì che si trova la query senza indice che blocca tutto, non scorrendo il file a mano.

Caso 3: il tempo è nel codice (plugin, tema, applicazione)

Se il database risponde bene (nessuna riga nello slow log con soglia a 1 secondo, anche sotto carico) ma la pagina resta lenta, il tempo si perde nell'esecuzione PHP: un plugin che fa chiamate esterne, un tema che ricalcola query su ogni caricamento, codice non ottimizzato. Lo strumento gratuito più semplice per isolare il colpevole su WordPress è l'opzione SAVEQUERIES più un plugin di debug che mostra il tempo per hook (es. Query Monitor), oppure, a livello di server, il profiler integrato in PHP-FPM che registra le chiamate che restano bloccate oltre una soglia: va configurato nel file del pool (tipicamente /etc/php/8.3/fpm/pool.d/www.conf su Ubuntu, o la sezione pool nel pannello su Plesk/cPanel) impostando un timeout e un file di log dedicato, e riavviando il servizio PHP-FPM per renderlo attivo.

Senza uno di questi due strumenti si sta solo indovinando: disattivare i plugin uno a uno a caso è un metodo, ma richiede di ripetere la misura del TTFB ad ogni disattivazione, altrimenti non si sa se il miglioramento è reale o rumore di rete.

Cosa NON serve a niente prima di aver misurato

Cambiare hosting senza aver fatto nessuna delle tre misure sopra è il modo più comune per spendere soldi senza risolvere nulla: se il problema è una query senza indice, è identico su qualunque server, anche il più potente. Allo stesso modo installare tre plugin di cache diversi insieme su WordPress non somma i benefici: spesso li annulla, perché più plugin intercettano le stesse richieste e generano conflitti che si vedono solo nel log degli errori PHP, non nella velocità percepita.

Se il problema può essere del fornitore

Se il TTFB è alto anche su una pagina statica vuota e il carico della macchina (uptime, top) non mostra nulla di anomalo, il sospetto si sposta sull'infrastruttura sotto il proprio controllo: storage condiviso lento, noisy neighbour su un VPS, problemi di rete verso il datacenter. In questo caso va aperto un ticket al provider allegando: l'orario esatto delle misure di TTFB fatte da più posti, l'output di uptime e iostat -x 1 5 nello stesso momento, e se possibile il traceroute (traceroute ilsito.it o mtr ilsito.it) per escludere un problema di instradamento prima che arrivi al server. Senza questi dati l'assistenza non può distinguere un problema loro da uno dentro la macchina, e la richiesta resta in coda più a lungo del necessario.