Sito lento: 5 cause che il 90% delle agenzie ignora (e come risolverle)
TTFB alto, pagine che caricano in 4+ secondi, clienti che si lamentano. Le cause sono quasi sempre lato server, non lato codice. Ecco dove guardare.
Il cliente ti scrive: "il sito è lento". Apri GTmetrix, vedi un TTFB di 2.8 secondi, pagine che pesano poco ma caricano in un'eternità. Istinti: "sarà un plugin pesante", "serve una CDN", "proviamo a cachare tutto".
Nella nostra esperienza su centinaia di sistemi, il problema è quasi sempre lato server, non lato codice. E le cause sono sorprendentemente poche e ripetitive.
Per un approfondimento solo sul database, continua poi con MySQL buffer pool: come calibrarlo davvero. Se invece il sito è lento durante un'emergenza e devi agire subito, trovi supporto nella pagina SOS e nel servizio Performance Tuning.
Causa #1: MySQL senza tuning (il colpevole nel 60% dei casi)
Il database è la prima cosa da controllare. La configurazione di default di MySQL/MariaDB è pensata per un server con 512MB di RAM nel 2010. Se il tuo server ha 8-32GB e servi decine di siti WordPress, quei default sono un collo di bottiglia enorme.
Come diagnosticare
# Quante query sono in esecuzione adesso?
mysqladmin processlist | wc -l
# Query lente negli ultimi minuti?
mysqladmin status
# Il buffer pool è troppo piccolo?
mysql -e "SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_reads';"
mysql -e "SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_read_requests';"
Se il rapporto tra Innodb_buffer_pool_reads (letture da disco) e Innodb_buffer_pool_read_requests (letture totali) è superiore all'1%, il buffer pool è troppo piccolo.
Come risolvere
# Calcola il buffer pool ideale: ~70% della RAM dedicata a MySQL
# Server da 8GB → innodb_buffer_pool_size = 5G
# Server da 16GB → innodb_buffer_pool_size = 10G
# Modifica /etc/mysql/mysql.conf.d/mysqld.cnf
innodb_buffer_pool_size = 5G
innodb_log_file_size = 512M
innodb_flush_log_at_trx_commit = 2
max_connections = 150
Questi valori sono esempi per un server da 8GB con carico medio. Ogni server ha esigenze diverse. Un tuning sbagliato peggiora le cose. Se non sei sicuro, fai analizzare la situazione.
Causa #2: PHP-FPM configurato male
PHP-FPM è il processo che esegue il codice PHP di WordPress. Se ci sono pochi worker disponibili, le richieste si accodano. Se ce ne sono troppi, la RAM si esaurisce.
Come diagnosticare
# Quanti processi PHP sono attivi?
ps aux | grep php-fpm | wc -l
# Stato del pool PHP-FPM
curl -s http://localhost/status 2>/dev/null || echo "Status page non abilitata"
# RAM usata per singolo processo PHP
ps aux | grep "php-fpm: pool" | awk '{sum+=$6; n++} END {print sum/n/1024 " MB per processo, " n " processi"}'
Come risolvere
Il calcolo è semplice: RAM disponibile per PHP / RAM per singolo processo = max_children.
Se ogni processo PHP usa 80MB e hai 4GB disponibili per PHP: 4096 / 80 = 51 max_children.
# /etc/php/8.2/fpm/pool.d/www.conf
pm = dynamic
pm.max_children = 50
## Quando la lentezza non è più un problema isolato
Se la stessa agenzia ha più siti lenti, alert ignorati e tuning fatto "a occhio", stai guardando un problema di operations, non una singola ottimizzazione. In quel caso conviene passare da [Monitoring](/servizi/monitoring/), [Server Management](/servizi/server-management/) o da un [audit gratuito](/audit-gratuito/) per mettere ordine prima di cambiare parametri a caso.
pm.start_servers = 10
pm.min_spare_servers = 5
pm.max_spare_servers = 20
pm.max_requests = 500
pm.max_requests = 500 è fondamentale: forza il riciclo dei worker dopo 500 richieste, prevenendo memory leak dei plugin WordPress.
Causa #3: Disco lento (o pieno all'80%+)
Un disco pieno oltre l'80% degrada le performance di scrittura. Al 95%+ il sistema diventa instabile.
Come diagnosticare
# Spazio disco
df -h
# I/O wait alto? (sopra il 5% è un problema)
iostat -x 1 3
# Quali processi stanno scrivendo di più?
iotop -o -b -n 3 2>/dev/null || echo "installa iotop: apt install iotop"
Come risolvere
- Disco pieno: pulisci i log (
journalctl --vacuum-size=200M), i backup locali vecchi, le sessioni PHP scadute (find /var/lib/php/sessions -mtime +1 -delete) - I/O wait alto su disco meccanico: migrare a SSD è l'unica soluzione strutturale. Come workaround, abilita il query cache MySQL e il page caching
- I/O wait alto su SSD: probabilmente è swap. Se il server sta swappando, serve più RAM o meno processi
Causa #4: Nessun page caching
WordPress senza cache genera ogni pagina da zero: query al database, esecuzione PHP, rendering HTML. Per ogni singolo visitatore.
Un sito con 1.000 visite/giorno senza cache fa circa 30.000 query MySQL al giorno che potrebbe non fare.
Come diagnosticare
# Controlla se c'è un header di cache nella risposta
curl -sI https://dominio.com | grep -i "x-cache\|x-fastcgi-cache\|cf-cache"
# Se non trovi nessun header di cache → nessun caching attivo
Come risolvere
La gerarchia di efficacia:
- Server-side full page cache (migliore): FastCGI Cache in Nginx, LiteSpeed Cache, Varnish. Il web server serve HTML statico senza toccare PHP.
- Plugin cache WordPress: WP Super Cache, W3 Total Cache, LiteSpeed Cache plugin. Meno efficiente ma più facile da configurare.
- CDN con cache (Cloudflare, BunnyCDN): riduce il carico sul server per asset statici e, con configurazione avanzata, anche per le pagine HTML.
Il setup che usiamo più spesso: Nginx FastCGI Cache per le pagine + Cloudflare per gli asset statici. Il server gestisce meno del 10% delle richieste reali. Il TTFB passa da 2-3 secondi a 50-100ms.
Causa #5: Troppi siti sullo stesso server
Un server da 8GB che ospita 40 siti WordPress non è "ottimizzato". È sovraffollato. Ogni sito ha i suoi cron, i suoi plugin, le sue query. Anche se nessun sito è "pesante", l'effetto cumulativo è devastante.
Come diagnosticare
# Quanti siti WordPress ci sono?
find /home -name "wp-config.php" 2>/dev/null | wc -l
# Quanti processi PHP totali?
ps aux | grep php-fpm | grep -v grep | wc -l
# Connessioni MySQL attive
mysqladmin processlist | wc -l
Come risolvere
Non c'è una scorciatoia. Le opzioni reali sono:
- Distribuire su più server: sposta i 10 siti più pesanti su un secondo server
- Upgrade risorse: più RAM e CPU, almeno come soluzione temporanea
- Disabilitare WP-Cron nativo e centralizzare con un cron di sistema: riduce drasticamente i picchi
# In ogni wp-config.php
define('DISABLE_WP_CRON', true);
# Nel crontab di sistema (un cron per sito, sfalsati)
*/5 * * * * curl -s https://sito1.com/wp-cron.php > /dev/null 2>&1
*/5 * * * * sleep 30 && curl -s https://sito2.com/wp-cron.php > /dev/null 2>&1
Il quadro completo
In ordine di impatto, quando un sito WordPress è lento:
- MySQL - tuning del buffer pool e delle connessioni (60% dei casi)
- PHP-FPM - worker configurati correttamente per la RAM disponibile
- Caching - page cache server-side attivo e funzionante
- Disco - spazio libero sufficiente, SSD, no swap
- Densità - numero di siti proporzionato alle risorse
Solo dopo aver verificato tutti questi punti ha senso guardare i plugin, il tema, o il codice dell'applicazione.
Quando serve un professionista
Se hai controllato tutti i punti sopra e il sito è ancora lento, il problema è probabilmente più complesso: query N+1 nel tema, plugin che fanno chiamate API sincrone, configurazione Cloudflare che invalida la cache, o un mix di tutto.
Facciamo diagnosi performance su server Linux a prezzo fisso. Identifichiamo il collo di bottiglia, lo risolviamo, ti diamo un report con i numeri prima/dopo. Richiedi un intervento SOS.
La regola d'oro: se il TTFB è sopra i 500ms, il problema è nel server. Se è sotto i 200ms ma la pagina carica lenta, allora è nel frontend. Non ottimizzare il frontend quando il backend è il collo di bottiglia.
Pronto a smettere di occuparti dei server?
Audit scritto, zero impegni, report PDF con assessment della tua situazione.
Altri playbook collegati.
Guide che completano questo scenario operativo e ti aiutano a chiudere il cerchio tra diagnosi, prevenzione e continuità.
MySQL slow queries: playbook operativo per trovare il collo di bottiglia vero
Le slow query non si risolvono alzando la RAM a caso. Devi capire quali query rallentano davvero, perché, e in che ordine intervenire.
PHP-FPM sizing: come dimensionare davvero i worker su WordPress
PHP-FPM lento o instabile non si aggiusta alzando numeri a caso. Devi misurare RAM per processo, coda richieste e comportamento del traffico.
MySQL buffer pool: come calibrarlo davvero (senza magia)
La regola del 70-80% della RAM è una semplificazione pericolosa. Il buffer pool si calcola con dati, non con formule. Ecco come fare tuning evidence-based.