Comment réduire le TTFB de votre site web ?
- Le TTFB est le temps que met votre serveur à envoyer le premier octet de réponse : visez 0,8 s ou moins.
- Il précède tout : un TTFB élevé laisse le visiteur devant une page blanche et alourdit toute la suite.
- Les causes et les leviers sont côté serveur (hébergement, cache, CDN) — un sujet à remonter à votre hébergeur.
Avant même qu’une page commence à s’afficher, il se passe quelque chose d’invisible : votre serveur reçoit la demande, prépare la réponse, et envoie le premier octet. Ce délai porte un nom — le TTFB — et quand il est trop long, tout le reste de la page hérite du retard. C’est le temps de réaction de votre serveur.
C’est quoi le TTFB ?
TTFB signifie Time To First Byte : le temps écoulé entre le moment où le navigateur demande la page et celui où il reçoit le premier octet de réponse du serveur. C’est, en somme, la rapidité avec laquelle votre serveur « décroche » quand on l’appelle.
Pourquoi c’est fondamental
Le TTFB précède tout le reste. Tant que le premier octet n’est pas arrivé, le navigateur attend devant une page blanche : il ne peut rien afficher. Un TTFB élevé, c’est donc du temps perdu avant même de commencer — et ce retard s’ajoute mécaniquement à toutes les mesures de vitesse qui suivent, dont le LCP.
La cible recommandée
Selon web.dev (la ressource performance de Google), il faut viser un TTFB de 0,8 seconde ou moins ; au-delà de 1,8 seconde, c’est considéré comme mauvais. Ce n’est pas un Core Web Vital en soi, mais une métrique « fondatrice » : si le serveur met une seconde et demie à répondre, vous avez déjà brûlé plus de la moitié de votre budget pour un bon affichage.
Ce qui fait grimper le TTFB
Les causes sont presque toujours côté serveur : un hébergement sous-dimensionné ou surchargé, une base de données lente, un site qui doit recalculer chaque page à la volée (cas fréquent des CMS comme WordPress avec beaucoup d’extensions), ou un serveur géographiquement loin du visiteur. Le point commun : le serveur met trop de temps à préparer la réponse.
Les leviers (côté serveur)
web.dev les classe par impact. D’abord l’hébergement : un hébergement de qualité est le premier levier. Ensuite la mise en cache des pages, qui évite de tout recalculer à chaque visite. Puis un CDN (réseau de serveurs proches des visiteurs) pour réduire la distance, et la suppression des redirections inutiles. Autant de réglages qui relèvent de votre hébergeur ou d’un développeur.
Pourquoi c’est « côté hébergeur »
Vous ne pouvez pas, depuis votre interface d’édition, accélérer la réponse de votre serveur : cela dépend de la machine, de sa configuration et de votre formule d’hébergement. C’est pourquoi un TTFB élevé est typiquement un sujet à remonter à votre hébergeur ou à votre prestataire technique, avec une question simple : « pourquoi mon serveur met-il si longtemps à répondre, et comment l’accélérer ? »
Comment le mesurer
Limpi mesure le TTFB de vos pages. Des outils gratuits comme PageSpeed Insights ou les outils de développement de votre navigateur (onglet « Réseau ») le donnent aussi. Si le chiffre dépasse nettement la seconde, c’est le signal qu’il faut regarder du côté du serveur avant toute autre optimisation.
Le TTFB est le premier domino de la chaîne de chargement. Tant qu’il n’est pas tombé, aucun autre ne bouge. L’optimiser profite donc à toute la vitesse de la page.
Le TTFB, c’est le temps que met le serveur à répondre au téléphone. Tant qu’il sonne dans le vide, le client patiente devant une page blanche.
En résumé
Le TTFB mesure la rapidité avec laquelle votre serveur envoie le premier octet de réponse. Visez 0,8 seconde ou moins : au-delà, tout le chargement en pâtit, le visiteur restant devant une page blanche. Les causes sont côté serveur (hébergement, base de données, absence de cache, distance), et les leviers aussi — d’où l’importance d’en parler à votre hébergeur. C’est le premier domino de la vitesse de votre site.
Questions fréquentes
C’est quoi le TTFB ?
Le Time To First Byte : le temps entre la demande de la page et l’arrivée du premier octet de réponse du serveur.
Quel TTFB viser ?
0,8 seconde ou moins selon web.dev (Google) ; au-delà de 1,8 seconde, c’est considéré comme mauvais.
Pourquoi est-ce si important ?
Parce qu’il précède tout l’affichage : tant que le premier octet n’arrive pas, le navigateur reste sur une page blanche.
Qu’est-ce qui fait grimper le TTFB ?
Un hébergement surchargé, une base de données lente, l’absence de cache, ou un serveur géographiquement loin du visiteur.
Que puis-je faire ?
Le remonter à votre hébergeur : les leviers (hébergement, cache, CDN) sont côté serveur et ne se règlent pas depuis l’éditeur.
Sources et références
- web.dev (Google) — Time to First Byte (TTFB) (nov. 2025)
- Google Search Central — Comprendre les Core Web Vitals et la recherche Google (mis à jour déc. 2025)
Vous voulez savoir ce qu'il en est sur VOTRE site ?
Limpi analyse votre site et vous dit, en clair, ce qui cloche et comment le corriger. Sans jargon.