Réduire le TTFB de WordPress : causes et solutions

Le TTFB (Time To First Byte) est le délai entre la demande d’une page et la réception du premier octet de la réponse du serveur. Sur WordPress, un TTFB élevé vient presque toujours de pages générées sans cache, d’un PHP lent ou saturé, de requêtes SQL trop lourdes ou d’appels externes : on le réduit d’abord avec un cache de page côté serveur, puis en allégeant ce que WordPress exécute à chaque visite.

Guide à jour au 27 octobre 2026. Les seuils cités sont ceux publiés par Google sur web.dev ; les commandes ont été testées avec WP-CLI et curl.

Qu’est-ce que le TTFB et pourquoi compte-t-il ?

Le TTFB mesure le temps écoulé entre le début de la navigation et l’arrivée du premier octet de la page HTML. Tant que ce premier octet n’est pas arrivé, le navigateur ne peut rien afficher ni télécharger d’autre : chaque milliseconde de TTFB s’ajoute donc au temps d’affichage du contenu principal (LCP).

D’après la documentation de Google sur web.dev, le TTFB additionne plusieurs étapes, dont certaines ne dépendent pas de WordPress :

Les seuils de référence sont simples : un TTFB de 0,8 seconde ou moins est bon, entre 0,8 et 1,8 seconde il faut l’améliorer, au-delà il est mauvais. Google les présente comme un repère approximatif ; pour WordPress, qui renvoie une page HTML complète, viser moins de 0,8 seconde est raisonnable.

Comment mesurer le TTFB d’un site WordPress ?

Combinez trois sources : PageSpeed Insights pour les données réelles de vos visiteurs, l’onglet Réseau du navigateur pour une page précise, et curl en ligne de commande pour décomposer le temps et répéter la mesure. Testez toujours déconnecté de WordPress, car un administrateur connecté contourne le cache de page.

1. Les données de terrain (PageSpeed Insights)

PageSpeed Insights affiche, pour les pages suffisamment visitées, le TTFB mesuré chez de vrais utilisateurs de Chrome sur 28 jours glissants. Elle reflète l’expérience réelle, réseau mobile compris, mais évolue lentement : suivez-la comme une tendance. Notre guide des Core Web Vitals sur WordPress explique comment lire ce rapport.

2. L’onglet Réseau du navigateur

Ouvrez une fenêtre de navigation privée, les outils de développement (F12), l’onglet Réseau, puis rechargez la page. Cliquez sur la première ligne (le document HTML) et ouvrez l’onglet Timing : la ligne « Waiting for server response » correspond au temps de traitement côté serveur, distinct du DNS, de la connexion et du TLS. Dans l’onglet En-têtes, l’en-tête x-litespeed-cache indique, sur un serveur LiteSpeed, si la page vient du cache (hit) ou vient d’être générée (miss).

3. curl, pour décomposer et répéter la mesure

La commande suivante affiche le temps cumulé à chaque étape. time_starttransfer correspond au TTFB ; la différence avec time_appconnect donne le temps passé par le serveur à préparer la réponse.

curl -s -o /dev/null -w "DNS        : %{time_namelookup} s\nConnexion  : %{time_connect} s\nTLS        : %{time_appconnect} s\nTTFB       : %{time_starttransfer} s\nTotal      : %{time_total} s\n" https://www.example.com/

Lancez-la deux ou trois fois de suite, puis vérifiez l’état du cache :

# Première requête : souvent "miss" (page générée puis stockée)
# Requêtes suivantes : "hit" attendu (page servie depuis le cache)
curl -sI https://www.example.com/ | grep -i -E "x-litespeed-cache|cache-control|age"

TTFB élevé malgré un hit : cherchez côté réseau ou serveur. Forte baisse entre miss et hit : le cache fonctionne, optimisez la génération des pages non mises en cache.

Réseau ou serveur : d’où vient votre TTFB élevé ?

Regardez où le temps s’accumule. Si DNS, connexion et TLS pèsent lourd, le problème est réseau. Si l’attente entre la fin du TLS et le premier octet domine, c’est le serveur ou WordPress. Le tableau ci-dessous associe les symptômes les plus courants à leur cause probable.

Quelles sont les causes d’un TTFB élevé sur WordPress ?

Sans cache, chaque visite fait démarrer WordPress, charger le thème et les extensions, et exécuter des dizaines de requêtes SQL avant d’envoyer le moindre octet. Tout ce qui ralentit cette chaîne (PHP ancien, base de données encombrée, extension gourmande, appel à un service externe, serveur saturé) s’ajoute directement au TTFB.

• Cache absent ou contourné : cookies qui créent des variantes, paramètres d’URL (utm_, fbclid) traités comme des pages distinctes, purges complètes trop fréquentes.
• PHP ancien ou saturé : quand tous les processus PHP sont occupés, les requêtes suivantes font la queue.
• Base de données encombrée et extensions coûteuses : options autoload volumineuses, requêtes lourdes exécutées sur chaque page.
• Attentes évitables : appels HTTP externes bloquants, WP-Cron lancé pendant les visites, redirections en chaîne, serveur éloigné ou sous-dimensionné.

Comment réduire le TTFB de WordPress, étape par étape ?

Procédez dans l’ordre du rapport effort/gain : cache de page d’abord, puis PHP et cache d’objet, puis base de données, extensions et appels externes, et enfin réseau. Mesurez après chaque étape avec la même commande curl pour savoir ce qui a réellement fait baisser le TTFB.

1. Activer un cache de page côté serveur

C’est l’action la plus efficace : une page en cache est renvoyée sans exécuter PHP ni interroger la base de données. Sur un serveur LiteSpeed, l’extension gratuite LiteSpeed Cache pilote le cache intégré au serveur web. Suivez notre guide pour configurer LiteSpeed Cache réglage par réglage, puis vérifiez l’en-tête x-litespeed-cache: hit. Sur Apache ou Nginx, choisissez une seule extension de cache reconnue ; notre comparatif LiteSpeed, Nginx ou Apache détaille les différences.

2. Augmenter la part de pages servies depuis le cache

Allongez la durée de vie du cache public si vos contenus changent peu, évitez les purges complètes à chaque publication (la purge ciblée des pages concernées suffit), ignorez les paramètres de campagne dans la clé de cache, et limitez les exclusions aux pages réellement personnalisées : panier, commande, compte. Si votre hébergeur l’autorise, le robot de préchargement de LiteSpeed Cache remplit le cache avant le passage des visiteurs.

3. Passer à une version de PHP maintenue

Chaque version de PHP apporte des optimisations, et seules les versions maintenues reçoivent des correctifs de sécurité. Selon le calendrier officiel de PHP, la branche 8.2 ne reçoit plus que des correctifs de sécurité jusqu’au 31 décembre 2026, tandis que 8.3, 8.4 et 8.5 restent maintenues plus longtemps. WordPress recommande PHP 8.3 ou plus. Testez d’abord sur une copie du site : la version active est indiquée dans Outils > Santé du site > Infos > Serveur.

4. Ajouter un cache d’objet pour les pages dynamiques

Les pages exclues du cache (panier WooCommerce, espace membre, administration) repassent par la base de données à chaque fois. Un cache d’objet persistant, Redis ou Memcached, garde en mémoire le résultat des requêtes répétées. LiteSpeed Cache sait s’y connecter dans Cache > Objet lorsque le service est disponible sur votre hébergement. Chez Hosterwise, Redis est disponible sur toutes les offres : choisissez la méthode Redis, renseignez l’hôte et le port affichés dans votre espace client ou communiqués par le support, enregistrez, puis vérifiez que le test de connexion (Connection Test) réussit. Pour un site vitrine entièrement servi depuis le cache de page, le gain est faible.

5. Alléger les options chargées automatiquement

À chaque requête, WordPress charge en une fois toutes les options marquées « autoload ». Des extensions désinstallées laissent souvent derrière elles des options volumineuses. Depuis WordPress 6.6, l’outil Santé du site signale un problème lorsque leur taille totale dépasse 800 Ko, comme l’explique la note de l’équipe de développement de WordPress. Si votre hébergeur fournit un accès SSH, vérifiez la taille et repérez les plus grosses options avec WP-CLI (adaptez le préfixe wp_ si le vôtre est différent) :

# Taille totale des options chargées automatiquement (en octets)
wp db query "SELECT SUM(LENGTH(option_value)) AS octets FROM wp_options WHERE autoload IN ('yes','on','auto-on','auto');"

# Les 10 options autoload les plus volumineuses
wp db query "SELECT option_name, LENGTH(option_value) AS octets FROM wp_options WHERE autoload IN ('yes','on','auto-on','auto') ORDER BY octets DESC LIMIT 10;"

Si une grosse option appartient à une extension supprimée, faites une sauvegarde puis supprimez-la avec wp option delete nom_option. Si elle appartient à une extension active, désactivez seulement son chargement automatique avec wp option set-autoload nom_option off (WP-CLI récent) et contrôlez que le site fonctionne toujours. Chez Hosterwise, sans accès SSH (un choix de sécurité), lancez les deux mêmes requêtes SELECT dans l’onglet SQL de phpMyAdmin, ouvert depuis CyberPanel (rubrique Databases & FTP) ; pour supprimer une option ou désactiver son chargement automatique, faites une sauvegarde puis demandez-le à notre support 24/7, qui lance la commande pour vous.

6. Profiler WordPress pour trouver l’extension coupable

La commande wp profile, un module officiel de WP-CLI (utilisable avec un accès SSH), mesure le temps passé dans chaque phase du chargement (démarrage, requête principale, gabarit), puis dans chaque fonction accrochée à un hook. Elle s’exécute sans cache, ce qui correspond exactement au coût d’une page générée :

# Installer le module (une seule fois)
wp package install wp-cli/profile-command:@stable

# Temps par phase pour une URL donnée
wp profile stage --url=https://www.example.com/blog/

# Détail de la phase la plus lente, en masquant les valeurs proches de zéro
wp profile stage bootstrap --spotlight --url=https://www.example.com/blog/

# Fonctions les plus coûteuses sur un hook précis
wp profile hook init --spotlight --url=https://www.example.com/blog/

Dans le navigateur, l’extension Query Monitor complète ce diagnostic en listant les requêtes SQL lentes ou dupliquées par extension ; nous y consacrons un guide pour diagnostiquer un WordPress lent avec Query Monitor. Sans accès SSH, comme chez Hosterwise, c’est l’outil à privilégier ; notre support 24/7 peut aussi lancer wp profile pour vous.

7. Supprimer les appels externes bloquants

Une extension qui interroge une API distante pendant le chargement de la page fait attendre le visiteur aussi longtemps que ce service répond. Repérez ces appels (Query Monitor les liste dans son panneau « HTTP API Calls »), puis demandez à l’éditeur de l’extension de les mettre en cache, remplacez l’extension ou déplacez l’appel dans une tâche planifiée.

8. Confier WP-Cron au serveur

Par défaut, WordPress vérifie ses tâches planifiées pendant les visites. Désactivez ce déclenchement avec define( 'DISABLE_WP_CRON', true ); dans wp-config.php et programmez une tâche cron côté serveur toutes les cinq minutes, depuis votre panneau d’hébergement (chez Hosterwise, CyberPanel, rubrique Cron Jobs). La procédure complète figure dans notre guide pour accélérer un site WordPress en 15 actions.

9. Supprimer les chaînes de redirections

Chaque redirection ajoute un aller-retour complet avant la page. Un visiteur qui tape http://example.com ne devrait subir qu’une redirection, directement vers l’adresse définitive en https. Vérifiez avec :

# Affiche chaque réponse de la chaîne : une seule 301 attendue
curl -sIL http://example.com/ | grep -i -E "^HTTP|^location"

10. Optimiser le réseau : DNS, TLS 1.3, HTTP/3 et proximité

Un DNS rapide raccourcit la résolution, TLS 1.3 limite la négociation du chiffrement à un aller-retour, et HTTP/3 (QUIC) combine connexion et chiffrement en résistant mieux aux pertes de paquets sur mobile. Reste la distance : un serveur proche de vos visiteurs réduit chaque aller-retour ; pour une audience internationale, un CDN qui met en cache le HTML devient pertinent.

Comment voir où part le temps côté serveur avec Server-Timing ?

L’en-tête HTTP Server-Timing permet au serveur d’envoyer ses propres mesures au navigateur, qui les affiche dans l’onglet Timing des outils de développement. Vous voyez ainsi, dans le même écran, le temps réseau et le temps passé dans WordPress, sans installer d’outil supplémentaire.

Ce petit module à placer dans wp-content/mu-plugins/ ajoute deux mesures pour les administrateurs uniquement : la durée de démarrage de WordPress jusqu’au choix du gabarit, et le nombre de requêtes SQL exécutées à ce stade. La documentation MDN rappelle que ces informations peuvent renseigner un attaquant : ne les exposez pas au public.

<?php
/**
 * Plugin Name: Server-Timing (administrateurs)
 * Ajoute un en-tête Server-Timing visible dans les outils de développement.
 */
add_action(
	'template_redirect',
	static function () {
		if ( headers_sent() || ! current_user_can( 'manage_options' ) ) {
			return;
		}
		global $wpdb;
		header(
			sprintf(
				'Server-Timing: wp;desc="bootstrap+query";dur=%.1f, sql;desc="%d queries"',
				timer_float() * 1000,
				(int) $wpdb->num_queries
			)
		);
	},
	PHP_INT_MAX
);

Un administrateur connecté contourne le cache : la mesure reflète donc le coût d’une page générée. Si la valeur wp représente l’essentiel du TTFB, le goulot est dans PHP et la base de données ; sinon, regardez le gabarit, le réseau ou le serveur.

Quel TTFB viser selon le type de page ?

Toutes les pages ne se valent pas : une page servie depuis le cache dépend surtout du réseau, alors qu’une page personnalisée dépend de PHP et de la base de données. Fixez-vous des objectifs différents et concentrez vos efforts là où vos visiteurs passent le plus de temps.

Checklist : réduire le TTFB de WordPress

1. Mesurer trois pages types, déconnecté, avec curl (deux passages), et noter les valeurs.
2. Vérifier que l’en-tête de cache passe de miss à hit ; régler la purge ciblée.
3. Passer à PHP 8.3 ou plus après un test sur copie.
4. Activer un cache d’objet si le site comporte des pages dynamiques.
5. Contrôler la taille des options autoload (alerte à 800 Ko).
6. Profiler avec wp profile ou Query Monitor et traiter l’extension la plus coûteuse.
7. Supprimer les appels externes bloquants, confier WP-Cron au serveur, raccourcir les redirections.
8. Vérifier TLS 1.3 et HTTP/3, puis refaire les mesures.

Un hébergement LiteSpeed pour partir d’un TTFB bas

Les étapes 1 à 4 et 10 dépendent largement de votre hébergeur. Chez Hosterwise, toutes les offres tournent sur des serveurs LiteSpeed Enterprise avec le cache LSCache intégré, un cache d’objet Redis, HTTP/3 et des certificats SSL gratuits : le cache de page est servi directement par le serveur web, sans couche supplémentaire. Découvrez notre hébergement WordPress LiteSpeed ou comparez les offres Starter, Premium et Boost sur la page tarifs. Votre site est ailleurs ? Notre équipe s’occupe du transfert avec la migration gratuite.