TTFB WordPress : comment diagnostiquer et réduire le temps de réponse serveur en dessous de 200 ms
Le TTFB (Time To First Byte) est le temps que met votre serveur à commencer à envoyer une réponse. Un TTFB > 600 ms rend impossible un bon score LCP. Sur WordPress, les causes sont multiples : absence de cache, base de données non optimisée, hébergement mutualisé saturé, PHP sans OPcache. Ce guide diagnostique et corrige chaque cause méthodiquement.
Le TTFB (Time To First Byte) est la première étape du chargement d’une page web : le temps entre l’envoi de la requête HTTP et la réception du premier octet de la réponse. C’est la fondation de toutes les performances — si votre serveur met 1 seconde à répondre, aucune autre optimisation ne peut compenser.
Mesurer le TTFB avec précision
Chrome DevTools
F12 → Network → sélectionnez votre URL principale → survol → vous verrez le détail : Queued, DNS Lookup, Connect, SSL, Waiting (TTFB), Content Download. Le TTFB correspond à « Waiting ».
PageSpeed Insights
La métrique TTFB n’est pas affichée directement, mais « Temps de réponse du serveur (TTFB) » apparaît dans les diagnostics si votre TTFB dépasse 600 ms.
WebPageTest.org
Outil gratuit plus précis : il affiche le TTFB par étape (DNS, connect, SSL, TTFB) avec des tests depuis plusieurs localisations géographiques.
Seuils TTFB recommandés
| TTFB | Évaluation | Impact LCP |
|---|---|---|
| < 200 ms | Excellent | LCP atteignable < 2 s |
| 200–600 ms | Acceptable | LCP < 2,5 s difficile |
| > 600 ms | Problématique | LCP > 3 s quasi-certain |
Cause n°1 : absence de cache de page (le plus fréquent)
Sans cache, WordPress exécute PHP + des dizaines de requêtes SQL pour générer chaque page. Sur un hébergement mutualisé, cela prend 400 à 1 500 ms. Avec un cache de page actif :
- WP Rocket : TTFB de 20 à 80 ms (fichier HTML statique servi)
- LiteSpeed Cache : TTFB de 10 à 50 ms (cache serveur LiteSpeed)
- Nginx FastCGI Cache (VPS) : TTFB de 5 à 30 ms
Action : installez WP Rocket ou LiteSpeed Cache immédiatement. C’est la correction à l’impact le plus élevé.
Cause n°2 : PHP sans OPcache
OPcache stocke le bytecode PHP compilé en mémoire, évitant de recompiler les fichiers PHP à chaque requête. Sans OPcache, chaque requête WordPress recompile 300 à 500 fichiers PHP.
Vérification : créez un fichier info.php avec <?php phpinfo(); ?> et cherchez « opcache.enable » → doit être « On ». Sinon, contactez votre hébergeur pour activer OPcache.
Gain typique avec OPcache : réduction du TTFB de 30 à 60 % sur les pages non cachées.
Cause n°3 : base de données lente
WordPress exécute 20 à 50 requêtes SQL par page sur un site moyen. Des tables non indexées, une table wp_options gonflée ou des requêtes N+1 peuvent multiplier le TTFB par 3 ou 4.
Diagnostic : installez le plugin Query Monitor (gratuit) pour voir le nombre de requêtes SQL, leur durée et les requêtes lentes.
Actions correctives :
- Nettoyer wp_options : supprimer les autoloaded options des plugins désinstallés avec Advanced Database Cleaner
- Installer Redis Object Cache : met en cache les résultats des requêtes SQL récurrentes
- Optimiser les tables :
OPTIMIZE TABLE wp_posts, wp_postmeta, wp_options;via phpMyAdmin
Cause n°4 : hébergement mutualisé saturé
Sur un hébergement mutualisé, vous partagez les ressources CPU et RAM avec des centaines d’autres sites. Aux heures de pointe, votre TTFB peut tripler sans que vous y soyez pour quoi que ce soit.
Solution à court terme : ajouter Cloudflare CDN en cache HTML pour absorber le trafic. Solution définitive : migrer sur un VPS (Hetzner, OVH VPS, Scaleway) ou un managed WordPress (Kinsta, SiteGround Go). Notre service d’hébergement WordPress + Cloudflare inclut cette migration.
Cause n°5 : trop de plugins actifs
Chaque plugin actif sur WordPress exécute du code PHP à chaque chargement de page, même s’il n’est pas utilisé sur cette page. 30 plugins actifs peuvent ajouter 200 à 600 ms de TTFB.
Règle : auditez régulièrement vos plugins. Si vous n’utilisez pas activement un plugin, désactivez-le. Utilisez Perfmatters pour désactiver des plugins par page/post type.
Cause n°6 : PHP version obsolète
PHP 8.2 est 20 à 30 % plus rapide que PHP 7.4 sur WordPress. PHP 8.3 apporte encore des gains supplémentaires. Vérifiez votre version PHP dans votre panneau d’hébergement et mettez à jour si vous êtes sous PHP 8.0.
Questions fréquentes sur le TTFB WordPress
Mon TTFB est bon sans Cloudflare mais lent avec — que se passe-t-il ?
Si Cloudflare augmente votre TTFB, c’est que le cache Cloudflare est bypassé (vous voyez « MISS » dans le header Cf-Cache-Status) et que la requête est transmise à votre serveur avec un aller-retour supplémentaire. Vérifiez vos Page Rules Cloudflare et assurez-vous que le cache HTML est activé pour les pages statiques.
Le Redis Object Cache améliore-t-il le TTFB sur les pages cachées ?
Non. Si votre page est dans le cache de page (HTML statique), Redis n’est pas sollicité — la page est servie directement depuis le disque ou la mémoire. Redis améliore le TTFB des pages non cachées (admin, pages personnalisées, WooCommerce checkout).
Quel est le TTFB typique avec WP Rocket sur OVH mutualisé ?
Avec WP Rocket sur OVH Pro, le TTFB des pages cachées est typiquement de 50 à 150 ms pour les visiteurs européens. Sans cache, le TTFB sur OVH mutualisé est de 400 à 1 200 ms selon la charge serveur et la complexité de votre site.