Skip to content

Tutto per WordPress, lo sviluppo web — e non solo

⏱ Time to first byte: cos'è il TTFB e come migliorarlo su WordPress

⏱ Time to first byte: cos'è il TTFB e come migliorarlo su WordPress

Hai cliccato un link e il browser resta lì, fermo. Nessun caricamento della pagina, nessun indicatore di progresso, solo una schermata bianca e attesa. Non è la velocità della tua connessione né JavaScript lento. È il TTFB: il tempo che il server impiega per rispondere alla primissima richiesta.

Il TTFB determina quando gli utenti vedranno qualcosa sul loro schermo. Con un TTFB lento, i visitatori abbandonano prima ancora che il tuo sito inizi a renderizzare. E a partire dal 2025, Google include la reattività del server nei suoi segnali di ranking Core Web Vitals.

Di seguito troverai cos'è realmente il TTFB, i quattro componenti che lo compongono e come ridurlo a un livello tale per cui il tuo sito consegna il primo byte più velocemente di un battito di ciglia.

💡 Panoramica rapida:

  • Capire cos'è il TTFB e perché ogni secondo di questo ritardo si moltiplica su ogni azione del visitatore.
  • Analizzare la catena di quattro fattori: DNS, server, plugin di WordPress e caching dell'HTML.
  • Confrontare quattro scenari con misurazioni reali di Pingdom, da 150 ms a catastrofici 4,2 secondi.
  • Abilitare la cache HTML e vedere come un singolo plugin riduce drasticamente il TTFB senza cambiare hosting.

Cos'è il TTFB e perché influisce su tutto

La definizione formale da Wikipedia: il TTFB è il tempo che intercorre tra l'invio di una richiesta HTTP e la ricezione del primo byte della risposta nel browser client. Include la latenza della connessione socket, il tempo di trasmissione della richiesta e il tempo di elaborazione del server.

In termini più semplici: il TTFB è la pausa tra «cliccare un link» e «qualcosa inizia ad accadere sul sito». In gergo videoludico, è la latenza, il ping, il ritardo prima della prima risposta. Gli utenti non vedono header, nessun menu, nessuno spinner, solo una scheda vuota. Più lunga è questa pausa, maggiore è la probabilità che chiudano la scheda.

Una sfumatura importante: il TTFB non influisce solo sul caricamento iniziale della pagina. Ogni navigazione interna, ogni clic su un link del menu, ogni clic su un'immagine all'interno di un articolo, è una richiesta HTTP separata con il proprio TTFB. Un punteggio scarso si moltiplica su ogni azione del lettore.

Quattro fattori che compongono il TTFB

Il TTFB non è una metrica singola, ma una somma di ritardi in ogni fase della catena «utente → sito». Tutti e quattro gli anelli funzionano in sequenza: se uno rallenta, anche il risultato finale rallenta. Esaminiamoli uno per uno.

DNS: il primo checkpoint

Il browser non sa dove si trova fisicamente il tuo server finché il DNS non converte il dominio in un indirizzo IP. Buoni server DNS con una rete distribuita di nodi lo fanno in millisecondi, mentre quelli scadenti aggiungono decine o centinaia di millisecondi a ogni caricamento di pagina.

Minimo pratico: usa Cloudflare o un servizio simile con cache DNS globale. Dopo la prima richiesta, l'indirizzo rimane in cache e la latenza DNS scompare completamente per le richieste successive.

Server e PHP: cosa succede sull'host

Ogni richiesta a una pagina WordPress non cachata avvia l'interprete PHP. Il server carica il core, il tema e i plugin attivi, esegue il loro codice e solo dopo consegna l'HTML. Le versioni moderne di PHP gestiscono questo ciclo molto più velocemente delle release di un decennio fa, per non parlare dei rami completamente obsoleti.

Due parametri dell'hosting determinano la velocità: la versione PHP e il tempo di CPU allocato al tuo piano. Hosting condiviso economico con decine di siti su un solo server e PHP obsoleto è una strada garantita verso un TTFB > 1 secondo. Hosting WordPress specializzato con PHP 8.2+ e caching integrato a livello server produce numeri radicalmente diversi.

Plugin e tema di WordPress

WordPress assembla le pagine da decine di file PHP e ogni plugin attivo aggiunge il proprio codice a questo processo. Dieci plugin di qualità di sviluppatori affidabili possono influire appena sul TTFB. Un plugin scritto male che fa tre query extra al database a ogni richiesta può affossare la velocità dell'intero sito.

Ecco un esempio di un set di plugin sensato, tutto il necessario, niente di superfluo:

Elenco plugin WordPress nel pannello di amministrazione con numero ottimale

E questa è già una configurazione potenzialmente problematica. Diverse decine di plugin attivi e il server deve elaborarli tutti durante la generazione della pagina:

Elenco lungo di plugin WordPress che rallenta la risposta del server

In pratica, più di 30 plugin attivi quasi garantiscono un TTFB elevato, anche su un buon hosting. La regola è semplice: ogni plugin dovrebbe svolgere un compito specifico che non può essere risolto altrimenti. Tutto ciò che è presente «per sicurezza» va rimosso.

Caching HTML: la leva principale

Il fattore più potente in assoluto. Un plugin di caching come Cache Enabler salva copie HTML già pronte delle pagine sul disco del server. Quando arriva una richiesta, il web server consegna un file statico, bypassando l'intero stack PHP e WordPress.

Il risultato: il server non deve più caricare core, tema e plugin per ogni visitatore. Solo il web server stesso (nginx o Apache) serve i contenuti direttamente. Ecco perché la cache offre la riduzione più significativa del TTFB, nell'ordine di grandezza, non di semplici percentuali. Abbiamo spiegato perché nginx è più efficiente di Apache per questo compito in un articolo dedicato.

TTFB nella pratica: quattro scenari

Passiamo a misurazioni reali. Di seguito i risultati dei test per diverse combinazioni di sito e server, ottenuti tramite Pingdom Tools. Ogni scenario mostra il TTFB sia nella versione senza cache sia in quella con cache.

Sito lento su server lento

La combinazione peggiore possibile: un sito con decine di plugin e senza cache su un vecchio hosting condiviso con PHP 5.4.

Risultato del test Pingdom per sito lento su server lento

Espandiamo i dettagli della prima richiesta, dove si vede il server che pensa per un'eternità:

Dettaglio TTFB che mostra 4,2 secondi in Pingdom per sito non ottimizzato

Il TTFB è di 4,2 secondi. Quattro secondi in cui l'utente fissa una schermata bianca prima che il browser riceva qualsiasi dato. Aggiungete il tempo di rendering della pagina e il tempo totale di attesa prima che il sito sia pronto arriva facilmente a sette secondi. Cloudflare davanti in questo caso non aiuta: il problema è più a monte, a livello di hosting e codice del sito.

Sito veloce su server medio

Cambiano le condizioni: un sito con plugin minimi, server su Apache con una versione PHP standard, senza cache.

Misurazione TTFB di sito veloce su hosting medio senza cache

Risultato: 521 ms. Già 8 volte meglio del primo scenario. Mezzo secondo per il primo byte, accettabile per la maggior parte dei siti. Ora attiviamo la cache:

TTFB di 152 ms dopo aver attivato la cache su server medio

Il TTFB scende a 152 ms. Anche un hosting medio con una cache configurata correttamente offre risultati eccellenti.

Sito lento su server veloce

La situazione opposta: un server ottimizzato su Plesk con nginx e una versione PHP standard, ma un sito appesantito dai plugin.

Il server veloce non salva il sito lento senza cache

Senza cache, il server veloce impiega comunque 1,29 secondi per elaborare il sito pesante. Un buon hosting mitiga ma non risolve il problema di un WordPress poco ottimizzato.

Lo stesso sito lento con cache ha mostrato un TTFB di 400 ms

Attivate la cache e il TTFB scende a 400 ms. Una differenza di oltre tre volte.

Sito veloce su server veloce

Lo scenario ottimale: un sito leggero su un buon hosting.

Sito veloce su server veloce senza caching

Senza cache, il server consegna il primo byte in meno di 500 ms. Aggiungete la cache:

Miglior risultato TTFB sotto i 150 ms su server veloce con cache

Risultato: meno di 150 ms. Risposta praticamente istantanea.

Riepilogo dei risultati

Tutti e quattro gli scenari in un unico grafico:

Grafico comparativo TTFB per quattro combinazioni di sito e hosting

La conclusione di queste misurazioni è chiara: l'hosting conta, ma ciò che fai con il sito stesso incide di più sul TTFB. Un server veloce con caching può portare anche un sito problematico a 400 ms accettabili, mentre un server lento senza cache affossa persino un WordPress leggero.

Come migliorare il TTFB: piano passo dopo passo

L'ottimizzazione procede dal semplice al complesso, da ciò che richiede cinque minuti e produce il massimo impatto fino agli interventi più fini.

Passo 1: attiva la cache HTML. Installa il plugin gratuito Cache Enabler o un plugin di caching simile. Questa singola azione riduce drasticamente il TTFB su qualsiasi hosting. Senza esagerare, è il più alto ritorno per minuto di impegno in tutta l'ottimizzazione WordPress.

Passo 2: verifica la versione PHP. Nel pannello di amministrazione del tuo hosting o in cPanel, trova l'impostazione della versione PHP. Se è disponibile una versione corrente (8.2 o superiore), passa a quella. Passare da un ramo obsoleto a uno moderno accelera sensibilmente l'elaborazione di ogni richiesta. Prima di cambiare, assicurati che il tema e tutti i plugin siano compatibili con la versione scelta.

Passo 3: fai un audit dei plugin. Disattiva tutto ciò che non è in uso attivo in questo momento. Tieni solo i plugin che risolvono un compito specifico. Tutto il resto va eliminato, non solo disattivato. I plugin tenuti «per uso futuro» o «potrebbero tornare utili» aggiungono codice a ogni richiesta, che tu li usi o no.

Passo 4: scegli un tema veloce. Il tema determina quanto codice PHP viene eseguito a ogni caricamento di pagina. I temi pesanti con page builder visuali generano un carico di lavoro sul server significativamente maggiore rispetto alle soluzioni minimaliste. Se un test TTFB su un'installazione WordPress pulita (nessun plugin, tema predefinito) mostra un buon risultato, ma il punteggio crolla dopo aver attivato il tuo tema, il problema è il tema stesso.

Passo 5: valuta il tuo hosting. Se il TTFB supera ancora i 500-800 ms dopo i primi quattro passi, la limitazione è lato hosting. Un hosting WordPress specializzato con nginx, PHP 8.2+ e caching lato server offre un livello di risposta fondamentalmente diverso. Nella scelta, cerca il caching a oggetti integrato (Redis o Memcached), che rappresenta il livello successivo dopo la cache HTML.

Video: TTFB dalla teoria ai risultati

Guarda un'analisi visiva del TTFB con misurazioni dal vivo prima e dopo l'ottimizzazione:

⁉️🤔 Domande frequenti

Quale TTFB è considerato buono per WordPress?

Usa i valori target di Google Core Web Vitals come guida: fino a 800 ms è accettabile, fino a 500 ms è buono, fino a 200 ms è eccellente. Nella pratica, per un sito WordPress con caching, l'intervallo raggiungibile è 100-400 ms. Senza caching, anche un sito veloce raramente scende sotto i 400-500 ms.

È obbligatorio cambiare hosting per migliorare il TTFB?

Non sempre. La cache HTML riduce drasticamente il TTFB anche su hosting di fascia media. Prima di migrare, attiva il caching, aggiorna PHP a una versione corrente e fai pulizia dei plugin. Se dopo questi interventi il TTFB è ancora sopra gli 800 ms, allora è davvero il momento di cambiare hosting.

Perché il TTFB varia da una misurazione all'altra?

Il TTFB è influenzato dal carico della CPU del server al momento della misurazione, dalla latenza di rete e dalla geografia del server di test. Fai una serie di 5-7 misurazioni e usa la mediana, non il primo valore casuale. Testa da più località: un server in Europa può mostrare un TTFB eccellente da Francoforte ma scarso da Tokyo.

Il TTFB influisce sul posizionamento su Google?

Sì, a partire dal 2025 la reattività del server fa parte dei Core Web Vitals come segnale di ranking. L'impatto diretto è moderato, ma l'impatto indiretto è significativo: un TTFB alto aumenta la frequenza di rimbalzo, e un'alta frequenza di rimbalzo danneggia direttamente il posizionamento.

Posso misurare il TTFB gratuitamente?

Sì. Usa Pingdom Tools, GTmetrix, PageSpeed Insights o WebPageTest. Una sfumatura importante: misura specificamente il TTFB (time to first byte), non il tempo totale di caricamento della pagina. Su Pingdom, per farlo devi espandere i dettagli della prima richiesta al sito.

Cosa fare subito per il TTFB

Il messaggio principale che emerge dalle misurazioni sopra: la cache HTML è la leva più potente e semplice. Un singolo plugin riduce drasticamente il TTFB su qualsiasi hosting, e richiede esattamente cinque minuti.

L'ordine delle azioni è il seguente:

  • Se il TTFB è > 1 secondo, inizia con il caching e l'aggiornamento di PHP. Questi due passi forniscono la maggior parte del miglioramento possibile.
  • Se il TTFB è tra 400 e 800 ms, un audit di plugin e tema di solito elimina il ritardo residuo.
  • Se il TTFB è costantemente sotto i 200 ms, sei nella zona ottimale; mantieni il livello attuale.

Inizia con un plugin di caching gratuito: installa, attiva ed esegui un test tramite Pingdom Tools. Vedrai la differenza immediatamente. Qual è il tuo TTFB attuale? Condividi i tuoi numeri nei commenti.