Il mio processo per un setup WooCommerce Performance (LEMP)

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 l’hardening del server — gestione accessi SSH, blocco servizi inutili, limiti di rete — passo alla configurazione delle performance. Queste sono le modifiche globali che applico una sola volta.

Swap e Swappiness

Creo un file di swap dimensionato in base alla RAM disponibile, e imposto sempre:

# /etc/sysctl.conf
vm.swappiness = 10

Così il sistema usa lo swap solo quando strettamente necessario.

Tuning MariaDB

Il database è il cuore di WooCommerce. In 50-server.cnf alloco una parte significativa della RAM:

innodb_buffer_pool_size = 8G   # su macchina da 16 GB
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 per mantenere costante il consumo di RAM:

maxmemory 1024mb
maxmemory-policy allkeys-lru

In questo modo Redis rimuove automaticamente le chiavi meno usate.

Tuning Nginx (Cache L2 globale)

Definisco il percorso della cache globale in nginx.conf, dentro il blocco http {}:

fastcgi_cache_path /var/cache/nginx levels=1:2 keys_zone=WORDPRESS:100m inactive=60m max_size=1g;

Questo crea la cache condivisa che i vari siti potranno utilizzare.

Firewall e sicurezza base

Abilito ufw solo 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.

1. 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.

2. 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.

3. Tuning PHP-FPM (per versione)

Se è la prima volta che uso una certa versione di PHP sul server, ottimizzo il pool:

pm = ondemand
pm.max_children = 75
pm.process_idle_timeout = 10s
memory_limit = 512M

Per siti ad alto traffico, valuto pm = dynamic con limiti più alti.

4. Configurazione Nginx (per sito)

Nel file di configurazione del dominio aggiungo:

fastcgi_cache WORDPRESS;
fastcgi_cache_valid 200 60m;
fastcgi_cache_bypass $skip_cache;
fastcgi_no_cache $skip_cache;

Includo anche le regole di bypass per carrello, checkout e pagine utente.

5. Config Purge

Aggiungo un blocco dedicato al purge, necessario 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";
}

6. Cron reale

Disabilito il cron finto di WordPress in wp-config.php:

define('DISABLE_WP_CRON', true);

Poi imposto un cron vero da Webmin, ogni 5 minuti come utente del sito:

*/5 * * * * php /home/utente/public_html/wp-cron.php > /dev/null 2>&1

7. 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).

8. Impostazioni Cloudflare consigliate

• Modalità proxy attiva (nuvola arancione).
• Page Rules o Cache Rules per 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:

Livello	Componente	Funzione
L1	Cloudflare	Edge Cache + DNS + Protezione DDoS
L2	Nginx FastCGI Cache	Cache delle pagine lato server
L3	Redis Object Cache	Cache degli oggetti WordPress
L4	MariaDB Buffer Pool	Query cache ottimizzata

Il risultato è 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.