Performance

TTFB (Time To First Byte) : comprendre et réduire le temps de réponse de votre serveur

Mis à jour le 26 octobre 2026 · 8 minutes de lecture

Votre site « s'affiche vite » une fois chargé, mais les premières secondes semblent toujours traîner avant que quoi que ce soit n'apparaisse ? Le coupable est souvent invisible dans les outils grand public : le TTFB, le temps que met votre serveur à envoyer le premier octet de réponse. Un chiffre technique, mais qui pèse directement sur votre référencement et sur la patience de vos visiteurs.

Qu'est-ce que le TTFB, exactement ?

Le Time To First Byte mesure le délai entre le moment où le navigateur envoie sa requête et le moment où il reçoit le premier octet de la réponse du serveur. Ce délai englobe trois étapes qui se produisent avant même que votre page commence à s'afficher :

1. La résolution DNS, qui traduit votre nom de domaine en adresse IP.
2. L'établissement de la connexion TCP, puis la négociation TLS si le site est en HTTPS.
3. Le traitement de la requête par le serveur : génération de la page, requêtes à la base de données, puis envoi de la première donnée.

Autrement dit, le TTFB se termine avant que le navigateur ait reçu une seule ligne de HTML à afficher. C'est un temps d'attente pur, sans aucun retour visuel pour le visiteur.

En quoi le TTFB diffère de la « vitesse » perçue du site

Beaucoup de propriétaires de site confondent le TTFB avec la vitesse globale de chargement. Les deux sont liés, mais pas identiques. Notre guide sur l' amélioration de la vitesse d'un site couvre l'ensemble du chargement : poids des images, nombre de requêtes, exécution du JavaScript. Le TTFB, lui, ne concerne que la toute première réponse du serveur, avant que ce travail côté navigateur ne commence.

Ce n'est pas un détail théorique : le TTFB entre directement dans le calcul du Largest Contentful Paint (LCP), l'un des trois Core Web Vitals utilisés par Google comme signal de classement. Un TTFB élevé retarde mécaniquement le LCP, même si le reste de la page est parfaitement optimisé. Impossible d'avoir un bon LCP avec un mauvais TTFB.

Les causes les plus fréquentes d'un TTFB élevé

Un hébergement mutualisé saturé

Sur un hébergement partagé par des centaines de sites, les ressources processeur et mémoire sont mutualisées. Si un autre site du même serveur consomme beaucoup de ressources, votre propre temps de réponse en pâtit, sans que vous ayez rien changé de votre côté.

Des requêtes de base de données lentes ou mal indexées

Chaque page générée dynamiquement (WordPress, PrestaShop, une application sur mesure) interroge une base de données. Des requêtes non optimisées, des tables sans index ou une base trop volumineuse sans maintenance font grimper le temps de génération côté serveur, donc le TTFB.

L'absence de cache côté serveur

Sans cache, chaque visite régénère entièrement la page à partir de zéro. Un cache applicatif ou un cache de page permet de servir une version déjà calculée en quelques millisecondes plutôt qu'en reconstruisant tout à chaque requête.

Une résolution DNS lente

Avant même d'atteindre votre serveur, le navigateur doit résoudre votre nom de domaine. Un fournisseur DNS lent ou mal configuré ajoute un délai invisible mais réel. Nous détaillons ce mécanisme dans notre article sur la propagation DNS.

Un serveur géographiquement éloigné du visiteur

La vitesse de la lumière reste une limite physique : plus la distance entre le visiteur et le serveur est grande, plus la latence réseau s'ajoute au TTFB mesuré. Un CDN rapproche le contenu statique du visiteur, mais ne résout pas un TTFB lent sur les pages dynamiques générées par le serveur d'origine.

Des plugins ou thèmes mal codés

Sur WordPress en particulier, l'accumulation de plugins qui exécutent du code à chaque chargement de page est l'une des causes les plus courantes de TTFB dégradé. Voir notre guide sur les mises à jour WordPress et PHP pour limiter ce type de dérive.

Quel est un « bon » TTFB ?

Les seuils communément admis, notamment par Google, sont les suivants :

• Moins de 200 ms : excellent, le serveur répond quasi instantanément.
• Entre 200 et 500 ms : correct pour la grande majorité des sites, sans impact majeur.
• Entre 500 ms et 1 seconde : perceptible et pénalisant pour le LCP, à corriger.
• Plus d'1 seconde : problématique, à traiter en priorité.

Comment mesurer votre TTFB

Plusieurs méthodes, du simple coup d'œil à la mesure technique précise :

• L'onglet Réseau de Chrome DevTools. Rechargez votre page, cliquez sur la première requête du document, et consultez l'onglet « Timing » : la ligne « Waiting for server response » (TTFB) y est détaillée.
• PageSpeed Insights ou WebPageTest. Ces outils gratuits affichent le TTFB dans le détail de l'analyse de chargement, avec un historique si vous testez régulièrement.
• La ligne de commande, pour les plus techniques, via une requête mesurant précisément le temps jusqu'au premier octet reçu, en dehors de tout rendu navigateur.

Un point important : le TTFB mesuré dépend de l'emplacement du serveur de test par rapport à votre hébergeur. Un test effectué depuis un seul pays peut sous-estimer ou surestimer le problème pour le reste de votre audience, comme nous l'expliquons dans notre article sur la surveillance multi-régions.

Comment réduire durablement son TTFB

1. Changer d'offre d'hébergement si vous êtes sur un mutualisé bas de gamme saturé, au profit d'un hébergement avec ressources dédiées ou d'un hébergement infogéré performant.
2. Activer un cache de page côté serveur ou via une extension dédiée, pour éviter de régénérer chaque page à chaque visite.
3. Optimiser ou nettoyer la base de données : suppression des révisions inutiles, ajout d'index, mise à jour du moteur de base de données.
4. Désactiver les plugins inutiles et auditer ceux qui restent, en particulier ceux exécutant du code à chaque requête.
5. Mettre à jour PHP vers une version récente : les gains de performance entre versions majeures de PHP sont souvent considérables, sans aucun coût.
6. Choisir un hébergeur proche de votre audience géographiquement, ou compléter avec un CDN pour le contenu statique.

Pourquoi surveiller le TTFB dans le temps, pas une seule fois

Une mesure ponctuelle donne une photo, pas un film. Un TTFB correct aujourd'hui peut se dégrader progressivement sur plusieurs semaines : base de données qui grossit, plugin ajouté sans recul, pic de trafic récurrent. Sans suivi dans le temps, cette dérive lente passe totalement inaperçue jusqu'à ce qu'elle devienne un problème de référencement ou de conversion.

C'est exactement ce que couvre la surveillance continue de la vitesse : au lieu de tester une fois par hasard, un contrôle régulier détecte la tendance et vous alerte avant que le ralentissement ne soit visible par vos visiteurs.

Questions fréquentes