Cos'è il Time to First Byte (TTFB) e come migliorarlo

Il Time to First Byte (TTFB) misura il tempo in millisecondi tra la richiesta di una pagina da parte del browser e la ricezione del primo byte della risposta dal server. Un buon TTFB è pari o inferiore a 800 millisecondi al 75° percentile. Il TTFB non è un Core Web Vital, ma è una metrica diagnostica fondamentale perché incide direttamente sia sul Largest Contentful Paint (LCP) sia sul First Contentful Paint (FCP).

Cos'è il Time to First Byte

Il Time to First Byte (TTFB) indica quanti millisecondi trascorrono dall'avvio della richiesta alla ricezione del primo byte di risposta da una pagina web. Per questo il TTFB viene chiamato anche tempo di attesa. Misura la reattività del server web e del percorso di rete tra l'utente e il server. Il TTFB è una metrica di base: qualsiasi ritardo accumulato sul TTFB si riflette direttamente su Largest Contentful Paint e First Contentful Paint. Ogni millisecondo risparmiato sul TTFB è un millisecondo guadagnato su entrambe queste metriche di paint.

Il TTFB non è un Core Web Vital

Chiariamolo subito: il TTFB non fa parte dei tre Core Web Vitals. I Core Web Vitals sono Largest Contentful Paint (LCP), Interaction to Next Paint (INP) e Cumulative Layout Shift (CLS). Google non usa direttamente il TTFB tra i segnali di ranking per la page experience.

Il TTFB è però classificato come metrica diagnostica. Ti aiuta a capire perché il tuo LCP o FCP è lento. Secondo il Web Almanac 2025, i siti con un LCP scarso passano in media 2,27 secondi solo sul TTFB. Questo esaurisce quasi per intero la soglia di 2,5 secondi del LCP prima ancora che il browser inizi a renderizzare la pagina. Ottimizzare il TTFB è quindi uno degli interventi più efficaci per i tuoi punteggi complessivi dei Core Web Vitals.

Perché il Time to First Byte è importante

Il Time to First Byte non è un Core Web Vital ed è del tutto possibile superare i Core Web Vitals pur fallendo la metrica del TTFB. Questo non significa che il TTFB non sia importante. È una metrica fondamentale da ottimizzare e risolvere i problemi di TTFB migliorerà nettamente la velocità e la page experience.

L'impatto del TTFB sui visitatori

Il Time to First Byte precede tutte le altre metriche di paint. Mentre il browser attende il Time to First Byte, non può fare nulla e mostra solo una schermata bianca. Qualsiasi aumento del Time to First Byte si traduce in più tempo a schermo bianco; ogni riduzione del Time to First Byte si converte in meno tempo a schermo bianco.

Per dare all'utente la sensazione di un caricamento istantaneo, il Time to First Byte deve essere il più rapido possibile.

Perché il TTFB non è un Core Web Vital? Il TTFB non tiene conto del rendering: un TTFB basso non garantisce una buona user experience perché ignora il tempo necessario al browser per renderizzare la pagina web. Anche scaricando tutti i byte all'istante, la pagina può impiegare molto tempo a mostrarsi se il browser deve eseguire parecchio JavaScript o calcolare layout complessi.

Qual è un buon valore di TTFB?

Il server dovrebbe rispondere alle richieste di navigazione abbastanza velocemente da consentire al 75° percentile degli utenti di registrare un FCP nella soglia "buono". Come linea guida generale, la maggior parte dei siti dovrebbe puntare a un TTFB pari o inferiore a 0,8 secondi.

• Un TTFB sotto gli 800 millisecondi è considerato buono.
• Un TTFB tra 800 e 1800 millisecondi richiede miglioramenti.
• Un TTFB superiore a 1800 millisecondi è considerato scarso e va corretto subito.

Impatto reale: il caso studio di T-Mobile

T-Mobile ha investito in modo massiccio nella riduzione del Time to First Byte all'interno di una più ampia iniziativa di ottimizzazione delle prestazioni. I risultati sono stati notevoli: un aumento del 60% nelle conversioni da visita a ordine. Passando a pagine renderizzate sull'edge e a un caching lato server aggressivo, T-Mobile ha ridotto drasticamente il tempo trascorso dagli utenti in attesa del primo byte. L'effetto a catena ha accelerato LCP e FCP, migliorando nettamente la user experience. Questo caso studio dimostra che ottimizzare il TTFB non è un semplice esercizio tecnico: incide in modo diretto sui risultati di business.

Il TTFB dalla richiesta alla risposta

Dal browser al server: la richiesta

Il tempo di richiesta del browser è l'intervallo tra l'invio della richiesta HTTP da parte del browser e il suo arrivo al server che ospita il sito web. Questa quota del TTFB è in gran parte fuori dal controllo diretto del sito e dipende soprattutto da:

• Velocità di connessione dell'utente.
• Qualità dell'infrastruttura di rete.
• Distanza fisica tra l'utente e il server.

In questa fase richiedono tempo il DNS lookup, l'avvio del browser, la ricerca nella cache del browser e la negoziazione della connessione con il server (TCP e TLS).

Sul server: elaborazione e preparazione della risposta

Ricevuta la richiesta, il server inizia a elaborare la risposta. È la fase su cui la maggior parte degli sviluppatori si concentra e dove l'ottimizzazione può avere l'impatto maggiore. I fattori principali includono:

• Capacità del server: contano hardware potente (CPU, RAM), software efficiente (server web, database) e configurazioni ottimizzate.
• Tempi del database: se la richiesta deve recuperare dati da un database, le query lente possono diventare un collo di bottiglia critico.
• Ottimizzazione del codice: codice lato server scritto male (come script inefficienti) provoca tempi di elaborazione lunghi.
• Strategie di caching: un caching efficace (lato server o tramite Content Delivery Network) riduce drasticamente il carico di elaborazione per le richieste ripetute.

Di ritorno al browser: invio del primo byte

Terminata l'elaborazione, il server invia la risposta al browser dell'utente, a partire dal primo byte.

• Come nella prima fase, le condizioni di rete e la distanza fisica incidono anche qui.
• Le CDN sono decisive in questa fase perché mettono i contenuti in cache vicino agli utenti, riducendo al minimo i tempi di transito.
• A questo punto vengono restituiti anche eventuali redirect, che costringono a ripetere l'intero processo aggiungendo ulteriore ritardo.

Fasi tecniche del Time to First Byte

Proprio come il percorso dalla richiesta alla risposta nel browser, il Time to First Byte delle richieste di navigazione si può misurare con la Navigation Timing API e scomporre in 5 componenti.

1. Tempo di redirect: quando una risorsa è stata spostata a un nuovo indirizzo, il tempo del redirect si somma al TTFB della risorsa.
2. Tempo di worker e cache: prima di scaricare una risorsa da internet, il browser prova a cercarla nella propria cache o tramite un worker (se configurato).
3. Tempo di DNS lookup: successivamente, il browser potrebbe dover eseguire un DNS lookup per convertire il nome di dominio (www.example.com) in un indirizzo IP.
4. Tempo di connessione TCP: a questo punto il browser si connette al server ed esegue alcuni controlli.
5. Handshake SSL: browser e server stabiliscono la cifratura della comunicazione.
6. Risposta del server: infine, il server invia l'HTML, eventualmente dopo averlo generato.

Come misurare il Time to First Byte (TTFB)

PageSpeed TIP: ogni risorsa ha il proprio Time to First Byte. In questo contesto, però, parliamo del Time to First Byte della pagina principale.

Il Time to First Byte può variare molto tra utenti con dispositivi diversi e da postazioni differenti. Misurare il Time to First Byte dal tuo computer desktop non è quindi una buona idea. Per lo stesso motivo, usare strumenti come Pingdom o GTMetrix non dà risultati affidabili.

Il modo migliore per misurare il Time to First Byte è raccogliere dati RUM (Real User Metrics) dai tuoi visitatori. Puoi farlo autonomamente con il codice qui sotto oppure affidarti a uno strumento RUM come CoreDash.

Misurare il TTFB con strumenti sintetici

Misurare il TTFB con il monitoraggio RUM

Misurare il TTFB con i dati CrUX

CrUX (Chrome User Experience Report) è un dataset pubblico di Google contenente dati di performance reali sui siti web. Google usa il dataset CrUX per stabilire se un sito supera o meno i Core Web Vitals.

Puoi accedere al dataset CrUX tramite strumenti come PageSpeed Insights, la CrUX API, Looker Studio o Google BigQuery. Usa uno di questi strumenti per ottenere il TTFB del tuo sito.

Misurare il TTFB con JavaScript

Per misurare il Time to First Byte (TTFB) con JavaScript puoi usare la Navigation Timing API. Puoi creare un PerformanceObserver che ascolta le voci di navigazione e registra nella console la proprietà responseStart. Questa proprietà rappresenta il timestamp esatto di ricezione del primo byte di risposta. La libreria JavaScript web-vitals offre un modo ancora più sintetico per misurare il TTFB nel browser tramite la funzione onTTFB.

Puoi usare il codice seguente per misurare il Time to First Byte (TTFB):

const formatTime = (time) => {

//round by 2 decimals, use Math.round() for integer
return Math.round(time * 100) / 100;
};

new PerformanceObserver((entryList) => {
const [pageNav] = entryList.getEntriesByType('navigation');

// timing start times are relative
const activationStart = pageNav.activationStart || 0;
const workerStart = Math.max(pageNav.workerStart - activationStart, activationStart);
const dnsStart = Math.max(pageNav.domainLookupStart - activationStart, workerStart);
const tcpStart = Math.max(pageNav.connectStart - activationStart, dnsStart);
const sslStart = Math.max(pageNav.secureConnectionStart - activationStart, tcpStart);
const requestStart = Math.max(pageNav.requestStart - activationStart, sslStart);
const responseStart = Math.max(pageNav.responseStart - activationStart, requestStart);

// attribution based on https://www.w3.org/TR/navigation-timing-2/#processing-model
// use associative array to log the results more readable
let attributionArray = [];
attributionArray['Redirect Time'] = { 'time in ms': formatTime(workerStart - activationStart) };
attributionArray['Worker and Cache Time'] = { 'time in ms': formatTime(dnsStart - workerStart) };
attributionArray['DNS Time'] = { 'time in ms': formatTime(tcpStart - dnsStart) };
attributionArray['TCP Time'] = { 'time in ms': formatTime(sslStart - tcpStart) };
attributionArray['SSL Time'] = { 'time in ms': formatTime(requestStart - sslStart) };
attributionArray['Request Time'] = { 'time in ms': formatTime(responseStart - requestStart) };
attributionArray['Total TTFB'] = { 'time in ms': formatTime(responseStart - activationStart) };

// log the results
console.log('%cTime to First Byte (' + formatTime(responseStart - activationStart) + 'ms)', 'color: blue; font-weight: bold;');
console.table(attributionArray);

console.log('%cOrigininal navigation entry', 'color: blue; font-weight: bold;');
console.log(pageNav);

}).observe({
type: 'navigation',
buffered: true
});

Trovere i colli di bottiglia con la Server-Timing API

La Server-Timing API offre uno standard per trasmettere al browser i tempi di esecuzione del server backend. Usando gli header Server-Timing, puoi misurare e analizzare le componenti lato server che contribuiscono al TTFB, individuando con precisione cosa ottimizzare per migliorare le prestazioni complessive del sito.

L'header Server-Timing può contenere i tempi di più metriche separate da virgole. Ogni voce include:

• Un nome breve per la metrica (come database e processing)
• Una durata in millisecondi (espressa come dur=123)
• Una descrizione facoltativa (espressa come desc="My Description")

Server-Timing: database;dur=123;desc="DB Query", processing;dur=234;desc="Template Render", cache;dur=0;desc="Cache HIT"

Leggere Server-Timing in Chrome DevTools

Chrome DevTools mostra le voci di Server-Timing direttamente nel pannello Network. Apri DevTools, seleziona la richiesta del documento nella scheda Network e scorri fino alla sezione "Server Timing" nella scheda Timing. Ogni metrica inviata tramite l'header Server-Timing comparirà con nome, descrizione e durata. In questo modo capisci subito se il collo di bottiglia è il database, il rendering del template o il layer di cache.

Puoi anche leggere l'header Server-Timing via codice e inviare queste metriche al tuo strumento RUM preferito, come CoreDash, per monitoraggio a lungo termine e avvisi automatici.

Velocizzare il TTFB con 103 Early Hints

103 Early Hints è uno status code HTTP che permette al server di inviare header di risposta preliminari al browser prima che la risposta finale sia pronta. Mentre il server elabora ancora la richiesta (interrogando il database o renderizzando il template), il browser può già iniziare a scaricare risorse critiche come fogli di stile, font e l'immagine del LCP.

Come funziona 103 Early Hints

Nel flusso tradizionale di una richiesta, il browser resta inattivo per tutto il tempo di elaborazione del server. Con 103 Early Hints, il server invia una risposta parziale subito dopo aver ricevuto la richiesta. Questa risposta parziale contiene header Link che indicano al browser quali risorse precaricare o a quali domini pre-connettersi. Il browser elabora questi hint mentre aspetta la risposta 200 completa.

In questo modo il tempo morto di attesa si trasforma in tempo utile di caricamento. Sebbene 103 Early Hints non riduca il TTFB del documento in sé, riduce l'impatto percepito del TTFB sulle metriche successive come LCP e FCP, anticipando la scoperta delle risorse da parte del browser.

Esempio di configurazione server per 103 Early Hints

Molte CDN e web server supportano ormai 103 Early Hints. Ecco un esempio con Cloudflare, che genera automaticamente 103 Early Hints a partire dagli header Link e dai tag preload/preconnect presenti nell'HTML:

HTTP/1.1 103 Early Hints
Link: </style.css>; rel=preload; as=style
Link: </static/img/hero.webp>; rel=preload; as=image
Link: <https://fonts.googleapis.com>; rel=preconnect

HTTP/1.1 200 OK
Content-Type: text/html
...

Su Nginx puoi configurare Early Hints aggiungendo header Link alla risposta e abilitando il server push in HTTP/2 o HTTP/3. Apache supporta 103 Early Hints tramite la direttiva H2EarlyHints. Consulta la nostra guida dettagliata sull'implementazione di 103 Early Hints per istruzioni dettagliate passo passo.

Azzerare il TTFB con la Speculation Rules API

La Speculation Rules API serve a migliorare le prestazioni per le navigazioni successive. Quando un visitatore arriva sulla pagina, puoi usare le Speculation Rules per indicare al browser di scaricare (con la direttiva prefetch) o persino renderizzare del tutto (con la direttiva prerender) le pagine che visiterà con maggiore probabilità.

Come Speculation Rules azzera il TTFB

Quando una pagina viene sottoposta a prerender, il browser la carica e la renderizza per intero in un tab nascosto. Quando l'utente fa clic sul link, la pagina prerenderizzata subentra all'istante. Risultato: un TTFB misurato di 0 millisecondi. Non è un dato teorico: le misurazioni RUM di CoreDash su corewebvitals.io confermano che le navigazioni con prerender tramite Speculation Rules registrano un TTFB al p75 di 0 ms.

Il prefetching è un'alternativa più leggera. Invece di renderizzare l'intera pagina, il browser scarica solo il documento HTML e lo salva in cache. Questo azzera la componente di rete del TTFB, pur richiedendo al browser di analizzare e renderizzare il documento al momento della navigazione.

Sintassi JSON di Speculation Rules

Le Speculation Rules si definiscono con un blocco <script type="speculationrules"> contenente JSON. Ecco un esempio che esegue il prerender di tutti i link di navigazione nella barra dei menu con prontezza (eagerness) "moderate" (attivato al passaggio del mouse o al tocco):

<script type="speculationrules">
{"prerender":
[{
  "source": "document",
  "where": {"selector_matches": "nav a"},
  "eagerness": "moderate"
}]}
</script>

Puoi anche usare un approccio basato su lista per URL specifici:

<script type="speculationrules">
{"prefetch":
[{
  "source": "list",
  "urls": ["/core-web-vitals/", "/pagespeed/103-early-hints"]
}]}
</script>

Il supporto dei browser per le Speculation Rules è in costante crescita. Chrome 121+ supporta l'API completa, comprese le regole di documento. Per i browser che non supportano ancora le Speculation Rules, puoi usare uno script leggero come quicklink come fallback. Usa il nostro generatore di Speculation Rules per creare la configurazione adatta al tuo sito.

Come influisce l'hosting sul Time to First Byte?

L'hosting incide sul Time to First Byte sotto diversi aspetti. Investendo in un hosting migliore è spesso possibile velocizzare all'istante il Time to First Byte senza toccare altro. Soprattutto passando da un hosting condiviso economico a server virtuali ben configurati e gestiti, il TTFB può migliorare drasticamente.

Hosting TIP: un hosting migliore offre elaborazione più rapida, velocità di rete superiore e memoria del server più capiente e veloce. Hosting costoso non significa automaticamente hosting migliore. Molti upgrade sui piani di hosting condiviso offrono solo più spazio su disco, non più potenza di calcolo (CPU).

Sconsiglio di cambiare hosting prima di aver compreso le cause reali dei problemi di TTFB. Prima imposta il tracciamento RUM e aggiungi gli header Server-Timing.

Quando passi a un piano di hosting superiore, cerca sempre almeno uno di questi tre miglioramenti:

• Più risorse (CPU + RAM): essenziali soprattutto quando il server impiega troppo tempo a generare l'HTML dinamico.
• DNS più rapido: molti provider di hosting economici sono noti per le scarse prestazioni dei loro DNS.
• Configurazione migliore: cerca cifrari SSL più veloci, HTTP/3, compressione Brotli e l'accesso alla configurazione del web server (per disabilitare i moduli inutilizzati), solo per citarne alcuni.

Come migliorare il TTFB: velocizzare la connessione iniziale

Un Time to First Byte elevato può avere varie cause. DNS, TCP e SSL impattano però su ogni singolo Time to First Byte. Partiamo quindi da qui. Anche se ottimizzare questi tre fattori potrebbe non produrre i guadagni più eclatanti, velocizzarli migliorerà ogni singola richiesta.

Velocizzare il DNS

PageSpeed TIP: DNS, TCP e SSL sono solitamente un problema più grave quando usi un host economico o quando servi un pubblico globale senza usare una CDN. Usa il tracciamento RUM per analizzare il TTFB globale e scomporlo nelle sue componenti.

Usa un provider DNS veloce. Le prestazioni dei provider DNS variano notevolmente. Alcuni provider DNS (anche gratuiti) sono semplicemente più lenti di altri. Cloudflare, ad esempio, mette a disposizione gratuitamente uno dei provider DNS più veloci al mondo.

Aumenta il TTL del DNS. Un'altra soluzione consiste nell'aumentare il valore di Time to Live (TTL). Il TTL è un'impostazione che stabilisce per quanto tempo il lookup può rimanere in cache. Più alto è il TTL, meno spesso il browser dovrà effettuare un altro DNS lookup. È importante ricordare che anche gli ISP memorizzano il DNS in cache.

Velocizzare il TCP

La "quota TCP" del TTFB è la connessione iniziale al web server. Durante la connessione, il browser e il server si scambiano informazioni su come avverrà il trasferimento dei dati. Puoi velocizzare il TCP connettendoti a un server geograficamente vicino alla posizione dell'utente e assicurandoti che il server abbia risorse libere a sufficienza. Talvolta passare a un server leggero come NGINX può velocizzare la parte TCP del TTFB. In molti casi, usare una CDN velocizzerà la connessione TCP.

Velocizzare SSL/TLS

Una volta stabilita la connessione TCP, browser e server devono proteggerla attraverso la cifratura. Puoi velocizzare questa fase adottando protocolli più veloci, recenti e leggeri (cifrari SSL) e avvicinandoti geograficamente al web server (poiché la negoziazione TLS richiede vari round-trip di andata e ritorno). Usare una CDN migliora spesso il tempo di connessione SSL, dato che le CDN sono quasi sempre ben configurate e dispongono di server distribuiti in tutto il mondo. TLS 1.3, in particolare, è progettato per mantenere la negoziazione TLS il più breve possibile.

Come migliorare il TTFB: velocizzare il lato server

Page caching

Il modo di gran lunga più efficiente per velocizzare il Time to First Byte è servire l'HTML dalla cache del server. Esistono diversi modi per implementare il full page caching. Il più efficace consiste nel farlo direttamente a livello di web server, ad esempio con il modulo di caching di NGINX o usando Varnish come reverse proxy di caching.

Esistono anche molti plugin per vari CMS capaci di memorizzare in cache intere pagine e molti framework SPA come Next.js hanno una propria implementazione del full page caching con diverse strategie di invalidazione.

Se vuoi implementare un sistema di caching proprietario, il principio di base è semplice. Quando un client richiede una pagina, controlli se esiste nella cartella di cache. Se non esiste, generi la pagina, la scrivi in cache e la mostri come faresti normalmente. A ogni richiesta successiva il file di cache sarà presente e potrai servire la pagina direttamente dalla cache.

Caching parziale

Con il caching parziale l'idea è memorizzare in cache porzioni di pagina o risorse frequenti, lente o onerose (come chiamate API o query al database) per un recupero rapido. Questo eliminerà i colli di bottiglia nella generazione della pagina. Se ti interessano queste ottimizzazioni, approfondisci questi concetti: Memory Cache, Object Cache, Database Cache, Object-Relational Mapping (ORM) Cache, Content Fragment Cache e Opcode Cache.

Ottimizzare il codice dell'applicazione

A volte la pagina non può essere servita da cache (totale o parziale) perché il file di cache non esiste, ampie porzioni della pagina sono dinamiche o subentrano altri problemi. Ecco perché dobbiamo ottimizzare il codice dell'applicazione. Come intervenire dipende interamente dalla tua applicazione: si tratta di riscrivere e ottimizzare le parti lente del codice.

Ottimizzare le query al database

La maggior parte delle volte query al database poco efficienti sono la causa principale di un Time to First Byte lento. Inizia registrando su disco le "slow query" e le "query che non usano indici". Analizzale, aggiungi gli indici o chiedi a un esperto di eseguire il tuning del database per risolvere questi problemi. Per ulteriori dettagli consulta il MongoDB Performance Advisor e il MySQL Slow Query Log.

Ridurre la latenza di rete interna

Una cattiva pratica che incontro più spesso di quanto vorrei è un ritardo nel Time to First Byte causato dalla lentezza nella comunicazione tra l'applicazione web e lo storage dei dati. Di solito questo accade solo con siti di grandi dimensioni che hanno delegato lo storage dei dati ad API cloud esterne.

Come migliorare il TTFB: velocizzare il lato client

Caching lato client

Il caching lato client fa sì che il browser dell'utente memorizzi le risorse già scaricate, come immagini e script. Quando l'utente torna sul sito web, il browser può recuperare rapidamente le risorse in cache invece di doverle scaricare di nuovo. Questo riduce notevolmente il numero di richieste inviate al server, abbassando a sua volta il TTFB.

Per implementare il caching lato client si usa l'header HTTP Cache-Control, che ti consente di specific are per quanto tempo il browser deve memorizzare una determinata risorsa.

Puoi valutare di memorizzare completamente in cache l'HTML della pagina sul lato client. Questo abbatterà drasticamente il TTFB perché non sarà necessaria alcuna richiesta al server. Lo svantaggio è che, una volta che la pagina è nella cache del browser, l'utente non vedrà alcun aggiornamento della versione online finché la cache della pagina non scade.

Service worker

I service worker sono script eseguiti in background nel browser dell'utente capaci di intercettare le richieste di rete effettuate dal browser. Questo significa che i service worker possono memorizzare in cache risorse come HTML, immagini, script e fogli di stile: quando l'utente torna sul sito, il browser recupera rapidamente le risorse memorizzate invece di doverle riscaricare.

Prefetching delle pagine

Se non vuoi usare la Speculation Rules API per via del suo limitato supporto browser, puoi usare un piccolo script chiamato quicklink. Questo script esegue il prefetch di tutti i link nel viewport visibile, azzerando quasi del tutto il Time to First Byte per questi collegamenti.

Lo svantaggio di quicklink è che richiede più risorse del browser, ma per ora supera la Speculation Rules API in termini di copertura dei browser.

Come migliorare il TTFB: usare una CDN

Una Content Delivery Network o CDN sfrutta una rete distribuita di server per distribuire risorse agli utenti. Questi server sono in genere geograficamente più vicini agli utenti finali e fortemente ottimizzati per la velocità. Se usi Cloudflare, consulta la nostra guida su come configurare Cloudflare per massimizzare le prestazioni dei Core Web Vitals.

Una CDN può aiutare a migliorare 5 delle 6 componenti del Time to First Byte:

• Tempo di redirect: la maggior parte delle CDN può memorizzare i redirect sull'edge o usare edge worker per gestirli senza doversi connettere al server di origine.
• Tempo di DNS lookup: quasi tutte le CDN offrono server DNS estremamente veloci che supereranno di gran lunga i tuoi server DNS attuali.
• Tempo di connessione TCP e handshake SSL: le CDN sono configurate in modo eccellente e queste configurazioni, insieme alla maggiore vicinanza agli utenti finali, velocizzeranno i tempi di connessione e di handshake.
• Risposta del server: le CDN velocizzano il tempo di risposta del server in due modi. Il primo è memorizzando la risposta del server sull'edge (full page edge caching), ma anche offrendo un'eccellente compressione (Brotli) e i protocolli più recenti (HTTP/3).

Come migliorare il TTFB: evitare i redirect

Il tempo dei redirect si somma al Time to First Byte. Pertanto, come regola generale, evita i redirect il più possibile. I redirect si verificano quando una risorsa non è più disponibile in un percorso ma è stata spostata in un altro. Il server risponde con un header di redirect e il browser tenta di raggiungere la nuova posizione.

Redirect same-origin. I redirect same-origin hanno origine da link sul tuo stesso sito web. Dovresti avere il pieno controllo su questi link e dare priorità alla loro correzione quando lavori sul Time to First Byte. Esistono molti strumenti in circolazione che ti permettono di scansionare l'intero sito web alla ricerca di redirect.

Redirect cross-origin. I redirect cross-origin hanno origine da link presenti su altri siti web. Su questi hai un controllo molto limitato.

Redirect multipli. I redirect multipli o catene di redirect si verificano quando un singolo redirect non punta alla destinazione finale della risorsa. Questi redirect appesantiscono ulteriormente il Time to First Byte e vanno evitati a ogni costo. Anche in questo caso, usa uno strumento per individuare queste catene di redirect e correggerle.

Redirect da HTTP a HTTPS. Un modo per evitare questo problema è usare l'header Strict-Transport-Security (HSTS), che impone HTTPS fin dalla prima visita all'origine e istruisce il browser ad accedere immediatamente tramite HTTPS alle visite successive.

Quando un utente richiede una pagina web, il server può rispondere con un redirect verso un'altra pagina. Questo redirect aggiunge ulteriore tempo al TTFB perché il browser deve effettuare una richiesta aggiuntiva verso la nuova pagina.

Esistono diversi modi per evitare i redirect o ridurne al minimo l'impatto:

1. Aggiorna i link interni. Ogni volta che modifichi il percorso di una pagina, aggiorna i link interni verso quella pagina per assicurarti che non rimangano riferimenti al vecchio indirizzo.
2. Gestisci i redirect a livello di server.
3. Usa URL relativi: quando colleghi pagine all'interno del tuo sito, usa URL relativi anziché assoluti. Questo aiuterà a prevenire redirect non necessari.
4. Usa URL canonical: se hai più pagine con contenuti simili, usa un URL canonical per indicare la versione preferita della pagina. Questo previene contenuti duplicati e redirect inutili.
5. Usa redirect 301: se devi impostare un redirect, usa un 301 invece di un 302. Un redirect 301 è permanente, mentre un 302 è temporaneo. L'uso di un redirect 301 evita richieste e redirect non necessari.

Ottimizzare la prioritizzazione delle risorse insieme al TTFB

Ridurre il TTFB è solo una parte dell'ottimizzazione delle prestazioni di caricamento. Una volta arrivato il primo byte, il browser deve sapere a quali risorse dare la priorità. Leggi la nostra guida alla prioritizzazione delle risorse per scoprire come gli hint fetchpriority, preload e preconnect lavorano insieme a un TTFB veloce per garantire i caricamenti di pagina più rapidi possibili. Inoltre, valuta di ospitare in locale i tuoi Google Fonts per eliminare lookup DNS e tempi di connessione verso terze parti che appesantiscono il TTFB percepito dagli utenti.

Cosa mostrano i dati reali sul TTFB

I dati seguenti provengono dal Real User Monitoring di CoreDash e dal Web Almanac 2025.

La variazione geografica è enorme

Il TTFB varia sensibilmente in base alla distanza fisica tra l'utente e il server. I dati di CoreDash rilevati su corewebvitals.io (con hosting in Europa) lo illustrano chiaramente:

Gli utenti europei vicini al server riscontrano un TTFB inferiore a 170 ms, mentre gli utenti in India registrano un TTFB 3 volte più alto e gli utenti in Cina rilevano un TTFB quasi 10 volte superiore (1.468 ms) a causa del Great Firewall e della notevole distanza fisica. Questi dati dimostrano perché una CDN con nodi edge globali sia essenziale per un pubblico internazionale.

Il prerender con Speculation Rules offre un TTFB di 0 ms

I dati sui tipi di navigazione di CoreDash confermano che le pagine con prerender tramite Speculation Rules raggiungono un TTFB al p75 di 0 millisecondi. Le navigazioni standard registrano 131 ms, le ricariche si attestano a 82 ms (beneficiando di connessioni già calde) e le navigazioni avanti/indietro risultano le più lente a 244 ms. Questo rende le Speculation Rules la tecnica in assoluto più efficace per azzerare il TTFB sui caricamenti di pagina successivi.

Il TTFB su mobile è 2,5 volte quello su desktop

Su corewebvitals.io, gli utenti mobile registrano un TTFB al p75 di 316 ms rispetto ai 124 ms del desktop. Questo divario di 2,5 volte è causato dalla latenza delle reti mobili, non da differenze del server. Solo l'88,5% dei caricamenti di pagina da mobile ottiene una valutazione "buono", rispetto al 96,1% su desktop. Quando ottimizzi il TTFB, esegui sempre i test su reti mobili reali.

Nuovi visitatori e visitatori di ritorno registrano un TTFB simile

Su questo sito, i nuovi visitatori registrano un TTFB al p75 di 127 ms mentre i visitatori di ritorno si attestano a 138 ms. Questa somiglianza suggerisce che un caching lato server coerente (più che i vantaggi della cache lato client) sia il fattore principale nelle prestazioni del TTFB. Nei siti privi di caching lato server, il divario tra nuovi visitatori e visitatori di ritorno può essere molto più ampio.

Il TTFB globale è fermo da 5 anni

Secondo il Web Almanac 2025, solo il 44% delle pagine su mobile ottiene un punteggio di TTFB "buono" a livello globale. Questo dato è pressoché invariato rispetto al 41% del 2021, rendendo il TTFB la metrica di prestazioni più stagnante del web. Nel frattempo, nello stesso periodo il LCP è migliorato passando dal 44% al 59% e l'INP dal 55% al 74%. I siti con un LCP scarso trascorrono in media 2,27 secondi solo sul TTFB, esaurendo quasi per intero la soglia di 2,5 secondi prevista per il LCP.

Guide correlate: le componenti del TTFB

Ogni componente del Time to First Byte richiede strategie di ottimizzazione specifiche:

• <b>Identificare e risolvere i problemi di TTFB</b>: una guida diagnostica passo passo per trovare la causa radice di un TTFB lento utilizzando DevTools, Server-Timing e dati RUM.
• <b>Ridurre la durata di attesa</b>: come minimizzare i tempi di redirect e i ritardi di elaborazione del server che appesantiscono il TTFB.
• <b>Ridurre la durata della cache</b>: strategie per caching del browser, service worker e back/forward cache (bfcache) per azzerare il TTFB per i visitatori di ritorno.
• <b>Minimizzare la durata del DNS</b>: come velocizzare la risoluzione DNS con provider DNS più rapidi, valori TTL più elevati e resource hint dns-prefetch.
• <b>Ottimizzare la durata della connessione (TCP + TLS)</b>: come ridurre i tempi di handshake TCP e TLS con HTTP/3, TLS 1.3, session resumption e hint preconnect.