# TTFB: cos'è il Time To First Byte e perché conta per le prestazioni di un sito
Table of Contents
Quando si apre una pagina web, c’è un momento di attesa prima che compaia qualsiasi cosa: la barra di caricamento gira, lo schermo resta bianco, e solo dopo iniziano ad apparire testi e immagini. Buona parte di quell’attesa iniziale ha un nome preciso: TTFB, cioè Time To First Byte, il “tempo fino al primo byte”. Capire cos’è aiuta a ragionare sulle prestazioni di un sito senza affidarsi a sensazioni vaghe.
Cos’è il TTFB in parole semplici
Il TTFB misura il tempo che passa da quando il browser inizia a richiedere una pagina a quando riceve il primo byte della risposta dal server. In pratica è quanto ci mette il server a “iniziare a rispondere”, non a finire.
Un paragone utile: è come ordinare al ristorante. Il TTFB non è il tempo per finire di mangiare, e nemmeno quello per avere il piatto completo davanti. È il tempo che passa dall’ordine al momento in cui il cameriere torna con la prima portata. Se quel primo segnale arriva tardi, tutto il resto slitta di conseguenza.
Vale la pena chiarire subito un punto: il TTFB non è una singola cosa, ma la somma di più passaggi. Secondo la documentazione di web.dev, comprende il tempo per eventuali redirect (rimbalzi da un indirizzo a un altro), l’avvio di un eventuale service worker, la risoluzione DNS (tradurre il nome del sito nell’indirizzo numerico del server), la negoziazione della connessione e del TLS (l‘“handshake” cifrato che protegge i dati) e infine l’elaborazione della richiesta fino al primo byte restituito.
Perché conta per chi usa il sito
Il primo byte non è ancora contenuto visibile: è solo il segnale che la risposta è iniziata. Ma finché non arriva, il browser non può fare nulla. Non può leggere l’HTML, non può scaricare immagini o fogli di stile, non può disegnare niente sullo schermo. Un TTFB alto sposta in avanti tutto ciò che viene dopo.
Per l’utente questo si traduce in una sensazione concreta: il sito sembra “lento a partire”. Anche se il resto è ottimizzato, un server che ci mette troppo a rispondere lascia lo schermo vuoto più a lungo, e la pagina dà l’impressione di non funzionare. Su questo tema le linee guida offrono un riferimento pratico: un TTFB è considerato buono a 0,8 secondi o meno ed è considerato scarso oltre 1,8 secondi. Non è una soglia assoluta, ma un ordine di grandezza utile per capire se c’è margine di miglioramento.
TTFB, SEO e Core Web Vitals
Qui serve un po’ di contesto. Google usa un insieme di metriche chiamate Core Web Vitals per misurare la qualità dell’esperienza di caricamento di una pagina, e queste metriche sono un fattore che influisce sul posizionamento nei risultati di ricerca. Sono tre: LCP (Largest Contentful Paint, quanto tempo passa prima che compaia il contenuto principale, buona sotto i 2,5 secondi), INP (Interaction to Next Paint, quanto è reattiva la pagina ai clic, buona sotto i 200 millisecondi) e CLS (Cumulative Layout Shift, quanto gli elementi “saltano” mentre la pagina si carica, buona sotto 0,1). Da notare che nel 2024 INP ha sostituito la vecchia metrica FID.
Il TTFB, di per sé, non è una delle Core Web Vitals. Però le precede tutte. È il primo mattoncino su cui si costruisce l’LCP in particolare: la documentazione di web.dev lo descrive come la prima parte dell’LCP e stima che possa pesarne circa il 40%. Il principio è semplice: nulla può accadere nella pagina finché il server non consegna quel primo byte, quindi qualsiasi cosa riduca il TTFB tende a migliorare anche le altre metriche di caricamento. Ridurre il TTFB non garantisce da solo un buon punteggio, ma un TTFB alto lo rende molto più difficile da ottenere.
Da cosa dipende il TTFB
Il TTFB non dipende da un unico fattore, ed è per questo che a volte è difficile diagnosticarlo. In generale entrano in gioco più livelli.
- La rete e la distanza geografica. Ogni richiesta viaggia fisicamente tra l’utente e il server. Più sono lontani, più tempo serve solo per il viaggio dei dati, a cui si aggiungono la risoluzione DNS e l’handshake TLS iniziali.
- Il server e l’hosting. Un server sovraccarico, sottodimensionato o con software datato risponde più lentamente. La qualità dell’hosting è spesso il primo punto da valutare.
- L’applicazione. Il codice che genera la pagina può fare lavoro pesante a ogni richiesta: calcoli, chiamate a servizi esterni, elaborazioni non ottimizzate. Tutto questo si accumula prima del primo byte.
- Il database. Se generare la pagina richiede interrogazioni lente o troppo numerose, il server resta in attesa del database prima di poter rispondere.
- La cache (o la sua assenza). Se ogni richiesta viene ricalcolata da zero, si paga ogni volta l’intero costo. La cache serve proprio a evitarlo.
Un TTFB alto, quindi, è un sintomo: il valore va poi scomposto per capire dove si perde tempo.
Le leve generali per migliorarlo
Non esiste un’unica soluzione valida per tutti, e conviene sempre misurare prima e dopo. Detto questo, gli approcci più diffusi sono pochi e agiscono sui livelli descritti sopra.
- Caching. È spesso la leva con il miglior rapporto tra sforzo e risultato. L’idea è servire un risultato già pronto invece di ricalcolarlo. Può avvenire a più livelli: una page cache che conserva l’HTML già generato, una cache dei dati o delle query e le intestazioni
Cache-Control, che indicano a browser e intermediari quando riusare una risposta. Con una cache efficace, solo la prima richiesta paga il costo pieno verso il server d’origine. - CDN (Content Delivery Network). Una CDN è una rete di server distribuiti geograficamente che avvicinano i contenuti all’utente. Serve la risposta da un nodo vicino invece che dal server d’origine lontano, riducendo il tempo di viaggio dei dati; in più le CDN in genere offrono DNS veloce, protocolli moderni come HTTP/2 e HTTP/3 e una gestione ottimizzata del TLS.
- Ottimizzazione del backend. Qui rientra tutto ciò che rende più rapida la generazione della risposta: query di database più efficienti, riduzione del lavoro svolto a ogni richiesta, aggiornamento dell’infrastruttura. È la parte meno “magica” e più artigianale, ma spesso la più risolutiva quando il collo di bottiglia è l’applicazione, come succede di frequente con un e-commerce cresciuto negli anni.
- Ridurre i redirect. Ogni rimbalzo da un indirizzo all’altro aggiunge un giro completo di rete prima ancora di iniziare a rispondere. Eliminare i redirect superflui, quando sono sotto il proprio controllo, aiuta.
In sintesi
Il TTFB è il tempo prima del primo byte di risposta: un valore piccolo ma fondamentale, perché tutto il resto del caricamento parte da lì. Non è una metrica ufficiale delle Core Web Vitals, ma le condiziona, e per questo incide sia sull’esperienza percepita sia, indirettamente, sulla SEO. Dipende da rete, server, applicazione, database e cache, e si affronta soprattutto con caching, CDN e ottimizzazione del backend. La regola pratica resta la stessa: misurare, capire dove si perde tempo e intervenire sul livello giusto invece di cambiare tutto a caso.
