Che cosa indica il TTFB e da dove nasce il ritardo

TTFB, acronimo di Time to First Byte, è il tempo che passa tra l’invio della richiesta dal browser e l’arrivo del primo byte della risposta dal server. È una metrica utile perché mostra quanto rapidamente il backend inizia a rispondere, ma non misura l’intero caricamento della pagina.

Questa distinzione è fondamentale per non leggere i numeri in modo troppo semplice. Il TTFB può includere tempi legati a DNS, connessione TCP, negoziazione TLS, elaborazione lato server, PHP, database, cache e chiamate ad API esterne. Se vuoi inquadrare meglio il rapporto tra TTFB e lentezza percepita, l’articolo perché il mio sito web è lento è un buon punto di partenza.

Cosa misura davvero il TTFB

In teoria il TTFB sembra solo un tempo di attesa. In pratica racchiude più fasi. Il browser deve individuare il server, aprire la connessione e, se il sito usa HTTPS, completare anche la parte crittografica. Solo dopo il server può preparare la risposta e inviare il primo byte.

Per questo il TTFB non è un semplice giudizio sulla “velocità del server”. È una misura dell’inizio della risposta, influenzata sia dalla rete sia dal lavoro svolto dall’applicazione. Una pagina statica e una pagina dinamica possono avere comportamenti molto diversi anche sullo stesso hosting.

Da dove può nascere il ritardo

Le cause più comuni del tempo perso prima del primo byte sono queste:

• DNS: risoluzione del nome di dominio.
• TCP: instaurazione della connessione.
• TLS: negoziazione della cifratura per HTTPS.
• Elaborazione server: preparazione della risposta sul backend.
• PHP: esecuzione di temi, plugin o logica applicativa.
• Database: query, join e attese di I/O.
• Cache: presenza o assenza di una risposta già pronta.
• API esterne: attesa di servizi di terze parti.

Spesso il problema non è un singolo passaggio, ma la somma di più passaggi brevi. Un po’ di latenza di rete, un po’ di lavoro PHP e una query lenta possono produrre un TTFB percepibilmente alto senza che ci sia un guasto evidente.

Cache e risposta non cachetizzata

Il comportamento del TTFB cambia molto tra cached e uncached. Se il contenuto è già in cache, il server può servire una risposta pronta con meno elaborazione. Se invece la pagina va generata al momento, il sistema deve eseguire più codice, spesso interrogare il database e poi costruire l’HTML.

Per questo un sito può mostrare TTFB molto diverso tra homepage, articoli, pagine di login, carrelli o aree riservate. Non tutte le richieste hanno lo stesso costo. Interpretare il dato senza sapere quale pagina è stata misurata porta facilmente a conclusioni sbagliate.

Perché una sola misura non basta

Il TTFB varia in base alla distanza geografica, alla qualità della rete, al carico del momento e ai servizi esterni coinvolti. Una singola lettura può quindi descrivere una situazione momentanea, non una tendenza stabile.

Inoltre, il TTFB non racconta tutto ciò che accade dopo il primo byte. Una pagina può avere un avvio buono ma restare lenta per colpa di immagini pesanti, script che bloccano il rendering o problemi di CLS e INP. Oppure può avere un TTFB più alto ma restare comunque accettabile se il resto dell’esperienza è ben progettato.

Quando un TTFB alto non significa hosting sbagliato

Un valore alto non indica automaticamente un hosting scarso. Spesso il collo di bottiglia è nell’applicazione: query costose, logica complessa, plugin pesanti o attese verso API esterne. In questi casi il server non è “lento” in senso assoluto: sta semplicemente eseguendo più lavoro prima di poter rispondere.

Se la lentezza compare soprattutto nelle pagine uncached o in punti specifici del sito, è più probabile che il problema sia nel codice o nell’architettura. Solo quando i limiti di CPU, RAM o I/O si ripetono diventa sensato guardare prima alla capacità dell’infrastruttura. Per capire meglio il ruolo generale del servizio, può essere utile leggere che cos’è il web hosting.

Quando i limiti di risorse si presentano con regolarità, ha senso valutare il tipo di hosting più adatto. Ma questa valutazione va fatta dopo aver distinto il carico dell’applicazione dal limite reale della macchina.

Come leggere il TTFB nel modo giusto

Il TTFB va sempre interpretato insieme al tipo di pagina e allo stato della cache. Una landing page statica, un articolo, una ricerca interna e una dashboard privata non hanno la stessa complessità. Anche il confronto tra prima visita e visite successive può cambiare molto il quadro.

La lettura corretta non è “alto o basso” in astratto, ma “alto rispetto a cosa?”. Se capisci quale lavoro viene svolto prima del primo byte, puoi distinguere più facilmente tra latenza di rete, elaborazione applicativa e saturazione delle risorse.

Per un ulteriore contesto sulla relazione tra storage e prestazioni del server, il contenuto che cos’è l’hosting NVMe può essere utile senza trasformare il TTFB in una questione di disco soltanto.

Il TTFB riflette soprattutto la velocità di risposta del server e quanto il contenuto sia già pronto. La cache del sito web accorcia la preparazione, mentre Redis object cache aiuta a riutilizzare dati complessi invece di ricostruirli a ogni richiesta.