Trois fichiers pour savoir qui ralentit votre WordPress

12 novembre 2026

Ou : avant de déménager, vérifiez que ce n’est pas vous qui avez rempli le grenier.

La réponse courte : pour savoir si un site WordPress lent souffre de son hébergeur ou de ses extensions, chronométrez trois adresses sur le même serveur : un fichier texte, un fichier PHP d’une ligne et une page WordPress. Si le fichier texte est déjà lent, le problème est le réseau ou la machine. Si le texte est rapide et le PHP lent, c’est l’hébergeur ou l’offre. Si seul WordPress est lent, ce sont les extensions, le thème ou les requêtes, et changer d’hébergeur n’y changera presque rien. L’outil de mesure est curl, dont la variable time_starttransfer donne, selon son manuel officiel, le temps écoulé jusqu’au premier octet reçu, calcul du serveur compris. Ce diagnostic vient avant toute décision sur l’hébergement de votre site WordPress.

Le chiffre mesuré s’appelle le TTFB, le temps de réponse jusqu’au premier octet. Pour le juger, web.dev fixe ses repères du TTFB : bon à 0,8 seconde ou moins, mauvais au-delà de 1,8 seconde. Ces seuils valent pour la page complète vue par un visiteur ; ici, c’est l’écart entre les trois fichiers qui compte, plus que leur valeur absolue.

Pour qui : un site WordPress dont le diagnostic a mis l’hébergeur en cause, et qui cherche une version récente de PHP et une mémoire de script généreuse.
À partir de : 5,75 € par mois hors TVA, facturés à l’année, pour l’hébergement WordPress Infomaniak, proposé sur son hébergement web (tarif affiché le 12 novembre 2026).
Pour démarrer : commander l’hébergement web Infomaniak, copier le site, puis refaire les trois mesures avant de basculer le domaine.

Site WordPress lent : le protocole des trois fichiers

Déposez deux fichiers à la racine du site, par FTP ou dans le gestionnaire de fichiers du panneau, puis mesurez chaque adresse une dizaine de fois, depuis la même machine, et gardez la valeur du milieu. Une mesure isolée ne dit rien : la première requête d’une série paie souvent la résolution DNS et l’ouverture de la connexion chiffrée.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
# 1. un fichier statique : aucun PHP
echo ok > test.txt
# 2. un fichier PHP d'une ligne : PHP, mais pas WordPress
echo '<?php echo "ok";' > test.php

# 3. dix mesures par adresse, valeur du milieu affichée
for page in test.txt test.php "" ; do
  for i in $(seq 10); do
    curl -s -o /dev/null -w "%{time_starttransfer}\n" "https://votre-site.be/$page"
  done | sort -n | sed -n '5p'
done

La troisième adresse, vide, mesure la page d’accueil. Notez si elle sort du cache de l’hébergeur : une page servie par le cache masque la lenteur de WordPress au lieu de la mesurer. Pensez à supprimer les deux fichiers de test à la fin.

Résultat	Coupable probable	Suite à donner
`test.txt` déjà lent	réseau, distance du centre de données, machine saturée	mesurer depuis un autre lieu, puis interroger l’hébergeur
`test.txt` rapide, `test.php` lent	démarrage de PHP, processus PHP saturés, offre trop petite	consulter les graphiques de ressources du panneau, envisager un autre palier ou un autre hébergeur
`test.php` rapide, WordPress lent	extensions, thème, requêtes à la base, appels à des services externes	Query Monitor, puis désactivation ciblée
Tout rapide la nuit, lent en journée	voisins ou plafonds du compte	comparer les heures de mesure aux graphiques de ressources

Méthode décrite le 12 novembre 2026 ; aucun chiffre de mesure n’est publié ici, parce que le seul qui compte est celui de votre site.

On ausculte d'abord, on opère ensuite : trois mesures évitent un déménagement inutile.

Quand WordPress est en cause, l’extension Query Monitor, active sur plus de 200 000 sites et testée jusqu’à WordPress 7.1.4 selon sa fiche relue le 12 novembre 2026, ouvre le capot. Elle regroupe les requêtes à la base de données par extension, par thème ou par fonction responsable, signale les requêtes lentes, en double ou en erreur, et liste les appels HTTP sortants. Ce dernier point trahit un classique : l’extension qui interroge un service distant à chaque affichage de page, et fait attendre le visiteur le temps de la réponse.

Pour confirmer un suspect sans casser le site, l’extension Health Check & Troubleshooting, publiée sur wordpress.org, désactive toutes les extensions et bascule sur un thème par défaut pour votre seule session, jusqu’à ce que vous en sortiez. On réactive ensuite les extensions une à une, en refaisant la mesure de la page WordPress à chaque étape. La première qui fait remonter le temps de réponse a gagné le droit d’être remplacée.

Quand la page mesurée sortait du cache

Une page d’accueil servie par le cache répond vite, même quand WordPress met longtemps à la reconstruire : la mesure flatte alors le site au lieu de le juger. Les en-têtes X-LiteSpeed-Cache, x-proxy-cache ou X-Kinsta-Cache disent qui a servi la page, comme l’explique le cache serveur de WordPress chez l’hébergeur.

Quand la lenteur finit en erreur

Une page qui ralentit puis tombe sur une erreur fatale, parfois après une importation ou une mise à jour, a souvent heurté la limite de mémoire de PHP. Savoir qui fixe cette limite et comment la relever est le sujet de l’erreur « Allowed memory size exhausted ».

Quand c’est vraiment l’hébergeur

Si test.php est lent, aucune extension n’y peut rien, et le choix d’un autre hébergeur se fait sur des valeurs publiées : version de PHP, processus PHP simultanés, cache. Les douze à vérifier sont réunies dans les critères pour choisir un hébergement WordPress.