200 ms : objectif sérieux ou chiffre de forum ?
Ce seuil vient de l'ancienne règle de PageSpeed Insights, qui demandait de ramener le temps de réponse du serveur sous 200 ms. Google est devenu plus souple depuis : sur web.dev, il considère qu'un TTFB de 0,8 seconde ou moins est bon (voir sa page consacrée au Time to First Byte).
Alors pourquoi viser plus bas ? Parce que rien ne s'affiche avant le premier octet. Chaque milliseconde perdue là est retirée du budget de votre LCP, et Googlebot explore plus volontiers un serveur qui répond vite et sans à-coups. Mais un TTFB de 150 ms n'a jamais fait monter une page faible : on retire un frein, on n'ajoute pas de moteur.
Nuance importante : une page servie depuis un cache descend sous 200 ms sur à peu près n'importe quel hébergement correct. Une page générée à la volée (panier WooCommerce, utilisateur connecté), c'est une autre paire de manches. Fixez l'objectif sur les pages que voient Google et vos visiteurs anonymes, c'est-à-dire presque toutes.
Mesurer avant de toucher quoi que ce soit
Le TTFB additionne plusieurs étapes : redirections éventuelles, résolution DNS, connexion TCP, négociation TLS, puis le temps que le serveur met à préparer sa réponse. Régler PHP quand le vrai coupable est un détour par http puis par www, c'est taper à côté. Une redirection de trop ajoute un aller-retour complet, d'où l'intérêt de savoir corriger une chaîne de redirections, et combien de sauts Google accepte de suivre.
Mon premier réflexe, depuis un terminal :
curl -o /dev/null -s -w "DNS : %{time_namelookup}\nTCP : %{time_connect}\nTLS : %{time_appconnect}\nTTFB : %{time_starttransfer}\n" https://votre-site.fr/Les valeurs sont cumulées, en secondes. Si l'écart entre la ligne TLS et la ligne TTFB représente presque tout le total, c'est le serveur qui traîne. Si DNS ou TCP pèsent lourd, regardez du côté du réseau et de la distance. Lancez la commande trois ou quatre fois : la première requête tombe souvent sur un cache froid.
Vérifiez ensuite si la page sort vraiment du cache. Un curl -I affiche les en-têtes : la plupart des extensions et des CDN y glissent un indicateur (x-cache, cf-cache-status, ou un commentaire en bas du code HTML). Ajoutez un paramètre bidon à l'URL, du type ?test=1, et vous obtenez souvent une génération à la volée. Vous avez vos deux chiffres.
Le cache de pages, le réglage qui fait presque tout
Sans cache, chaque visite réveille PHP, charge WordPress et ses extensions, interroge la base de données des dizaines de fois, puis assemble le HTML. Avec un cache de pages, le serveur renvoie un fichier déjà prêt. On passe de « calculer » à « livrer ».
Le bon outil dépend du serveur. Sur un hébergement LiteSpeed, l'extension LiteSpeed Cache travaille au niveau du serveur web, c'est le choix logique. Sur Apache ou Nginx, WP Rocket, WP Super Cache ou W3 Total Cache génèrent des pages statiques. Sur un VPS que vous administrez, le cache FastCGI de Nginx (ou Varnish) sert les pages sans même solliciter PHP : la voie la plus rapide, et la plus technique.
Le piège classique, c'est le cache qui ne s'applique jamais. Une extension de consentement ou de test A/B qui pose un cookie sur toutes les pages, et beaucoup de caches s'écartent poliment. Une durée de vie trop courte sur un site à faible trafic, et le cache expire avant que quiconque en profite. Activez le préchargement : c'est le robot de l'extension qui doit régénérer les pages, pas votre premier visiteur. Ni Googlebot.
PHP : version, OPcache et processus
Pour tout ce qui échappe au cache, le moteur PHP reprend la main. Première vérification : la version. Les branches 8.x sont nettement plus véloces que les anciennes 7.x, et WordPress recommande une version 8 récente. Ça se change en deux clics dans la plupart des panneaux d'hébergement (testez sur une copie si votre thème a de l'âge).
Ensuite, OPcache. Il garde en mémoire le code PHP déjà compilé au lieu de relire et recompiler les fichiers à chaque requête (le principe est décrit dans la documentation officielle de PHP). Il est livré avec PHP, mais pas toujours bien dimensionné : WordPress plus une vingtaine d'extensions, ça fait beaucoup de fichiers. Les directives à regarder :
opcache.memory_consumption: la mémoire allouée, à augmenter si elle sature ;opcache.max_accelerated_files: le nombre de scripts que le cache peut garder ;opcache.revalidate_freq: à allonger en production, là où le code bouge peu.
Reste PHP-FPM, sur un VPS. Quand tous les processus sont occupés, la requête suivante attend son tour, et cette attente atterrit directement dans le TTFB. Dimensionnez pm.max_children selon la RAM disponible et la mémoire consommée par processus. Le mode ondemand économise de la mémoire mais ajoute un temps de démarrage ; sur un site au trafic régulier, dynamic répond plus vite. Sur un mutualisé, c'est souvent ce plafond qui explique les lenteurs aux heures de pointe.
Base de données et extensions : les suspects habituels
Premier suspect, la table wp_options. Toutes les options en chargement automatique (autoload) sont lues à chaque requête, et des extensions supprimées y laissent parfois des données volumineuses. L'écran Santé du site de WordPress signale quand ce volume devient trop gros. Second suspect : les extensions qui appellent une API externe pendant la génération de la page. L'extension Query Monitor les démasque en quelques minutes.
Le cache objet persistant (Redis ou Memcached) conserve les résultats de requêtes d'une visite à l'autre. Inutile pour une page déjà servie par le cache de pages, précieux pour les utilisateurs connectés, WooCommerce et l'administration.
Réseau et hébergement : le HTML doit encore voyager
Même un HTML tout prêt doit traverser le réseau, et une connexion HTTPS demande plusieurs allers-retours avant le premier octet. Pour un public francophone, un serveur en France ou dans un pays voisin est le choix évident. Activez TLS 1.3 (un aller-retour de moins à la négociation par rapport à TLS 1.2) et HTTP/2, voire HTTP/3 si votre hébergeur le propose.
Étape suivante : mettre le HTML lui-même en cache sur un CDN, au plus près du visiteur. Par défaut, la plupart des CDN ne cachent que les images, les CSS et les scripts. Il faut une règle dédiée (chez Cloudflare, une règle de cache ou l'option APO pensée pour WordPress), en excluant soigneusement panier, compte client et pages de connexion.
Si, malgré tout ça, les pages non cachées restent lentes, la machine elle-même est en cause. C'est le moment de mesurer l'impact réel d'un mutualisé ou d'un VPS sur votre référencement avant de déménager.
Vérifier que Google voit la différence
Côté utilisateurs réels, PageSpeed Insights affiche le TTFB mesuré dans Chrome quand le site a assez de trafic, avec quelques semaines de décalage. Côté robot, le rapport Statistiques sur l'exploration de la Search Console donne un temps de réponse moyen, et vos journaux serveur peuvent enregistrer la durée de chaque requête. Si vous avez l'habitude d'analyser vos logs serveur sous l'angle SEO, filtrez sur Googlebot : c'est la mesure la plus honnête de ce que le robot subit vraiment.
Mesurer, cacher, régler PHP, rapprocher : dans cet ordre, vous aurez réglé l'essentiel avant même de vous demander s'il faut changer d'hébergeur.