Scopri come ottimizzare la metrica Time to First Byte.
Pubblicazione: 19 gennaio 2023, ultimo aggiornamento: 28 novembre 2025
Il Time to First Byte (TTFB) è una metrica fondamentale sul rendimento web che precede ogni altra metrica significativa dell'esperienza utente, come First Contentful Paint (FCP) e Largest Contentful Paint (LCP). Ciò significa che valori TTFB elevati aggiungono tempo alle metriche successive.
Ti consigliamo di fare in modo che il tuo server risponda alle richieste di navigazione abbastanza rapidamente da consentire al 75° percentile degli utenti di riscontrare un FCP entro la soglia "buona". In linea di massima, la maggior parte dei siti dovrebbe cercare di avere un TTFB di 0,8 secondi o meno.
Come misurare il TTFB
Prima di poter ottimizzare il TTFB, devi osservare l'impatto che ha sugli utenti del tuo sito web. Devi fare affidamento sui dati dei campi come fonte principale per osservare il TTFB, in quanto è influenzato dai reindirizzamenti, mentre gli strumenti basati su lab vengono spesso misurati utilizzando l'URL finale, quindi non tengono conto di questo ritardo aggiuntivo.
PageSpeed Insights è un modo per ottenere informazioni sia sul campo che di laboratorio per i siti web pubblici disponibili nel Chrome User Experience Report.
Il TTFB per gli utenti reali viene mostrato nella sezione in alto Scopri l'esperienza degli utenti reali:
Per i dati di lab, i problemi relativi al TTFB vengono mostrati nell'insight Latenza di richiesta di download del documento:
Per scoprire altri modi per misurare il TTFB sia sul campo che in laboratorio, consulta la pagina della metrica TTFB.
Comprendi le differenze tra TTFB sul campo e in laboratorio
Il TTFB di laboratorio e quello sul campo possono differire per una serie di motivi e, quando ciò accade, è importante capire il perché per poter utilizzare efficacemente i dati di laboratorio per migliorare le esperienze utente.
Quando il TTFB di laboratorio è molto più elevato del TTFB sul campo, significa che l'ambiente di laboratorio è più limitato rispetto alle esperienze utente tipiche. Questo non è necessariamente un problema, in quanto i risultati e i consigli del lab sono ancora validi, ma potrebbero esagerare l'impatto e il miglioramento.
Quando il TTFB sul campo è molto più grande del TTFB di laboratorio, ciò indica problemi che non sono evidenti nell'esecuzione di laboratorio, come l'utilizzo della memorizzazione nella cache lato server, i reindirizzamenti o le differenze di rete. In questo caso, i risultati e i consigli del lab potrebbero essere meno utili, in quanto non tengono conto di uno dei problemi principali.
Per verificare se la memorizzazione nella cache lato server influisce sul TTFB di laboratorio, prova a testare pagine meno comuni o a utilizzare parametri URL diversi per ottenere contenuti non memorizzati nella cache e verificare se il TTFB è più in linea con il TTFB sul campo. Può anche essere utile avere la possibilità di bypassare la memorizzazione nella cache lato server con un particolare parametro URL. Consulta la sezione sui contenuti memorizzati nella cache.
Per i reindirizzamenti e le differenze di rete, l'analisi del modo in cui il traffico arriva al nostro sito e della sua provenienza può essere utile per diagnosticare se si tratta di potenziali problemi.
Esegui il debug di un TTFB elevato sul campo con Server-Timing
L'intestazione della risposta Server-Timing può essere utilizzata nel backend dell'applicazione per misurare processi di backend distinti che potrebbero contribuire a una latenza elevata. La struttura del valore dell'intestazione è flessibile e accetta, come minimo, un handle definito da te. I valori facoltativi includono un valore di durata (tramite dur) e una descrizione facoltativa leggibile (tramite desc).
Serving-Timing può essere utilizzato per misurare molti processi di backend delle applicazioni, ma ce ne sono alcuni a cui potresti voler prestare particolare attenzione:
- Query di database
- Tempo di rendering lato server, se applicabile
- Ricerche su disco
- Successi o fallimenti della cache del server perimetrale (se utilizzi una CDN)
Tutte le parti di una voce Server-Timing sono separate da due punti e più voci possono essere separate da una virgola:
// Two metrics with descriptions and values
Server-Timing: db;desc="Database";dur=121.3, ssr;desc="Server-side Rendering";dur=212.2
L'intestazione può essere impostata utilizzando il linguaggio scelto per il backend dell'applicazione. In PHP, ad esempio, puoi impostare l'intestazione in questo modo:
<?php
// Get a high-resolution timestamp before
// the database query is performed:
$dbReadStartTime = hrtime(true);
// Perform a database query and get results...
// ...
// Get a high-resolution timestamp after
// the database query is performed:
$dbReadEndTime = hrtime(true);
// Get the total time, converting nanoseconds to
// milliseconds (or whatever granularity you need):
$dbReadTotalTime = ($dbReadEndTime - $dbReadStartTime) / 1e+6;
// Set the Server-Timing header:
header('Server-Timing: db;desc="Database";dur=' . $dbReadTotalTime);
?>
Quando questa intestazione è impostata, vengono mostrate informazioni che puoi utilizzare sia in laboratorio che sul campo.
Nel campo, qualsiasi pagina con un'intestazione della risposta Server-Timing impostata compila la proprietà serverTiming nell'API Navigation Timing:
// Get the serverTiming entry for the first navigation request:
performance.getEntries('navigation')[0].serverTiming.forEach(entry => {
// Log the server timing data:
console.log(entry.name, entry.description, entry.duration);
});
In laboratorio, i dati dell'intestazione della risposta Server-Timing vengono visualizzati nel riquadro Tempi della scheda Rete in Chrome DevTools:
In questo caso, Server-Timing viene utilizzato per misurare se una richiesta di una risorsa ha raggiunto la cache CDN e quanto tempo impiega la richiesta per raggiungere l'edge server della CDN e poi l'origine.
Le tempistiche del server vengono visualizzate anche nella traccia Rete del riquadro Prestazioni di Chrome DevTools:
Una volta stabilito che il TTFB è problematico analizzando i dati disponibili, puoi procedere alla risoluzione del problema.
Modi per ottimizzare il TTFB
L'aspetto più difficile dell'ottimizzazione del TTFB è che, mentre lo stack frontend del web è sempre HTML, CSS e JavaScript, gli stack backend possono variare in modo significativo. Esistono numerosi stack di backend e prodotti di database, ognuno con le proprie tecniche di ottimizzazione. Pertanto, questa guida si concentra su ciò che si applica alla maggior parte delle architetture, anziché concentrarsi esclusivamente su indicazioni specifiche per lo stack.
Indicazioni specifiche per la piattaforma
La piattaforma che utilizzi per il tuo sito web può influire notevolmente sul TTFB. Ad esempio, le prestazioni di WordPress sono influenzate dal numero e dalla qualità dei plug-in o dai temi utilizzati. Altre piattaforme sono interessate in modo simile quando la piattaforma è personalizzata. Consulta la documentazione della tua piattaforma per consigli specifici del fornitore che integrino i consigli più generali sulle prestazioni contenuti in questo post. L'insight di Lighthouse include anche alcune indicazioni specifiche per lo stack.
Hosting, hosting, hosting
Prima ancora di prendere in considerazione altri approcci di ottimizzazione, l'hosting dovrebbe essere la prima cosa da considerare. Non ci sono molte indicazioni specifiche che possiamo offrire in questo caso, ma una regola generale è assicurarsi che l'host del tuo sito web sia in grado di gestire il traffico che gli invii.
L'hosting condiviso è generalmente più lento. Se gestisci un piccolo sito web personale che pubblica principalmente file statici, probabilmente non è un problema. Utilizza alcune delle tecniche di ottimizzazione riportate di seguito per ridurre il più possibile il TTFB.
Tuttavia, se esegui un'applicazione più grande con molti utenti che prevede la personalizzazione, l'esecuzione di query sul database e altre operazioni intensive lato server, la scelta dell'hosting diventa fondamentale per ridurre il TTFB sul campo.
Ecco alcuni aspetti da tenere presente quando scegli un provider host:
- Quanta memoria è allocata per l'istanza dell'applicazione? Se la tua applicazione non dispone di memoria sufficiente, si verificherà un sovraccarico e farà fatica a pubblicare le pagine il più velocemente possibile.
- Il tuo provider host mantiene aggiornato lo stack di backend? Man mano che vengono rilasciate nuove versioni dei linguaggi di backend delle applicazioni, delle implementazioni HTTP e del software di database, le prestazioni di questo software migliorano nel tempo. È fondamentale collaborare con un provider host che dia priorità a questo tipo di manutenzione cruciale.
- Se hai requisiti molto specifici per l'applicazione e vuoi un accesso di livello più basso ai file di configurazione del server, chiedi se ha senso personalizzare il backend della tua istanza dell'applicazione.
Esistono molti provider host che si occupano di questi aspetti per te, ma se inizi a osservare valori TTFB elevati anche con provider host dedicati, potrebbe essere un segnale che devi rivalutare le funzionalità del tuo attuale provider host per offrire la migliore esperienza utente possibile.
Utilizza una rete CDN (Content Delivery Network)
L'argomento Utilizzo della CDN è molto discusso, ma per un buon motivo: potresti avere un backend dell'applicazione molto ben ottimizzato, ma gli utenti che si trovano lontano dal server di origine potrebbero comunque riscontrare un TTFB elevato sul campo.
Le CDN risolvono il problema della vicinanza degli utenti al server di origine utilizzando una rete distribuita di server che memorizzano nella cache le risorse su server fisicamente più vicini agli utenti. Questi server sono chiamati edge server.
I provider CDN possono anche offrire vantaggi che vanno oltre i server perimetrali:
- I provider CDN di solito offrono tempi di risoluzione DNS estremamente rapidi.
- Una CDN probabilmente fornisce i tuoi contenuti da server perimetrali utilizzando protocolli moderni come HTTP/2 o HTTP/3.
- HTTP/3 in particolare risolve il problema del blocco head-of-line presente in TCP (su cui si basa HTTP/2) utilizzando il protocollo UDP.
- Una CDN probabilmente fornisce versioni moderne di TLS, il che riduce la latenza coinvolta nel tempo di negoziazione TLS. TLS 1.3, in particolare, è progettato per mantenere la negoziazione TLS il più breve possibile.
- Alcuni provider CDN offrono una funzionalità spesso chiamata "edge worker", che utilizza un'API simile a quella dell'API Service Worker per intercettare le richieste, gestire in modo programmatico le risposte nelle cache perimetrali o riscrivere completamente le risposte.
- I provider CDN sono molto bravi a ottimizzare la compressione. La compressione è difficile da eseguire correttamente in autonomia e, in alcuni casi, può comportare tempi di risposta più lenti con il markup generato dinamicamente, che deve essere compresso al volo.
- Inoltre, i provider CDN memorizzano automaticamente nella cache le risposte compresse per le risorse statiche, ottenendo la migliore combinazione di rapporto di compressione e tempo di risposta.
Sebbene l'adozione di una CDN comporti un impegno variabile, da minimo a significativo, se il tuo sito web non ne utilizza già una, l'adozione di una CDN dovrebbe essere una priorità assoluta per ottimizzare il TTFB.
Utilizza i contenuti memorizzati nella cache, se possibile
Le CDN consentono di memorizzare nella cache i contenuti sui server perimetrali che si trovano fisicamente più vicini ai visitatori, a condizione che i contenuti siano configurati con le intestazioni HTTP Cache-Control appropriate. Sebbene questo non sia appropriato per i contenuti personalizzati, richiedere un percorso completo fino all'origine può annullare gran parte del valore di una CDN.
Per i siti che aggiornano di frequente i propri contenuti, anche un breve periodo di memorizzazione nella cache può comportare un notevole aumento delle prestazioni per i siti con un traffico elevato, poiché solo il primo visitatore durante quel periodo sperimenta la latenza completa fino al server di origine, mentre tutti gli altri visitatori possono riutilizzare la risorsa memorizzata nella cache dal server perimetrale. Alcune CDN consentono l'annullamento della convalida della cache nelle release del sito, offrendo il meglio di entrambi i mondi: tempi di memorizzazione nella cache lunghi, ma aggiornamenti istantanei quando necessario.
Anche se la memorizzazione nella cache è configurata correttamente, questa può essere ignorata tramite l'utilizzo di parametri di stringa di query univoci per la misurazione di Analytics. Questi parametri potrebbero sembrare contenuti diversi per la CDN, anche se sono uguali, pertanto la versione memorizzata nella cache non verrà utilizzata.
Inoltre, i contenuti meno recenti o meno visitati potrebbero non essere memorizzati nella cache, il che può comportare valori TTFB più elevati su alcune pagine rispetto ad altre. L'aumento dei tempi di memorizzazione nella cache può ridurre l'impatto di questo problema, ma tieni presente che con l'aumento dei tempi di memorizzazione nella cache aumenta la possibilità di pubblicare contenuti potenzialmente obsoleti.
L'impatto dei contenuti memorizzati nella cache non riguarda solo chi utilizza le CDN. L'infrastruttura del server potrebbe dover generare contenuti da ricerche di database costose quando i contenuti memorizzati nella cache non possono essere riutilizzati. I dati ad accesso più frequente o le pagine pre-memorizzate nella cache spesso possono avere un rendimento migliore.
Evita i reindirizzamenti tra più pagine
Un fattore comune che contribuisce a un TTFB elevato sono i reindirizzamenti. I reindirizzamenti si verificano quando una richiesta di navigazione per un documento riceve una risposta che informa il browser che la risorsa esiste in un'altra posizione. Un reindirizzamento può sicuramente aggiungere latenza indesiderata a una richiesta di navigazione, ma la situazione può peggiorare se il reindirizzamento rimanda a un'altra risorsa che genera un altro reindirizzamento e così via. Ciò può influire in particolare sui siti che ricevono un volume elevato di visitatori da annunci o newsletter, poiché spesso vengono reindirizzati tramite servizi di analisi per scopi di misurazione. Eliminare i reindirizzamenti sotto il tuo controllo diretto può aiutarti a ottenere un buon TTFB.
Esistono due tipi di reindirizzamenti:
- Reindirizzamenti della stessa origine, in cui il reindirizzamento avviene interamente sul tuo sito web.
- Reindirizzamenti multiorigine, in cui il reindirizzamento avviene inizialmente su un'altra origine, ad esempio da un servizio di abbreviazione URL di un social media, prima di arrivare al tuo sito web.
Concentrati sull'eliminazione dei reindirizzamenti della stessa origine, poiché si tratta di un aspetto su cui hai il controllo diretto. Ciò comporta il controllo dei link sul tuo sito web per verificare se qualcuno di questi genera un codice di risposta 302 o 301. Spesso questo può essere il risultato della mancata inclusione dello schema https:// (per cui i browser utilizzano per impostazione predefinita http://, che poi reindirizza) o del fatto che le barre finali non sono incluse o escluse in modo appropriato nell'URL.
I reindirizzamenti multiorigine sono più complessi, in quanto spesso non sono sotto il tuo controllo, ma cerca di evitare reindirizzamenti multipli, se possibile, ad esempio utilizzando più abbreviazioni di link quando condividi i link. Assicurati che l'URL fornito agli inserzionisti o alle newsletter sia l'URL finale corretto, in modo da non aggiungere un altro reindirizzamento a quelli utilizzati da questi servizi.
Un'altra importante fonte di tempo di reindirizzamento può essere rappresentata dai reindirizzamenti da HTTP a HTTPS. Un modo per aggirare questo problema è utilizzare l'intestazione Strict-Transport-Security (HSTS), che applica HTTPS alla prima visita a un'origine e poi indica al browser di accedere immediatamente all'origine tramite lo schema HTTPS nelle visite future.
Una volta implementata una buona policy HSTS, puoi velocizzare le operazioni alla prima visita a un'origine aggiungendo il tuo sito all'elenco di precaricamento HSTS.
Esegui lo streaming del markup nel browser
I browser sono ottimizzati per elaborare il markup in modo efficiente quando viene trasmesso in streaming, il che significa che il markup viene gestito in blocchi man mano che arriva dal server. Questo è fondamentale quando si tratta di payload di markup di grandi dimensioni, in quanto significa che il browser può analizzare i blocchi di markup in modo incrementale, anziché attendere l'arrivo dell'intera risposta prima di poter iniziare l'analisi.
Sebbene i browser siano ottimi nella gestione del markup in streaming, è fondamentale fare tutto il possibile per mantenere il flusso in modo che i primi bit di markup siano in arrivo il prima possibile. Se il backend sta rallentando le cose, questo è un problema. Poiché gli stack di backend sono numerosi, non rientra nell'ambito di questa guida trattare ogni singolo stack e i problemi che potrebbero sorgere in ciascuno di essi.
React, ad esempio, e altri framework in grado di eseguire il rendering del markup on demand sul server hanno utilizzato un approccio sincrono al rendering lato server. Tuttavia, le versioni più recenti di React hanno implementato metodi server per lo streaming del markup durante il rendering. Ciò significa che non devi attendere che un metodo API del server React esegua il rendering dell'intera risposta prima che venga inviata.
Un altro modo per garantire che il markup venga trasmesso rapidamente al browser è affidarsi al rendering statico, che genera file HTML durante la fase di build. Con il file completo disponibile immediatamente, i server web possono iniziare a inviare il file immediatamente e la natura intrinseca di HTTP genera un markup di streaming. Sebbene questo approccio non sia adatto a tutte le pagine di ogni sito web, ad esempio quelle che richiedono una risposta dinamica nell'ambito dell'esperienza utente, può essere utile per le pagine che non richiedono la personalizzazione del markup per un utente specifico.
Utilizza un service worker
L'API Service Worker può avere un impatto significativo sul TTFB sia per i documenti sia per le risorse che caricano. Questo perché un service worker funge da proxy tra il browser e il server, ma l'impatto sul TTFB del tuo sito web dipende da come configuri il service worker e se questa configurazione è in linea con i requisiti della tua applicazione.
- Utilizza una strategia stale-while-revalidate per gli asset. Se un asset si trova nella cache del service worker, che si tratti di un documento o di una risorsa richiesta dal documento, la strategia stale-while-revalidate fornisce la risorsa dalla cache prima, poi scarica l'asset in background e lo fornisce dalla cache per le interazioni future.
- Se hai risorse di documenti che non cambiano molto spesso, l'utilizzo di una strategia stale-while-revalidate può rendere il TTFB di una pagina quasi istantaneo. Tuttavia, questo non funziona molto bene se il tuo sito web invia markup generato dinamicamente, ad esempio markup che cambia a seconda che un utente sia autenticato o meno. In questi casi, è sempre consigliabile accedere prima alla rete, in modo che il documento sia il più aggiornato possibile.
- Se il documento carica risorse non critiche che cambiano con una certa frequenza, ma il recupero della risorsa obsoleta non influisce in modo significativo sull'esperienza utente, ad esempio immagini selezionate o altre risorse non critiche, il TTFB per queste risorse può essere notevolmente ridotto utilizzando una strategia stale-while-revalidate.
- Utilizza il modello di shell dell'app per le applicazioni con rendering lato client. Questo modello è più adatto per le SPA in cui la "shell" della pagina può essere pubblicata istantaneamente dalla cache del service worker e i contenuti dinamici della pagina vengono compilati e visualizzati in un secondo momento nel ciclo di vita della pagina.
Utilizza 103 Early Hints per le risorse fondamentali per il rendering
Indipendentemente da quanto sia ottimizzato il backend dell'applicazione, il server potrebbe comunque dover svolgere una quantità significativa di lavoro per preparare una risposta, incluso un lavoro di database costoso (ma necessario) che ritarda l'arrivo della risposta di navigazione il più rapidamente possibile. L'effetto potenziale è che alcune risorse successive critiche per il rendering potrebbero subire ritardi, ad esempio CSS o, in alcuni casi, JavaScript che esegue il rendering del markup sul client.
L'intestazione 103 Early Hints è un codice di risposta iniziale che il server può inviare al browser mentre il backend è occupato a preparare il markup. Questa intestazione può essere utilizzata per suggerire al browser che esistono risorse fondamentali per il rendering che la pagina deve iniziare a scaricare durante la preparazione del markup. Per i browser supportati, l'effetto può essere un rendering più rapido dei documenti (CSS) e un caricamento pagina più veloce.
Uno svantaggio di 103 Early Hints è che, come la memorizzazione nella cache, possono mascherare il TTFB "reale" di un sito. Se un'infrastruttura server è lenta (perché non è sufficientemente potente o perché il codice deve essere ottimizzato), questo potrebbe essere meno evidente quando viene utilizzato 103 Early Hints, poiché il TTFB sembra veloce. I siti che utilizzano 103 Early Hints dovrebbero prendere in considerazione la misurazione del tempo effettivo del server (tramite Server-Timing o finalResponseHeadersStart dell'API PerformanceNavigationTiming).
Conclusione
Poiché esistono così tante combinazioni di stack di applicazioni di backend, non esiste un singolo articolo che possa riassumere tutto ciò che potete fare per ridurre il TTFB del vostro sito web. Tuttavia, queste sono alcune opzioni che puoi esplorare per cercare di velocizzare un po' le cose lato server.
Come per l'ottimizzazione di ogni metrica, l'approccio è molto simile: misura il TTFB sul campo, utilizza gli strumenti di laboratorio per analizzare le cause e poi applica le ottimizzazioni, se possibile. Sebbene alcune tecniche potrebbero non essere applicabili alla tua situazione, altre probabilmente lo sono. Come sempre, dovrai monitorare attentamente i dati sul campo e apportare le modifiche necessarie per garantire un'esperienza utente il più rapida possibile.