Time to First Byte (TTFB): guida

TL;DR — Time to First Byte è il tempo che il browser aspetta, dopo aver richiesto una pagina, prima che torni il primissimo byte della risposta. Misura la reattività del server. Un TTFB buono è pari o inferiore a 0,8 secondi. Non è un Core Web Vital, ma un TTFB lento trascina verso il basso le metriche che lo sono, perché nulla nella pagina può iniziare finché non arrivano i primi byte.

Che cos’è il TTFB

Quando fai clic su un link, il browser invia una richiesta a un server e poi aspetta. Time to First Byte (TTFB) è la durata di quell’attesa — dal momento in cui inizia la richiesta al momento in cui comincia ad arrivare il primo byte della risposta.

Non significa soltanto «quanto velocemente pensa il server». Prima che il browser parli con la macchina corretta succedono molte cose: può seguire un redirect, cercare il dominio nel DNS, aprire una connessione e negoziare l’handshake sicuro (TLS). Il TTFB riunisce tutto questo, aggiunge il tempo di elaborazione del server e ferma il cronometro al ritorno del primo byte.

Che cosa si considera buono

Le indicazioni di web.dev di Google sono semplici: punta a un TTFB di 0,8 secondi o meno. Oltre 1,8 secondi è considerato scarso. La maggior parte dei siti dovrebbe riuscire a raggiungere il livello buono — e molti non ci riescono, proprio per questo vale la pena controllare.

Perché conta anche se non è una metrica «core»

Sentirai parlare spesso dei Core Web Vitals — LCP, INP e CLS. Il TTFB non è uno di loro. Ma sta sotto quelli relativi al caricamento: sia First Contentful Paint sia Largest Contentful Paint includono il TTFB nella misurazione. Il browser non può disegnare nulla finché i byte non iniziano ad arrivare. Quindi un TTFB lento pone un tetto alla velocità percepibile della pagina.

La conclusione pratica: il TTFB da solo non ti fa posizionare, ma uno cattivo frena silenziosamente le metriche che contano.

Le correzioni usuali, in parole semplici

• Usa una CDN. Mette una copia del sito su server fisicamente più vicini ai visitatori, così il percorso di andata e ritorno è più breve.
• Metti in cache le pagine. Se il server può restituire una copia pronta invece di ricostruire la pagina ogni volta, il primo byte arriva molto prima.
• Scegli un hosting migliore. Un server e un database più veloci sono la correzione più diretta.
• Riduci i redirect. Ogni redirect è un ulteriore viaggio di andata e ritorno prima ancora che la pagina reale inizi a caricarsi.

Vuoi la versione completa — soglie esatte, relazione con LCP, confusione tra soglie Lighthouse e CrUX, Early Hints e modalità di misurazione? Passa alla scheda Advanced.

TL;DR — TTFB è il tempo dall’inizio della richiesta all’arrivo del primo byte della risposta — la somma di tempo dei redirect, avvio del service worker, ricerca DNS, negoziazione della connessione + TLS e richiesta stessa, fino a quel primo byte. Non è un Core Web Vital; è una metrica fondamentale e diagnostica che alimenta FCP e LCP. web.dev: buono ≤0,8 s, scarso >1,8 s (75° percentile). È una metrica sia di campo sia di laboratorio. L’audit Lighthouse «Reduce server response times» è più ristretto: segnala un tempo server oltre ~600 ms, non il TTFB completo, e da Lighthouse 13 vive nell’insight «Document request latency». Risolvilo con CDN, cache edge/HTML, hosting più veloce, meno redirect, 103 Early Hints e TLS efficiente. E un TTFB alto non significa sempre un sito lento.

Che cosa misura davvero il TTFB

TTFB misura il tempo tra l’inizio della navigazione verso una pagina e l’inizio dell’arrivo del primo byte della risposta. L’errore comune è trattarlo come puro tempo di elaborazione backend. Non lo è. È la somma di tutto ciò che deve terminare prima che quel primo byte possa tornare:

1. Tempo dei redirect
2. Tempo di avvio del service worker (se applicabile)
3. Ricerca DNS
4. Negoziazione della connessione e TLS
5. La richiesta — fino al momento in cui è arrivato il primo byte della risposta

Il tempo di elaborazione del server è incluso, ma lo è anche l’intero costo della configurazione della connessione. La distinzione conta quando inizi a leggere gli strumenti, perché non misurano tutti la stessa porzione (ne parleremo più avanti).

Non è un Core Web Vital

Lo dico chiaramente perché è il malinteso più comune: TTFB non è un Core Web Vital. I tre Core Web Vitals sono LCP (caricamento), INP (interattività) e CLS (stabilità visiva). TTFB è una metrica fondamentale e diagnostica — la formulazione di Google è che è «a foundational metric for measuring connection setup time and web server responsiveness in both the lab and the field» («una metrica fondamentale per misurare il tempo di configurazione della connessione e la reattività del web server sia in laboratorio sia sul campo»).

Google è esplicito anche sul fatto che non devi necessariamente raggiungere la soglia TTFB buona: poiché non è un Core Web Vital, «not absolutely necessary that sites meet the ‘good’ TTFB threshold, provided that it doesn’t impede their ability to score well on the metrics that matter» («non è assolutamente necessario che i siti raggiungano la soglia TTFB “buona”, purché ciò non impedisca loro di ottenere buoni risultati nelle metriche che contano»). L’ultima clausola è il punto: per la maggior parte dei siti un TTFB cattivo ostacola davvero le metriche importanti.

Come limita FCP e LCP

TTFB precede ogni metrica di caricamento centrata sull’utente. Sia First Contentful Paint sia Largest Contentful Paint includono il TTFB nella misurazione: il cronometro di quelle metriche è già in funzione mentre aspetti il primo byte. web.dev scompone LCP in parti e TTFB è la prima, per questo non puoi avere un LCP veloce costruito sopra un TTFB lento.

È anche qui che i dati reali diventano indicativi. Il Web Almanac di HTTP Archive ha rilevato che, sui siti con LCP scarso, il solo TTFB consumava circa 2,27 secondi — quasi tutto il budget di 2,5 secondi per un «buon LCP» — prima ancora che immagini o testo iniziassero a essere renderizzati. Se il tuo LCP è cattivo e il contenuto on-page sembra ottimizzato, TTFB è il primo punto che controllerei.

La storia del ranking è quindi indiretta ma reale: TTFB non è un segnale di ranking Google (i segnali di ranking sono LCP, INP e CLS — TTFB non è nominato in quell’insieme). Ma è incorporato in LCP, che è un segnale di ranking. Il percorso passa da LCP, non direttamente da TTFB.

Soglie: buono, da migliorare, scarso

Le indicazioni di web.dev, misurate al 75° percentile dei caricamenti di utenti reali:

• Buono: ≤ 0,8 s
• Scarso: > 1,8 s

«Most sites should strive to have a TTFB of 0.8 seconds or less.» («La maggior parte dei siti dovrebbe puntare a un TTFB di 0,8 secondi o meno».) Vale la pena conoscere la storia: Google ha spostato la linea del «buono» da 500 ms a 800 ms nel 2022 e i dati precedenti sono stati ricalcolati secondo il nuovo standard; non confrontare numeri TTFB storici grezzi senza controllare quale soglia usavano.

La confusione tra 600 ms e 800 ms

Questo confonde molte persone, quindi è utile essere precisi. Circolano due numeri diversi:

• Soglia TTFB CrUX / web.dev: 800 ms. È la soglia sul campo per il TTFB completo (DNS + connessione + TLS + redirect + tempo server).
• Audit Lighthouse «Reduce server response times»: ~600 ms. È un audit di laboratorio che segnala quando il browser aspetta più o meno 600 ms perché il server risponda alla richiesta del documento principale. Soprattutto, misura solo il tempo di risposta del server: non include DNS, configurazione della connessione o TLS.

Il numero Lighthouse sembra quindi più severo, ma misura una porzione più ristretta. Come dicono i documenti, «server response time is only part of the full Time to First Byte (TTFB)» («il tempo di risposta del server è solo una parte del Time to First Byte (TTFB) completo»). Non considerare un audit Lighthouse superato come prova di un buon TTFB sul campo e non allarmarti perché 600 < 800: le soglie misurano cose diverse.

Una nota sulla versione: da Lighthouse 13 questo audit non è più autonomo, ma è stato incluso nell’insight più ampio «Document request latency». Il controllo sottostante del tempo di risposta server di ~600 ms è lo stesso; viene solo mostrato in modo diverso a seconda della versione Lighthouse che ha generato il report.

Sul campo e in laboratorio — entrambi

TTFB è una delle metriche che puoi leggere in entrambi i mondi. Sul campo proviene da CrUX (utenti Chrome reali) ed è mostrato in PageSpeed Insights e Search Console. In laboratorio, Chrome DevTools lo etichetta «Waiting (TTFB)» nel waterfall del pannello Network («il browser sta aspettando il primo byte della risposta»), e lo riportano anche strumenti come WebPageTest e Lighthouse. Una cautela sul campo: in CrUX TTFB è ancora considerato in parte sperimentale — esclude alcuni tipi avanzati di navigazione, come navigazioni prerenderizzate e dalla back/forward cache, quindi le medie sul campo possono essere un po’ pessimistiche rispetto a ciò che gli utenti percepiscono davvero.

Un TTFB alto non significa sempre un sito lento

Ecco la sfumatura che i numeri delle soglie nascondono. Una pagina renderizzata dal server può avere un TTFB più alto di una pagina renderizzata dal client e fornire comunque FCP e LCP migliori, perché quando arriva quel primo byte è HTML completo che il browser può disegnare subito, invece di un guscio sottile che deve poi recuperare ed eseguire un bundle JavaScript prima che compaia qualcosa. Google lo dice direttamente: «a server-rendered site that does not require as much client-side work could have a higher TTFB, but better FCP and LCP values than an entirely client-rendered experience» («un sito renderizzato dal server che non richiede altrettanto lavoro lato client potrebbe avere un TTFB più alto, ma valori FCP e LCP migliori rispetto a un’esperienza interamente renderizzata dal client»).

Il rovescio della medaglia: in una single-page app renderizzata dal client, TTFB determina quando il bundle JavaScript inizia persino a caricarsi, quindi un TTFB basso conta di più, non di meno. Non ottimizzare TTFB nel vuoto: ottimizza l’intera catena di caricamento e giudica TTFB da ciò che fa a FCP e LCP.

Come migliorare TTFB

Approssimativamente in ordine di priorità:

• Inizia dall’hosting. Un backend lento o una query al database è un costo su ogni richiesta e nessuna quantità di lavoro frontend lo elimina. È la prima cosa da considerare.
• Usa una CDN. Una CDN risolve il problema della prossimità: una rete distribuita di server edge memorizza le risorse nella cache fisicamente più vicine agli utenti, riducendo il costo della distanza e dell’handshake TLS. È la correzione con il miglior ROI per la maggior parte dei siti, perché la distanza geografica dall’origine è un costo strutturale che nulla nel backend può cancellare. La cautela: per contenuti completamente dinamici e personalizzati che non possono essere messi in cache, una CDN aggiunge un passaggio senza il vantaggio di un cache hit; lì servono ottimizzazione backend, edge compute o streaming.
• Metti in cache l’HTML, anche brevemente. Anche un tempo di cache breve aiuta sensibilmente un sito trafficato: solo il primo visitatore della finestra paga tutta la latenza verso l’origine, gli altri ricevono la copia in cache.
• Elimina i redirect. I redirect contribuiscono spesso a un TTFB alto: ognuno è un viaggio di andata e ritorno prima che inizi la risposta reale. Riduci quelli sotto il tuo controllo.
• Trasmetti il markup al browser. I browser elaborano il markup in modo efficiente quando arriva in blocchi. Molti framework SSR supportano lo streaming ma lo lasciano disattivato; abilitarlo può ridurre TTFB sulle pagine dinamiche senza alcun cambiamento all’infrastruttura.
• Usa 103 Early Hints. Il codice di stato 103 è una risposta preliminare che il server può inviare mentre il backend sta ancora preparando il markup, suggerendo al browser di iniziare presto a scaricare le risorse critiche per il rendering. Non abbassa TTFB in sé — anzi, un 103 può contare come «primo byte» — ma riduce l’impatto di un TTFB alto. Shopify e Cloudflare hanno riferito miglioramenti LCP di diverse centinaia di millisecondi, in alcuni casi quasi un secondo.
• Negozia TLS in modo efficiente e ottimizza l’avvio del service worker. Un service worker non ancora avviato aggiunge il proprio tempo di avvio a TTFB; una volta attivo, la sua cache (stale-while-revalidate o un modello app-shell per le SPA) può ridurre drasticamente TTFB.

Dove si trovano davvero i siti

Vale la pena prestare attenzione perché è un problema ostinato sul web. Il tasso di TTFB buono mobile del Web Almanac è cambiato appena in cinque anni — resta intorno al 41–42% — quindi la maggior parte dei siti mobile non ha ancora un TTFB «buono». Questa stagnazione è, francamente, un’opportunità. Per un sito pesante lato server che non supera LCP, TTFB è di solito la correzione con la leva più alta.

Questa pagina fa parte del cluster web-performance, che si trova sotto Core Web Vitals. Per le metriche alimentate da TTFB, consulta Largest Contentful Paint e First Contentful Paint; per misurarlo su utenti reali e in laboratorio, consulta CrUX, PageSpeed Insights e Lighthouse.

Riepilogo AI

Una sintesi della versione Advanced:

• TTFB = attesa del primo byte. Tempo dall’inizio della richiesta all’arrivo del primo byte della risposta — somma di tempo dei redirect, avvio service worker, ricerca DNS, negoziazione connessione + TLS e richiesta stessa. Non solo elaborazione server.
• NON è un Core Web Vital. I Core Web Vitals sono LCP, INP e CLS. TTFB è una metrica fondamentale e diagnostica.
• Limita FCP e LCP. Entrambi includono TTFB, quindi un TTFB lento pone un tetto alla velocità di caricamento. Sui siti con LCP scarso, il solo TTFB era ~2,27 s — quasi tutto il budget di 2,5 s per un buon LCP.
• Ranking: indiretto. TTFB non è un segnale di ranking Google, ma è incorporato in LCP, che lo è. Il percorso passa da LCP.
• Soglie (75° percentile): buono ≤ 0,8 s, scarso > 1,8 s. La linea del «buono» è passata da 500 ms a 800 ms nel 2022.
• 600 ms rispetto a 800 ms: l’audit Lighthouse «Reduce server response times» segnala ~600 ms di solo tempo server, una soglia di laboratorio più ristretta rispetto agli 800 ms del TTFB completo sul campo. «Il tempo di risposta del server è solo una parte del TTFB completo». Da Lighthouse 13 l’audit vive nell’insight «Document request latency».
• Campo e laboratorio: CrUX/PSI/Search Console (campo); DevTools «Waiting (TTFB)», WebPageTest e Lighthouse (laboratorio).
• TTFB alto ≠ sito lento: una pagina SSR può avere TTFB più alto ma FCP/LCP migliori di una renderizzata dal client, perché il primo byte è HTML completo.
• Correzioni (priorità): hosting, poi CDN, cache HTML, meno redirect, streaming, 103 Early Hints, TLS efficiente, avvio service worker.
• Stato del web: il TTFB buono mobile è fermo intorno al 41–42% da cinque anni — un’opportunità reale.

Documentazione ufficiale

Documentazione primaria dei team Chrome e web.dev di Google.

• Time to First Byte (TTFB) — definizione, cinque componenti, soglie 0,8 s / 1,8 s, motivo per cui non è un Core Web Vital e relazione con FCP e LCP.
• Optimize TTFB — guida all’ottimizzazione: prima hosting, poi CDN, cache, redirect, streaming, 103 Early Hints e service worker.
• Reduce server response times — audit Lighthouse (soglia ~600 ms di tempo server) e differenza rispetto al TTFB completo. Da Lighthouse 13 è incluso nell’insight «Document request latency».
• Web Vitals — posizione di TTFB nella tassonomia delle metriche: metrica supplementare/diagnostica, con LCP, INP e CLS come Core Web Vitals.
• Largest Contentful Paint (LCP) — conferma che LCP include i ritardi TTFB.
• First Contentful Paint (FCP) — conferma che FCP include TTFB e cita «reduce server response times (TTFB)» come correzione.
• Core Web Vitals (Google Search Central) — i documenti sui segnali di ranking nominano solo LCP, INP e CLS; TTFB non è elencato.
• 103 Early Hints — codice di risposta anticipata, supporto browser/server e risultati reali.

Citazioni dalla fonte

Dichiarazioni ufficiali dei team web.dev e Chrome di Google. Ogni link è un deep link che porta al passaggio citato nella pagina fonte in cui è stata verificata.

web.dev — che cos’è TTFB

• “TTFB is a metric that measures the time between starting navigating to a page and when the first byte of a response begins to arrive.” — «TTFB è una metrica che misura il tempo tra l’inizio della navigazione verso una pagina e l’inizio dell’arrivo del primo byte di una risposta». Vai alla citazione
• “Time to First Byte (TTFB) is a foundational metric for measuring connection setup time and web server responsiveness in both the lab and the field.” — «Time to First Byte (TTFB) è una metrica fondamentale per misurare il tempo di configurazione della connessione e la reattività del web server sia in laboratorio sia sul campo». Vai alla citazione

web.dev — soglie

• “Good TTFB values are 0.8 seconds or less, and poor values are greater than 1.8 seconds.” — «I valori TTFB buoni sono pari o inferiori a 0,8 secondi e quelli scarsi sono superiori a 1,8 secondi». Vai alla citazione

web.dev — non è un Core Web Vital

• “Because TTFB isn’t a Core Web Vitals metric, it’s not absolutely necessary that sites meet the ‘good’ TTFB threshold, provided that it doesn’t impede their ability to score well on the metrics that matter.” — «Poiché TTFB non è una metrica dei Core Web Vitals, non è assolutamente necessario che i siti raggiungano la soglia TTFB “buona”, purché ciò non impedisca loro di ottenere buoni risultati nelle metriche che contano». Vai alla citazione

web.dev — relazione con FCP e LCP

• “Because TTFB precedes user-centric metrics such as First Contentful Paint (FCP) and Largest Contentful Paint (LCP)…” — «Poiché TTFB precede metriche centrate sull’utente come First Contentful Paint (FCP) e Largest Contentful Paint (LCP)…». Vai alla citazione
• Su un sito renderizzato dal server: “a server-rendered site that does not require as much client-side work could have a higher TTFB, but better FCP and LCP values than an entirely client-rendered experience.” — «un sito renderizzato dal server che non richiede altrettanto lavoro lato client potrebbe avere un TTFB più alto, ma valori FCP e LCP migliori rispetto a un’esperienza interamente renderizzata dal client» (web.dev, «Time to First Byte»).

Lighthouse — tempo di risposta server rispetto al TTFB completo

• “Server response time is only part of the full Time to First Byte (TTFB).” — «Il tempo di risposta del server è solo una parte del Time to First Byte (TTFB) completo». (Lighthouse, «Reduce server response times».)

Patrick Stox — sullo stato di TTFB (dalla mia guida Ahrefs ai Core Web Vitals)

• “There are additional Web Vitals that serve as proxy measures or supplemental metrics but are not used in the ranking calculations. The Web Vitals metrics for visual load include Time to First Byte (TTFB) and First Contentful Paint (FCP).” — «Esistono altri Web Vitals che fungono da misure proxy o metriche supplementari ma non vengono usati nei calcoli del ranking. Le metriche Web Vitals per il caricamento visivo includono Time to First Byte (TTFB) e First Contentful Paint (FCP)». Leggi la guida

Checklist di triage TTFB

Quando PageSpeed Insights, Search Console o Lighthouse segnala una risposta server lenta, procedi con questo elenco:

• Conferma ciò che stai guardando — TTFB completo sul campo (≤0,8 s buono) o audit Lighthouse «Reduce server response times» (~600 ms, solo tempo server). Non sono lo stesso numero.
• Controlla il campo, non solo il laboratorio — recupera TTFB da CrUX tramite PageSpeed Insights o dal report Core Web Vitals di Search Console, al 75° percentile.
• Verifica se TTFB è ciò che limita LCP — se LCP è scarso e il contenuto della pagina è ottimizzato, TTFB è il primo sospetto.
• Conta i redirect — elimina le catene di redirect sotto il tuo controllo sugli URL di ingresso importanti.
• Conferma che una CDN serva i tuoi utenti (PoP edge vicini al pubblico) e che la cache HTML/edge abbia effettivamente hit, non solo gli asset statici.
• Analizza il backend — query database lente o lavoro server pesante sulla richiesta del documento principale.
• Verifica che TLS sia efficiente (protocollo moderno, ripresa della sessione) e che il DNS sia veloce.
• Se la pagina è SSR dinamica, controlla che lo streaming sia abilitato nel framework: spesso è disattivato per impostazione predefinita.
• Valuta 103 Early Hints per le risorse critiche al rendering se il server/CDN lo supporta.
• Se usi un service worker, controlla che il suo avvio non aggiunga TTFB al primo caricamento e che la strategia di cache aiuti i caricamenti ripetuti.

Scheda rapida TTFB

La somma di TTFB

1. Tempo dei redirect
2. Avvio del service worker (se presente)
3. Ricerca DNS
4. Negoziazione della connessione + TLS
5. La richiesta — fino al primo byte della risposta

Soglie (75° percentile dei caricamenti di utenti reali)

Due soglie, due ambiti

Fatti rapidi

• TTFB non è un Core Web Vital. I Core Web Vitals sono LCP, INP, CLS.
• È una metrica sia di campo sia di laboratorio.
• Sia FCP sia LCP includono TTFB: pone un tetto a entrambi.
• L’impatto sul ranking è indiretto, tramite LCP: TTFB in sé non è un segnale di ranking.
• DevTools lo etichetta «Waiting (TTFB)» nel pannello Network.
• La linea del «buono» è passata da 500 ms → 800 ms nel 2022.

Priorità delle correzioni: hosting → CDN → cache HTML/edge → riduci i redirect → trasmetti il markup → 103 Early Hints → TLS efficiente → avvio service worker.

Strumenti per misurare TTFB

• PageSpeed Insights — la lettura sul campo più semplice: mostra TTFB CrUX (utenti Chrome reali) accanto a un’esecuzione di laboratorio, per un URL o un’origine.
• Search Console — report Core Web Vitals — dati sul campo raggruppati per pattern URL; il punto in cui individuare problemi TTFB su larga scala.
• CrUX (Chrome User Experience Report) — il dataset sottostante sul campo, interrogabile direttamente tramite CrUX API o BigQuery per le tendenze storiche.
• Chrome DevTools — pannello Network — passa sul documento principale e leggi il tempo «Waiting (TTFB)» per una scomposizione precisa di connessione rispetto al tempo server.
• Lighthouse — esegue l’audit «Reduce server response times» (flag ~600 ms di tempo server); è integrato in DevTools e PageSpeed Insights. Da Lighthouse 13 il controllo compare nell’insight «Document request latency».
• WebPageTest — waterfall dettagliati con TTFB separato per fase di connessione e test multi-posizione/connessione per isolare la latenza geografica.
• Libreria JS web-vitals — raccogli TTFB (e il resto) dai tuoi utenti reali sul campo e invialo alla tua analytics.

Errori TTFB che portano alla correzione sbagliata

Chiamare ogni ritardo un problema del server

TTFB include redirect, DNS, configurazione della connessione, TLS, avvio del service worker ed elaborazione server. Scomponi la richiesta in fasi prima di cambiare codice applicativo o hosting.

Confrontare l’audit Lighthouse da 600 ms con la soglia sul campo da 800 ms

L’audit Lighthouse è una diagnosi di laboratorio più ristretta, mentre l’indicazione di 0,8 secondi descrive il TTFB completo. Indica fonte e ambito quando riferisci uno dei due numeri.

Testare solo da una posizione vicina all’origine

Un laboratorio vicino può nascondere la latenza geografica. Confronta le regioni o usa dati di utenti reali prima di presumere che la stessa esperienza valga per tutto il pubblico.

Inseguire TTFB quando la pagina è già veloce

Un TTFB alto può essere compatibile con un’esperienza veloce trasmessa in streaming o servita dalla cache. Controlla se limita davvero FCP o LCP prima di anteporlo a un collo di bottiglia più grande.

Diagnosticare un TTFB lento in base al sintomo

La prima richiesta è lenta ma le richieste ripetute sono veloci

Causa probabile: cache fredde, configurazione della connessione o riscaldamento dell’applicazione. Correzione: controlla gli header di cache e separa i test a freddo da quelli a caldo. Conferma: il waterfall mostra quale fase di connessione o server scompare nella richiesta ripetuta.

TTFB lento solo nelle regioni lontane

Causa probabile: distanza fisica dall’origine o cache miss della CDN. Correzione: servi HTML memorizzabile in cache più vicino agli utenti e verifica il comportamento della cache edge. Conferma: i test regionali mostrano un’attesa più breve senza cambiare il body della risposta.

Un URL ha TTFB molto peggiore dei suoi omologhi di template

Causa probabile: redirect, route non in cache o lavoro backend costoso specifico della pagina. Correzione: confronta catena dei redirect, stato della cache e timing server con un omologo sano. Conferma: la richiesta del documento anomala torna verso il baseline del template.

DevTools e CrUX non coincidono

Causa probabile: una singola richiesta di laboratorio non può rappresentare dispositivi, posizioni, stati della cache e 75° percentile del campo. Correzione: usa la richiesta di laboratorio per diagnosticare e i dati sul campo per giudicare la prevalenza. Conferma: la distribuzione RUM spiega quale segmento produce l’aggregato più lento.

Misurare TTFB dalla riga di comando

Usa le variabili di timing di curl per separare il primo byte da DNS, connessione e configurazione TLS.

curl -sS -o /dev/null \
  -w 'dns=%{time_namelookup}s connect=%{time_connect}s tls=%{time_appconnect}s starttransfer=%{time_starttransfer}s total=%{time_total}s\n' \
  https://example.com/

time_starttransfer è la misurazione in stile TTFB del comando. Esegui varie richieste a freddo e a caldo da più di una regione pertinente; un singolo campione locale non è un benchmark sul campo.

Leggere Navigation Timing nel browser

const nav = performance.getEntriesByType('navigation')[0];
console.table({
  ttfb: Math.round(nav.responseStart - nav.requestStart),
  dns: Math.round(nav.domainLookupEnd - nav.domainLookupStart),
  connect: Math.round(nav.connectEnd - nav.connectStart),
});

Dimostrare che una modifica TTFB ha avuto effetto

Test della cache edge

Test da eseguire: richiedi due volte lo stesso documento con curl -sS -D - -o /dev/null, poi controlla gli header cache-status e age della CDN. Risultato atteso: la richiesta ripetuta viene servita dalla cache secondo l’header documentato dalla CDN. Interpretazione del fallimento: la route elude la cache o la fa scadere immediatamente. Finestra di monitoraggio: immediata. Trigger di rollback: HTML personalizzato, autenticato o obsoleto viene servito alla richiesta sbagliata.

Test di rimozione dei redirect

Test da eseguire: usa curl -sS -I sull’URL pubblico finale e ispeziona separatamente la catena dei redirect. Risultato atteso: l’URL di ingresso previsto raggiunge il documento senza un passaggio evitabile. Interpretazione del fallimento: le regole di routing o dell’host canonical aggiungono ancora un viaggio di andata e ritorno. Finestra di monitoraggio: immediata. Trigger di rollback: la modifica interrompe la normalizzazione HTTP-to-HTTPS o del nome host necessaria.

Test TTFB sul campo

Test da eseguire: confronta Navigation Timing post-release o TTFB web-vitals per regione e template con il baseline pre-release. Risultato atteso: p75 migliora nei segmenti interessati senza più errori. Interpretazione del fallimento: il miglioramento di laboratorio non ha raggiunto gli utenti reali o ha spostato il lavoro altrove. Finestra di monitoraggio: mentre arriva traffico RUM; CrUX nella propria finestra mobile. Trigger di rollback: peggiorano tasso di errore, correttezza della cache o latenza visibile all’utente.

Metriche TTFB da monitorare

TTFB degli utenti reali al p75

Metrica: TTFB al 75° percentile per template, regione e classe di dispositivo. Che cosa indica: quanto la richiesta del documento ritarda la maggior parte delle visite reali prima che inizi il rendering. Come recuperarla: Navigation Timing, libreria web-vitals, CrUX o PageSpeed Insights. Benchmark / intervallo realistico: 0,8 secondi o meno è il target buono descritto in questo articolo; interpreta i segmenti separatamente. Cadenza: settimanale in RUM e mensile per la tendenza pubblica sul campo.

TTFB con cache hit rispetto a TTFB con cache miss

Metrica: TTFB p75 separato in base all’esito della cache CDN. Che cosa indica: se il ritardo appartiene al lavoro dell’origine o alla distribuzione edge. Come recuperarla: unisci gli header response cache-status con log RUM o CDN. Benchmark / intervallo realistico: usa il baseline regionale del sito perché provider, route e personalizzazione differiscono. Cadenza: settimanale e dopo modifiche alle regole di cache.

Quota TTFB di LCP

Metrica: TTFB diviso per la durata LCP della stessa visita. Che cosa indica: se tempo server e connessione sono la parte limitante dell’esperienza di caricamento. Come recuperarla: raccogli insieme TTFB e LCP in RUM. Benchmark / intervallo realistico: nessuna percentuale universale sarebbe onesta; dai priorità a TTFB quando consuma costantemente una parte ampia di LCP. Cadenza: mensile per template.

Risorse che meritano il tuo tempo

I miei articoli correlati

• Core Web Vitals: A Beginner’s Guide — dove si colloca TTFB tra le metriche di caricamento e perché è una metrica supplementare, non un segnale di ranking.
• The Beginner’s Guide to Technical SEO — il quadro più ampio in cui rientra la performance del sito.

Ufficiale

• web.dev TTFB e Optimize TTFB — le due pagine definitive.
• L’articolo del team Chrome su 103 Early Hints, con i risultati Shopify/Cloudflare.

Dati

• Il capitolo Performance del Web Almanac di HTTP Archive — dati sul campo TTFB e LCP a lungo termine per l’intero web.

Dal settore

• Blog Cloudflare: Early Hints — il resoconto di Cloudflare sulla distribuzione di 103 Early Hints, con risultati reali e dettagli d’implementazione CDN.
• Libreria JS web-vitals (GitHub) — la libreria canonica per raccogliere TTFB (e tutti i Web Vitals) dagli utenti reali; usala per inviare TTFB sul campo alla tua analytics.
• HTTP Archive Web Almanac 2022 — Performance — baseline storico che mostra il 40% di TTFB buono mobile sotto la soglia allora nuova di 800 ms; utile per il contesto delle tendenze pluriennali.
• Fastly — HTTP/2 Server Push vs Early Hints — prospettiva CDN sul motivo per cui Early Hints sta sostituendo Server Push per ridurre l’impatto di TTFB.

Statistiche che vale la pena citare

• ~42% dei siti mobile ha un TTFB «buono» — e il dato è cambiato appena in cinque anni. Il tasso TTFB buono mobile del Web Almanac è rimasto intorno al 41–42% nei cinque anni di dati: una stagnazione ostinata dell’intero web. Fonte
• Sui siti con LCP scarso, il solo TTFB ha consumato ~2,27 secondi — quasi tutta la soglia di 2,5 secondi per un «buon LCP», prima che venisse renderizzato qualsiasi contenuto. TTFB è la sottoparte più grande di LCP per i siti che non la superano. Fonte
• 103 Early Hints ha prodotto miglioramenti LCP di diverse centinaia di millisecondi nei test Shopify e Cloudflare — in alcuni casi quasi un secondo più velocemente. Fonte
• La linea TTFB «buona» è passata da 500 ms a 800 ms nel 2022 e i dati storici sono stati ricalcolati secondo il nuovo standard: è utile saperlo prima di confrontare vecchi numeri TTFB. Fonte

Mettiti alla prova: Time to First Byte

Cinque domande rapide su ciò che misura TTFB e su come migliorarlo. Scegli una risposta per ciascuna, poi controlla.

Cronologia modifiche