TTFB des utilisateurs réels (données terrain)

Ce que vérifie ce contrôle

Lit le Time to First Byte au 75e centile depuis le Chrome User Experience Report — le temps entre l’instant où le navigateur d’un vrai utilisateur Chrome envoie la requête de navigation et l’instant où le premier octet de la réponse arrive. CrUX agrège cette mesure sur une fenêtre glissante de 28 jours. C’est une métrique CWV expérimentale, pas un signal de classement à part entière, mais elle plafonne toutes les autres métriques de peinture : rien d’autre ne peut s’afficher avant l’arrivée du premier octet.

TTFB terrain (p75)	Verdict
≤ 800 ms	Bon
800–1 800 ms	À améliorer
> 1 800 ms	Mauvais

Le TTFB englobe tout ce qui se passe entre l’utilisateur et l’origine : résolution DNS, négociation TLS, chaînes de redirection, mise en file d’attente des requêtes sur votre serveur, traitement applicatif, et temps passé à rendre les gabarits côté serveur. Tout ce qui se produit avant que le premier octet ne parte s’ajoute à ce chiffre.

Pourquoi c’est important

Le TTFB n’est pas un Core Web Vital, mais c’est la contrainte en amont de tous les Core Web Vitals. Un TTFB de 2 secondes rend impossible un LCP sous 2,5 s — il ne reste que 500 ms pour tout le reste. Couper 500 ms de TTFB tend à couper le LCP d’autant, presque gratuitement.

Il met aussi en lumière des problèmes que les outils de labo manquent :

Utilisateurs éloignés. Un serveur en us-east-1 paraît rapide vu d’un outil de labo basé aux États-Unis, et catastrophique pour un utilisateur brésilien. Le TTFB terrain vous montre la réalité géographique.
États serveur à froid. Si votre origine tourne sur des fonctions serverless, la latence de démarrage à froid n’apparaît que dans les données réelles ; les outils de labo réchauffent le cache pour vous.
Chaînes de redirection. Un 301 de example.com → www.example.com → https://www.example.com/ ajoute un aller-retour complet par saut au TTFB. Les outils de labo soit sautent ces étapes, soit les rapportent autrement.

Comment l’améliorer

1. Placez un CDN devant votre origine. Même pour des pages dynamiques, un CDN peut mettre en cache les sessions TLS et l’état de connexion. Cloudflare, Fastly, Bunny et Vercel Edge offrent tous une formule gratuite ou quasi gratuite :

# Proxy Cloudflare activé (nuage orange) — CDN instantané
# nslookup sur votre domaine — vous devriez voir des IP Cloudflare, pas votre origine

2. Mettez le HTML en cache à la périphérie. Pour les pages qui n’ont pas besoin d’être personnalisées (marketing, blog, docs), définissez Cache-Control: s-maxage=86400, stale-while-revalidate=604800 pour que le CDN renvoie le HTML mis en cache en moins de 50 ms :

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

La directive stale-while-revalidate permet au CDN de servir instantanément une réponse périmée pendant qu’il la revalide en arrière-plan — le meilleur des deux mondes.

3. Éliminez les chaînes de redirection. Auditez avec curl :

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

Chaque ligne Location: est un aller-retour supplémentaire. Coupables habituels : http→https, apex→www (ou www→apex), et différences de barre oblique finale. Repliez tout cela en un seul 301 si possible.

4. Profilez votre serveur avec Server-Timing. Ajoutez des en-têtes de réponse qui indiquent aux DevTools où le temps est passé :

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

L’onglet Network de Chrome affichera une décomposition par phase pour que vous puissiez voir si le temps part dans les requêtes BD, le rendu de gabarit ou la surcharge du framework.

5. Utilisez HTTP/2 ou HTTP/3. Le démarrage lent TCP et le blocage en tête de file de HTTP/1.1 coûtent du TTFB réel. Tous les CDN modernes utilisent HTTP/2 par défaut ; beaucoup servent déjà HTTP/3 (QUIC) pour de meilleures performances sur les réseaux mobiles.

6. Réduisez la distance à l’origine. Si vous avez une origine mono-région et des utilisateurs mondiaux, envisagez de répliquer ou de migrer vers un framework rendu en périphérie (Astro, Next.js sur Vercel, SvelteKit sur Cloudflare Workers).

Questions fréquentes

Mon TTFB est rapide sur ma machine de dev mais lent dans CrUX. Pourquoi ?

Vous êtes colocalisé avec votre origine ; pas vos vrais utilisateurs. Ajoutez un CDN et vos utilisateurs mondiaux verront un TTFB plus proche de votre expérience de dev. L’autre cause fréquente est la latence de démarrage à froid sur les déploiements serverless — votre première requête après inactivité paie une pénalité de 500 à 2 000 ms.

Dois-je me soucier du TTFB s’il est étiqueté « expérimental » dans CrUX ?

Oui. Il est expérimental au sens où Google n’en a pas encore fait un Core Web Vital officiel, mais la valeur est bien définie et les seuils sont stables. Traitez-le comme un indicateur avancé pour votre LCP — si le TTFB est mauvais, le LCP le sera presque certainement aussi.

Mon TTFB est bon mais mon LCP est mauvais. Que se passe-t-il ?

Le goulot d’étranglement est en aval : rendu, chargement d’image, ou ressources bloquant le rendu. Regardez la règle LCP ensuite. Un TTFB terrain bon avec un LCP bon signifie que votre serveur est rapide et que la lenteur est côté client ; un TTFB terrain mauvais avec un LCP mauvais signifie qu’il faut d’abord corriger le TTFB, parce que chaque correction y donne gratuitement des améliorations de LCP.