Quando preparo un nuovo server per WooCommerce, seguo un processo distillato negli anni.
Non è una “ricetta magica”, ma un manuale operativo per trasformare una macchina cloud standard in un setup ottimizzato per l’e-commerce.
L’obiettivo è la stabilità e la velocità, che ottengo lavorando su tre fronti: I/O stabile, ottimizzazione della RAM per il database e una cache a tre livelli + CDN.
Stack di riferimento
- Server: macchina cloud con vCPU dedicate per garantire I/O costante.
- OS: Ubuntu 24.04 LTS.
- Pannello: Virtualmin installato in modalità
--minimal. Solo stack LEMP, senza servizi email o DNS locali. - Motori: Nginx e PHP-FPM dai repository
ppa:ondrej, più Redis per la cache. - DNS & CDN: Cloudflare per la gestione DNS, la protezione DDoS e la cache di livello 1 (Edge Cache e proxy HTTPS).
Appena installato Virtualmin, il primo passo è la purga:
disabilito tutti i servizi non necessari (postfix, dovecot, bind9, proftpd, firewalld, spamassassin, clamav-daemon).
Messa a punto del server master (una tantum)
Dopo aver completato l’hardening del server — quindi la messa in sicurezza del sistema, la gestione degli accessi SSH, il blocco dei servizi inutili e l’applicazione dei limiti di rete — passo alla configurazione delle performance.
Queste sono le modifiche globali che applico al server una sola volta.
- Swap e Swappiness
Creo un file di swap. La dimensione dipende dalla RAM, ma imposto semprevm.swappiness = 10in/etc/sysctl.conf, così il sistema usa lo swap solo quando strettamente necessario. - Tuning MariaDB
Il database è il cuore di WooCommerce.
In50-server.cnfalloco una parte significativa della RAM all’innodb_buffer_pool_size(es. 8 GB su una macchina da 16 GB).
Aggiungo:innodb_flush_method = O_DIRECT
innodb_log_file_size = 1G
innodb_buffer_pool_instances = 8 - Tuning Redis (Cache L3)
Redis funge da Object Cache per WordPress.
Imposto limiti precisi:
In questo modo Redis rimuove automaticamente le chiavi meno usate e mantiene costante il consumo di RAM.maxmemory 1024mb
maxmemory-policy allkeys-lru - Tuning Nginx (Cache L2 globale)
Definisco il percorso della cache globale nel filenginx.conf(dentrohttp {}):
Questo crea la cache condivisa che i vari siti potranno utilizzare.fastcgi_cache_path /var/cache/nginx levels=1:2 keys_zone=WORDPRESS:100m inactive=60m max_size=1g; - Firewall e sicurezza base
Abilitoufwsolo sulle porte essenziali (22, 80, 443, 10000) e lascio la protezione avanzata a Cloudflare.
Checklist per un nuovo sito WooCommerce
Per ogni nuovo dominio WooCommerce, seguo un flusso preciso e ripetibile.
- Creazione del sito
Da Virtualmin creo un “Virtual Server”, disabilitando email e DNS locali.
Il dominio principale usa Cloudflare, che gestisce il traffico e la cache di primo livello. - SSL e HTTP/2
Richiedo il certificato Let’s Encrypt e abilito SSL + HTTP/2 dalle “Nginx Website Options”.
Su Cloudflare, imposto modalità SSL “Full (Strict)” e attivo HTTP/3.
- Tuning PHP-FPM (per versione)
Se è la prima volta che uso una certa versione di PHP sul server, ottimizzo il pool:
Per siti ad alto traffico, valutopm = ondemand
pm.max_children = 75
pm.process_idle_timeout = 10s
memory_limit = 512Mpm = dynamiccon limiti più alti. - Configurazione Nginx (per sito)
Modifico il file di configurazione del dominio e aggiungo:
Includo anche le regole di bypass per carrello, checkout e pagine utente.fastcgi_cache WORDPRESS;
fastcgi_cache_valid 200 60m;
fastcgi_cache_bypass $skip_cache;
fastcgi_no_cache $skip_cache; - Config Purge
Aggiungo un blocco dedicato al purge:
Serve al plugin Nginx Helper per svuotare la cache L2 in modo selettivo.location ~ /purge(/.*) {
allow 127.0.0.1;
deny all;
fastcgi_cache_purge WORDPRESS "$scheme$request_method$host$1";
} - Cron reale
Disabilito il cron finto di WordPress aggiungendo inwp-config.php:
Poi imposto un cron vero da Webmin, che gira ogni 5 minuti come utente del sito:define('DISABLE_WP_CRON', true);*/5 * * * * php /home/utente/public_html/wp-cron.php > /dev/null 2>&1 - Plugin WordPress
Dopo l’installazione, attivo:- Redis Object Cache – gestisce la cache L3 a livello di oggetti.
- Nginx Helper – gestisce la cache L2 e le operazioni di purge.
- Cloudflare (ufficiale) – integra la cache L1 edge e le funzioni di protezione (Firewall, DDoS, Bot Fight).
- Impostazioni Cloudflare consigliate
- Modalità proxy attiva (nuvola arancione).
- Page Rules o Cache Rules per cache “Cache Everything” sulle pagine pubbliche.
- Firewall Rules per bloccare accessi diretti all’IP origin.
- Browser Cache TTL = 1 giorno, Edge Cache TTL = 1 ora (bilanciato).
- Always Use HTTPS e HTTP/3 abilitati.
Risultato finale
Con questo schema a quattro livelli di cache:
- L1 → Cloudflare (Edge Cache + DNS + Protezione)
- L2 → Nginx FastCGI Cache
- L3 → Redis Object Cache
- L4 → Query cache di MariaDB (buffer pool ottimizzato)
ottengo un’infrastruttura WooCommerce veloce, sicura e replicabile,
con tempi di risposta medi sotto i 100 ms per le pagine cached e un backend stabile anche con carichi elevati.