TTFB élevé sur WordPress : causes réelles et corrections

Un audit PageSpeed Insights qui affiche « Réduire le temps de réponse initial du serveur » et un TTFB (Time To First Byte) au-dessus de 600 ms, c’est un site WordPress qui perd des points Core Web Vitals avant même que le premier octet de HTML n’arrive au navigateur. Le problème ne se résout pas en installant un énième plugin de cache : la plupart du temps, la cause est structurelle et se situe dans la stack PHP/MySQL, pas dans le HTML ou le CSS. Voici où chercher, comment mesurer précisément, et quoi corriger.

Mesurer le TTFB correctement avant de corriger quoi que ce soit

Google PageSpeed donne un chiffre agrégé, mais pas la décomposition. Pour isoler le temps serveur pur, sans le bruit du DNS ou du TLS, la commande la plus fiable reste curl en ligne de commande :

curl -o /dev/null -s -w "DNS: %{time_namelookup}snConnexion: %{time_connect}snTLS: %{time_appconnect}snTTFB: %{time_starttransfer}snTotal: %{time_total}sn" https://votresite.fr/

Un TTFB sain se situe sous 200 ms pour une page en cache, et sous 600 ms pour une page générée dynamiquement sans cache. Au-delà de 800 ms sur une page cachée, il y a un problème réel à traiter, pas un détail à optimiser en marge.

L’hébergement mutualisé sous-dimensionné, cause numéro un

Sur un mutualisé bas de gamme, le PHP tourne avec un nombre de workers limité et partage le CPU avec des dizaines d’autres sites sur la même machine. Quand une requête WordPress met 400 ms à s’exécuter côté PHP parce que le processeur est contendu, aucun plugin de cache de page ne résout le problème sur les pages qui doivent rester dynamiques (panier WooCommerce, formulaire connecté, contenu personnalisé). Le test simple : comparez le TTFB d’une page statique HTML pure hébergée sur le même serveur avec celui d’une page WordPress. Si l’écart est de plusieurs centaines de millisecondes alors que la page WordPress est censée être en cache, l’hébergement est sous-dimensionné pour la charge réelle. Un VPS avec PHP-FPM configuré correctement (workers dédiés, pas de partage CPU avec d’autres locataires) règle ce point structurellement.

La base de données : requêtes non indexées et table wp_options surchargée

C’est la cause la plus fréquente sur les sites qui tournent depuis plusieurs années. La table wp_options accumule des lignes marquées autoload = yes, c’est-à-dire chargées à chaque requête même quand elles ne servent à rien sur la page affichée. Des plugins mal désinstallés laissent des dizaines de milliers de lignes autoloadées derrière eux. Pour diagnostiquer :

SELECT option_name, LENGTH(option_value) AS taille
FROM wp_options
WHERE autoload = 'yes'
ORDER BY taille DESC
LIMIT 20;

Si le total des lignes autoloadées dépasse 1 à 2 Mo, chaque page charge ce volume avant même de commencer à construire le HTML. C’est un cas typique où le nettoyage manuel ne suffit plus et où repartir sur une base propre, avec un thème natif et une structure de données maîtrisée, coûte moins cher à terme qu’un rafistolage permanent — c’est exactement le type de situation qui justifie une refonte site web plutôt qu’un énième plugin correctif.

Les plugins qui multiplient les requêtes SQL par page

Un plugin de builder de pages, un plugin SEO qui recalcule des scores à chaque chargement, ou un plugin de sécurité qui scanne en synchrone : chacun ajoute des requêtes SQL, des hooks WordPress supplémentaires, parfois des appels réseau externes bloquants. L’outil de diagnostic incontournable ici est Query Monitor. Une fois activé, il affiche le nombre de requêtes SQL par page et leur temps cumulé. Sur un site WordPress bien construit, on reste sous 30 à 40 requêtes pour une page de contenu standard. Au-delà de 100 requêtes, il y a systématiquement un ou plusieurs plugins qui interrogent la base en boucle, souvent dans une fonction appelée à chaque widget ou à chaque élément de menu au lieu d’une requête unique groupée.

Les page builders génèrent du travail serveur à chaque affichage

Elementor, Divi et consorts ne se contentent pas d’alourdir le HTML et le CSS envoyés au navigateur : ils exécutent, côté serveur, des couches de rendu supplémentaires à chaque requête non cachée pour transformer la configuration stockée en JSON en balisage HTML final. Ce traitement ajoute un temps PHP réel avant le premier octet, en plus du poids qu’il ajoute côté front. Un thème codé en PHP natif, sans couche d’abstraction de builder, élimine cette étape : le gabarit compile directement les données WordPress en HTML, sans passer par un moteur de rendu tiers. C’est la logique derrière une approche de wordpress sur mesure : moins de code exécuté à chaque requête, donc un TTFB mécaniquement plus bas, indépendamment de toute optimisation de cache.

L’absence de cache objet entre PHP et MySQL

Un cache de page (type WP Rocket, W3 Total Cache ou un cache serveur type FastCGI cache) sert du HTML statique pour les visiteurs anonymes, mais il ne fait rien pour les pages qui doivent rester dynamiques : panier, compte client, contenu affiché différemment selon l’utilisateur. Sur ces pages, chaque requête WordPress standard repasse par des dizaines d’appels à wp_options, aux transients, aux métadonnées de posts. Un cache objet persistant (Redis ou Memcached, via un plugin comme Redis Object Cache) intercepte ces appels et les sert depuis la mémoire au lieu de repasser par MySQL à chaque fois. Sur un site WooCommerce avec du trafic connecté significatif, l’écart de TTFB avant/après activation d’un cache objet dépasse fréquemment 300 à 500 ms. Vérifiez qu’il est actif :

wp cache type

Si la commande WP-CLI renvoie default au lieu de Redis ou Memcached, aucun cache objet persistant n’est en place.

Version de PHP obsolète et OPcache mal configuré

Chaque version majeure de PHP depuis PHP 7.4 a apporté des gains de performance mesurables sur l’exécution du code WordPress, PHP 8.1 et 8.2 étant nettement plus rapides que PHP 7.4 sur des benchmarks WordPress équivalents. Vérifier la version active :

wp cli info

Au-delà de la version, OPcache doit être activé et correctement dimensionné : sans lui, PHP recompile le code source à chaque requête au lieu de réutiliser le bytecode déjà compilé en mémoire. Sur un hébergement mutualisé, ce réglage n’est souvent pas accessible ; c’est un argument de plus pour migrer vers un environnement où la configuration PHP est sous contrôle.

La distance géographique entre le serveur et le visiteur

Un TTFB de 300 ms peut être partiellement dû à la latence réseau pure si le serveur est hébergé loin de l’audience majoritaire du site — un serveur aux États-Unis pour un site ciblant la France ajoute mécaniquement 80 à 150 ms de latence réseau avant même que le serveur ne commence à traiter la requête. Ce facteur se distingue du temps de traitement serveur : le test curl présenté plus haut isole time_connect (latence pure) de time_starttransfer (traitement inclus). Si l’écart entre les deux est déjà élevé avant tout traitement PHP, la solution est un hébergeur localisé en Europe pour une audience française, éventuellement complété par un CDN pour les assets statiques — le CDN n’améliore pas le TTFB du HTML dynamique lui-même, seulement celui des ressources qu’il sert directement.

FAQ

Quel TTFB viser pour de bons scores Core Web Vitals sur WordPress ?

Google recommande un TTFB sous 800 ms dans l’absolu, mais viser ce seuil comme objectif est trop permissif pour un site bien optimisé : sous 200 ms pour les pages en cache et sous 400-500 ms pour les pages dynamiques non cachées sont des cibles réalistes sur un hébergement correctement dimensionné avec un thème natif et un cache objet actif.

Un plugin de cache suffit-il à corriger un TTFB élevé ?

Non, dans la majorité des cas. Un plugin de cache de page réduit le TTFB uniquement pour les visiteurs anonymes sur des pages statiques. Il n’agit ni sur les requêtes SQL non indexées, ni sur les pages dynamiques (panier, compte client), ni sur le temps d’exécution PHP lié à un thème lourd ou à un hébergement sous-dimensionné : ces causes demandent un traitement à la source.

Comment savoir si le problème vient du thème ou de l’hébergement ?

Désactivez temporairement tous les plugins non essentiels et passez sur un thème par défaut WordPress (Twenty Twenty-Four) sur un environnement de test identique. Si le TTFB chute significativement, le thème ou les plugins sont en cause. S’il reste élevé même avec ce minimum, le problème est dans la configuration serveur, PHP ou base de données.

Si le diagnostic montre que la cause est structurelle — thème construit sur un page builder, base de données jamais nettoyée, hébergement inadapté au trafic réel — un audit technique permet de chiffrer précisément ce qui doit être repris avant d’investir davantage dans du contenu ou de l’acquisition de trafic.