Un site qui tourne sans problème depuis trois ans, puis qui se met soudain à ramer, sans qu’aucune modification n’ait été faite. Des pages qui mettent huit à dix secondes à s’afficher, parfois un timeout pur et simple. Et quand on regarde le serveur, rien d’alarmant : le CPU tourne à 15-20%, la RAM à 60%. C’est exactement le genre de situation qui rend un diagnostic frustrant, parce que les indicateurs habituels ne montrent rien.

La réponse courte : sur un VPS aux ressources larges, une lenteur WordPress qui persiste malgré un serveur au repos vient presque toujours d’un goulot d’étranglement applicatif, pas matériel. Trois suspects reviennent le plus souvent : une version PHP ancienne sans OPcache actif, des requêtes MySQL lentes noyées dans des logs trop verbeux pour être lues à l’oeil, et des extensions accumulées depuis des années qui exécutent du code à chaque chargement de page, même quand elles ne servent plus à rien.

Pourquoi le CPU et la RAM ne racontent pas toute l’histoire

Un serveur peut afficher des ressources disponibles tout en étant lent, parce que la lenteur d’un site WordPress ne vient pas forcément d’un manque de puissance brute. Elle vient souvent d’un temps d’attente : PHP qui recompile le même code à chaque requête, une requête MySQL qui prend deux secondes sans jamais saturer le CPU, ou un appel réseau externe (API tierce, service de licence d’un plugin) qui bloque le rendu de la page pendant qu’il attend une réponse.

Le CPU à 20% ne dit rien sur le temps mort passé à attendre une ressource. C’est la différence entre un serveur occupé et un serveur qui perd du temps. Pour un diagnostic fiable, il faut mesurer le temps réellement passé dans chaque couche (PHP, MySQL, réseau), pas seulement l’occupation globale des ressources.

Première étape : mesurer avant de changer quoi que ce soit

Avant de toucher à la version PHP ou à la configuration, il faut un point de référence précis. GTmetrix donne une note globale utile pour suivre une tendance dans le temps, mais il ne dit pas où le temps est perdu côté serveur. Pour ça, il faut des outils qui regardent à l’intérieur de la requête.

  • Query Monitor (plugin WordPress) affiche, directement dans l’admin, le nombre de requêtes SQL exécutées par page, leur temps cumulé, et les hooks les plus lents.
  • New Relic ou l’équivalent proposé par certains hébergeurs OVH donne une vue par transaction, avec la répartition PHP / MySQL / externe.
  • php -i | grep opcache en SSH permet de vérifier en une commande si OPcache est seulement installé ou réellement activé.
  • Les logs lents MySQL (slow_query_log), une fois activés avec un seuil bas, remontent les requêtes qui passent inaperçues dans un usage normal.

Activer le log des requêtes lentes MySQL avec un seuil de 0,5 seconde permet de voir, sur une journée normale, ce qui traîne réellement :

slow_query_log = 1
slow_query_log_file = /var/log/mysql/mysql-slow.log
long_query_time = 0.5
log_queries_not_using_indexes = 1

Ce réglage seul suffit souvent à identifier une requête WooCommerce, un plugin de recherche ou une jointure mal indexée qui ralentit chaque page sans jamais faire grimper le CPU de façon visible.

PHP 7.4 vers 8.2 : ce que ça change vraiment

PHP 7.4 est en fin de vie depuis fin 2022, sans mise à jour de sécurité depuis. Ce n’est pas qu’un problème de conformité : les versions récentes de PHP apportent des gains de performance mesurables, indépendamment de tout réglage supplémentaire. Le moteur Zend a été retravaillé plusieurs fois entre PHP 7.4 et 8.2, avec un JIT (Just-In-Time compiler) introduit en 8.0, qui compile certaines portions de code à la volée plutôt que de les interpréter à chaque exécution.

Sur un WordPress classique avec quelques dizaines d’extensions, le passage de 7.4 à 8.2 apporte généralement un gain de temps de réponse PHP de 20 à 40%, avant même de toucher à OPcache. Mais ce chiffre varie énormément selon la compatibilité des extensions actives : certaines vieilles extensions abandonnées peuvent au contraire ralentir ou planter sous PHP 8.2, à cause de fonctions dépréciées ou de typage strict introduit dans les versions récentes.

La bonne méthode n’est donc pas de sauter directement à la dernière version, mais de passer par une étape intermédiaire testée en staging. Le guide complet sur comment mettre à jour PHP sur WordPress sans casser le site détaille la procédure de vérification de compatibilité avant bascule.

OPcache : la case souvent oubliée

Passer à PHP 8.2 sans activer correctement OPcache revient à changer de moteur sans faire le plein. OPcache stocke le bytecode compilé de vos fichiers PHP en mémoire, pour éviter de tout recompiler à chaque requête. Sur un site WordPress avec des centaines de fichiers PHP chargés par page (coeur, thème, extensions), l’absence d’OPcache actif se traduit directement par un temps de compilation répété, invisible dans les métriques CPU globales mais très présent dans le temps de réponse ressenti.

Une configuration de base raisonnable, à placer dans php.ini ou un fichier dédié comme opcache.ini :

opcache.enable=1
opcache.memory_consumption=256
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=20000
opcache.revalidate_freq=2
opcache.save_comments=1
opcache.validate_timestamps=1

opcache.max_accelerated_files mérite une attention particulière : sur un WordPress avec beaucoup d’extensions, le nombre de fichiers PHP dépasse facilement la valeur par défaut (souvent 10 000), ce qui fait qu’OPcache expulse et recompile des fichiers en permanence, un comportement qui ressemble à un cache qui ne sert à rien alors qu’il est techniquement actif. Comptez le nombre réel de fichiers PHP du site avant de fixer cette valeur :

find /var/www/monsite -name '*.php' | wc -l

Une fois OPcache réglé, vérifiez son taux de succès (hit rate) directement en PHP, avec un script temporaire à supprimer après usage :

<?php
$status = opcache_get_status();
echo 'Hit rate: ' . round($status['opcache_statistics']['opcache_hit_rate'], 2) . '%';
echo ' / Fichiers en cache: ' . $status['opcache_statistics']['num_cached_scripts'];
echo ' / Fichiers max: ' . ini_get('opcache.max_accelerated_files');

Un hit rate en dessous de 95% après quelques heures d’usage normal indique presque toujours un max_accelerated_files trop bas ou un revalidate_freq mal réglé pour le contexte (production vs développement).

Les extensions accumulées depuis trois ans

Sur un site géré seul depuis longtemps, sans revue régulière, les extensions s’accumulent rarement par excès de zèle : elles s’ajoutent une par une pour un besoin ponctuel, puis restent actives bien après que ce besoin a disparu. Chaque extension active charge son code à chaque chargement de page, qu’elle soit réellement utilisée sur cette page ou non.

Pour repérer les extensions coûteuses sans deviner, Query Monitor affiche un panneau dédié au temps d’exécution par hook, ce qui permet de voir concrètement quelle extension consomme le plus de temps PHP à chaque chargement. Un audit simple consiste à désactiver temporairement, une par une en environnement de test, les extensions non essentielles au fonctionnement du site, et à comparer le temps de réponse avant/après avec un outil comme curl en mesurant le temps total :

curl -o /dev/null -s -w 'Temps total: %{time_total}sn' https://monsite.fr/

Répétée plusieurs fois avec et sans une extension active, cette simple commande donne une mesure brute mais fiable de son coût réel.

Manager de transition ou audit externe : à quel moment ça se justifie

Pour un site personnel ou une petite structure, faire appel à un manager de transition infra est rarement le bon niveau d’intervention : ce type de mission concerne surtout des organisations avec une équipe technique existante à encadrer sur une période de changement, avec des budgets qui se comptent en dizaines de milliers d’euros sur plusieurs mois. Pour un diagnostic ponctuel de lenteur sur un WordPress, un audit technique ciblé (souvent facturé à la demi-journée ou à la journée par un freelance spécialisé perf/infra) est largement suffisant et beaucoup plus proportionné au besoin.

Avant de déléguer quoi que ce soit, la démarche de ce guide (Query Monitor, logs lents MySQL, vérification OPcache, audit des extensions) permet dans la majorité des cas d’identifier la cause soi-même, ou au minimum d’arriver face à un prestataire avec des données concrètes plutôt qu’une simple impression de lenteur, ce qui réduit fortement le temps (et le coût) de la mission.

Checklist de diagnostic dans l’ordre

  • Vérifier la version PHP active et sa date de fin de support.
  • Confirmer qu’OPcache est activé (pas seulement installé) et calculer max_accelerated_files selon le nombre réel de fichiers du site.
  • Activer temporairement le log des requêtes lentes MySQL avec un seuil de 0,5 seconde.
  • Installer Query Monitor et observer le temps cumulé par extension sur les pages les plus visitées.
  • Tester la mise à jour PHP en staging avant toute bascule en production, avec la liste des extensions actives comme feuille de route.
  • Désactiver les extensions inutilisées identifiées pendant l’audit.

Pour la partie strictement liée au ralentissement de l’interface d’administration plutôt qu’au site public, la cause est souvent différente (widgets du tableau de bord, plugins de statistiques trop gourmands) : le guide sur le back office WordPress lent couvre ce cas précis séparément.

FAQ sur un site WordPress lent malgré un serveur qui va bien

Le CPU et la RAM sont normaux, pourquoi mon WordPress reste-t-il lent ?

Parce que la lenteur vient souvent d’un temps d’attente (compilation PHP répétée, requête MySQL lente, appel réseau externe) plutôt que d’une saturation de ressources. Ces temps morts ne font pas forcément grimper le CPU de façon visible.

Passer de PHP 7.4 à 8.2 va-t-il vraiment améliorer les performances ?

Oui dans la majorité des cas, souvent entre 20 et 40% de gain sur le temps de réponse PHP, à condition de vérifier la compatibilité des extensions actives avant la bascule en production.

OPcache est installé sur mon serveur, est-ce suffisant ?

Non. Installé ne veut pas dire activé ni bien configuré. Vérifiez opcache.enable=1 et surtout opcache.max_accelerated_files, souvent trop bas pour un WordPress avec de nombreuses extensions.

Comment savoir si une extension ralentit vraiment le site ?

Installez Query Monitor et regardez le temps cumulé par extension sur une page réelle, ou désactivez-la temporairement en test et comparez le temps de réponse avec curl -w '%{time_total}'.

Faut-il engager un manager de transition pour ce genre de problème ?

Rarement pour un site personnel ou une petite structure. Un audit technique ciblé par un freelance perf/infra, facturé à la journée, est généralement suffisant et bien plus proportionné qu’une mission de manager de transition.

Sources et références

G
WP Admin Lab

Architecte web full-stack. WordPress, performance, data et sécurité. Notes de terrain, tests reproductibles et retours d'expérience.