# TTFB

> TTFB (Time To First Byte) : métrique de performance web qui mesure le délai entre la requête HTTP du navigateur et la réception du premier octet de la réponse — indicateur principal de la latence serveur et reflet direct de la qualité de l'infrastructure.

- **Catégorie** : Technique
- **URL** : https://www.romaindelfosse.fr/glossary/ttfb/

---

Le **TTFB** (Time To First Byte) est une métrique de performance web qui mesure le délai entre le moment où un navigateur envoie une requête HTTP et le moment où il reçoit le premier octet de la réponse du serveur. C'est l'indicateur le plus direct de la latence perçue par l'utilisateur : avant que la page ne puisse commencer à s'afficher, le navigateur doit recevoir le début de la réponse. Un TTFB élevé produit une sensation de site lent même si le reste du chargement est rapide — ce qui en fait l'un des premiers points à optimiser sur une application web.

## Définition technique

### Les quatre composantes du TTFB

Lorsqu'un navigateur tape `https://exemple.com/` et appuie sur Entrée, plusieurs étapes se succèdent avant que le premier octet ne revienne :

1. **Résolution DNS** — traduction du nom de domaine en adresse IP. Coût typique : 10 à 100 ms, amortissable par le cache DNS local.
2. **Connexion TCP** — établissement de la connexion avec le serveur. Coût typique : un aller-retour réseau (RTT), soit 10 à 200 ms selon la distance géographique.
3. **Handshake TLS** — négociation du chiffrement HTTPS. Coût typique : 1 à 2 RTT supplémentaires, réduit à 0 RTT avec TLS 1.3 et la reprise de session.
4. **Temps de traitement serveur** — exécution du code applicatif, requêtes en base de données, rendu de la réponse. C'est cette étape qui domine largement le TTFB sur une application dynamique comme WordPress, et c'est celle sur laquelle on a le plus de marge de manœuvre.

### TTFB et Core Web Vitals

Depuis 2021, Google a intégré les **Core Web Vitals** (LCP, FID, CLS) à ses critères de classement SEO, et le TTFB — bien qu'il ne soit pas un Web Vital à part entière — est un indicateur de santé qui influence directement le **Largest Contentful Paint (LCP)** : si le serveur met 2 secondes à commencer à répondre, le LCP ne peut pas être meilleur que 2 secondes. Améliorer le TTFB est donc une condition nécessaire (mais non suffisante) pour avoir un bon score Core Web Vitals.

## Enjeux actuels

### Le TTFB comme révélateur de l'infrastructure

Le TTFB est un excellent diagnostic de la santé d'une infrastructure. Un TTFB qui varie fortement d'une requête à l'autre révèle un problème de contention (base de données sous-dimensionnée, cache qui manque, workers PHP saturés). Un TTFB systématiquement élevé sur toutes les requêtes révèle un problème structurel : hébergement sous-dimensionné, application mal optimisée, ou latence réseau excessive. La première chose que je fais quand on me demande un audit de performance d'un site WordPress, c'est regarder le TTFB sur plusieurs URL — cela donne immédiatement une idée du niveau d'effort nécessaire.

### L'effet des plugins de sécurité sur le TTFB

Sur une installation WordPress typique, chaque plugin de sécurité ajoute un coût mesurable au TTFB : il s'insère dans le chemin de chargement, vérifie chaque requête, écrit des logs, interroge sa configuration en base. L'addition de plusieurs plugins de sécurité peut faire passer le TTFB de quelques centaines de millisecondes à plus d'une seconde, sans que l'utilisateur ne voie aucun gain fonctionnel. Remonter ces contrôles au niveau infrastructure (Nginx, headers HTTP, filesystem immuable) supprime ce coût tout en améliorant la posture de sécurité — c'est le double bénéfice que j'expérimente dans [mon article sur la sécurisation de WordPress via Infrastructure as Code](/blog/securiser-wordpress-sans-plugins-infrastructure-as-code/).

## Applications pratiques

### Mesurer le TTFB

Les outils les plus utilisés pour mesurer le TTFB sont : l'onglet Network des DevTools du navigateur (colonne "Waiting (TTFB)"), [WebPageTest](https://www.webpagetest.org/), [PageSpeed Insights](https://pagespeed.web.dev/), et le rapport CrUX (Chrome User Experience Report) qui agrège les mesures réelles des utilisateurs Chrome à l'échelle mondiale. Pour du monitoring continu, un outil APM (Datadog, New Relic, Sentry Performance) permet de suivre l'évolution du TTFB dans le temps et d'identifier les régressions.

### Optimiser sans casser

Améliorer le TTFB peut introduire des bugs si on ne mesure pas. Activer un cache HTTP agressif sur une page qui devrait être dynamique, c'est transformer une page "lente et juste" en page "rapide et fausse". La règle d'or : chaque optimisation doit s'accompagner de tests fonctionnels qui valident que le comportement reste correct — idéalement automatisés dans la CI.



## Questions fréquentes

### Qu'est-ce que le TTFB mesure exactement ?

Le TTFB agrège quatre temps distincts : (1) résolution DNS du nom de domaine, (2) établissement de la connexion TCP avec le serveur, (3) négociation TLS (handshake SSL/TLS en HTTPS), (4) temps de traitement serveur (exécution du code applicatif, requêtes en base de données, génération de la réponse). En pratique, sur une application PHP comme WordPress, c'est le 4e temps qui domine largement les trois premiers : la plupart de l'amélioration de TTFB vient de l'optimisation serveur et applicative.

### Quelle est une bonne valeur de TTFB ?

Google considère qu'un TTFB inférieur à 200 ms est bon, entre 200 et 600 ms est acceptable, au-dessus de 600 ms nécessite une amélioration. Ces seuils sont pris en compte par l'indicateur Core Web Vitals, et donc indirectement par le classement SEO. Pour un site servi par un bon CDN avec cache HTTP, le TTFB peut descendre sous 50 ms. Pour un WordPress non optimisé, il est fréquent de dépasser 1 seconde, ce qui dégrade fortement la perception de rapidité du site.

### Quels sont les leviers pour améliorer le TTFB d'une application web ?

Les plus efficaces, par ordre d'impact : (1) activer un cache HTTP au niveau reverse proxy ou CDN pour que les pages fréquemment demandées soient servies sans exécuter le code applicatif, (2) activer OPcache avec validate_timestamps=0 pour supprimer la recompilation PHP, (3) mettre en place un cache objet (Redis, Memcached) pour éviter les requêtes répétées en base de données, (4) optimiser les requêtes SQL lentes identifiées via un profiler, (5) utiliser un CDN avec points de présence proches des utilisateurs, (6) passer à HTTP/2 ou HTTP/3 pour réduire la latence de connexion, (7) réduire le nombre de plugins qui tournent à chaque requête sur WordPress.



## Ressources

- [Time to First Byte (TTFB) — web.dev](https://web.dev/articles/ttfb?utm_source=romaindelfosse&utm_medium=glossaire&utm_campaign=ttfb) — Google Chrome DevRel

- [Core Web Vitals — Google Search Central](https://developers.google.com/search/docs/appearance/core-web-vitals?utm_source=romaindelfosse&utm_medium=glossaire&utm_campaign=ttfb) — Google