TTFB : pourquoi c’est le premier indicateur technique à corriger en SEO

On répète que le TTFB est le premier indicateur à corriger, parce qu’il conditionne tout ce qui suit. C’est vrai, mais à une condition qu’aucun guide ne pose : encore faut-il que votre trafic passe par le serveur. Sur un site dont les pages vues sont servies depuis le cache, le TTFB de terrain est déjà bas et le travailler ne rapporte rien. Sur un site avec sessions, il devient le plafond de votre LCP. Savoir dans quel cas vous êtes est le vrai point de départ.

Ce que le TTFB mesure, et ce qu’il inclut vraiment

Le TTFB, Time To First Byte, est le délai entre l’envoi de la requête par le navigateur et la réception du premier octet de réponse. Il n’est pas un Core Web Vital, mais il sert de métrique de diagnostic.

Ce que beaucoup ignorent, c’est son périmètre exact. Le TFFB agrège plusieurs phases : la résolution DNS, l’établissement de la connexion TCP, la négociation TLS, le temps de traitement du serveur, et surtout toutes les redirections rencontrées avant d’atteindre la page finale. Un serveur qui génère la réponse en 150 millisecondes mais impose un passage de http vers https puis de la version sans www vers la version avec, ajoute deux allers-retours réseau complets, comptés dans le TTFB que Google observe sur le terrain.

Les seuils courants : satisfaisant sous 800 millisecondes, à améliorer entre 800 et 1800, problématique au-delà. Pour une page générée sans cache, viser moins de 500 millisecondes est un objectif raisonnable ; une page servie depuis le cache doit répondre en quelques dizaines de millisecondes.

Pourquoi il conditionne le reste

Le TTFB est un plancher. Le navigateur ne peut rien afficher, ni commencer à télécharger la moindre ressource, avant d’avoir reçu le premier octet du document. Un TTFB de 1500 millisecondes signifie que votre LCP ne descendra jamais sous 1,5 seconde, quelle que soit l’optimisation des images ou du CSS. Optimiser le rendu avant de régler le TTFB, c’est repeindre une pièce dont le plancher est en pente.

Il pèse aussi sur le budget de crawl. Un robot qui attend une à deux secondes par page explore moins d’URL dans le même temps. Sur un gros site, un TTFB élevé ralentit la découverte et la mise à jour des pages dans l’index.

D’où la règle « à corriger en premier ». Mais elle suppose que le TTFB observé par vos visiteurs soit effectivement mauvais, et cela dépend de qui sont vos visiteurs.

Le diagnostic préalable : votre trafic passe-t-il par le cache ?

La plupart des sites servent deux populations très différentes, avec deux TTFB.

Les visiteurs anonymes

Un internaute qui arrive depuis Google, sans être connecté à votre site, reçoit une page statique servie depuis le cache : cache de page du CMS, cache serveur, ou cache en périphérie d’un CDN. Le serveur ne régénère rien. Le TTFB est de l’ordre de quelques dizaines de millisecondes, plus la latence réseau. Il est déjà bon.

Les visiteurs connectés

Un client avec un panier, un membre identifié, un utilisateur d’un espace privé : sa page est personnalisée, donc elle contourne le cache et est régénérée à chaque requête. C’est là que le temps de traitement du serveur, les requêtes en base et les extensions lourdes se paient plein pot. Le TTFB peut monter à 1, 2, voire 3 secondes.

Comment savoir lequel domine

Faites deux mesures sur la même page : une en navigation privée, non connecté, et une en étant connecté avec une session active. Comparez les TTFB. Si l’écart est faible, votre trafic est essentiellement caché : le TTFB n’est pas votre priorité, concentrez-vous sur les ressources qui alimentent le LCP. Si l’écart est important et que vous avez une part significative d’utilisateurs connectés, e-commerce, marketplace, SaaS, B2B avec espace client, alors le TTFB backend est votre premier chantier, parce qu’il plafonne le LCP de vos utilisateurs les plus engagés.

Dans la Search Console et les données CrUX, le TTFB affiché mélange les deux populations. Cette segmentation manuelle est le seul moyen simple de savoir ce que vous devez réellement corriger.

Les redirections en chaîne : le gain TTFB qui ne touche pas au serveur

Même sur un site entièrement caché, un TTFB de terrain médiocre est possible, et la cause est presque toujours la même : une chaîne de redirections.

Le cas classique : une requête vers http://exemple.fr renvoie une redirection vers https://exemple.fr, qui renvoie elle-même vers https://www.exemple.fr. Trois requêtes, deux allers-retours réseau supplémentaires avant la première réponse utile, chacun ajoutant sa résolution DNS et sa poignée de main TLS. Sur mobile, avec une latence réseau élevée, cela peut représenter plusieurs centaines de millisecondes ajoutées au TTFB, invisibles dans un test en local mais bien présentes dans les données de terrain.

1. Tracer la chaîneDans les DevTools, onglet Réseau, cochez « Preserve log » et chargez la version http non-www de votre domaine. Comptez les réponses 301 avant d’atteindre la page finale.
2. Réduire à une seule redirectionLa cible finale doit être atteinte en un seul saut. Une règle de réécriture unique qui force à la fois le HTTPS et la variante canonique du domaine, plutôt que deux règles enchaînées.
3. Vérifier le HSTSUn en-tête Strict-Transport-Security évite le premier aller-retour en http pour les visiteurs déjà venus : le navigateur passe directement en https.

Ce chantier ne demande aucune intervention sur le code applicatif ni sur la base de données. C’est souvent le meilleur rapport gain sur effort de tout le sujet performance.

Quand le backend est vraiment en cause

Si votre diagnostic montre un TTFB élevé sur les pages non cachées, voici les causes par ordre de fréquence.

Un cas documenté sur un site avec sessions : de 2,13 secondes à 1,40 seconde de TTFB en conditions identiques, session active, grâce au seul chargement conditionnel des extensions et à un nettoyage backend. La même page, servie depuis le cache pour un visiteur anonyme, répondait déjà en moins de 100 millisecondes. Les deux chiffres coexistent sur le même site.

Mesurer correctement

Trois précautions pour ne pas se tromper de diagnostic.

Mesurer plusieurs gabarits. L’accueil, une page de catégorie, une fiche, une page de compte. Le TTFB n’est pas uniforme.

Mesurer à des heures différentes. Une variation forte entre midi et minuit sur un mutualisé signale un problème de voisinage, pas un problème de code.

Distinguer la première requête des suivantes. Sur un CMS avec cache, la toute première requête après une publication régénère la page en PHP et affiche un TTFB élevé, non représentatif. C’est la deuxième requête, servie depuis le cache, qui reflète l’expérience réelle des visiteurs.

Outils : l’onglet Réseau des DevTools pour la valeur en local, PageSpeed Insights et CrUX pour la donnée de terrain, un outil comme WebPageTest pour choisir la localisation de test.

Corriger dans le bon ordre

La séquence est claire. On segmente d’abord le TTFB entre trafic caché et trafic connecté. Si le trafic est majoritairement caché, on vérifie la chaîne de redirections et on la ramène à un saut : c’est le seul vrai levier TTFB dans ce cas, et il ne touche pas au serveur. Si une part importante du trafic contourne le cache, on attaque le backend dans l’ordre du tableau ci-dessus, en commençant par le cache d’objet et l’audit des extensions. Ensuite seulement, on passe au LCP et au reste.

Poser ce diagnostic et l’exécuter proprement, sans casser une personnalisation au passage, est un travail que mène un accompagnement en performance web, gabarit par gabarit et en mesurant chaque étape.