Cos'è il Time to First Byte (TTFB)?

Il Time to First Byte misura quanto tempo occorre al primo byte di una risposta per raggiungere il browser dopo l'invio di una richiesta. Per gli storefront di commerce renderizzati server-side o all'edge è la metrica di latenza fondamentale: ogni Vital successivo, in particolare LCP, si basa su di essa. Un TTFB scarso non può essere salvato da un codice client-side per quanto ingegnoso.

Definizione

Il TTFB include la risoluzione DNS, gli handshake TCP e TLS, il forwarding della richiesta attraverso eventuali CDN e reverse proxy, il tempo di rendering upstream all'origine o all'edge worker, e infine il tempo necessario per inviare il primo byte del documento HTML. Viene catturato tramite la Navigation Timing API e mostrato in strumenti come la libreria web-vitals, Lighthouse e la maggior parte delle piattaforme RUM. Google considera buoni valori sotto gli 800 ms per le richieste di navigazione, mentre valori sotto i 200 ms sono realistici per risposte in cache servite da una content-delivery-network-cdn o da un edge worker.

Perché è importante

Il TTFB stabilisce il limite massimo per la performance percepita. Negli storefront headless che eseguono SSR su Next.js o Remix, il TTFB è spesso dominato dalle chiamate upstream alle API di commerce, ai provider di ricerca e ai servizi di personalizzazione. Un rendering SSR a freddo di 600 ms non lascia margine per raggiungere un LCP di 2,5 secondi su reti mobili lente. Il TTFB condiziona anche le strategie di streaming SSR: senza un invio anticipato dell'head del documento, i browser non possono iniziare il precaricamento delle risorse critiche. Migliorare il TTFB ha quindi effetti composti su Core Web Vitals, conversion-rate-optimization-cro e search-engine-optimization-seo.

Casi d'uso

I team di storefront composable attaccano il TTFB memorizzando l'HTML in cache all'edge con ISR o stale-while-revalidate, collocando i render worker vicino all'origine e riducendo il numero di chiamate API bloccanti durante l'SSR. Gli storefront su Vercel Edge, Cloudflare Workers o Netlify Edge usano fragment renderizzati all'edge per mantenere veloce il contenuto dinamico mentre gli shell statici vengono trasmessi in streaming per primi. Lo streaming SSR viene abbinato a React Server Components per inviare presto l'HTML e risolvere in seguito i dati prodotto. I team monitorano il TTFB per rotta e per regione, e trattano i regressi nel tasso di hit del livello di cache come incidenti di produzione perché si propagano immediatamente su LCP e bounce-rate.

Correlati

Scopri Performance and Core Web Vitals · Composable Headless Frontend.