TTFB
Définition
Time To First Byte. Délai entre la requête HTTP et le premier octet de réponse du serveur. Indicateur de la performance backend et de l'infrastructure.
Ce que TTFB mesure
TTFB (Time To First Byte) est le délai entre la requête HTTP envoyée par le navigateur et le premier octet de réponse reçu du serveur. Il agrège tout ce qui se passe avant que votre code front-end commence à rendre quoi que ce soit : résolution DNS, établissement de la connexion TCP, négociation TLS, latence réseau aller-retour, temps de génération de la page côté backend (rendu serveur, requêtes base de données, appels API tiers). C'est la part purement serveur de la performance perçue. Si le TTFB est mauvais, aucune optimisation front-end ne peut compenser.
Pourquoi c'est critique
Le TTFB pose le plancher de tout le reste. Si le serveur met 1,5 seconde à répondre, le LCP ne descendra jamais sous cette valeur, peu importe l'optimisation front. Sur un site SEO, un TTFB élevé bloque l'atteinte des Core Web Vitals verts. Sur un e-commerce, c'est la première seconde où l'utilisateur ne voit rien : taux d'abandon élevé, surtout sur mobile en 4G. Sur une API consommée par une app mobile ou un service tiers, un TTFB lent multiplie les timeouts et dégrade l'expérience. La cible raisonnable est sous 600 ms, idéalement sous 200 ms pour les pages statiques.
Décomposer le TTFB
Chrome DevTools, onglet Network, sépare le TTFB en plusieurs phases visibles : DNS lookup, Initial connection (TCP), SSL, Request sent, Waiting (TTFB serveur), Content download. Le "Waiting" est la part la plus actionnable côté backend. Si elle dépasse 500 ms, le serveur traite trop de logique synchrone. Si c'est la phase DNS qui pèse, on utilise un DNS plus rapide ou on précharge via dns-prefetch. Si c'est SSL, on vérifie HTTP/2 ou HTTP/3 activés. Cette analyse précise oriente l'optimisation au bon endroit, plutôt que de tout traiter en bloc.
Les leviers serveur
Hébergement edge ou proche de l'audience : un utilisateur français servi depuis Paris, pas depuis Virginia. Vercel et Cloudflare déploient partout dans le monde par défaut, ce qui coupe la latence réseau de 200 à 500 ms sur les utilisateurs distants. ISR ou SSG quand le contenu n'a pas besoin d'être calculé à chaque requête : la page est pré-générée, servie en pur statique, TTFB sous 50 ms. Cache HTTP applicatif (Redis, Memcached) pour les pages dynamiques qui dépendent de données peu changeantes. HTTP/2 et HTTP/3 activés sur le serveur, qui multiplexent les requêtes et réduisent l'overhead.
Les leviers base de données
Beaucoup de TTFB élevés viennent de requêtes base de données mal indexées. Les outils comme pg_stat_statements ou Datadog APM montrent les requêtes les plus lentes. On ajoute les index manquants, on optimise les jointures, on évite les N+1 (une requête par item dans une liste). Pour les pages très consultées, on cache le résultat applicativement. Sur PostgreSQL, EXPLAIN ANALYZE révèle les plans d'exécution coûteux. Sur les SaaS multi-tenant avec RLS, on vérifie que les policies n'ajoutent pas un coût caché à chaque requête. Ces audits réguliers évitent les surprises en production.
Cas particuliers
Sur un site WordPress, le TTFB plafonne souvent à 800 ms ou plus à cause de PHP synchrone et de plugins lourds : passer en SSG avec WP comme headless résout le problème. Sur une API qui appelle plusieurs services tiers en chaîne, le TTFB cumule les latences : on parallélise (Promise.all) ou on cache les réponses tierces. Sur un site avec authentification stricte, chaque page passe par une vérification de session : on accélère avec un JWT vérifié côté edge plutôt qu'un appel base. Sur un cron job ou un job de fond, on accepte un TTFB élevé en échange d'un traitement complet, c'est un compromis légitime.
Mesurer en continu
Search Console ne reporte pas directement le TTFB, mais le LCP en field data le reflète indirectement. Vercel Analytics, Cloudflare Analytics ou les RUM commerciaux affichent le TTFB par page et par région. Sur les sites critiques, on alerte si le TTFB médian dépasse 800 ms ou si le p95 explose à 3 secondes. Ces seuils déclenchent un investigation immédiate : surcharge serveur, attaque DDoS, dégradation d'un service tiers, requête base devenue lente après un changement de schéma. La latence est rarement aléatoire, elle a presque toujours une cause traçable.