Cos’è il TTFB e come funziona
Il TTFB misura il tempo che intercorre tra l’invio della richiesta del browser e l’arrivo del primo byte di risposta dal server: dentro quel tempo ci sono la latenza di rete, la risoluzione DNS, la negoziazione TLS e il lavoro del backend per costruire la pagina. È il primo segnale di reattività del server, prima ancora che l’utente veda qualcosa a schermo.
Come funziona il TTFB
- Cosa misura: il tempo tra la richiesta HTTP del browser e l’arrivo del primo byte di risposta dal server.
- Fasi coinvolte: invio della richiesta, risoluzione DNS, handshake TCP, negoziazione TLS ed elaborazione lato server.
- Cause più frequenti di un valore alto: hosting sottodimensionato, assenza di caching, query al database lente, redirect multipli.
- Come si misura: strumenti di laboratorio come Chrome DevTools e WebPageTest, oppure dati reali raccolti sul campo.
- Soglia di riferimento: le fasce ufficiali Google le trovo più utili lette insieme alle altre metriche, nella pagina sulle soglie ufficiali dei Core Web Vitals.
Da cosa è composto il TTFB
Il TTFB somma tre fasi distinte, e capire quale pesa di più è il primo passo per intervenire. La prima è l’invio della richiesta HTTP dal client verso il server che ospita il sito: fin qui il tempo dipende dalla rete, non dal codice che gira sul server.
La seconda fase è la latenza di rete vera e propria: risoluzione DNS del dominio, handshake TCP per aprire la connessione, negoziazione TLS se il sito usa HTTPS, cosa ormai quasi universale. Ogni passaggio aggiunge millisecondi, e su una connessione mobile con DNS lento questa fase può pesare quanto l’elaborazione lato server.
La terza fase è l’elaborazione del server: il backend riceve la richiesta, interroga il database o chiama API esterne, costruisce la risposta e la invia. Su un CMS con plugin pesanti o query non ottimizzate è qui che il TTFB sale, ed è anche la fase su cui si può intervenire di più senza toccare la rete.
Google e il progetto Web Vitals classificano il TTFB su tre fasce, da buono a scarso: ho raccolto i valori esatti nella pagina sulle soglie ufficiali dei Core Web Vitals, perché vanno letti insieme alle metriche di rendering che arrivano subito dopo. Alcune guide di settore propongono un target più stringente, sotto i 200-500 millisecondi: non è la soglia ufficiale di Google ma un margine di sicurezza che alcuni consulenti consigliano per lasciare spazio alle fasi successive.
Cause più comuni di un TTFB lento
Quando il TTFB supera gli 800 millisecondi, la causa sta quasi sempre in uno di questi cinque punti. Il primo è un hosting inadeguato, con CPU o RAM insufficienti per il traffico reale del sito: capita spesso su hosting condivisi economici pensati per siti vetrina, non per e-commerce con migliaia di visite. Il secondo è la distanza geografica tra il server di origine e chi fa la richiesta, un ritardo che nessuna ottimizzazione del codice risolve da sola. Il terzo è l’assenza di caching, sia a livello di pagina che di singolo oggetto: il server deve ricostruire da zero ogni risposta anche quando il contenuto non è cambiato. Il quarto sono le query al database lente, spesso per indici mancanti o per temi e plugin che sommano chiamate non necessarie alla stessa pagina. Il quinto sono le catene di redirect lunghe, oppure un server ancora fermo a HTTP/1.1 senza supporto per HTTP/2 o HTTP/3.
Se il TTFB resta alto nonostante un hosting adeguato
La mia regola, quando un cliente mi dice che l’hosting è già performante ma il TTFB non scende, è controllare in ordine questi quattro punti prima di cambiare qualunque cosa:
- Apro la scheda Network degli strumenti per sviluppatori e conto quanti redirect precedono la risposta finale: ogni salto aggiunge un giro di rete completo.
- Verifico se la pagina genera query al database a ogni visita o se esiste già un livello di cache attivo tra l’utente e il backend.
- Controllo negli header di risposta del server se la connessione usa HTTP/2 o HTTP/3: un protocollo più vecchio aggiunge overhead a ogni richiesta.
- Se il sito usa plugin o moduli di terze parti eseguiti lato server, li disattivo uno alla volta e rimisuro il TTFB dopo ogni passaggio.
Come misurare il TTFB
Il TTFB si misura in due condizioni diverse, e confonderle porta a conclusioni sbagliate. La misura di laboratorio è un test ripetibile fatto a comando, su una macchina con condizioni di rete controllate; la misura di campo arriva dagli utenti veri che hanno visitato il sito, con la rete e il dispositivo che hanno davvero.
| Tipo di misurazione | Strumenti | Quando la uso |
|---|---|---|
| Laboratorio | Chrome DevTools (scheda Network), WebPageTest, GTmetrix, KeyCDN | Per confrontare una modifica prima e dopo, in condizioni ripetibili |
| Campo | Chrome User Experience Report, libreria web-vitals | Per sapere cosa succede davvero ai visitatori del sito, dispositivi e reti reali inclusi |
Per un controllo rapido che unisce le due letture uso spesso cos’è e come funziona PageSpeed Insights, perché nello stesso report mostra sia il test di laboratorio che i dati reali raccolti dagli utenti Chrome.
Come migliorare il TTFB
Intervengo sempre nello stesso ordine: prima il caching, poi la rete, poi il codice. Attivare una cache di pagina o di oggetto, con soluzioni come Redis o Memcached, evita di ricalcolare la stessa risposta a ogni visita. Una CDN avvicina geograficamente i contenuti statici all’utente e riduce la parte di latenza di rete che nessun lavoro sul backend può togliere.
Sconsiglio di fermarsi qui, però: senza un hosting con risorse sufficienti e un server configurato bene, con Keep-Alive attivo e software come NGINX o le versioni recenti di Apache, la cache maschera il problema invece di risolverlo. L’ultimo passaggio è il database: query ottimizzate, indici giusti e meno chiamate ridondanti riducono il tempo che il backend passa a costruire la risposta.
TTFB rispetto a FCP e LCP
Il TTFB arriva sempre prima delle metriche che l’utente percepisce con gli occhi: finché il primo byte non è arrivato, il browser non ha nulla da disegnare. Per questo un TTFB alto si riflette quasi sempre su cos’è l’FCP e come funziona e su cos’è l’LCP e come funziona: se il server impiega due secondi a rispondere, quei due secondi si sommano a qualunque tempo di rendering successivo.
Il TTFB non è però un Core Web Vital ufficiale: fa parte delle metriche correlate che aiutano a diagnosticare dove nasce il ritardo, mentre i tre segnali ufficiali restano quelli descritti nella pagina su cosa sono i Core Web Vitals e come funzionano. Lo controllo per primo proprio perché, se il server è lento, intervenire sul rendering lato browser serve a poco.
Casi particolari e letture del TTFB che ingannano
Un TTFB vicino allo zero non è sempre un buon segno: spesso significa che la risorsa arriva dalla cache locale del browser, non dal server. Quando misuro il TTFB di una singola immagine o di uno script ospitato su un dominio diverso, può risultare pari a zero anche se la risorsa non era in cache, semplicemente perché manca l’header Timing-Allow-Origin che autorizza il browser a riportare il dato: in quel caso il numero non dice nulla sulla reattività reale del server esterno.
Se il dato di laboratorio e il dato reale non coincidono
Capita spesso che un test di laboratorio dia un TTFB ottimo e Search Console, o un report basato sui dati reali, mostri valori più alti: la differenza nasce dal fatto che il test di laboratorio parte da una connessione pulita, mentre gli utenti reali arrivano con reti più lente, dispositivi meno potenti e cache spesso vuota. In questi casi mi fido del dato di campo per decidere le priorità, e uso il laboratorio solo per verificare se una modifica ha funzionato.
Un’altra condizione che altera il conteggio sono gli Early Hints, la risposta preliminare 103 che alcuni server inviano prima del documento finale: viene contata come primo byte, quindi un sito che la usa può mostrare un TTFB più basso senza che il documento vero e proprio sia arrivato prima. È una pratica corretta, ma va saputo quando si confrontano due siti diversi sullo stesso valore.
Domande frequenti
Cos’è il TTFB e cosa misura?
Il TTFB è il tempo tra l’invio della richiesta del browser e l’arrivo del primo byte di risposta dal server: include la latenza di rete e il tempo che il backend impiega a generare la pagina, prima che l’utente veda qualcosa.
Da cosa dipende un TTFB lento?
Dipende quasi sempre da hosting sottodimensionato, distanza geografica dal server, assenza di caching, query al database lente o catene di redirect lunghe: di solito è una combinazione di due o tre di questi fattori, non uno solo.
Qual è un buon valore di TTFB?
Un valore fino a 800 millisecondi è considerato buono secondo le soglie ufficiali di Google, descritte nel dettaglio nella pagina sui Core Web Vitals; alcune guide di settore puntano a un margine più stretto, sotto i 200-500 millisecondi.
Come si misura il TTFB?
Si misura con strumenti di laboratorio come Chrome DevTools, WebPageTest e GTmetrix per i test ripetibili, oppure con dati di campo come il Chrome User Experience Report per vedere cosa succede ai visitatori reali.
Qual è la differenza tra TTFB e First Contentful Paint?
Il TTFB misura quando arriva il primo byte dal server, mentre l’FCP misura quando il browser disegna il primo elemento visibile: il TTFB viene sempre prima e, se è alto, rallenta inevitabilmente anche l’FCP.
Il TTFB è un Core Web Vital ufficiale?
No, il TTFB non rientra tra i tre segnali ufficiali dei Core Web Vitals (LCP, INP, CLS): è una metrica correlata, utile per capire se un ritardo nasce dal server prima ancora di guardare il rendering della pagina.
Perché il TTFB di laboratorio è diverso da quello reale?
Il test di laboratorio parte da una connessione pulita e condizioni controllate, mentre il dato di campo arriva da utenti con reti e dispositivi diversi: per questo il valore reale è quasi sempre più alto di quello misurato in laboratorio.
