TTFB d'usuaris reals (dades de camp)

Què comprova aquesta auditoria

Llegeix el Time to First Byte al percentil 75 del Chrome User Experience Report: el temps des del moment en què el navegador d’un usuari real de Chrome envia la petició de navegació fins al moment en què arriba el primer byte de la resposta. CrUX agrega això en una finestra mòbil de 28 dies. És una mètrica CWV experimental, no un senyal de posicionament per ell mateix, però marca el sostre de la resta de mètriques de paint: res més es pot renderitzar fins que arriba el primer byte.

TTFB de camp (p75)	Veredicte
≤ 800 ms	Bo
800–1.800 ms	Cal millorar
> 1.800 ms	Pobre

El TTFB engloba tot el que hi ha entre l’usuari i l’origen: resolució DNS, handshake TLS, cadenes de redireccions, encolat de peticions al teu servidor, feina d’aplicació i temps renderitzant plantilles al servidor. Qualsevol cosa que passi abans que surti el primer byte se suma a aquest número.

Per què importa

El TTFB no és un Core Web Vital, però és la restricció upstream de tots els Core Web Vitals. Un TTFB de 2 segons fa que l’LCP no pugui ser per sota de 2,5 s: només queden 500 ms per a tota la resta. Reduir el TTFB en 500 ms tendeix a reduir l’LCP una quantitat semblant gairebé gratis.

També exposa problemes que les eines de laboratori no veuen:

Usuaris llunyans. Un servidor a us-east-1 sembla ràpid des d’una eina de laboratori als EUA, però terrible per a un usuari brasiler. El TTFB de camp et mostra la realitat geogràfica.
Estats de servidor freds. Si el teu origen executa funcions serverless, la latència de cold-start només apareix a les dades d’usuari real; les eines de laboratori et preescalfen la caché.
Cadenes de redireccions. Una 301 de example.com → www.example.com → https://www.example.com/ afegeix un round-trip complet per salt al TTFB. Les eines de laboratori o bé se les salten o les reporten de manera diferent.

Com millorar-ho

1. Posa una CDN davant del teu origen. Fins i tot per a pàgines dinàmiques, una CDN pot cachejar sessions TLS i estat de connexió. Cloudflare, Fastly, Bunny i Vercel Edge tenen tarifes gratuïtes o gairebé gratuïtes:

# Proxy de Cloudflare activat (núvol taronja), CDN instantània
# nslookup del teu domini, hauries de veure IPs de Cloudflare, no el teu origen

2. Cacheja l’HTML a l’edge. Per a pàgines que no han de ser per usuari (marketing, blog, docs), posa Cache-Control: s-maxage=86400, stale-while-revalidate=604800 perquè la CDN retorni l’HTML cachejat en <50 ms:

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

La directiva stale-while-revalidate deixa que la CDN serveixi una resposta antiga a l’instant mentre la revalida en segon pla, el millor dels dos mons.

3. Elimina les cadenes de redireccions. Audita amb curl:

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

Cada línia Location: és un round-trip extra. Ofensors habituals: http→https, apex→www (o www→apex) i diferències de barra final. Col·lapsa això a una sola 301 si és possible.

4. Perfila el teu servidor amb Server-Timing. Afegeix capçaleres de resposta que diguin a DevTools on s’ha anat el temps:

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

La pestanya Network de Chrome mostrarà un desglossament per fase perquè puguis veure si el temps va en consultes a la BBDD, renderitzat de plantilles o overhead del framework.

5. Fes servir HTTP/2 o HTTP/3. El slow-start de TCP i el head-of-line blocking de HTTP/1.1 costen TTFB real. Totes les CDN modernes van per defecte amb HTTP/2; moltes ja serveixen HTTP/3 (QUIC) per a un millor rendiment en xarxes mòbils.

6. Retalla la distància a l’origen. Si tens un origen en una sola regió i usuaris globals, plantegeu replicar o migrar a un framework renderitzat a l’edge (Astro, Next.js a Vercel, SvelteKit a Cloudflare Workers).

Preguntes freqüents

El meu TTFB és ràpid a la meva màquina de desenvolupament però lent a CrUX. Per què?

Tu estàs co-localitzat amb el teu origen; els teus usuaris reals no. Afegeix una CDN i els teus usuaris globals veuran un TTFB més proper a la teva experiència de desenvolupament. L’altra causa habitual és la latència de cold-start a desplegaments serverless: la primera petició després d’estar inactiu paga una penalització de 500–2.000 ms.

M’he de preocupar pel TTFB si està etiquetat com a “experimental” a CrUX?

Sí. És experimental en el sentit que Google encara no l’ha convertit formalment en Core Web Vital, però el valor està ben definit i els llindars són estables. Tracta’l com un indicador avançat del teu LCP: si el TTFB és pobre, l’LCP gairebé segur que també ho serà.

El meu TTFB és bo però l’LCP és pobre. Què passa?

El coll d’ampolla és downstream: renderitzat, càrrega d’imatges o recursos que bloquegen el renderitzat. Mira la regla d’LCP a continuació. TTFB de camp bo + LCP pobre vol dir que el teu servidor és ràpid i la lentitud és al client; TTFB de camp pobre + LCP pobre vol dir arregla el TTFB primer perquè cada solució allà es compon en millores d’LCP gratuïtes.