WordPress lent : trouver la vraie cause avant de tout optimiser

Un site WordPress qui rame, c'est rarement une seule cause. Le réflexe habituel consiste à installer un plugin de cache, compresser les images, puis constater que rien ne change vraiment. La raison est souvent ailleurs : le serveur met trop de temps à produire la page, et aucune optimisation côté site ne rattrape ce retard.

Cet article donne une méthode de diagnostic en deux temps : séparer ce qui vient de votre site de ce qui vient de votre hébergement, puis agir au bon endroit.

1. Mesurer avant d'agir

Avant toute optimisation, il faut un point de départ chiffré. Trois outils suffisent :

• PageSpeed Insights : donne les Core Web Vitals de Google, avec les données réelles de vos visiteurs si votre site a assez de trafic.
• Une mesure du temps de réponse depuis votre poste, avec une simple commande :

curl -o /dev/null -s -w "TTFB : %{time_starttransfer}s | total : %{time_total}s\n" https://votre-site.fr

• Query Monitor, une extension gratuite qui affiche le nombre de requêtes SQL, les appels HTTP externes et les extensions les plus lentes, page par page.

2. Le TTFB, le juge de paix

Le TTFB (time to first byte) mesure le temps entre la requête du navigateur et le premier octet renvoyé par le serveur. C'est la partie que votre hébergement contrôle entièrement.

Google considère un TTFB correct en dessous de 800 ms, et vise idéalement quelques centaines de millisecondes. Surtout, retenez cette règle : le LCP ne peut jamais être plus rapide que le TTFB. Si votre serveur met 900 ms à répondre, votre plus grand élément visible ne s'affichera jamais sous les 2,5 secondes recommandées, quelle que soit la qualité de vos images.

3. Ce qui vient de votre site

Si le TTFB est bon mais que la page reste lente à s'afficher, le travail se fait dans WordPress :

• Les images sont la première cause. Servez-les en WebP, à la taille réellement affichée, avec le chargement différé natif de WordPress pour tout ce qui est sous la ligne de flottaison.
• Les extensions : une seule extension mal codée peut ajouter des dizaines de requêtes SQL par page. Query Monitor les identifie en quelques minutes. Désactivez ce que vous n'utilisez plus, plutôt que de le laisser dormir.
• Le thème et les constructeurs de page : les constructeurs visuels chargent souvent des feuilles de style et des scripts sur toutes les pages, même là où ils ne servent pas.
• Les scripts tiers : une carte, un chat, plusieurs outils de mesure. Chacun ajoute des connexions externes que vous ne maîtrisez pas.

4. Ce qui vient du serveur

Si le TTFB dépasse systématiquement 800 ms, cherchez ici :

• La version de PHP. WordPress recommande aujourd'hui PHP 8.3 ou plus récent. Passer d'une version 7.x à une version 8.x apporte un gain de performance immédiat, sans toucher au site. Vérifiez la compatibilité de vos extensions avant.
• La base de données. WordPress recommande MariaDB 10.11 ou MySQL 8.0 au minimum. Une table wp_options gonflée d'options chargées automatiquement, ou des révisions d'articles jamais nettoyées, alourdissent chaque requête.
• L'absence de cache serveur. Un cache de pages évite de régénérer le HTML à chaque visite ; un cache objet (Redis) évite de refaire les mêmes requêtes SQL. Sur un site dynamique, c'est souvent ce qui fait passer le TTFB de 800 ms à moins de 200.
• La distance. Un serveur situé à l'autre bout du monde ajoute de la latence à chaque requête. Pour une audience française, un hébergement en France supprime ce handicap.

Notre guide optimiser PHP-FPM et le cache Nginx détaille les réglages côté serveur.

5. La limite invisible du mutualisé

Sur un hébergement mutualisé, votre site partage le processeur, la mémoire et surtout les entrées-sorties disque avec des dizaines, parfois des centaines d'autres sites. Deux conséquences que les tableaux comparatifs n'affichent jamais :

• Vos performances dépendent des voisins. Un site qui se fait attaquer ou un script mal écrit sur la même machine ralentit le vôtre, sans que vous puissiez agir.
• Les limites sont silencieuses. Nombre de processus PHP simultanés, requêtes SQL par heure, mémoire par script : quand le plafond est atteint, les visiteurs attendent ou reçoivent une erreur, souvent au pire moment, celui où vous avez du trafic.

C'est pour cette raison qu'un même site WordPress peut afficher un TTFB de 800 ms sur un mutualisé chargé et de 200 ms sur un serveur dédié à lui seul, sans qu'une seule ligne de code ait changé.

6. Faut-il changer d'hébergement ?

Soyons honnêtes : tous les sites n'ont pas besoin d'un VPS. Voici comment trancher.

Restez sur un hébergement mutualisé si

• Votre site est une vitrine ou un blog avec un trafic modéré.
• Votre TTFB est déjà sous 500 ms aux heures de pointe.
• Vous ne voulez pas administrer un serveur.

Dans ce cas, notre hébergement web avec Plesk suffit largement, et vous n'avez rien à maintenir.

Passez sur un VPS si

• Votre TTFB dépasse 800 ms alors que le site est déjà optimisé.
• Vous vendez en ligne : un panier et un tunnel de commande ne se mettent pas en cache.
• Vous avez des pics de trafic, des tâches planifiées lourdes ou plusieurs sites à héberger.
• Vous voulez choisir votre version de PHP, ajouter Redis ou régler votre cache vous-même.

Nos VPS NVMe réservent leurs ressources à votre site seul.

Pour dimensionner correctement, lisez quelle configuration de VPS pour WordPress, et pour le déménagement lui-même, notre guide migrer WordPress vers un VPS sans coupure.

À lire ensuite

Migrer WordPress vers un VPS sans coupure

Migrer un site WordPress d'un hébergement mutualisé vers un VPS sans interruption : préparation, transfert, test avant bascule, DNS, SSL et vérifications.

Quel VPS pour héberger WordPress ?

RAM, vCPU, disque : quelle configuration de VPS pour un site WordPress selon son trafic, avec ou sans panel, et ce que coûte vraiment l'hébergement.

NVMe, SSD SATA ou HDD : quel stockage ?

NVMe Gen4, SSD SATA ou disque dur : quelles différences réelles de performance pour un VPS ou un serveur dédié, et quand cela se ressent sur votre projet.

Questions fréquentes