SEO Technique

TTFB : c'est quoi, comment le mesurer et pourquoi ça impacte votre SEO ?

Par Jonathan Boetsch, Consultant SEO Freelance & Growth Marketer · 11 min de lecture

Quand je réalise un audit SEO technique, le TTFB est systématiquement l'un des trois premiers indicateurs que j'ouvre. Le temps de réponse serveur est discret, souvent ignoré par les propriétaires de sites, mais il conditionne littéralement tout ce qui se passe ensuite dans le navigateur de votre visiteur. Un TTFB dégradé, c'est une chaîne de performance qui part mal dès le départ, et Google le sait.

C'est quoi le TTFB ?

Définition simple : ce qui se passe entre le clic et le premier octet reçu

Le TTFB, acronyme de Time to First Byte, mesure le délai entre le moment où un navigateur envoie une requête HTTP à votre serveur et le moment où il reçoit le tout premier octet de la réponse. Ce n'est pas encore le chargement complet de la page : c'est uniquement l'instant où le serveur commence à répondre.

Concrètement, pendant ce laps de temps, trois choses se produisent successivement. D'abord, la résolution DNS (transformer le nom de domaine en adresse IP). Ensuite, l'établissement de la connexion TCP et la négociation TLS si le site est en HTTPS. Enfin, et c'est souvent là que le bât blesse, le temps de traitement côté serveur : PHP qui s'exécute, WordPress qui interroge sa base de données, le serveur qui génère le HTML à la volée avant d'envoyer quoi que ce soit.

Si vous avez déjà vu dans DevTools la barre grise intitulée « Waiting (TTFB) » avant que quoi que ce soit ne commence à se charger, c'est exactement cela. Ce délai d'attente, c'est le TTFB.

TTFB vs LCP vs FCP : où ça se situe dans les Core Web Vitals

Le TTFB n'est pas officiellement un Core Web Vital au sens strict du terme, mais il en est le précurseur direct. Pour comprendre pourquoi, il faut visualiser la cascade de chargement d'une page.

Le FCP (First Contentful Paint) mesure quand le premier élément visuel apparaît. Le LCP (Largest Contentful Paint), qui lui est un Core Web Vital officiel, mesure quand l'élément principal de la page est visible. Ces deux métriques ne peuvent pas être bonnes si le TTFB est mauvais : le navigateur ne peut pas commencer à afficher quoi que ce soit tant que le serveur n'a pas commencé à répondre. Un TTFB de 1,5 seconde, c'est 1,5 seconde de délai incompressible avant même que le navigateur ne parse une seule ligne de HTML.

Pour aller plus loin sur la relation entre ces métriques, j'ai écrit un article détaillé sur ce que sont les Core Web Vitals et pourquoi ils comptent pour votre SEO.

Quel TTFB est acceptable pour votre site ?

Les seuils Google : bon, à améliorer, mauvais

Google a publié des seuils clairs dans sa documentation sur les métriques web. Pour le TTFB, les recommandations sont les suivantes :

• Bon : inférieur à 800 ms
• À améliorer : entre 800 ms et 1 800 ms
• Mauvais : au-delà de 1 800 ms

Ces seuils s'appliquent aux données de terrain réelles (CrUX, le Chrome User Experience Report), pas uniquement aux tests en laboratoire. Autrement dit, Google mesure le TTFB réel ressenti par vos visiteurs, pas uniquement celui que vous observez depuis votre bureau avec une connexion fibre.

Personnellement, je fixe un objectif plus exigeant pour mes clients : viser un TTFB inférieur à 500 ms en conditions normales de charge. C'est atteignable, même sur des sites WordPress bien configurés, et ça laisse de la marge pour les fluctuations réseau.

Benchmarks par type de site (e-commerce, vitrine, WordPress)

Les chiffres varient fortement selon la nature du site. Un site statique (HTML pur, hébergé sur un CDN) peut atteindre des TTFB de 50 à 150 ms sans difficulté. Une vitrine WordPress correctement mise en cache tourne raisonnablement entre 150 et 400 ms. Un site e-commerce WooCommerce avec des pages produit générées dynamiquement, sans cache, peut facilement dépasser 1 500 ms, voire 3 secondes sur un hébergement mutualisé d'entrée de gamme.

Ce dernier cas est malheureusement très fréquent. J'audite régulièrement des boutiques en ligne dont le TTFB dépasse 2 secondes uniquement parce que l'hébergeur est sous-dimensionné et que le cache n'a jamais été configuré. Le potentiel d'amélioration est immédiat et mesurable.

Pourquoi votre site met trop de temps à répondre ?

Hébergeur lent ou mutualisé

C'est la cause numéro un que je rencontre en audit. Les offres d'hébergement mutualisé d'entrée de gamme font cohabiter des centaines, parfois des milliers de sites sur un même serveur physique. Quand l'un d'eux reçoit un pic de trafic, tous les voisins en pâtissent. Les ressources CPU et mémoire vive disponibles pour votre site sont limitées et disputées en permanence.

Le symptôme caractéristique : votre TTFB varie fortement d'un test à l'autre, avec des pics à 2 ou 3 secondes sans raison apparente. C'est le signe d'un hébergement saturé. Le correctif passe par une migration vers un hébergement dédié, un VPS ou un hébergement cloud avec des ressources garanties.

Base de données non optimisée, requêtes WordPress lourdes

WordPress interroge sa base de données MySQL à chaque chargement de page non mise en cache. Sur un site vieillissant, cette base de données accumule des tables auto-draft, des révisions de posts, des données de plugins désinstallés et des transients expirés. Résultat : des requêtes lentes qui retardent la génération du HTML.

J'ai eu le cas récemment d'un site WordPress de 4 ans dont la table wp_options pesait plus de 80 Mo à cause de transients accumulés. Après nettoyage et optimisation des index, le temps de traitement PHP est passé de 900 ms à 180 ms. Le TTFB global est tombé de 1 400 ms à 320 ms, sans changer d'hébergeur.

Parmi les coupables habituels côté plugins : les page builders lourds avec des dizaines de requêtes imbriquées, les plugins de sécurité qui scannent chaque requête, ou encore les plugins de WooCommerce qui multiplient les appels base de données sur les pages panier et commande.

Absence de cache serveur

Sans cache, chaque visite de page recalcule entièrement le HTML depuis zéro : PHP s'exécute, WordPress requête la base de données, assemble les templates, génère la réponse. C'est le scénario le plus coûteux en temps de traitement serveur.

Le cache serveur (ou cache de page) consiste à stocker une copie statique du HTML généré et à la servir directement aux visiteurs suivants, sans repasser par PHP ni la base de données. Le gain de TTFB est souvent spectaculaire : on passe facilement de 1 200 ms à 150 ms sur la même infrastructure.

Comment mesurer votre TTFB gratuitement

Plusieurs outils permettent de mesurer votre TTFB sans débourser un euro.

• PageSpeed Insights (web.dev/measure ou pagespeed.web.dev) : fournit le TTFB issu des données de terrain CrUX ainsi que des données de laboratoire via Lighthouse. C'est le référentiel direct de Google, à consulter en priorité.
• GTmetrix : affiche le TTFB dans l'onglet « Waterfall » avec une visualisation claire de la phase d'attente. Vous pouvez tester depuis plusieurs localisations géographiques pour identifier d'éventuels problèmes de latence réseau.
• WebPageTest (webpagetest.org) : l'outil le plus granulaire pour analyser le TTFB. Il décompose précisément les phases DNS, connexion, TLS et traitement serveur. Idéal pour diagnostiquer exactement où le temps est perdu.
• Chrome DevTools : dans l'onglet Network, en survolant la barre de requête principale, vous voyez le détail de la phase « Waiting (TTFB) » en temps réel depuis votre propre connexion.

Une précision importante : testez toujours votre TTFB depuis plusieurs localisations et à plusieurs moments de la journée. Un hébergement mutualisé saturé le soir peut afficher un TTFB acceptable le matin. Les données de terrain CrUX de PageSpeed Insights sont à ce titre plus représentatives qu'un seul test ponctuel.

5 actions concrètes pour réduire votre TTFB

Changer d'hébergeur ou passer à un VPS/CDN

Si votre hébergement mutualisé est la cause principale, la migration s'impose. Vers un hébergement managé WordPress (Kinsta, WP Engine, o2switch en France), un VPS avec Nginx bien configuré, ou un service cloud avec auto-scaling. Coupler cela à un CDN (Cloudflare en premier lieu) permet de servir les actifs statiques depuis des serveurs géographiquement proches de vos visiteurs, réduisant la latence réseau de manière significative.

Un CDN ne résout pas un TTFB lent côté serveur d'origine, mais il peut mettre en cache des pages entières pour les visiteurs récurrents, ce qui revient fonctionnellement à servir un TTFB quasi nul pour ces requêtes.

Activer le cache serveur (LiteSpeed Cache, WP Rocket, Redis)

Sur WordPress, c'est l'action au meilleur rapport effort/résultat. Les options principales :

• WP Rocket : solution payante, configuration simple, cache de page efficace avec préchargement automatique.
• LiteSpeed Cache : gratuit, exceptionnellement performant si votre hébergeur utilise le serveur web LiteSpeed (c'est le cas de beaucoup d'hébergements managés modernes).
• Redis ou Memcached : cache objet qui stocke les résultats de requêtes base de données en mémoire vive. Complémentaire du cache de page, il réduit drastiquement le temps de traitement PHP pour les pages non mises en cache (panier WooCommerce, espace client, etc.).

Pour approfondir la configuration technique de WordPress en vue d'améliorer les performances globales, mon article sur l'optimisation SEO WordPress couvre ces paramètres en détail.

Optimiser les requêtes base de données

Concrètement, cela passe par plusieurs actions combinées : nettoyer les révisions et les transients avec un plugin comme WP-Optimize ou Advanced Database Cleaner, vérifier les requêtes lentes avec le plugin Query Monitor (qui affiche chaque requête SQL et son temps d'exécution), supprimer les plugins inutilisés qui continuent à interroger la base de données en arrière-plan, et enfin s'assurer que les tables utilisent les bons index MySQL. Sur des bases de données volumineuses, ajouter un index sur une colonne fréquemment interrogée peut diviser par 10 le temps d'une requête.

TTFB et audit SEO : pourquoi c'est l'un des premiers points analysés

Dans ma méthodologie d'audit, le TTFB est l'indicateur zéro, celui que je regarde avant même d'ouvrir un crawler. La raison est simple : un TTFB dégradé contamine tout le reste. Un Googlebot qui attend 2 secondes avant de recevoir le premier octet va explorer moins de pages par session de crawl, ce qui réduit mécaniquement le crawl budget alloué à votre site. Les pages profondes et récemment mises à jour risquent de ne pas être recrawlées assez fréquemment.

Par ailleurs, un TTFB élevé rend artificiellement mauvaises toutes vos métriques de performance : LCP, FCP, Time to Interactive. Corriger le TTFB en premier permet souvent d'améliorer plusieurs Core Web Vitals d'un coup, sans toucher au code front-end. C'est pour cette raison qu'il figure systématiquement dans les recommandations prioritaires de mes rapports d'audit.

Si vous souhaitez aller plus loin, ma page dédiée à l'audit SEO technique explique comment j'aborde l'analyse complète d'un site, du TTFB jusqu'au maillage interne. Et si vous réfléchissez à intégrer la performance technique dans une vision SEO plus globale, la page stratégie SEO vous donnera le cadre d'ensemble.

FAQ TTFB

Que signifie « attente TTFB » dans les outils de développement ?

Dans Chrome DevTools ou GTmetrix, la mention « Waiting (TTFB) » correspond au temps pendant lequel le navigateur a envoyé sa requête au serveur et attend que celui-ci commence à répondre. C'est le délai de traitement côté serveur, avant même que le moindre octet de contenu ne soit transmis. Une valeur élevée ici indique généralement un problème d'hébergement, de cache ou de performance base de données.

Un mauvais TTFB fait-il vraiment baisser le classement Google ?

Google n'a pas confirmé de pénalité directe liée au TTFB seul. En revanche, un TTFB élevé dégrade mécaniquement le LCP, qui lui est un signal de ranking confirmé depuis le déploiement de l'algorithme Page Experience. De plus, un TTFB lent réduit l'efficacité du crawl Googlebot, ce qui peut ralentir l'indexation de vos nouvelles pages. L'impact SEO est donc réel, même s'il est indirect.

Quel est le temps de réponse serveur acceptable pour un site WordPress ?

Pour un site WordPress correctement configuré (cache activé, hébergement adapté), un TTFB inférieur à 500 ms est un objectif raisonnable et atteignable. En dessous de 200 ms, vous êtes dans l'excellente plage. Au-delà de 800 ms, Google considère le TTFB comme devant être amélioré, et au-delà de 1 800 ms, il est jugé mauvais. Sur des pages non mises en cache (panier, compte client), accepter un TTFB jusqu'à 800 ms est tolérable à condition que le reste de la page bénéficie du cache objet Redis.

Le TTFB se mesure-t-il différemment sur mobile et desktop ?

La métrique TTFB en elle-même est identique : c'est le délai serveur, indépendant du terminal. Cependant, les données de terrain CrUX distinguent mobile et desktop, et le TTFB perçu sur mobile est souvent plus élevé en raison de la latence réseau 4G/5G variable. Si vous constatez un écart important entre vos mesures mobile et desktop dans PageSpeed Insights, la latence réseau est souvent en cause plutôt que le serveur lui-même. Dans ce cas, un CDN avec des points de présence rapprochés de vos utilisateurs mobiles est la solution la plus efficace.

Vous souhaitez savoir précisément où en est votre TTFB et comment il impacte votre SEO ? Demandez un audit technique gratuit : j'analyse votre temps de réponse serveur, vos Core Web Vitals et les leviers d'optimisation prioritaires pour votre site.