Deploy WordPress su Nginx: come ottenere un TTFB sotto 200ms

Il Time to First Byte è il primo segnale che Google e l'utente ricevono dal tuo sito. Se supera i 600ms, stai perdendo posizioni e visitatori. Con uno stack WordPress su Nginx configurato correttamente, un TTFB sotto i 200ms è raggiungibile anche su hosting economico. Ecco come.

Perché Nginx batte Apache per WordPress

Apache processa ogni richiesta leggendo il file .htaccess, interpretando le regole mod_rewrite, e generando la risposta. Con WordPress, questo significa: lettura .htaccess → interpretazione regole → avvio PHP → connessione MySQL → generazione pagina. Ogni passaggio aggiunge millisecondi.

Nginx funziona diversamente: le regole sono compilate una volta all'avvio del server. Non c'è .htaccess da leggere ad ogni richiesta. Le connessioni sono gestite in modo asincrono (event-driven), quindi un singolo processo Nginx gestisce migliaia di connessioni simultanee senza creare nuovi thread. Il risultato è un overhead drasticamente inferiore su ogni singola richiesta.

La configurazione Nginx ottimale per WordPress

La configurazione base che produce i migliori risultati per WordPress:

• PHP-FPM come FastCGI: Nginx non esegue PHP direttamente. Passa le richieste .php a PHP-FPM tramite socket Unix (più veloce delle connessioni TCP). Configurazione pool: pm=dynamic, pm.max_children calcolato sulla RAM disponibile (ogni processo PHP consuma circa 40-60MB).
• FastCGI cache: Nginx può salvare l'output HTML generato da PHP e servirlo direttamente alle richieste successive senza coinvolgere PHP. Per pagine che non cambiano frequentemente (homepage, pagine servizi, articoli blog), questo riduce il TTFB a 10-30ms.
• Gzip/Brotli compression: comprime le risposte HTML, CSS e JS prima di inviarle al browser. Riduce il peso del trasferimento del 60-80%. Brotli è più efficiente di Gzip ma richiede HTTPS.
• HTTP/2 e keep-alive: multiplexing delle richieste su una singola connessione TCP. Elimina il costo di apertura connessione per ogni risorsa.

PHP 8.3 + OPcache: il turbo per WordPress

PHP 8.3 con OPcache attivo precompila i file PHP in bytecode e li tiene in memoria. Il risultato: WordPress non deve ri-interpretare migliaia di file PHP ad ogni richiesta. La differenza è enorme — un WordPress vanilla passa da 300-400ms a 80-120ms di tempo di esecuzione PHP solo con OPcache.

Configurazione OPcache consigliata: opcache.memory_consumption=256, opcache.max_accelerated_files=20000, opcache.revalidate_freq=60, opcache.validate_timestamps=1. Su produzione stabile, puoi impostare validate_timestamps=0 per eliminare anche il check di modifica file — ma ricordati di fare opcache_reset() dopo ogni deploy.

Redis Object Cache: eliminare le query ripetitive

WordPress esegue decine di query MySQL per ogni page load: opzioni, post meta, transient, sessioni. Molte di queste query restituiscono sempre gli stessi dati. Redis le intercetta e le serve dalla RAM, eliminando il round-trip al database.

Su un sito con WooCommerce, Redis Object Cache riduce le query MySQL per pagina da 200-400 a 30-50. Il risparmio in tempo: 100-300ms per richiesta. Con il plugin Redis Object Cache (gratuito) e un server Redis locale, l'implementazione richiede 15 minuti.

Misurare il TTFB: strumenti e metodo

Non fidarti di un singolo test. Misura il TTFB con almeno tre strumenti e fai la media:

• curl da terminale: curl -o /dev/null -s -w "TTFB: %{time_starttransfer}s\n" https://tuosito.it — il più affidabile, misura dal server senza overhead del browser.
• Chrome DevTools → Network: filtra per il documento HTML, guarda la colonna "Waiting (TTFB)". Attenzione: include la latenza di rete, non solo il tempo server.
• WebPageTest.org: test da diverse location geografiche. Utile per capire l'impatto della distanza dal server per visitatori in diverse regioni.

Il target: TTFB sotto 200ms dal data center, sotto 400ms dal browser dell'utente (include latenza di rete). Con lo stack descritto sopra e un hosting italiano o europeo, entrambi i target sono raggiungibili.

Serve un VPS dedicato o basta un hosting condiviso?

Per ottenere TTFB sotto 200ms in modo consistente, serve almeno un VPS. L'hosting condiviso non ti dà controllo su Nginx, PHP-FPM e Redis. Un VPS da 10-20€/mese (Hetzner, Contabo, OVH) con 2 core e 4GB RAM gestisce tranquillamente un sito WordPress con 50.000 visite/mese.

La CDN aiuta con il TTFB?

Sì, ma non come pensi. Una CDN come Cloudflare riduce il TTFB per le risorse statiche (immagini, CSS, JS) servendole da edge server vicini all'utente. Per il documento HTML, la CDN aiuta solo se abiliti il page caching (che però può creare problemi con contenuti dinamici, carrelli, aree riservate). Per il TTFB del server, la soluzione è lo stack — non la CDN.

Posso ottenere questi risultati senza essere un sysadmin?

Sì, con panel di gestione come CloudPanel o RunCloud che configurano Nginx, PHP-FPM e Redis con interfaccia grafica. Non avrai il controllo granulare di una configurazione manuale, ma otterrai l'80% dei benefici con il 20% dello sforzo. LANGA Tools include strumenti di diagnostica performance che ti mostrano dove il sito sta perdendo tempo.

Per continuare a leggere,
accedi al tuo account.

Il tuo account LANGA ti connette a tutta la Galaxy.