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 è di 800 millisecondi o meno al 75° percentile. Il TTFB non è un Core Web Vital, ma è una metrica diagnostica critica perché influenza direttamente sia il Largest Contentful Paint (LCP) che il First Contentful Paint (FCP).

Cos'è il Time to First Byte

Il Time to First Byte (TTFB) indica quanto tempo è trascorso in millisecondi tra l'inizio della richiesta e la ricezione della prima risposta (byte) da una pagina web. Il TTFB viene quindi anche definito come tempo di attesa. Il TTFB è un modo per misurare la reattività di un server web e il percorso di rete tra l'utente e quel server. Il TTFB è una metrica fondamentale; ciò significa che il tempo aggiunto al TTFB verrà aggiunto anche al Largest Contentful Paint e al First Contentful Paint. Ogni millisecondo risparmiato sul TTFB è un millisecondo risparmiato su entrambe queste metriche di paint.

Il TTFB non è un Core Web Vital

È importante dichiararlo chiaramente: il TTFB non è uno dei tre Core Web Vitals. I Core Web Vitals sono composti da Largest Contentful Paint (LCP), Interaction to Next Paint (INP) e Cumulative Layout Shift (CLS). Google non utilizza direttamente il TTFB nei suoi segnali di ranking della page experience.

Tuttavia, il TTFB è classificato come una metrica diagnostica. Ti aiuta a capire perché il tuo LCP o FCP potrebbe essere lento. Secondo la 2025 Web Almanac, i siti con LCP scarso impiegano in media 2,27 secondi solo per il TTFB, il che esaurisce quasi completamente la soglia di 2,5 secondi del LCP prima ancora che il browser inizi a renderizzare la pagina. Correggere il TTFB è quindi una delle azioni più incisive che puoi intraprendere per i tuoi punteggi Core Web Vitals complessivi.

Perché il Time to First Byte è importante

Il Time to First Byte non è un Core Web Vital ed è molto possibile superare i Core Web Vitals pur non superando la metrica TTFB. Ciò non significa che il TTFB non sia importante. Il TTFB è una metrica estremamente importante da ottimizzare e correggere il TTFB migliorerà notevolmente la velocità della pagina e l'esperienza della pagina.

L'impatto del TTFB per i 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 mostrerà solo uno schermo bianco. Ciò significa che qualsiasi aumento del Time to First Byte risulterà in tempo extra di "schermo bianco" e qualsiasi diminuzione del Time to First Byte si tradurrà in meno tempo di "schermo bianco".

Per ottenere quella sensazione di pagine che si caricano istantaneamente, il Time to First Byte deve essere il più veloce possibile.

Perché il TTFB non è un Core Web Vital? Il TTFB non tiene conto del rendering: un TTFB basso non significa necessariamente una buona esperienza utente perché non considera il tempo necessario al browser per renderizzare la pagina web. Anche se tutti i byte vengono scaricati rapidamente, la pagina web potrebbe comunque impiegare molto tempo per essere visualizzata se il browser deve elaborare molto JavaScript o renderizzare layout complessi.

Qual è un buon punteggio TTFB?

Si raccomanda che il server risponda alle richieste di navigazione abbastanza velocemente affinché il 75° percentile degli utenti sperimenti un FCP entro la soglia "buono". Come linea guida generale, la maggior parte dei siti dovrebbe puntare ad avere un TTFB di 0,8 secondi o meno.

• Un TTFB inferiore a 800 millisecondi è considerato buono.
• Un TTFB tra 800 e 1800 millisecondi necessita di miglioramento.
• Un TTFB superiore a 1800 millisecondi è considerato scarso e dovrebbe essere migliorato immediatamente.

Impatto nel mondo reale: il caso studio T-Mobile

T-Mobile ha investito notevolmente nella riduzione del proprio Time to First Byte come parte di un'iniziativa più ampia di ottimizzazione delle prestazioni. I risultati sono stati impressionanti: un aumento del 60% nelle conversioni da visita a ordine. Passando a pagine renderizzate all'edge e a un caching server-side aggressivo, T-Mobile ha ridotto drasticamente il tempo che gli utenti trascorrevano in attesa del primo byte, il che si è propagato in LCP più veloci, FCP più veloci e un'esperienza utente misurabilmente migliore. Questo caso studio dimostra che l'ottimizzazione del TTFB non è solo un esercizio tecnico; ha un impatto diretto sui risultati aziendali.

Il TTFB dalla richiesta alla risposta

Dal browser al server: la richiesta

Il tempo di richiesta del browser è il tempo trascorso dal momento in cui il browser dell'utente invia una richiesta HTTP fino a quando quella richiesta raggiunge il server che ospita il sito web. Il TTFB di questa parte è in gran parte al di fuori del controllo diretto del sito web e dipende fortemente da:

• La velocità internet dell'utente.
• La qualità della sua infrastruttura di rete.
• La distanza fisica tra l'utente e il server.

In questa fase, la ricerca DNS, il tempo di avvio del browser, le ricerche nella cache del browser e la negoziazione della connessione al server (TCP e TLS) richiedono tutti un po' di tempo.

Sul server: elaborazione e preparazione della risposta

Una volta che il server riceve la richiesta, il tempo scorre mentre lavora per generare una risposta. Questa fase è quella su cui la maggior parte degli sviluppatori tende a concentrarsi e dove gli sforzi di ottimizzazione possono avere l'impatto più significativo. I fattori da considerare includono:

• Capacità del server: Hardware potente (CPU, RAM), software efficiente (server web, database) e configurazioni ottimizzate sono tutti importanti.
• Durata del database: Se la richiesta richiede il recupero di dati da un database, le query lente possono essere un collo di bottiglia importante.
• Ottimizzazione del codice: Codice server-side scritto male (ad es. script inefficienti) può portare a tempi di elaborazione lunghi.
• Strategie di caching: Un caching efficace (come il caching server-side o l'uso di un Content Delivery Network) può ridurre drasticamente il carico di elaborazione per le richieste ripetute.

Ritorno al browser: consegna del primo byte

Dopo l'elaborazione, il server invia la risposta, iniziando con il primo byte, al browser dell'utente.

• Come nella prima fase, le condizioni di rete e la distanza giocano un ruolo anche qui.
• I CDN sono particolarmente utili in questa fase poiché memorizzano nella cache i contenuti più vicino agli utenti, minimizzando il tempo di viaggio.
• I redirect vengono serviti in questo punto, il che fa ripetere il processo con un ritardo aggiuntivo.

Fasi tecniche del Time To First Byte

Similmente al "percorso dalla richiesta alla risposta" nel tuo browser, il Time To First Byte delle richieste di navigazione può essere misurato con la Navigation Timing API e suddiviso in 5 sotto-parti.

1. Tempo di redirect: quando una risorsa è stata spostata in una nuova posizione, il tempo di redirect viene aggiunto al TTFB della risorsa.
2. Tempo di worker e cache: prima che una risorsa venga recuperata da internet, un browser proverà prima a cercarla nella propria cache o tramite un worker (se un worker è stato configurato).
3. Tempo di ricerca DNS: Successivamente un browser potrebbe dover eseguire una ricerca DNS per tradurre il nome di dominio (www.example.com) in un indirizzo IP.
4. Tempo di connessione TCP: Poi il browser si connette al server ed esegue alcuni controlli.
5. Handshake SSL: Quindi il browser e il server criptano la loro comunicazione.
6. Risposta del server: Infine il server deve inviare l'HTML. Potrebbe dover generare prima l'HTML.

Come misurare il Time To First Byte (TTFB)

PageSpeed TIP: ogni risorsa ha il proprio Time to First Byte. In questo contesto tuttavia stiamo parlando del Time to First Byte della pagina principale.

Il Time to First Byte può variare notevolmente tra diversi utenti con diversi dispositivi e da diverse posizioni. Ecco perché misurare autonomamente il Time to First Byte dal tuo computer desktop probabilmente non è una buona idea. Utilizzare strumenti come Pingdom o GTMetrix non è affidabile per lo stesso motivo.

Il modo migliore per misurare il Time To First Byte è raccogliere dati Real User Metrics (RUM) dai tuoi visitatori. Puoi farlo autonomamente con il codice sottostante o utilizzare uno strumento RUM come CoreDash.

Misurare il TTFB con strumenti sintetici

Misurare il TTFB con il tracking RUM

Misurare il TTFB con i dati CrUX

CrUX (Chrome User Experience Report) è un dataset pubblicamente disponibile di Google che contiene dati sulle prestazioni reali dei siti web. Google utilizza il dataset CrUX per determinare se stai superando o meno i Core Web Vitals.

Il dataset CrUX è accessibile tramite strumenti come PageSpeed Insights, la CrUX API, Looker Studio o Google BigQuery. Utilizza uno qualsiasi 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 utilizzare la Navigation Timing API. Puoi creare un PerformanceObserver che ascolta una entry di navigazione e registra la proprietà responseStart nella console. La proprietà responseStart rappresenta il timestamp di quando è stato ricevuto il primo byte della risposta. La libreria JavaScript web-vitals fornisce un modo più conciso per misurare il TTFB nel browser utilizzando la funzione onTTFB.

Il codice sottostante può essere utilizzato 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
});

Trovare i colli di bottiglia con la Server-Timing API

La Server-Timing API fornisce un modo standardizzato per inviare i tempi delle prestazioni del server backend al browser. Utilizzando gli header Server-Timing, gli sviluppatori possono misurare e analizzare efficacemente i componenti server-side che contribuiscono al TTFB, aiutando a identificare le aree di ottimizzazione e migliorando le prestazioni complessive del sito web.

L'header Server-Timing può contenere tempi per più metriche separati da virgole. Ogni voce è composta da:

• Un nome breve per la metrica (come database e processing)
• Una durata in millisecondi (espressa come dur=123)
• Una descrizione opzionale (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 Server-Timing direttamente nel pannello Network. Apri DevTools, seleziona la richiesta del documento nella scheda Network, scorri fino alla sezione "Server Timing" nella scheda Timing. Ogni metrica che invii tramite l'header Server-Timing apparirà con il suo nome, descrizione e durata. Questo rende semplice identificare se il tuo database, il rendering del template o il livello di caching è il collo di bottiglia.

Puoi anche leggere l'header Server-Timing programmaticamente e inviare questi tempi al tuo strumento RUM preferito come CoreDash per il monitoraggio a lungo termine e gli avvisi.

Velocizzare il TTFB con 103 Early Hints

103 Early Hints è un codice di stato HTTP che permette al server di inviare header di risposta preliminari al browser prima che la risposta finale sia pronta. Mentre il server sta ancora elaborando la richiesta (interrogando il database, renderizzando il template), il browser può già iniziare a caricare risorse critiche come fogli di stile, font e l'immagine LCP.

Come funzionano i 103 Early Hints

In un flusso di richiesta tradizionale, il browser resta inattivo durante l'intero tempo di elaborazione del server. Con 103 Early Hints, il server invia una risposta parziale immediatamente dopo aver ricevuto la richiesta. Questa risposta parziale contiene header Link che indicano al browser quali risorse precaricare o a quali effettuare il preconnect. Il browser agisce su questi suggerimenti mentre attende la risposta completa 200.

Questo trasforma efficacemente il tempo di attesa morto in tempo di caricamento produttivo. Sebbene i 103 Early Hints non riducano il TTFB del documento stesso, riducono l'impatto percepito del TTFB sulle metriche successive come LCP e FCP dando al browser un vantaggio nella scoperta delle risorse.

Esempio di configurazione del server per 103 Early Hints

Molti CDN e server web ora supportano i 103 Early Hints. Ecco un esempio usando Cloudflare, che genera automaticamente 103 Early Hints dagli header Link e dai tag preload/preconnect trovati nel tuo 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
...

Per Nginx, puoi configurare Early Hints aggiungendo header Link alla tua risposta e abilitando HTTP/2 o HTTP/3 push. Apache supporta 103 Early Hints tramite la direttiva H2EarlyHints. Consulta la nostra guida dettagliata sull'implementazione dei 103 Early Hints per istruzioni passo dopo passo.

Eliminare il TTFB con la Speculation Rules API

La Speculation Rules API è progettata per migliorare le prestazioni per le navigazioni future. Una volta che un visitatore è atterrato sulla tua pagina, puoi usare le Speculation Rules per istruire un browser a recuperare (con la direttiva prefetch) o anche a renderizzare completamente (con la direttiva prerender) le pagine che il visitatore è più probabile che visiti successivamente.

Come le Speculation Rules eliminano il TTFB

Quando una pagina viene prerenderizzata, il browser la carica e la renderizza completamente in una scheda nascosta. Quando l'utente clicca poi sul link, la pagina prerenderizzata viene inserita istantaneamente. Il risultato: un TTFB misurato di 0 millisecondi. Questo non è un numero teorico. I dati RUM di CoreDash da corewebvitals.io confermano che le navigazioni prerenderizzate tramite Speculation Rules mostrano un TTFB p75 di 0ms.

Il prefetching è un'alternativa più leggera. Invece di renderizzare completamente la pagina, il browser recupera solo il documento HTML e lo memorizza nella cache. Questo elimina la parte di rete del TTFB pur richiedendo al browser di parsare e renderizzare il documento al momento della navigazione.

Sintassi JSON delle Speculation Rules

Le Speculation Rules sono definite usando un blocco <script type="speculationrules"> contenente JSON. Ecco un esempio che prerenderizza tutti i link di navigazione nella barra del menu con eagerness "moderate" (attivato al passaggio del mouse o al pointer down):

<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 crescita. Chrome 121+ supporta l'API completa incluse le document rules. Per i browser che non supportano ancora le Speculation Rules, potresti usare uno script leggero come quicklink come fallback. Usa il nostro generatore di Speculation Rules per creare la configurazione giusta per il tuo sito.

Come l'hosting influisce sul Time to First Byte?

L'hosting influisce sul Time to First Byte in molteplici modi. Investendo in un hosting migliore è solitamente possibile migliorare immediatamente il Time to First Byte senza cambiare nient'altro. Soprattutto quando si passa da hosting condiviso economico a server virtuali correttamente configurati e gestiti, il TTFB potrebbe migliorare drasticamente.

Hosting TIP: un hosting migliore comporta un'elaborazione più veloce, una migliore velocità di rete e più memoria del server più veloce. Un hosting costoso non equivale sempre a un hosting migliore. Molti upgrade sugli hosting condivisi ti danno solo più spazio di archiviazione, non più potenza CPU.

Non consiglio di cambiare hosting senza conoscere le cause principali dei problemi di TTFB. Ti consiglio di impostare il tracking RUM e aggiungere gli header Server-Timing.

Quando fai l'upgrade del tuo hosting dovresti generalmente cercare almeno uno di questi tre miglioramenti:

• Più risorse (CPU + RAM): Soprattutto quando il server impiega troppo tempo per generare l'HTML dinamico.
• DNS più veloce: Molti provider di hosting economico sono noti per le loro scarse prestazioni DNS.
• Configurazione migliore: Cerca cipher SSL più veloci, HTTP/3, compressione Brotli e accesso alla configurazione del server web (per disabilitare i moduli non necessari) per citarne alcuni.

Come migliorare il TTFB: velocizzare la connessione iniziale

Un Time to First Byte alto può avere molteplici cause. Tuttavia DNS, TCP e SSL influiscono su tutti i Time to First Byte. Quindi iniziamo da lì. Anche se l'ottimizzazione di questi tre potrebbe non produrre i risultati più grandi, ottimizzarli ottimizzerà ogni singolo TTFB.

Velocizzare il DNS

PageSpeed TIP: DNS, TCP e SSL sono solitamente un problema maggiore quando si utilizza un hosting economico o quando si serve un pubblico globale senza utilizzare un CDN. Usa il tracking RUM per visualizzare il tuo TTFB globale e scomporre il TTFB nelle sue sotto-parti.

Usa un provider DNS veloce. Non tutti i provider DNS sono ugualmente veloci. Alcuni provider DNS (gratuiti) sono semplicemente più lenti di altri provider DNS (gratuiti). Cloudflare ad esempio ti darà uno dei provider DNS più veloci al mondo gratuitamente.

Aumenta il TTL del DNS. Un altro modo è aumentare il valore Time to Live (TTL). Il TTL è un'impostazione che determina per quanto tempo la ricerca può essere memorizzata nella cache. Più alto è il TTL, meno probabile è che il browser debba eseguire un'altra ricerca DNS. È importante notare che anche gli ISP memorizzano nella cache il DNS.

Velocizzare il TCP

La "parte TCP" del TTFB è la connessione iniziale al server web. Durante la connessione, il browser e il server condividono informazioni su come i dati verranno scambiati. Puoi velocizzare il TCP connettendoti a un server geograficamente vicino alla tua posizione e assicurandoti che il server abbia risorse libere sufficienti. A volte passare a un server leggero come NGINX può velocizzare la parte TCP del TTFB. In molti casi l'uso di un CDN velocizzerà la connessione TCP.

Velocizzare SSL/TLS

Una volta stabilita la connessione TCP, il browser e il server dovranno proteggere la connessione tramite crittografia. Puoi velocizzare questo processo usando protocolli più veloci, più nuovi e più leggeri (cipher SSL) e essendo geograficamente più vicino al tuo server web (poiché la negoziazione TLS richiede diversi scambi di andata e ritorno). L'uso di un CDN spesso migliorerà il tempo di connessione SSL poiché i CDN sono spesso molto ben configurati e hanno più server 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

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

Esistono anche molti plugin per diversi sistemi CMS che memorizzano nella cache pagine intere e molti framework SPA come Next.js hanno la propria implementazione del caching completo della pagina insieme a diverse strategie di invalidazione.

Se desideri implementare il tuo caching, l'idea di base è semplice. Quando un client richiede una pagina, controlla se esiste nella cartella cache. Se non esiste, crea la pagina, scrivila nella cache e mostra la pagina come faresti normalmente. Alla prossima richiesta della pagina il file di cache esisterà e potrai servire la pagina direttamente dalla cache.

Caching parziale

Con il caching parziale l'idea è di memorizzare nella cache parti della pagina o risorse utilizzate frequentemente, lente o costose (come chiamate API, risultati del database) per un recupero rapido. Questo eliminerà i colli di bottiglia nella generazione di una pagina. Se sei interessato a questo tipo di ottimizzazioni dovresti cercare 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 dalla cache (parziale) perché il file di cache non esiste, grandi parti delle pagine sono dinamiche o perché si incontrano altri problemi. Ecco perché dobbiamo ottimizzare il codice dell'applicazione. Come questo viene fatto dipende interamente dalla tua applicazione. Si basa sulla riscrittura e ottimizzazione delle parti lente del tuo codice.

Ottimizzare le query del database

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

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. Questo solitamente accade solo con siti di grandi dimensioni che hanno esternalizzato il loro storage dei dati verso API cloud.

Come migliorare il TTFB: velocizzare il lato client

Caching lato client

Il caching lato client comporta che il browser dell'utente memorizzi le risorse a cui ha già avuto accesso, come immagini e script. Così quando l'utente torna sul tuo sito web, il browser può recuperare rapidamente le risorse memorizzate nella cache invece di doverle scaricare di nuovo. Questo può ridurre significativamente il numero di richieste fatte al server, il che a sua volta può ridurre il TTFB.

Per implementare il caching lato client, puoi usare l'header HTTP Cache-Control. Questo header ti permette di specificare per quanto tempo il browser dovrebbe memorizzare nella cache una particolare risorsa.

Potresti considerare di memorizzare completamente nella cache l'HTML della pagina sul lato client. Questo ridurrà drasticamente il TTFB poiché non è necessaria alcuna richiesta al server. Lo svantaggio è che una volta che la pagina è nella cache del browser, eventuali aggiornamenti sulla versione live della pagina non saranno visti dall'utente fino alla scadenza della cache della pagina.

Service Workers

I service workers sono script che vengono eseguiti in background nel browser dell'utente e possono intercettare le richieste di rete fatte dal browser. Ciò significa che i service workers possono memorizzare nella cache risorse come HTML, immagini, script e fogli di stile, così che quando l'utente torna sul tuo sito web, il browser può recuperare rapidamente le risorse memorizzate nella cache invece di doverle scaricare di nuovo.

Page Prefetching

Se non vuoi usare la Speculation Rules API a causa del suo limitato supporto dei browser, potresti usare un piccolo script chiamato quicklink. Questo effettuerà il prefetch di tutti i link nel viewport visibile e eliminerà quasi completamente il Time To First Byte per questi link.

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

Come migliorare il TTFB: usare un CDN

Un Content Delivery Network o CDN utilizza una rete distribuita di server per consegnare risorse agli utenti. Questi server sono solitamente geograficamente più vicini agli utenti finali e altamente ottimizzati per la velocità. Se stai usando Cloudflare, consulta la nostra guida su come configurare Cloudflare per prestazioni ottimali dei Core Web Vitals.

Un CDN può aiutare a migliorare 5 delle 6 parti del Time to First Byte:

• Tempo di redirect: La maggior parte dei CDN può memorizzare nella cache i redirect sull'edge o usare edge worker per gestire i redirect senza la necessità di connettersi al server di origine.
• Tempo di ricerca DNS: La maggior parte dei CDN offre server DNS estremamente veloci che probabilmente supereranno i tuoi server DNS attuali.
• Tempo di connessione TCP e handshake SSL: La maggior parte dei CDN è configurata in modo estremamente ottimale e queste configurazioni, insieme alla maggiore vicinanza agli utenti finali, velocizzeranno i tempi di connessione e handshake.
• Risposta del server: I CDN possono velocizzare il tempo di risposta del server in diversi modi. Il primo è memorizzando nella cache 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 di redirect viene aggiunto al Time To First Byte. Pertanto, come regola generale, evita i redirect il più possibile. I redirect possono verificarsi quando una risorsa non è più disponibile in una posizione ma è stata spostata in un'altra. Il server risponderà con un header di risposta redirect e il browser proverà quella nuova posizione.

Redirect same-origin. I redirect same-origin provengono da link sul tuo stesso sito web. Dovresti avere il pieno controllo su questi link e dovresti dare priorità alla correzione di questi link quando lavori sul Time to First Byte. Ci sono molti strumenti là fuori che ti permetteranno di controllare l'intero sito web per i redirect.

Redirect cross-origin. I redirect cross-origin provengono da link su altri siti web. Hai pochissimo controllo su questi.

Redirect multipli. I redirect multipli o le catene di redirect si verificano quando un singolo redirect non reindirizza alla posizione finale della risorsa. Questi tipi di redirect mettono più pressione sul Time to First Byte e dovrebbero essere evitati a tutti i costi. Ancora una volta, usa uno strumento per trovare questi tipi di redirect e correggerli.

Redirect HTTP-to-HTTPS. Un modo per aggirare questo è usare l'header Strict-Transport-Security (HSTS), che imporrà HTTPS alla prima visita a un'origine, e poi dirà al browser di accedere immediatamente all'origine tramite lo schema HTTPS nelle visite future.

Quando un utente richiede una pagina web, il server potrebbe rispondere con un redirect a un'altra pagina. Questo redirect può aggiungere tempo aggiuntivo al TTFB perché il browser deve fare una richiesta aggiuntiva alla nuova pagina.

Ci sono diversi modi per evitare i redirect o minimizzare l'impatto dei redirect:

1. Aggiorna i tuoi link interni. Ogni volta che cambi la posizione di una pagina, aggiorna i tuoi link interni a quella pagina per assicurarti che non rimangano riferimenti alla posizione precedente della pagina.
2. Gestisci i redirect a livello di server.
3. Usa URL relativi: Quando crei link a pagine sul tuo stesso sito web, usa URL relativi invece di URL assoluti. Questo aiuterà a prevenire redirect non necessari.
4. Usa URL canonici: Se hai più pagine con contenuti simili, usa un URL canonico per indicare la versione preferita della pagina. Questo aiuterà a prevenire contenuti duplicati e redirect non necessari.
5. Usa redirect 301: Se devi usare un redirect, usa un redirect 301 invece di un redirect 302. Un redirect 301 è un redirect permanente, mentre un redirect 302 è un redirect temporaneo. Usare un redirect 301 aiuterà a prevenire redirect non necessari.

Ottimizzare la priorità delle risorse insieme al TTFB

Ridurre il TTFB è solo una parte della storia delle prestazioni di caricamento. Una volta che il primo byte arriva, il browser deve sapere quali risorse dare la priorità. Leggi la nostra guida alla priorità delle risorse per scoprire come gli hint fetchpriority, preload e preconnect lavorano insieme a un TTFB veloce per ottenere i caricamenti di pagina più rapidi possibili. Inoltre, considera di ospitare autonomamente i tuoi Google Fonts per eliminare le ricerche DNS di terze parti e i tempi di connessione che si aggiungono al TTFB percepito dai tuoi utenti.

Cosa mostrano i dati TTFB reali

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

La variazione geografica è enorme

Il TTFB varia drasticamente in base alla distanza fisica tra l'utente e il server. I dati di CoreDash da corewebvitals.io (ospitato in Europa) illustrano questo chiaramente:

Gli utenti europei vicini al server vedono un TTFB inferiore a 170ms, mentre gli utenti in India sperimentano un TTFB 3 volte superiore e gli utenti in Cina vedono un TTFB quasi 10 volte superiore (1.468ms) a causa del Great Firewall e della pura distanza fisica. Questi dati dimostrano perché un CDN con posizioni edge globali è essenziale per il pubblico internazionale.

Le Speculation Rules con prerender offrono 0ms di TTFB

I dati sul tipo di navigazione di CoreDash confermano che le pagine prerenderizzate tramite Speculation Rules raggiungono un TTFB p75 di 0 millisecondi. Le navigazioni standard misurano 131ms, i reload arrivano a 82ms (beneficiando di connessioni calde) e le navigazioni back-forward sono le più lente a 244ms. Questo rende le Speculation Rules la tecnica singola più efficace per eliminare il TTFB nei caricamenti di pagina successivi.

Il TTFB mobile è 2,5 volte quello desktop

Su corewebvitals.io, gli utenti mobile sperimentano un TTFB p75 di 316ms rispetto a 124ms su desktop. Questo divario di 2,5 volte è causato dalla latenza della rete mobile, non da differenze del server. Solo l'88,5% dei caricamenti di pagina mobile raggiunge un rating TTFB "buono" rispetto al 96,1% su desktop. Quando ottimizzi per il TTFB, testa sempre su reti mobile reali.

Visitatori nuovi vs. di ritorno vedono un TTFB simile

Su questo sito, i nuovi visitatori vedono un TTFB p75 di 127ms mentre i visitatori di ritorno vedono 138ms. La somiglianza suggerisce che il caching server-side consistente (piuttosto che i vantaggi della cache lato client) è il fattore primario nelle prestazioni TTFB. Sui siti senza caching server-side, il divario tra visitatori nuovi e di ritorno può essere molto più grande.

Il TTFB globale è stagnante da 5 anni

Secondo la 2025 Web Almanac, solo il 44% delle pagine mobile raggiunge globalmente un punteggio TTFB "buono". Questo numero è appena cambiato rispetto al 41% del 2021, rendendo il TTFB la metrica di prestazione più stagnante del web. Nel frattempo, LCP è migliorato dal 44% al 59% e INP dal 55% al 74% nello stesso periodo. I siti con LCP scarso spendono in media 2,27 secondi solo per il TTFB, quasi l'intera soglia di 2,5 secondi del LCP.

Guide correlate: sotto-parti del TTFB

Ogni sotto-parte del Time to First Byte ha le proprie strategie di ottimizzazione:

• <b>Risolvere e identificare i problemi di TTFB</b>: Una guida diagnostica passo dopo passo per trovare la causa principale di un TTFB lento usando DevTools, Server-Timing e dati RUM.
• <b>Ridurre la durata di attesa</b>: Come minimizzare il tempo di redirect e i ritardi di elaborazione del server che si aggiungono al tuo TTFB.
• <b>Ridurre la durata della cache</b>: Strategie per il caching del browser, i service workers e la back/forward cache (bfcache) per eliminare il TTFB per i visitatori di ritorno.
• <b>Minimizzare la durata DNS</b>: Come velocizzare la risoluzione DNS con provider DNS più veloci, valori TTL aumentati e hint di risorse dns-prefetch.
• <b>Ottimizzare la durata della connessione (TCP + TLS)</b>: Ridurre il tempo di handshake TCP e TLS con HTTP/3, TLS 1.3, ripresa della sessione e hint preconnect.