Hébergement web et SEO : ce que coûte un TTFB lent

Le Time To First Byte (TTFB) mesure le temps qui s'écoule entre l'envoi d'une requête HTTP et la réception du premier octet de réponse. C'est un chiffre différent du temps de chargement total : une page peut afficher un LCP tout à fait correct grâce à des images compressées et un thème léger, tout en ayant un TTFB de 900 millisecondes parce que le serveur met neuf dixièmes de seconde à générer le HTML avant même que le navigateur ne commence à le recevoir. La plupart des guides sur la vitesse d'une page parlent des images, du CSS bloquant, de la mise en cache du navigateur ou des Core Web Vitals visibles à l'écran. Aucun ne s'arrête sur ce qui se passe avant que la première ligne de HTML n'arrive : le travail que fait votre hébergeur.

Cet article traite uniquement de cette partie-là : comment isoler le TTFB du reste du temps de chargement, ce qui distingue un hébergement mutualisé d'un VPS quand Googlebot explore un site en rafale, pourquoi un CDN peut cacher un TTFB catastrophique à Lighthouse sans le cacher à Googlebot, ce que change la position géographique du serveur pour une audience française, et comment savoir si le problème vient réellement de l'hébergeur avant de payer plus cher pour le découvrir.

TTFB : ce que ce chiffre mesure vraiment

Le TTFB additionne plusieurs étapes qu'on a tendance à confondre : la résolution DNS, la poignée de main TCP, la négociation TLS si le site est en HTTPS, puis le temps que le serveur met à construire la réponse avant d'en envoyer le premier octet. Les trois premières étapes dépendent surtout du réseau et sont largement hors de votre contrôle direct. La quatrième, le temps de traitement serveur, est celle qui révèle si votre hébergement, votre base de données et votre code font correctement leur travail.

Pour l'isoler, l'onglet Réseau des outils de développement du navigateur affiche une ligne « Attente » (Waiting for server response) dans le détail d'une requête : c'est le TTFB. PageSpeed Insights le signale sous l'intitulé « Réduire les temps de réponse initiaux du serveur » quand il dépasse un certain seuil. En ligne de commande, la façon la plus directe de mesurer uniquement ce chiffre, sans dépendance à un outil tiers, est curl avec l'option de format de sortie : curl -w "%{time_starttransfer}\n" -o /dev/null -s https://votresite.fr. Répétez la mesure plusieurs fois et à différentes heures : un TTFB stable donne une base fiable, un TTFB qui varie fortement selon le moment de la journée est déjà un indice sur la cause, abordé plus bas.

La documentation officielle de Google sur les Core Web Vitals (web.dev) situe un TTFB « bon » sous 800 millisecondes, et classe tout ce qui dépasse 1,8 seconde comme problématique. Le TTFB n'est pas lui-même un Core Web Vital nommé, mais il conditionne mécaniquement le LCP : le chronomètre du LCP démarre à la navigation, donc chaque milliseconde perdue avant le premier octet est une milliseconde que l'image ou le titre principal ne pourra jamais rattraper, quelle que soit l'optimisation appliquée côté navigateur.

Un TTFB élevé n'indique pas forcément un processeur trop lent. Il peut tout aussi bien venir d'une attente : le serveur interroge une base de données distante, appelle une API externe (un service de recommandation, une passerelle de vérification consultée même sur une page qui n'en a pas besoin, une extension qui contrôle une licence à chaque chargement), ou patiente sur une écriture disque vers un stockage réseau saturé. Dans ce cas, ajouter du CPU ou de la RAM ne change rien au problème : le serveur n'est pas occupé à calculer, il est occupé à attendre une réponse qui vient d'ailleurs.

Le piège du CDN : bon score Lighthouse, TTFB réel inchangé pour Googlebot

Un CDN met en cache des réponses sur des serveurs périphériques proches de l'endroit d'où part la requête. Quand cette réponse est déjà en cache, l'edge répond directement, sans jamais interroger le serveur d'origine : le TTFB mesuré est alors celui du CDN, pas celui de votre hébergement. C'est exactement ce que teste un audit Lighthouse ou PageSpeed Insights lancé depuis un point donné, souvent après plusieurs exécutions qui ont déjà réchauffé le cache pour cette URL précise. Le score peut être excellent alors que le serveur d'origine, lui, n'a jamais été sollicité pendant le test.

Googlebot ne se comporte pas comme un testeur qui recharge la page d'accueil dix fois de suite. Il explore des milliers d'URLs profondes, souvent visitées une seule fois toutes les quelques semaines, il revérifie régulièrement les URLs canoniques, et il rencontre des variantes (paramètres, slash final, contenu paginé) qui ne sont pas toutes servies depuis le même objet de cache. Une proportion bien plus importante de ses requêtes tombe donc en cache miss et remonte jusqu'à l'origine, là où votre hébergement fait tout le travail sans filet.

Pour vérifier ce qui se passe réellement pendant une exploration, ne vous fiez pas seulement à votre propre navigation : inspectez les en-têtes de réponse renvoyés (CF-Cache-Status chez Cloudflare, X-Cache ou Age chez d'autres CDN) sur un échantillon d'URLs peu visitées, et croisez avec le rapport « Statistiques sur l'exploration » de Search Console, qui reflète le temps de réponse réellement subi par Googlebot et non celui perçu par un outil de test isolé.

• Cache HIT : réponse servie par l'edge, TTFB indépendant de l'hébergement
• Cache MISS : requête transmise à l'origine, TTFB révélateur de l'hébergement
• Googlebot génère structurellement plus de cache miss qu'un visiteur ou qu'un outil d'audit

Mutualisé, VPS : ce qui se passe sous une rafale de crawl

Sur un hébergement mutualisé, plusieurs sites se partagent le même processeur, la même mémoire, le même pool de workers PHP-FPM et souvent la même instance de base de données. Le modèle économique du mutualisé repose sur l'hypothèse que la majorité des sites hébergés sont inactifs la plupart du temps : c'est ce qui permet des prix bas. Une salve de requêtes de Googlebot qui arrive en quelques secondes sur des dizaines d'URLs à la fois est précisément le type de charge concurrente que cette hypothèse ne couvre pas. Le pool de workers PHP-FPM, souvent limité à un petit nombre sur ces offres, met les requêtes en file d'attente ; le TTFB gonfle, et des réponses 503 peuvent apparaître si la file déborde.

Sur un VPS ou un serveur dédié, les ressources vous sont réservées, ou du moins garanties dans une certaine limite. Un mauvais TTFB dans ce contexte n'est presque jamais dû à « un autre client qui consomme le CPU » : c'est le plus souvent un problème de configuration, un nombre de workers mal dimensionné par rapport au trafic réel, une mémoire insuffisante qui pousse le système à utiliser le swap, ou une base de données jamais réglée depuis son installation par défaut.

Un moyen simple de distinguer contention et configuration sans outil d'analyse avancé : ouvrir un ticket auprès du support de l'hébergeur mutualisé et demander directement si le compte a été limité en CPU ou en nombre de processus PHP simultanés pendant la période concernée. La plupart des offres mutualisées imposent des quotas précis, documentés dans les conditions du plan mais rarement visibles dans un tableau de bord grand public ; l'hébergeur, lui, les connaît et peut confirmer si le compte les a atteints au moment des pics de TTFB.

• TTFB correct la nuit, mauvais aux heures de forte fréquentation partagée : signe de contention mutualisée
• TTFB mauvais en permanence, même avec peu de trafic propre : signe de configuration ou d'application, pas de voisinage
• Erreurs 503 ou délais intermittents visibles dans les journaux serveur pendant les fenêtres d'exploration : pool de workers saturé

La France, l'Europe, et la distance physique au serveur

Une partie du TTFB est de la pure physique réseau, indépendante de tout réglage logiciel : la distance parcourue par les paquets, le nombre de sauts entre routeurs, et la latence propre à chaque liaison. Un serveur hébergé aux États-Unis pour un site qui s'adresse essentiellement à un public français ajoute un aller-retour transocéanique incompressible avant même que le serveur ne commence à traiter quoi que ce soit. Aucune optimisation de code n'efface cette distance : elle s'ajoute au temps de traitement, elle ne le remplace pas.

Un hébergeur avec un datacenter en France, ou au minimum en Europe continentale, retire ce coût fixe de l'équation avant même que votre application n'entre en jeu. Un CDN avec un point de présence français atténue ce problème pour le contenu statique mis en cache, mais pas pour la requête dynamique qui doit atteindre l'origine à chaque cache miss, sauf à mettre en place une mise en cache complète de page au niveau de l'edge — une configuration que peu de sites activent réellement pour leurs pages dynamiques.

Le signal qu'on voit vraiment bouger : les statistiques d'exploration de Search Console

Le rapport « Statistiques sur l'exploration », accessible dans les réglages de Search Console, affiche entre autres le temps de réponse moyen du serveur constaté par Googlebot, réparti par code de réponse et par type de fichier, sur une fenêtre glissante de 90 jours. C'est l'un des rares endroits où l'on peut comparer objectivement un « avant » et un « après » sans se demander si l'effet observé vient d'autre chose.

La plupart des changements SEO produisent un effet diffus, étalé sur des semaines, mêlé à des dizaines d'autres variables : une mise à jour d'algorithme, un concurrent qui publie du contenu, une saisonnalité. Un changement d'hébergeur n'a pas ce problème. Notez le temps de réponse médian avant la migration, laissez à Googlebot quelques jours pour revenir explorer le site à son propre rythme, puis comparez la même fenêtre après coup. Si l'hébergement était réellement le goulot d'étranglement, la courbe bouge de façon visible et attribuable, ce qui est rarement le cas pour une action technique isolée en SEO.

Le plafond honnête : quand changer d'hébergeur ne sert à rien

Avant de payer pour une offre plus puissante, un test simple sépare un problème d'infrastructure d'un problème d'application : comparez le TTFB d'un fichier statique minimal, sans exécution de code, hébergé sur le même serveur (un fichier HTML nu, ou même robots.txt), avec le TTFB de la page dynamique réelle du site. Si le fichier statique répond en quelques dizaines de millisecondes et que la page dynamique met plusieurs centaines de millisecondes ou plus, le problème n'est pas l'hébergeur : c'est une requête de base de données non indexée, une extension qui fait un appel externe synchrone à chaque chargement, ou l'absence de mise en cache applicative. Un hébergement plus cher accélérera un peu ce genre de page grâce à un processeur plus rapide, mais il ne corrigera pas l'inefficacité elle-même : vous paierez plus pour rester lent.

Si au contraire le fichier statique lui-même répond lentement, le problème est réellement du côté de l'infrastructure : réseau saturé, ressources contendues avec d'autres locataires, ou capacité insuffisante pour le trafic réel. C'est le cas où changer d'hébergeur ou monter en gamme produit un effet direct et mesurable, celui que le rapport de Search Console rendra visible.

• Vérifier qu'un cache d'objets persistant (Redis ou Memcached) est actif si le CMS le permet : c'est souvent le levier le plus rentable avant tout changement d'offre
• Repérer une extension ou un module qui exécute un appel réseau ou un calcul lourd à chaque chargement de page
• Consulter le journal des requêtes lentes de la base de données si l'hébergeur ou le panneau d'administration l'expose
• Confirmer qu'une mise en cache complète de page est active pour les visiteurs anonymes, l'état dans lequel Googlebot se présente toujours
• Mesurer le TTFB à plusieurs heures de la journée avant de conclure : un pic isolé pendant une sauvegarde automatique nocturne ou une tâche planifiée n'a pas la même cause qu'une lenteur constante toute la journée