
Cos'è il TTFB (Time To First Byte)? Cosa è considerato buono e come ridurlo (2026)
- vuetelemetry
- Guide
- 6 min di lettura
Il TTFB è il tempo che intercorre tra la richiesta di una pagina e la ricezione del primo byte della risposta. Cosa misura, cosa conta come un buon TTFB (sotto i ~800 ms), come alimenta l'LCP e le leve lato server, cache e CDN che lo riducono.
Il TTFB, ovvero Time To First Byte, è il tempo che intercorre tra il momento in cui il tuo browser chiede una pagina a un server e il momento in cui torna indietro il primo byte della risposta. Si misura in millisecondi e comprende tutto ciò che deve accadere prima che il browser possa persino iniziare a leggere la pagina: la risoluzione del dominio, l'apertura della connessione e - la parte che di solito domina - il server che svolge il suo lavoro e invia quel primo byte.
È importante perché il TTFB è la tassa pagata su ogni singola richiesta prima che possa accadere qualcosa di visibile. Un browser non può renderizzare un solo pixel finché i byte non iniziano ad arrivare, quindi un TTFB lento ritarda l'intera pagina di quella stessa quantità, per quanto bene siano ottimizzati le tue immagini, il tuo CSS e il tuo JavaScript. È il pavimento sotto la tua velocità di caricamento.
Cosa misura davvero il TTFB

Sotto il cofano, il TTFB è la somma di attese più piccole: eventuali reindirizzamenti, la risoluzione DNS che trasforma il tuo dominio in un indirizzo IP, la connessione TCP e l'handshake TLS che la mette in sicurezza, il tempo che la richiesta impiega a viaggiare verso il server e infine il tempo di elaborazione del server fino a quando il primo byte non viene riscritto. Sulla maggior parte dei siti quest'ultimo pezzo - quanto tempo impiega il server a costruire la risposta - è il più grande e il più facile da correggere.
Fondamentalmente, il TTFB è una misura di back-end e di rete, non di front-end. Se il tuo TTFB è alto, il problema è sul server, sull'hosting o sul percorso di rete, non nel tuo codice React o Vue. È una diagnosi utile: ti dice di guardare al tuo host, alla tua cache e al tuo database piuttosto che alla dimensione del tuo bundle.
Cosa si considera un buon TTFB
Le linee guida di Google, pubblicate su web.dev, indicano che un buon TTFB è all'incirca sotto gli 800 millisecondi per la maggior parte dei siti, mentre tutto ciò che supera 1.8 s è considerato scadente. Sono soglie sul campo - misurate su visite reali - quindi tengono già conto di reti e dispositivi reali anziché di un test di laboratorio su hardware veloce.
- Hosting lento o sovraccarico - un server condiviso che arranca sotto il traffico di altri siti
- Pagine dinamiche non memorizzate in cache rigenerate da zero a ogni singola richiesta
- Query pesanti al database o codice back-end lento che gonfiano il tempo di elaborazione del server
- Nessun CDN, così ogni visitatore si connette a un unico server di origine distante
- Catene di reindirizzamenti che aggiungono viaggi di andata e ritorno extra prima che inizi la risposta reale
- Handshake TLS lenti o un server situato lontano dalla maggior parte del tuo pubblico
Il TTFB non è di per sé uno dei tre Core Web Vitals, ma alimenta direttamente il Largest Contentful Paint. L'LCP non può mai essere più veloce del TTFB che lo precede, perché il contenuto principale non può apparire finché la risposta non è iniziata. Migliorare un TTFB lento spesso alza l'LCP gratuitamente, ed è per questo che il lavoro sulle prestazioni parte così spesso da qui.
Come ridurre il TTFB
La leva lato server più grande è la cache. Servire una pagina da una cache di pagina completa o da una cache edge di un CDN evita il lavoro di rigenerarla a ogni richiesta, trasformando centinaia di millisecondi di elaborazione in una risposta quasi istantanea. Oltre a questo, un hosting più veloce o meno affollato, un codice back-end più snello e lo sfoltimento delle query lente al database riducono tutti direttamente la porzione di elaborazione.
Sul versante della rete, un CDN accorcia la distanza fisica tra il tuo server e ogni visitatore, così la richiesta e la risposta viaggiano per un tratto più breve. Una gestione moderna delle connessioni - HTTP/2 o HTTP/3, keep-alive e una configurazione TLS ben impostata - riduce l'overhead dell'handshake, e dove una pagina può essere pre-renderizzata in file statici, l'hosting statico rimuove quasi del tutto l'elaborazione del server dal percorso critico.
In sintesi
In breve, il TTFB è la tassa di risposta del server su ogni pagina che servi, e fissa il tetto di quanto veloce può sembrare il resto del tuo sito. Un host capace, una cache aggressiva e un CDN sono le tre leve che lo muovono di più - ed è per questo che correggere il TTFB è di solito il lavoro sulle prestazioni con il maggiore effetto leva che puoi fare prima di toccare una singola riga di codice front-end.



Sul versante della rete, un CDN accorcia la distanza fisica tra il tuo server e ogni visitatore, così la richiesta e la risposta viaggiano per un tratto più breve. Una gestione moderna delle connessioni - HTTP/2 o HTTP/3, keep-alive e una configurazione TLS ben impostata - riduce l'overhead dell'handshake, e dove una pagina può essere pre-renderizzata in file statici, l'hosting statico rimuove quasi del tutto l'elaborazione del server dal percorso critico.