TTFB di utenti reali (dati di campo)

Q: Il mio TTFB è veloce sulla macchina di sviluppo ma lento in CrUX. Perché?

Tu sei co-localizzato con la tua origine; i tuoi utenti reali no. Aggiungi una CDN e i tuoi utenti globali vedranno un TTFB più vicino alla tua esperienza di sviluppo. L'altra causa comune è la latenza di cold-start sui deployment serverless — la prima richiesta dopo un periodo di idle paga una penalità di 500–2.000 ms.

Q: Devo preoccuparmi del TTFB se in CrUX è etichettato come "sperimentale"?

Sì. È sperimentale nel senso che Google non ne ha ancora fatto un Core Web Vital formale, ma il valore è ben definito e le soglie sono stabili. Trattalo come indicatore anticipatore del tuo LCP — se il TTFB è scarso, l'LCP quasi sicuramente lo sarà anche lui.

Q: Il mio TTFB è buono ma l'LCP è scarso. Che succede?

Il collo di bottiglia è a valle: rendering, caricamento immagini o risorse che bloccano il rendering. Guarda la regola sull'LCP. TTFB di campo buono + LCP scarso significa che il server è veloce e la lentezza è nel client; TTFB di campo scarso + LCP scarso significa che devi sistemare prima il TTFB perché ogni correzione lì si traduce gratis in miglioramenti dell'LCP.

Cosa fa questo controllo

Legge il 75° percentile del Time to First Byte dal Chrome User Experience Report — il tempo che passa dal momento in cui il browser di un utente Chrome reale invia la richiesta di navigazione al momento in cui arriva il primo byte della risposta. CrUX aggrega questo dato su una finestra mobile di 28 giorni. È una metrica CWV sperimentale, non un segnale di ranking a sé, ma fa da tetto a tutte le altre metriche di paint: niente può renderizzarsi finché non arriva il primo byte.

TTFB di campo (p75)	Verdetto
≤ 800 ms	Buono
800–1.800 ms	Da migliorare
> 1.800 ms	Scarso

Il TTFB include tutto quello che c’è tra utente e origine: lookup DNS, handshake TLS, catene di redirect, accodamento delle richieste sul tuo server, lavoro applicativo e tempo speso a renderizzare i template lato server. Qualunque cosa accada prima che parta il primo byte si aggiunge a questo numero.

Perché conta

Il TTFB non è un Core Web Vital, ma è il vincolo a monte di ogni Core Web Vital. Un TTFB di 2 secondi significa che l’LCP non può scendere sotto 2,5 s — restano solo 500 ms per tutto il resto. Tagliare 500 ms al TTFB tende a tagliare l’LCP della stessa quantità quasi gratis.

Espone anche problemi che gli strumenti di lab non vedono:

Utenti distanti. Un server in us-east-1 sembra veloce da uno strumento di lab in USA, terribile per un utente brasiliano. Il TTFB di campo ti mostra la realtà geografica.
Stati server a freddo. Se la tua origine gira funzioni serverless, la latenza di cold-start emerge solo dai dati reali; gli strumenti di lab ti riscaldano la cache.
Catene di redirect. Un 301 da example.com → www.example.com → https://www.example.com/ aggiunge un round-trip completo per ogni hop al TTFB. Gli strumenti di lab o li saltano o li riportano in modo diverso.

Come migliorarlo

1. Metti una CDN davanti alla tua origine. Anche per pagine dinamiche, una CDN può mettere in cache sessioni TLS e stato della connessione. Cloudflare, Fastly, Bunny e Vercel Edge hanno tutti piani gratuiti o quasi gratuiti:

# Proxy Cloudflare attivo (nuvola arancione) — CDN istantanea
# nslookup sul tuo dominio — dovresti vedere IP Cloudflare, non quelli della tua origine

2. Metti in cache l’HTML all’edge. Per pagine che non devono essere per-utente (marketing, blog, docs), imposta Cache-Control: s-maxage=86400, stale-while-revalidate=604800 così la CDN restituisce HTML cachato in <50 ms:

Cache-Control: public, s-maxage=86400, stale-while-revalidate=604800

La direttiva stale-while-revalidate lascia che la CDN serva una risposta stale all’istante mentre la rivalida in background — il meglio di entrambi i mondi.

3. Elimina le catene di redirect. Verifica con curl:

curl -sIL https://example.com/ | grep -E "^(HTTP|Location)"

Ogni riga Location: è un round-trip in più. Colpevoli comuni: http→https, apex→www (o www→apex) e differenze sullo slash finale. Riducili a un singolo 301 quando possibile.

4. Profila il server con Server-Timing. Aggiungi header di risposta che dicano a DevTools dove va a finire il tempo:

// Esempio Express/Node
res.setHeader("Server-Timing", "db;dur=120, render;dur=45, total;dur=170");

Il tab Network di Chrome mostrerà una scomposizione per fase, così vedi se il tempo se ne va in query al DB, rendering dei template o overhead del framework.

5. Usa HTTP/2 o HTTP/3. Lo slow-start TCP e l’head-of-line blocking su HTTP/1.1 costano TTFB reale. Tutte le CDN moderne usano HTTP/2 di default; molte già servono HTTP/3 (QUIC) per prestazioni ancora migliori su rete mobile.

6. Riduci la distanza dall’origine. Se hai un’origine in un’unica regione e utenti globali, valuta di replicarla o di passare a un framework con rendering all’edge (Astro, Next.js su Vercel, SvelteKit su Cloudflare Workers).

Domande frequenti

Il mio TTFB è veloce sulla macchina di sviluppo ma lento in CrUX. Perché?

Tu sei co-localizzato con la tua origine; i tuoi utenti reali no. Aggiungi una CDN e i tuoi utenti globali vedranno un TTFB più vicino alla tua esperienza di sviluppo. L’altra causa comune è la latenza di cold-start sui deployment serverless — la prima richiesta dopo un periodo di idle paga una penalità di 500–2.000 ms.

Devo preoccuparmi del TTFB se in CrUX è etichettato come “sperimentale”?

Sì. È sperimentale nel senso che Google non ne ha ancora fatto un Core Web Vital formale, ma il valore è ben definito e le soglie sono stabili. Trattalo come indicatore anticipatore del tuo LCP — se il TTFB è scarso, l’LCP quasi sicuramente lo sarà anche lui.

Il mio TTFB è buono ma l’LCP è scarso. Che succede?

Il collo di bottiglia è a valle: rendering, caricamento immagini o risorse che bloccano il rendering. Guarda la regola sull’LCP. TTFB di campo buono + LCP scarso significa che il server è veloce e la lentezza è nel client; TTFB di campo scarso + LCP scarso significa che devi sistemare prima il TTFB perché ogni correzione lì si traduce gratis in miglioramenti dell’LCP.