TTFB WordPress: dal server al primo byte, ogni millisecondo conta (e come abbassarlo davvero)

Il TTFB — Time to First Byte — è il tempo che il server impiega per iniziare a inviare il primo byte di risposta dopo che il browser ha fatto la richiesta. Non è il tempo di caricamento della pagina: è il tempo prima che qualsiasi cosa arrivi. È la metrica più sottovalutata e, allo stesso tempo, quella che penalizza di più un sito WordPress. Un TTFB alto significa che ogni visitatore aspetta prima ancora di vedere il primo elemento — e quell'attesa si somma a tutto il resto.

La confusione più comune è pensare che il TTFB dipenda dalla velocità di connessione dell'utente. Non è così, o almeno non principalmente. Il TTFB dipende da cosa succede sul server tra il momento in cui riceve la richiesta HTTP e il momento in cui inizia a inviare la risposta. Su WordPress, questo significa: PHP che si avvia, esegue il core, carica i plugin, fa le query al database, renderizza il template, e finalmente invia il primo byte. Ogni passaggio aggiunge tempo. Un TTFB di 1.200ms significa che il server ha impiegato più di un secondo solo per iniziare a rispondere.

Misurare il TTFB correttamente (non con PageSpeed)

Il primo errore è misurare il TTFB con PageSpeed Insights e basta. PageSpeed misura il TTFB in laboratorio, da un data center Google, su una connessione simulata — non dal tuo utente reale. Il TTFB che conta è quello che vede il visitatore, e lo misuri con cURL dal terminale:

# Misura il TTFB con cURL (il valore che conta)
curl -o /dev/null -s -w 'TTFB: %{time_starttransfer}s\nTotal: %{time_total}s\nConnect: %{time_connect}s\n' https://www.example.com/

# Ripeti 5 volte per vedere la varianza
for i in 1 2 3 4 5; do
  curl -o /dev/null -s -w 'TTFB: %{time_starttransfer}s\n' https://www.example.com/
done

# Misura anche la cache fredda vs calda:
# Prima richiesta: cache fredda (PHP gira, query al DB)
# Seconda richiesta: cache calda (HTML servito dalla page cache)

Il TTFB che vedi su PageSpeed è diverso da quello reale perché Google lo misura dal suo data center, su una connessione simulata, e con un DNS che potrebbe non essere ottimizzato. Il TTFB che conta è quello che vedi con cURL dal tuo terminale, o meglio, quello che vedi dai CrUX (Chrome User Experience Report) — i dati reali degli utenti. Se PageSpeed dice 800ms ma i CrUX dicono 300ms, il problema è il laboratorio, non il tuo sito.

Cosa determina il TTFB (in ordine di impatto)

Il fattore più importante è la page cache. Se il server può servire l'HTML già renderizzato senza far girare PHP, il TTFB scende a 50-150ms. Se PHP deve girare per ogni richiesta — perché la page cache non è attiva o la pagina è dinamica — il TTFB sale a 400-1200ms a seconda del numero di plugin e della complessità delle query. È la singola ottimizzazione più impattante.

Il secondo fattore è il database. Su un sito con molte tabelle wp_postmeta gonfie, o query complesse non ottimizzate, ogni richiesta aggiunge 100-300ms solo di tempo MySQL. L'object cache Redis riduce questo tempo intercettando le query ripetute. Il terzo fattore è il numero di plugin attivi: ogni plugin aggiunge overhead al caricamento del core, anche se non fa nulla sulla pagina corrente. Un sito con 40 plugin attivi ha un TTFB base più alto di uno con 10, a parità di tutto il resto.

Il quarto fattore — e spesso il più trascurato — è l'hosting. Un hosting condiviso sovraccarico ha un TTFB base di 300-500ms prima ancora di toccare WordPress, perché il server è saturo. Un hosting cloud dedicato con risorse garantite parte da 50-100ms. Non è un'ottimizzazione che fai sul codice: è una scelta di infrastruttura.

Gli interventi che abbassano il TTFB davvero

Primo: attiva la page cache. Su un hosting gestito è spesso già attiva; su un hosting generico, usa un plugin come WP Rocket o la cache del server. Il salto di TTFB è immediato e misurabile: da 800ms a 150ms sulle pagine statiche. Verifica che la cache non serva pagine dinamiche (checkout, account) — vedi l'articolo sul caching avanzato per le esclusioni corrette.

Secondo: riduci i plugin. Disattiva e rimuovi i plugin che non usi — non basta disattivarli, perché alcuni plugin registrano hook anche da disattivati. Un audit dei plugin attivi è il primo passo. Terzo: ottimizza il database. Tabelle wp_postmeta con milioni di righe, wp_options con autoload pesanti, revisioni accumulate. Una pulizia mirata può ridurre il TTFB del 20-30% sui siti più carichi.

-- Trova le opzioni autoload più pesanti (cause comuni di TTFB alto)
SELECT option_name, LENGTH(option_value) AS size
FROM wp_options
WHERE autoload = 'yes'
ORDER BY size DESC
LIMIT 20;

-- Se trovi opzioni di decine di KB con autoload=yes
-- che appartengono a plugin disinstallati, rimuovile:
-- DELETE FROM wp_options WHERE option_name = 'plugin_rimosso_cache';

-- Conta le revisioni (gonfiore che rallenta le query)
SELECT COUNT(*) FROM wp_posts WHERE post_type = 'revision';

Il TTFB che non puoi ottimizzare dal codice

C'è un limite oltre il quale nessuna ottimizzazione del codice aiuta: l'infrastruttura. Se il tuo hosting è condiviso e sovraccarico, il TTFB base è alto prima ancora che WordPress si avvii. Se il data center è dall'altra parte del mondo rispetto ai tuoi utenti, la latenza di rete aggiunge 100-200ms che nessuna cache può rimuovere. Se il server ha risorse insufficienti (1 vCPU, 1GB RAM), PHP non ha abbastanza potenza per renderizzare le pagine in tempo utile sotto carico.

Il TTFB è la metrica più onesta di WordPress: non puoi nasconderla con un plugin, non puoi migliorarla con un'immagine più leggera. Dice esattamente quanto il tuo server è veloce nel rispondere — e se è lento, lo è per tutti. Un audit Core Web Vitals parte sempre da lì: misura il TTFB, identifica il collo di bottiglia, e interviene sul livello giusto. Non ha senso ottimizzare le immagini se il server impiega un secondo per iniziare a rispondere.