Che cosa include il tempo fino al primo byte del tuo sito

Se guardi un grafico e non sai se quel tempo è rete, TLS o applicazione, la domanda è che cosa include il tempo fino al primo byte del tuo sito. Il 3 novembre 2026 ho letto due pagine di web.dev e tre pagine già online. Non dicono la stessa cosa. Non ho misurato un sito. Il nome della metrica, Time to First Byte, sta qui, dopo la domanda.

Le pagine già online

La pagina su Server-Timing risponde a come il server scrive, su quella risposta, i tempi del proprio lavoro. Si legge negli strumenti di sviluppo. Non elenca le fasi che il browser somma fino al primo byte. Non la riscrivo. Server-Timing: come misurare i tempi di risposta del backend.

La pagina su DNS, hosting e CDN risponde a dove sta il nome e dove stanno le pagine. Il 3 novembre 2026 aveva già riportato, dalla pagina della metrica, la definizione, le fasi, le soglie e la nota sugli Early Hints. Scrive anche di non avere aperto la guida su come migliorare il primo byte. Non la riscrivo. Questa pagina apre quella guida, e non sostituisce la mappa. Dove sta il nome del tuo sito e dove stanno le pagine.

La pagina sulle misure risponde a che cosa misurare prima di cambiare server. Tiene le soglie delle sue fonti. Non riapro quelle fonti qui, e non importo i suoi numeri dentro questa pagina. Non la riscrivo. Che cosa misurare sul tuo sito prima di cambiare server.

Due documenti, lo stesso orologio in intestazione

La pagina della metrica è di Barry Pollard e Jeremy Wagner. In pagina: pubblicata il 26 ottobre 2021, ultimo aggiornamento il 18 novembre 2025. Last-modified della risposta: 28 novembre 2025 alle 08:00:00 GMT. La risposta letta il 3 novembre 2026 porta la data 05:40:00 GMT. Il giorno dell'aggiornamento in pagina e il giorno del last-modified non coincidono. Non li unisco. Indirizzo: https://web.dev/articles/ttfb.

La guida per migliorare il primo byte ha gli stessi due autori. In pagina: pubblicata il 19 gennaio 2023, ultimo aggiornamento il 28 novembre 2025. Last-modified della risposta: 28 novembre 2025 alle 08:00:00 GMT. La risposta letta il 3 novembre 2026 porta la data 05:40:01 GMT. Qui il giorno in pagina e il giorno del last-modified coincidono. L'ora c'è solo nell'intestazione. Non la metto dentro la riga in pagina. Il 19 gennaio 2023 non è il 28 novembre 2025. Non li unisco. Indirizzo: https://web.dev/articles/optimize-ttfb.

Le due risposte portano lo stesso last-modified, allo stesso secondo. Sono due documenti. La pagina della metrica in pagina resta al 18 novembre 2025. La guida in pagina è al 28 novembre 2025. Le risposte distano un secondo, 05:40:00 e 05:40:01. Non ne faccio una sola lettura.

La somma, sulla pagina del 18 novembre 2025

Definisce il primo byte come il tempo fra l'inizio della navigazione verso una pagina e il momento in cui il primo byte di una risposta comincia ad arrivare. La didascalia del disegno dice che la metrica misura il tempo trascorso fra startTime e responseStart. L'esempio in pagina, più sotto, legge responseStart della voce di navigazione e lo scrive come questo tempo. Il disegno parla di un intervallo fra due segni. L'esempio stampa un solo campo. Non so, da questa pagina, se i due numeri coincidono. Non li unisco. Non incollo l'osservatore.

La pagina dice che il primo byte è la somma di queste fasi. Tempo di reindirizzamento. Tempo di avvio del service worker, se c'è. Ricerca del nome, il lookup DNS. Connessione e negoziazione TLS. La richiesta, fino al punto in cui il primo byte della risposta è arrivato. Sono cinque voci. Connessione e negoziazione TLS sono una voce sola. Non le separo in due barre. La ricerca del nome è una fase della somma. Non è tutta la metrica. La quinta voce è la richiesta fino al primo byte. La pagina non la chiama applicazione.

Una frase dopo dice che ridurre la latenza nel tempo di apertura della connessione e nel backend può abbassare questo tempo. Apertura della connessione, e backend, stanno nella stessa frase. Non ne faccio la prova che il numero sia solo rete, o solo applicazione.

La mappa, aggiornata il 3 novembre 2026, riporta già queste fasi e scrive che il lookup DNS non è tutta la metrica. L'ho riletta oggi sulla pagina della metrica. Non riscrivo la mappa. La differenza che tengo qui è il disegno: intervallo fra startTime e responseStart, e, in un altro punto, la stampa del solo responseStart.

Che cosa un solo numero non dimostra

Un solo totale è quella somma. Non dimostra, da solo, che il tempo sia la rete, che sia il TLS, o che sia l'applicazione. Il TLS, su questa pagina, non ha una voce sua: sta dentro la voce connessione e negoziazione TLS.

La guida del 28 novembre 2025 ha un punto chiave che la pagina della metrica non ha. L'audit di Lighthouse sul tempo di risposta del server esclude la ricerca del nome e i tempi di reindirizzamento, e quindi rappresenta solo un sottoinsieme del primo byte. Quel numero più corto non è la somma. Non lo unisco a responseStart.

La stessa guida dice di usare i dati di campo come fonte primaria, perché il primo byte è toccato dai reindirizzamenti, mentre gli strumenti di laboratorio sono spesso misurati sull'indirizzo finale e quindi perdono quel ritardo in più. Sono due modi di misurare. Non li unisco.

Poi tiene due casi, quando i numeri divergono. Se il laboratorio è molto più alto del campo, l'ambiente di laboratorio è più vincolato di ciò che vive la persona tipica. I risultati e i consigli possono restare validi, e possono esagerare l'impatto. Se il campo è molto più alto del laboratorio, ci sono questioni che la corsa di laboratorio non mostra, per esempio la cache lato server, i reindirizzamenti, o differenze di rete. In quel caso i risultati di laboratorio possono essere meno utili, perché manca uno dei problemi principali. Laboratorio più alto, e campo più alto, restano due frasi. Non le unisco. Non ho aperto PageSpeed su un sito, e non ho fatto una corsa di laboratorio.

Gli Early Hints e il documento finale

Sulla pagina del 18 novembre 2025, l'introduzione degli Early Hints 103 crea confusione su quale primo byte misuri la metrica. Il 103 conta come primi byte. finalResponseHeadersStart è una voce di tempo aggiuntiva rispetto a responseStart: misura l'inizio della risposta finale del documento, di solito una risposta 200. Chrome, in base ai riscontri, ha aggiornato responseStart, e quindi il primo byte, all'inizio della risposta finale del documento, quella poi standardizzata come finalResponseHeadersStart, da Chrome 115. Questo ha creato un problema di compatibilità fra molti strumenti, ed è stato riportato indietro in Chrome 133. Chrome 115 e Chrome 133 restano due frasi. Non ne ricavo quale versione stia guardando chi legge.

Gli Early Hints, scrive, sono solo un esempio più recente di rispondere presto. Alcuni server possono mandare avanti la risposta del documento prima che il corpo principale sia pronto: con le sole intestazioni HTTP, oppure con l'elemento head. La pagina li considera simili, nell'effetto, agli Early Hints. È un'altra ragione per cui queste uscite si misurano come responseStart, e quindi come primo byte. Intestazioni sole, ed elemento head, sono due casi della stessa pagina. Non li unisco in un solo gesto.

C'è valore, scrive, nel mandare dati presto se la risposta intera richiederà ancora tempo. Questo però rende difficile confrontare il primo byte fra piattaforme e tecnologie, secondo le funzioni che usano e secondo come quelle funzioni toccano la misura. La cosa che conta è capire che cosa misura lo strumento che stai usando, e come la piattaforma misurata lo tocca. Un primo byte basso non dimostra, da solo, che il documento finale sia già partito.

La mappa riporta già il 103, finalResponseHeadersStart, Chrome 115 e Chrome 133. Non la riscrivo. Qui aggiungo i due casi, intestazioni oppure elemento head, che in quella pagina erano diventati un pezzo solo.

Le soglie restano su due frasi, e su un'altra pagina

Sulla pagina del 18 novembre 2025, perché il primo byte precede metriche centrate sulla persona, come il First Contentful Paint e LCP, si raccomanda che il server risponda alle richieste di navigazione abbastanza in fretta perché il 75° percentile degli utenti abbia un First Contentful Paint dentro la soglia buona. Come guida ruvida, la maggior parte dei siti dovrebbe cercare un primo byte di 0,8 secondi o meno. Il testo inglese usa il punto. In un'altra frase, i valori buoni sono 0,8 secondi o meno, e i valori scarsi sono maggiori di 1,8 secondi, anche qui col punto. Il 75° di quella frase parla del First Contentful Paint. Lo 0,8 è la guida ruvida. La coppia buono e scarso è la frase dopo. Non li unisco. Il numero della soglia buona del First Contentful Paint, su questa pagina, non c'è. Non lo invento.

Un punto chiave dice che il primo byte non è una metrica Core Web Vitals, e che non è assolutamente necessario raggiungere la soglia buona, purché non impedisca di andare bene sulle metriche che contano.

Due casi restano distinti. Se il sito manda il markup in fretta ma quel markup ha poi bisogno di JavaScript per riempirsi di contenuto, come nelle applicazioni a pagina singola, il primo byte più basso possibile è particolarmente importante, così il disegno lato client può avvenire prima. Un sito disegnato sul server, che non chiede altrettanto lavoro al client, può avere un primo byte più alto e però valori migliori di First Contentful Paint e di LCP rispetto a un'esperienza disegnata tutta sul client. Per questo le soglie sono una guida ruvida, da pesare su come il sito consegna il contenuto. I due casi non sono la stessa frase.

La guida del 28 novembre 2025 ripete la guida ruvida dello 0,8. La coppia buono e scarso, sulla guida, è una frase sua: 0,8 secondi o meno, e poi i valori scarsi maggiori di 1,8, senza la congiunzione che sta sulla pagina della metrica. Il punto chiave, sulla guida, dice che non è una Core Web Vital, quindi non è assolutamente necessario. Sulla pagina della metrica la stessa idea è introdotta da perché. Non le unisco. Il caso del sito disegnato sul server, sulla guida, è un sito che richiede meno lavoro lato client. Sulla pagina della metrica è un sito che non richiede altrettanto lavoro lato client. Meno, e non altrettanto, restano due scritti.

La mappa tiene già lo stacco fra il 75°, la guida ruvida e la coppia. La pagina delle misure tiene le soglie delle sue fonti. Non le riscrivo, e non ci metto dentro lo 0,8 di queste due pagine.

Dove si legge

La pagina del 18 novembre 2025 dice che si può misurare in laboratorio e sul campo. Sul campo nomina il rapporto sull'esperienza di Chrome e la libreria web-vitals. In laboratorio nomina il pannello Network degli strumenti di sviluppo di Chrome, e WebPageTest. Non ho aperto WebPageTest. Non ho aperto il pannello su un sito.

La guida del 28 novembre 2025 nomina PageSpeed Insights come un modo per avere campo e laboratorio, per i siti pubblici presenti nel rapporto sull'esperienza di Chrome. Il primo byte delle persone vere, scrive, sta nella sezione in alto su che cosa vivono gli utenti reali. In laboratorio, i problemi di primo byte stanno nell'insight sulla latenza della richiesta del documento. Non ho aperto PageSpeed su un sito. Quella sezione e quell'insight non sono l'audit di Lighthouse che esclude nome e reindirizzamenti. Restano tre posti. Non li unisco.

La stessa pagina della metrica dice che il primo byte si può misurare anche su tutte le richieste, non solo su quella di navigazione. Le risorse su un altro origine possono aggiungere latenza perché bisogna aprire una connessione verso quei server. Una nota dice che CrUX e altri strumenti di misura possono dare il primo byte solo sulla richiesta di navigazione principale. Possono. Non lo trasformo in sempre.

Per le risorse, la pagina avverte che alcune possono avere responseStart uguale a 0, perché la risorsa è in cache, oppure perché una risorsa di un altro origine è servita senza l'header Timing-Allow-Origin. Cache, e header assente, sono due cause nella stessa frase. Uno zero non dimostra che l'origine abbia risposto all'istante. Una frase a parte dice che il primo byte delle richieste verso un altro origine non sarà misurabile con accuratezza sul campo se quei server non impostano Timing-Allow-Origin. Non la unisco alla frase dello zero.

La riga che il server dichiara

La guida del 28 novembre 2025 dice che l'header Server-Timing si può usare nel backend per misurare processi distinti che possono contribuire a una latenza alta. Se misurare così non è praticabile, nomina in alternativa un monitoraggio delle prestazioni dell'applicazione. Non apro quel tema.

Elenca processi a cui fare attenzione, e non dice che l'elenco sia completo. Query verso la base dati. Tempo di disegno lato server, se c'è. Ricerche sul disco. Colpi o mancati della cache sul server di bordo, se si usa una CDN. Sono quattro voci della guida. Non sono la quinta fase della somma, e non sono responseStart. Una durata in quella riga è una dichiarazione del server. Non è il tempo fra l'inizio della navigazione e il primo byte.

La guida dice che, in laboratorio, quei valori si vedono nel pannello Timings della scheda Network, e anche nella traccia Network del pannello Performance. È lì che si legge la riga dichiarata. Non è il posto in cui la pagina della metrica definisce la somma. L'esempio di header della guida ha delle durate. Non le assegno a un sito. Non le copio. Come è fatta la riga, e chi può vederla, sta già sulla pagina Server-Timing. Non la riscrivo.

Una cautela della stessa guida: la cache può mascherare un backend lento, e diagnosticare un primo byte lungo diventa più difficile, perché provare una pagina in cache spesso non mostra problemi di primo byte. Consiglia un modo per saltare la CDN e gli altri strati di cache, per esempio con un parametro nell'indirizzo, così si vede il tempo pieno del server che alcune persone vivono come primo byte. Il parametro è l'esempio della cautela. Non ne scrivo uno. Non l'ho usato su un sito.

Reindirizzamenti, hosting e copie

Il reindirizzamento è la prima fase della somma, sulla pagina della metrica. La guida del 28 novembre 2025 dice che un reindirizzamento può aggiungere latenza, e che una catena, in cui la risposta punta a un'altra risorsa che a sua volta reindirizza, può andare peggio. Un salto, e una catena, restano due frasi. Distingue due tipi. Quelli sulla stessa origine, sul tuo sito. Quelli da un'altra origine, per esempio un servizio che accorcia gli indirizzi, prima di arrivare al sito. Dice di concentrarsi su quelli della stessa origine, perché sono sotto il tuo controllo, e nomina come casi frequenti uno schema mancante e la barra finale dell'indirizzo. Nomina anche le risposte 301 e 302. Non ho cercato queste risposte su un sito.

Un'altra fonte di tempo di reindirizzamento, scrive la guida, può essere il passaggio da HTTP a HTTPS. Nomina l'header Strict-Transport-Security come un modo con cui le visite successive vanno subito allo schema protetto, e nomina anche la lista di preload. La pagina già online su quell'header è un altro argomento. Non la riscrivo, e non ricopio i passi. Perché il browser del visitatore riapre il tuo sito in chiaro.

Sull'hosting, la guida dice di considerarlo per primo, prima delle altre strade, e che non c'è molta guida specifica: la regola generale è che l'host regga il traffico che gli mandi. L'hosting condiviso, scrive, è in genere più lento, e per un sito personale piccolo fatto soprattutto di file statici può andare. Per un'applicazione più grande, con molte persone, personalizzazione, query e altro lavoro intenso lato server, la scelta dell'host diventa critica per abbassare il primo byte sul campo. Sito piccolo, e applicazione grande, restano due casi. Non dà una cifra di memoria. Non ne invento una. Dove vive la macchina sta sulla mappa. Non la riscrivo.

Sulla CDN, la guida dice che un backend anche ben curato può lasciare un primo byte alto sul campo a chi sta lontano dall'origine, e che le copie sui server di bordo stanno più vicino. Poi tiene frasi separate, e non le unisco. I fornitori di solito offrono risoluzioni del nome molto rapide. È probabile che servano il contenuto con protocolli moderni come HTTP/2 o HTTP/3. In una frase sua, HTTP/3 affronta il blocco di testa di linea presente in TCP, su cui poggia HTTP/2, usando UDP. È probabile che forniscano versioni moderne di TLS, il che abbassa la latenza della negoziazione, e TLS 1.3 in particolare è pensato per tenere la negoziazione più corta possibile. La compressione, scrive, è facile da sbagliare da soli e in certi casi può rallentare il markup generato al momento, che va compresso al volo. Queste frasi stanno nella sezione CDN della guida. Non spezzano la voce unica connessione e negoziazione TLS della pagina della metrica in due barre misurate.

Dove stanno il nome, la macchina e le copie è la mappa. Come funziona HTTP/3 è la pagina sul trasporto. Che cosa succede se la pagina si comprime due volte è la pagina sulla compressione. Non le riscrivo. HTTP/3: come funziona e quando può migliorare le prestazioni. Che cosa succede se il tuo sito comprime la pagina due volte.

Esempio ipotetico

bottega.example è un nome di scuola. Non l'ho aperto. Non so se il tempo fino al primo byte, su un suo grafico, è un reindirizzamento, la ricerca del nome, la connessione e il TLS insieme, o l'attesa della risposta. prova.bottega.example è l'altro nome. Non l'ho aperto. Non so se una pagina in cache nasconde un backend lento, né se una riga Server-Timing dichiarerebbe una query, un disegno lato server, una ricerca sul disco o un colpo di cache.

Non assegno a questi nomi 0,8 secondi, 1,8 secondi, un 75° percentile, Chrome 115, Chrome 133, uno zero di responseStart, né una durata della riga del server. I numeri restano quelli delle pagine lette.

Che cosa questa pagina lascia stare

Non ho misurato un sito. Non ho aperto PageSpeed, WebPageTest, Lighthouse né il pannello Network su una pagina vera. Non ho aperto la pagina del First Contentful Paint per copiarne la soglia buona. Non ho scritto un parametro per saltare la cache. La copertina è nuova, perché la pagina è nuova.

Non ho riscritto la pagina su Server-Timing, la mappa di DNS, hosting e CDN, la pagina sulle misure, la pagina sugli spostamenti, la pagina sulla connessione lunga, la pagina sul lavoro lungo, la pagina sulla copia di prova, la pagina sulla chiave, la pagina sulla compressione, la pagina sulla cartella, la pagina su HTTP/3 e la pagina sull'header che riapre il sito in chiaro. Il disco pieno non è questa pagina. Non l'ho scritta.

Fonti lette il 3 novembre 2026. Pagina Time to First Byte, pubblicata il 26 ottobre 2021, ultimo aggiornamento in pagina il 18 novembre 2025, last-modified 28 novembre 2025 alle 08:00:00 GMT, risposta delle 05:40:00 GMT, https://web.dev/articles/ttfb. Guida Optimize Time to First Byte, pubblicata il 19 gennaio 2023, ultimo aggiornamento in pagina il 28 novembre 2025, last-modified 28 novembre 2025 alle 08:00:00 GMT, risposta delle 05:40:01 GMT, https://web.dev/articles/optimize-ttfb. Pagine già online, non riscritte: Server-Timing, la mappa, le misure.