Ottimizzare il server per WordPress

Requisiti server per WordPress

WordPress è un CMS potente ma esigente: per funzionare al meglio necessita di un ambiente server adeguatamente configurato. I requisiti minimi ufficiali includono PHP 7.4 o superiore (consigliato PHP 8.1+), MySQL 5.7 o MariaDB 10.4+, e supporto HTTPS. Tuttavia, per un sito professionale, questi valori rappresentano solo il punto di partenza. La memoria PHP consigliata è di almeno 128 MB per sito, ma con plugin complessi e temi page builder si sale rapidamente a 256 o 512 MB. La CPU incide soprattutto sui picchi di traffico: un sito condiviso su server economici soffre durante i momenti di alta richiesta.

La scelta della versione PHP è critica: PHP 8.x offre miglioramenti prestazionali fino al 30% rispetto a PHP 7.4 grazie al JIT compiler. Verificate sempre che il vostro hosting supporti le versioni più recenti e che i plugin e il tema siano compatibili. Strumenti come “Health Check & Troubleshooting” di WordPress aiutano a diagnosticare problemi di compatibilità.

Scegliere il tipo di hosting

L’infrastruttura di hosting è la base su cui poggia tutto il resto. La scelta tra hosting condiviso, VPS, dedicato e cloud dipende dal volume di traffico, dal budget e dalle competenze tecniche.

Hosting condiviso

Economico e gestito, ideale per siti piccoli o in fase di lancio. Le risorse (CPU, RAM, I/O) sono condivise tra centinaia di utenti. Se un sito vicino assorbe traffico, il vostro ne risente. Adatto per blog personali o siti vetrina con poche visite giornaliere.

VPS (Virtual Private Server)

Offre risorse dedicate all’interno di un ambiente virtualizzato. Ogni VPS ha CPU, RAM e storage assegnati, senza competizione con altri utenti. È la scelta più bilanciata per siti in crescita. Richiede competenze di amministrazione Linux o un pannello come Plesk, cPanel o RunCloud.

Server dedicato

Una macchina fisica interamente per voi. Massime prestazioni e controllo totale. Necessario per siti con centinaia di migliaia di visite mensili, e-commerce pesanti o applicazioni custom. Costo elevato e gestione complessa.

Cloud hosting

Piattaforme come AWS, Google Cloud, DigitalOcean o Linode offrono scalabilità orizzontale. Si paga a consumo e si possono aggiungere risorse al volo. Ottimo per siti con traffico variabile. Servono competenze DevOps per configurare correttamente load balancer, auto-scaling e caching distribuito.

Ottimizzazione del web server

Il web server è il primo punto di contatto con i visitatori. La configurazione influisce direttamente sui tempi di risposta e sulla capacità di gestire richieste concorrenti.

Nginx vs Apache

Apache è tradizionale, funziona con .htaccess, ed è più facile da configurare. Nginx è event-driven, consuma meno memoria e gestisce più connessioni simultanee con minori risorse. Per WordPress, Nginx con PHP-FPM è considerato lo stack più performante. Apache con mod_php è più semplice ma meno efficiente sotto carico. Una configurazione ibrida (Nginx come reverse proxy con Apache dietro) unisce flessibilità e prestazioni.

PHP-FPM e worker process

PHP-FPM separa l’esecuzione PHP dal web server. I parametri cruciali sono pm.max_children, pm.start_servers, pm.min_spare_servers e pm.max_spare_servers. Un valore troppo basso causa errori “502 Bad Gateway” sotto carico; troppo alto esaurisce la RAM. Per un VPS con 2 GB di RAM, un buon punto di partenza è max_children = 10, con processi dinamici. Usate strumenti come htop e il log di PHP-FPM per monitorare l’utilizzo.

Gzip e caching delle pagine statiche

Abilitate la compressione Gzip a livello server per ridurre la dimensione dei file trasferiti. Nginx: gzip on; gzip_types text/css application/javascript image/svg+xml;. Per le risorse statiche (CSS, JS, immagini), impostate header Cache-Control con expiry lungo. Plugin come WP Rocket o Flying Press gestiscono automaticamente il caching lato server, ma una configurazione manuale su Nginx con FastCGI Cache elimina la necessità di plugin.

Ottimizzazione del database

Il database MySQL o MariaDB è spesso il collo di bottiglia nascosto. WordPress esegue numerose query per ogni pagina; un database ottimizzato riduce i tempi di caricamento in modo significativo.

Query cache e buffer pool

InnoDB è il motore predefinito e consigliato. Il parametro innodb_buffer_pool_size dovrebbe occupare il 70-80% della RAM disponibile (escludendo quella riservata a PHP e OS). Su un server con 4 GB di RAM, impostate 2-3 GB. La query cache (query_cache_type e query_cache_size) è deprecata da MySQL 8, ma su MariaDB è ancora utile. Attivate query_cache_type = 1 con una dimensione di 64-128 MB per siti con molte letture.

Altre ottimizzazioni InnoDB

innodb_log_file_size = 256 MB per gestire scritture pesanti senza attriti. innodb_flush_method = O_DIRECT per bypassare il filesystem cache. innodb_file_per_table = ON per gestire singole tabelle. Disabilitate innodb_flush_log_at_trx_commit = 2 se la durabilità immediata non è critica (raddoppia le prestazioni di scrittura). Usate lo script mysqltuner.pl per ricevere raccomandazioni personalizzate.

Manutenzione periodica del database

Plugin come WP-Optimize o Advanced Database Cleaner eliminano revisioni, post spam e transient scaduti. Pianificate pulizie settimanali. Le tabelle wp_options e wp_postmeta crescono rapidamente; ottimizzatele con OPTIMIZE TABLE. Per database molto grandi, valutate l’indicizzazione personalizzata delle meta query più frequenti.

Ottimizzazione a livello di sistema operativo

Il kernel Linux offre parametri regolabili per migliorare le prestazioni del server WordPress.

Swappiness

vm.swappiness controlla la propensione del kernel a usare la swap. Su un server dedicato, impostate vm.swappiness = 10 (valore predefinito 60). Questo riduce l’uso della swap e mantiene i dati in RAM, dove l’accesso è più veloce. Per server con molta RAM, potete scendere a 5 o addirittura 0.

File descriptors e connessioni

Il limite di file descriptors (ulimit -n) deve essere alto per gestire molte connessioni simultanee. Impostate fs.file-max = 100000 in /etc/sysctl.conf. Per Nginx, aumentate worker_connections a 1024 o più. Anche il net.core.somaxconn (coda di connessioni in attesa) va portato ad almeno 1024 per evitare rifiuti di connessione sotto carico.

Kernel parameters per reti

net.ipv4.tcp_tw_reuse = 1 per riutilizzare i socket TIME_WAIT. net.core.rmem_max e net.core.wmem_max = 16777216 per buffer di rete più grandi. net.ipv4.tcp_congestion_control = bbr (BBR congestion control) migliora la velocità percepita su connessioni con perdita di pacchetti. Applicate con sysctl -p e verificate con sysctl .

Configurazione PHP

Il file php.ini contiene decine di parametri che influenzano WordPress. I più importanti sono raggruppabili in tre aree: limiti di risorse, gestione upload e caching delle opcode.

Limiti di memoria e tempo

memory_limit = 256M (o 512M per siti complessi). max_execution_time = 120 secondi per permettere operazioni lunghe (import, backup, aggiornamenti). max_input_time = 120. Questi valori si impostano nel php.ini principale o tramite wp-config.php con define(‘WP_MEMORY_LIMIT’, ‘256M’);.

Upload e file

upload_max_filesize = 64M (per caricare temi, plugin e media pesanti). post_max_size = 64M (deve essere >= upload_max_filesize). max_file_uploads = 20 (numero massimo di file per richiesta). Se usate un CDN per media, potete tenere valori più bassi.

OPcache

OPcache memorizza il bytecode compilato di PHP in RAM, eliminando la ricompilazione a ogni richiesta. Configurazione consigliata: opcache.enable=1, opcache.memory_consumption=128, opcache.max_accelerated_files=4000, opcache.revalidate_freq=60. Su server con molti plugin, aumentate memory_consumption a 256 MB e max_accelerated_files a 10000. Disabilitate opcache.validate_timestamps in produzione per massime prestazioni (ma ricordatevi di svuotare la cache dopo aggiornamenti).

Monitoraggio della salute del server

L’ottimizzazione non è un’operazione una tantum. Strumenti di monitoraggio aiutano a identificare colli di bottiglia prima che diventino critici.

htop, iotop e nload danno una panoramica in tempo reale di CPU, I/O disco e banda di rete. Per monitoraggio storico, Netdata o Prometheus con Grafana sono la scelta professionale. New Relic e Datadog offrono piani gratuiti con tracciamento delle transazioni PHP. Dal lato WordPress, il plugin Query Monitor mostra query lente, hook dispendiosi e warning PHP in tempo reale.

Impostate alert per: utilizzo CPU > 80% per 5 minuti, RAM libera < 256 MB, spazio disco < 10%, e tempi di risposta HTTP > 2 secondi. Servizi come UptimeRobot o Better Uptime inviano notifiche su Telegram, email o Slack. Con un monitoraggio solido, potete intervenire prima che gli utenti notino rallentamenti.

Conclusioni

Ottimizzare un server WordPress è un lavoro a più livelli: sistema operativo, web server, database e PHP devono lavorare in sintonia. Non serve essere esperti DevOps per ottenere miglioramenti significativi. Partite dai requisiti minimi, scegliete l’hosting adatto alle vostre esigenze, configurate Nginx con PHP-FPM, ottimizzate InnoDB per il database, regolate i parametri del kernel e impostate OPcache. Ogni passo riduce i millisecondi di caricamento e aumenta la capacità di gestire traffico. Misurate prima e dopo ogni modifica con strumenti come Lighthouse o WebPageTest per verificare i miglioramenti. Un server ben configurato è il fondamento di un sito WordPress veloce, sicuro e scalabile.

Leave a Reply