WordPress TTFB Optimization: Get Time to First Byte Under 200ms

La maggior parte dei proprietari di siti è ossessionata dai punteggi Lighthouse, dalla compressione delle immagini e dal numero di plugin. Ma c'è un numero che rivela più di qualsiasi altro sulla tua infrastruttura: Time to First Byte (TTFB).

Il TTFB è il tempo che intercorre tra la richiesta della pagina da parte del browser dell'utente e la ricezione del primo byte della risposta. È la misura più pura di quanto sia veloce il tuo server — prima che una singola immagine, script o foglio di stile venga scaricato.

Un TTFB lento significa che il tuo server stesso è lento. Nessuna quantità di ottimizzazione delle immagini o plugin di caching può nasconderlo. Questo è il motivo per cui i Core Web Vitals di Google trattano il TTFB come la base del Largest Contentful Paint (LCP): un server lento ritarda tutto ciò che segue.

In questa guida, imparerai come appare un buon TTFB, come misurarlo e la sequenza esatta di otto passaggi per ridurre il TTFB del tuo WordPress sotto i 200ms — il target che garantiamo sull'infrastruttura Fortezza Digitale.

Qual è un Buon TTFB per WordPress?

Prima di ottimizzare, ti serve un benchmark. Ecco la scala che usa la maggior parte degli ingegneri delle prestazioni:

Sotto 100ms: Eccellente. Solo VPS dedicati o server dedicati con software ottimizzato raggiungono questo risultato.
100–200ms: Molto buono. Un VPS ben configurato con una corretta cache. Questo è l'obiettivo per siti seri.
200–500ms: Accettabile ma lento. Tipico di hosting condiviso o di un VPS non ottimizzato. Gli utenti lo notano.
500ms–1s: Scarso. Il tuo server è il collo di bottiglia. I visitatori iniziano ad abbandonare il sito.
Oltre 1s: Critico. Qualcosa è fondamentalmente sbagliato nel tuo hosting o nella configurazione.

Google raccomanda un TTFB di sotto 800ms, ma questo è un minimo, non un obiettivo. Per un sito che si posiziona e converte, mira a 200ms o meno. Ogni 100ms di latenza del server ritarda direttamente il tuo LCP e spinge i tuoi Core Web Vitals più lontano dal verde.

La verità dolorosa: se il tuo TTFB supera i 300ms, il problema è il tuo hosting, non il tuo sito. Puoi rifinire il frontend tutto il giorno, ma una risposta lenta del server limita tutto.

Come misurare correttamente il TTFB

La maggior parte delle persone misura il TTFB in modo errato. Il pannello di rete del browser include la risoluzione DNS, la configurazione della connessione e l'handshake TLS, che possono trarre in inganno.

Misura a livello di server

La misurazione più pulita è sul server stesso, bypassando la rete:

curl -o /dev/null -s -w "TTFB: %{time_starttransfer}s\n" https://yourdomain.com

Questo isola il tempo di risposta grezzo del server. Eseguilo 5 volte e prendi la mediana, non la media (una singola richiesta a freddo gonfia il numero).

Misura da più posizioni

Una singola misurazione dal tuo ufficio ti dice poco. Usa:

WebPageTest con una posizione lontana dal tuo server per testare la latenza globale.
GTmetrix vista a cascata per vedere il TTFB suddiviso per DNS, connessione e tempo di attesa.
Google PageSpeed Insights — guarda il campo “server response time” nella diagnostica.

Separa i due componenti del TTFB

Un TTFB misurato è in realtà due cose: RTT di rete (quanto distante è il tuo utente dal tuo server) e tempo di elaborazione del server (quanto tempo impiega il server per generare la risposta).

Il comando curl sopra ti mostra il totale. Per isolare l'elaborazione del server, confrontala con un semplice test di latenza (ping o curl a un file statico). Se un file statico è veloce (20ms) ma la tua homepage è 400ms, il problema è elaborazione lato server, non la rete.

Questa distinzione è importante: una CDN risolve la latenza di rete, ma solo l'ottimizzazione del server risolve l'elaborazione lenta. La maggior parte dei problemi TTFB di WordPress sono lato server — ed è redditizio risolverli perché ne hai il controllo.

La Sequenza in 8 Passi per Ridurre il TTFB di WordPress

Affrontali in ordine. Ogni passaggio affronta un diverso livello dello stack e ciascuno si accumula sul precedente.

Passo 1: Sistemare l'Hosting Stesso

Il TTFB inizia dalle fondamenta. Se sei su hosting condiviso, questo è il tuo tetto, punto e basta.

L'hosting condiviso limita la CPU, limita l'uso degli inode e fa overselling delle risorse del server. Il picco di traffico del tuo vicino “veloce” rallenta il tuo sito. Nessuna ottimizzazione — caching, CDN o altro — compensa pienamente un host che ti limita.

Passa a VPS con CPU e RAM garantite. Solo questo spesso fa scendere il TTFB da 600ms a 150ms perché smetti di competere per le risorse. Scegli un provider con storage NVMe veloce e data center vicini al tuo pubblico.

Non hai bisogno del piano più costoso. Hai bisogno risorse garantite. Un VPS modesto ma isolato batte ogni volta un piano condiviso nominalmente più veloce.

Passaggio 2: Ottimizza PHP-FPM

PHP-FPM è il process manager che esegue il tuo codice PHP. La sua configurazione predefinita è progettata per un uso ridotto della memoria, non per la velocità — e limita i siti WordPress ad alto traffico.

Apri il tuo php-fpm.conf (o configurazione del pool) e regola:

pm.max_children = 30
pm.start_servers = 5
pm.min_spare_servers = 5
pm.max_spare_servers = 10

I numeri esatti dipendono dalla RAM del tuo server. Una regola approssimativa: ogni worker PHP utilizza circa 40–80MB. Un VPS da 4GB esegue comodamente 30–40 worker.

Una sotto-provisioning di PHP-FPM significa che le richieste si accodano in attesa di un worker libero. Questo aumenta direttamente il TTFB. Regolalo in modo da non aspettare mai un worker in condizioni di traffico normale.

Passo 3: Usa la Versione PHP Corretta

Questa è la vittoria più economica sul TTFB disponibile. Ogni versione principale di PHP è più veloce della precedente.

PHP 7.4 ha raggiunto la fine del ciclo di vita ed è drammaticamente più lento rispetto alle versioni moderne.
PHP 8.1 è circa 2 volte più veloce rispetto a PHP 7.4 per i tipici carichi di lavoro WordPress.
PHP 8.2 e 8.3 continuano i guadagni con il supporto JIT e i miglioramenti di opcache.

Se sei ancora su PHP 7.x, l'aggiornamento a 8.3+ è un semplice menu a tendina nella maggior parte dei pannelli di controllo e può ridurre il TTFB del 30–50% senza modifiche al codice. Verifica prima che i tuoi plugin e il tema supportino la versione, ma quasi tutti i plugin moderni lo fanno.

Abilita l'estensione OpCache se non è già attiva. OpCache memorizza nella cache il bytecode PHP compilato in memoria, eliminando la fase di parsing e compilazione a ogni richiesta — una significativa riduzione lato server.

Passaggio 4: Ottimizza il database

Il database di WordPress è un frequente killer nascosto del TTFB. Ogni caricamento di pagina esegue decine di query, e un database non ottimizzato rende ciascuna più lenta e ripete il lavoro.

Inizia con il caching dei risultati delle query (object caching). Come spiegato nella nostra guida su Redis, installare Redis come backend dell'object cache riduce drasticamente il numero di query al database ripetute per richiesta. È uno dei cambiamenti lato server ad alto impatto disponibili.

Poi pulisci il database:

Rimuovi transient, revisioni e spam dalle tabelle.
Aggiungi indici appropriati alle wp_options e wp_postmeta tabelle — queste sono le tabelle che ricevono il maggior numero di query in WordPress.
Considera MariaDB o MySQL 8 rispetto alle versioni MySQL più vecchie per un migliore ottimizzatore di query e prestazioni InnoDB.

Un database ottimizzato dovrebbe rispondere alle query di una pagina in meno di 30ms. Se richiede 200ms, il database è il tuo collo di bottiglia.

Passaggio 5: Aggiungi la cache delle pagine a livello di server.

La cache delle pagine serve una copia HTML statica di ogni pagina invece di eseguire PHP a ogni richiesta. Questa è la più grande riduzione del TTFB disponibile.

Ci sono due livelli:

Cache di pagina tramite plugin (ad esempio, WP Super Cache, plugin di cache) funziona, ma avvia comunque WordPress e PHP per servire il file in cache — il suo TTFB è solo marginalmente migliore rispetto a una pagina dinamica.
Cache a livello di server (cache FastCGI di Nginx, Varnish, cache di pagina Redis) serve l'HTML in cache direttamente dalla memoria. prima PHP gira. Per i visitatori anonimi questo può portare il TTFB sotto 50ms.

La differenza è enorme. La cache a livello server intercetta la richiesta al server web, mai toccando PHP. Ecco perché la nostra configurazione Fortezza usa un livello di cache nativo piuttosto che affidarsi solo ai plugin.

Passaggio 6: Abilita compressione e HTTP/2

Due ottimizzazioni a livello di protocollo riducono i byte trasferiti e l'overhead di connessione:

Gzip o Brotli La compressione riduce HTML, CSS e JS del 60-80% prima che vengano trasmessi. Brotli generalmente comprime meglio di gzip con le stesse impostazioni.
HTTP/2 multiplexa più richieste su una singola connessione, eliminando il blocco head-of-line di HTTP/1.1 e riducendo i round trip per le risorse della pagina.

Entrambe sono configurate sotto il cofano a livello di web server o CDN. Non riducono direttamente l'elaborazione del server tempo, ma riducono millisecondi reali dalla risposta totale — e sono gratuiti.

Passaggio 7: Aggiungi una CDN con caching perimetrale

Una Content Delivery Network (CDN) replica i tuoi asset statici — e, con il caching perimetrale, la tua pagina intera — in data center più vicini ai tuoi visitatori.

Questo affronta RTT di rete componente del TTFB. Un utente a Milano che raggiunge un server a Francoforte o Amsterdam ha una latenza di andata e ritorno di 30–60ms. Con un nodo edge CDN a Milano, quella scende a meno di 10ms.

Per la cache a pagina intera, la CDN memorizza l'output HTML al bordo e lo serve ai visitatori anonimi senza mai contattare il tuo server di origine. Combinato con la cache a livello server, questo ti dà un TTFB sub-50ms per la stragrande maggioranza delle richieste.

Poiché serviamo clienti europei con requisiti GDPR, usiamo una CDN con posizioni edge solo nell'UE e garantiamo che nessun dato lasci l'UE.

Passaggio 8: Monitora e mantieni

L'ottimizzazione non è un compito una tantum. Il TTFB si degrada silenziosamente mentre il tuo sito cresce, i plugin si accumulano e i modelli di traffico cambiano.

Imposta un ciclo di monitoraggio:

Settimanalmente: Esegui la misurazione curl di cui sopra e registra la mediana.
Mensilmente: Controlla i Core Web Vitals in Search Console e PageSpeed Insights.
Ad ogni modifica: Ripeti il test del TTFB ogni volta che aggiungi un plugin pesante, cambi tema o modifichi la configurazione del server.

Fai attenzione alla crescita lenta. Un TTFB che sale da 150ms a 300ms nell'arco di tre mesi segnala una regressione di un plugin o un server sottodimensionato che necessita di scaling.

Una diagnosi reale: da 900ms a 160ms

Per rendere il tutto concreto, ecco l'esatta sequenza di riscontri di un tipico sito WordPress lento — lo stesso schema che vediamo su quasi ogni sito che arriva su Fortezza con “il mio sito è lento”.

Punto di partenza: TTFB di 900ms misurato tramite curl, caricamento pagina di 4,2 secondi, LCP di 5,4s. Il proprietario aveva già provato quattro plugin di ottimizzazione immagini e tre plugin cache senza alcun miglioramento reale.

Diagnosi (5 minuti):

curl -w "TTFB: %{time_starttransfer}s\n" → 900ms. Già tutto il problema.
Servire un file statico → 40ms. Quindi la rete era a posto; l'elaborazione del server era 860ms.
Versione PHP controllata → ancora in esecuzione PHP 7.4, fine del ciclo di vita.
pm.max_children → impostato su 10 worker conservativi, tutti saturati durante i picchi di traffico.
Cache oggetti Redis → non installata. Ogni richiesta ripeteva le stesse ~40 query al database.
Nessuna cache di pagina a livello di server. Ogni caricamento di pagina anonima eseguiva PHP + MySQL completi.

Correzioni applicate in ordine:

Aggiornato PHP 7.4 → PHP 8.3: TTFB sceso da 900ms a ~500ms. I miglioramenti del compilatore e di OpCache da soli hanno fatto la maggior parte del lavoro.
Ottimizzato PHP-FPM pm.max_children da 10 a 32 e ho regolato i server di riserva: il TTFB è sceso a ~350ms. Non più code su lavoratori liberi.
Installato Redis come backend per la cache degli oggetti: il TTFB è sceso a ~260ms. Le query ripetute al database sono cessate.
Cache FastCGI Nginx abilitata per i visitatori anonimi: TTFB sceso a ~120ms, perché PHP non girava più affatto per le pagine in cache.
Aggiunto un CDN con edge in UE per la latenza geografica residua: TTFB misurato da una città europea remota sceso a ~90ms.

Per favore, fornisci le stringhe da tradurre. { "text": "TTFB di 90–120ms (a seconda della posizione), LCP inferiore a 2.5s, Core Web Vitals completamente verdi. Tempo totale investito: meno di un'ora, interamente lato server." }

La lezione è sempre la stessa: il sito non era mai stato rotto — era lo stack. Una volta che al server sono state date risorse reali, un PHP moderno, una query cache e un layer nativo di page-cache, il "sito lento" è sparito senza toccare una singola riga di frontend.

Una Configurazione di Riferimento per la Cache FastCGI Nginx

Se usi Nginx come web server e vuoi il page caching a livello di server, una cache FastCGI è una delle cose ad alto impatto che puoi abilitare. Ecco un riferimento minimo funzionante:

# Nel contesto http
fastcgi_cache_path /var/cache/nginx levels=1:2 keys_zone=WORDPRESS:100m inactive=60m max_size=1g;
fastcgi_cache_key "$scheme$request_method$host$request_uri";

# Nel blocco server / location che fa da proxy a PHP
set $skip_cache 0;
if ($request_uri ~* "/wp-admin/|/wp-json/|/xmlrpc.php|wp-.*.php") { set $skip_cache 1; }
if ($request_method = POST) { set $skip_cache 1; }
if ($query_string != "") { set $skip_cache 1; }

location ~ \.php$ {
    include fastcgi_params;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    fastcgi_pass unix:/var/run/php/php8.3-fpm.sock;
    fastcgi_cache WORDPRESS;
    fastcgi_cache_valid 200 60m;
    add_header X-Cache $upstream_cache_status;
    fastcgi_cache_bypass $skip_cache;
    fastcgi_no_cache $skip_cache;
}

{"The": "Il"} X-Cache ti permette di confermare che la cache funziona: HIT appare sulle risposte in cache, MISS sulla prima richiesta. Le regole $skip_cache mantengono dinamici l'area admin, l'API REST e i flussi con login, così non servi mai contenuti stantii agli utenti autenticati.

Nota che WordPress imposta gli header Cache-Control e potresti aver bisogno di una piccola modifica per la piena compatibilità. Per il comportamento del team e le sessioni con login, i casi limite contano — ecco perché un layer di caching ben testato e pre-costruito (come quello di una configurazione managed) batte il fai-da-te su un sito trafficato.

Cosa NON fare: errori comuni relativi al TTFB

Diverse ottimizzazioni sembrano utili ma fanno perdere tempo o peggiorano le cose:

Nascondere il TTFB con uno spinner di caricamento o uno skeleton. Questo non risolve il problema del server lento; maschera solo il ritardo all'utente. Google continua a misurare il tempo di risposta reale.
Risolvere il TTFB con il lazy loading front-end. Il lazy loading posticipa immagini e script — non velocizza la risposta iniziale del server. Aiuta l'LCP ma non il TTFB.
Sospetto sui plugin “cache everything” che entrano in conflitto. Troppi livelli di cache che si contrastano a vicenda creano pagine obsolete e doppio lavoro. Usa uno stack coerente, non cinque plugin sovrapposti.
Ottimizzare prima di misurare. Se non puoi indicare il tuo TTFB mediano attuale, stai ottimizzando alla cieca. Misura prima.

Il punto fondamentale

Il TTFB è la metrica delle prestazioni più onesta del web, e la strada più rapida per un sito veloce è risolverlo.

Ecco di nuovo la sequenza, in una riga: {"translation":"esci dall'hosting condiviso → ottimizza PHP-FPM → aggiorna PHP → metti in cache le query con Redis → aggiungi la cache delle pagine a livello di server → attiva la compressione e HTTP/2 → metti una CDN davanti → monitora settimanalmente."}

Fai tutti gli otto e atterrerai sotto i 200ms, spesso sotto i 100ms. Non farne nessuno e ogni altro sforzo di performance che fai è limitato da un server lento.

Questo è esattamente lo stack che usiamo su Fortezza Digitale: infrastruttura VPS dedicata, caching nativo, TTFB sotto 200ms garantito e monitoraggio continuo così le prestazioni non decadono mai silenziosamente.

Un TTFB lento non è un mistero. È una checklist. Ora ce l'hai.