Votre WordPress est lent et ce ne sont pas les images : 7 causes cachées et comment les résoudre

Vous avez compressé les images, activé le cache et supprimé les plugins que vous n’utilisiez pas. PageSpeed semble même être d’accord avec vous. Mais WordPress continue de prendre trop de temps à répondre.

Le problème de la lenteur de WordPress ne réside peut-être pas dans ce que le navigateur télécharge, mais dans tout ce qui se passe avant : des requêtes qui ne se terminent pas, des tâches accumulées, des options qui se chargent inutilement ou des processus bloqués.

Installer un autre plugin pour essayer d’accélérer WordPress ne résoudra pas toujours le problème. Parfois, cela ne fait qu’ajouter plus de travail à un WordPress qui en a déjà trop. Voici sept causes moins visibles, comment les détecter et ce que vous pouvez faire pour les résoudre.

Avant tout, découvrez où se produit la lenteur

Ne commencez pas à nettoyer la base de données ni à désactiver des fonctions au hasard. Essayez d’abord de localiser le problème.

Vérifiez si la lenteur :

• Affecte tout le site ou seulement une page.
• Apparaît également dans le panneau d’administration.
• Se concentre sur les produits, commandes ou processus de WooCommerce.
• Se produit de manière continue ou seulement à certaines heures.
• Coïncide avec des sauvegardes, importations ou envois de courriels.
• Apparaît avant que la page ne commence à s’afficher.

Le temps que le serveur met à envoyer le premier octet (connu sous le nom de TTFB) peut vous donner un premier indice. Si l’attente se produit avant que le navigateur ne commence à recevoir du contenu, compresser une autre image ne résoudra probablement pas le problème.

Ce que vous devriez vérifier en premier

Symptôme	Cause possible	Où vérifier
Tout le site met du temps à commencer à charger	Options autoload ou requêtes lentes	Santé du site ou Query Monitor
Les tâches s’exécutent en retard ou ne se terminent pas	WP-Cron ou requêtes loopback	WP Crontrol ou Santé du site
WooCommerce retarde les commandes, courriels ou abonnements	Actions programmées bloquées	WooCommerce → État
La base de données croît continuellement	Transients ou résidus de plugins	Outil de nettoyage de la base de données
Seul un écran est lent	Requête inefficace ou dupliquée	Query Monitor
La lenteur apparaît à certaines heures	Cron, sauvegardes ou processus automatiques	WP Crontrol ou journaux du serveur

Appliquez un changement à la fois et mesurez à nouveau. Si vous modifiez simultanément cinq éléments, le site peut s’améliorer, mais vous ignorerez ce qui causait le problème ni comment agir si cela se reproduit.

Pour compléter le diagnostic, vous pouvez utiliser ConnectiLogs, un outil de cdmon qui présente de manière visuelle les informations des journaux du serveur et aide à détecter les erreurs, accès échoués ou comportements suspects.

Avant de modifier la base de données ou la configuration de WordPress, créez une sauvegarde. Si possible, testez d’abord les changements dans un environnement de staging.

WordPress charge trop d’options autoload

Que se passe-t-il ?

WordPress stocke dans la table wp_options beaucoup de données dont il a besoin pour fonctionner, comme les réglages du thème, la configuration des plugins et d’autres préférences du site.

Certaines de ces options sont marquées comme autoload, ce qui signifie que WordPress les charge automatiquement chaque fois que quelqu’un visite une page, même si elles ne sont pas nécessaires à ce moment-là.

Cela ne pose pas de problème lorsqu’il y a peu de données. Le site peut commencer à ralentir lorsqu’il accumule des données de plugins que vous n’utilisez plus, de thèmes supprimés ou d’outils qui stockent plus d’informations que nécessaire.

Comment le résoudre ?

Accédez à :

Outils → Santé du site → État

WordPress peut afficher un avertissement s’il détecte une grande quantité d’options chargées automatiquement.

Pour enquêter sur leur origine, vous pouvez utiliser un outil comme Advanced Database Cleaner ou effectuer une requête via WP-CLI, disponible chez cdmon à partir du plan d’hébergement Senior, si vous avez des connaissances techniques. L’objectif n’est pas de supprimer les options qui occupent le plus d’espace, mais d’identifier quel plugin ou thème les a créées.

Qu’une option soit grande ne signifie pas qu’elle est inutile : elle peut contenir des informations importantes pour le fonctionnement du site.

Recherchez particulièrement :

• Réglages de plugins que vous n’utilisez plus.
• Informations temporaires qui ont été enregistrées de manière permanente.
• Données répétées.
• Configurations très lourdes d’un thème précédent.

Une fois l’origine identifiée, vérifiez si le plugin lui-même inclut une fonction pour nettoyer ou régénérer ces données. S’il est toujours installé, le mettre à jour ou revoir sa configuration est généralement plus sûr que de supprimer des enregistrements manuellement.

WP-Cron exécute trop de tâches

Que se passe-t-il ?

WP-Cron est responsable des tâches programmées de WordPress : vérifier les mises à jour, publier des articles, envoyer des notifications, exécuter des sauvegardes ou activer des processus de certains plugins.

Contrairement aux tâches programmées du serveur, WP-Cron s’active lorsque quelqu’un visite le site. C’est pourquoi, sur une page avec beaucoup de visites, il peut s’exécuter plus souvent que nécessaire, tandis que sur une page avec peu de trafic, certaines tâches peuvent prendre du temps à se terminer.

Le problème ne réside généralement pas dans WP-Cron, mais dans les tâches que certains plugins ajoutent à ce système.

Si les publications programmées n’apparaissent pas à temps, les courriels sont envoyés en retard ou le site se ralentit toujours à certaines heures, il est possible que l’une de ces tâches s’exécute avec des erreurs ou trop fréquemment.

Comment le résoudre ?

Vous pouvez examiner les événements avec WP Crontrol, depuis :

Outils → Événements cron

L’outil montre quelles tâches sont programmées, quand elles doivent s’exécuter et à quelle fréquence. Faites attention à :

• Événements qui auraient dû s’exécuter et apparaissent en retard.
• Tâches qui se répètent toutes les quelques minutes sans raison claire.
• Tâches automatiques créées par des plugins que vous avez déjà supprimés.
• Plusieurs tâches similaires créées par le même composant.

Ne supprimez pas une tâche uniquement parce que vous ne reconnaissez pas son nom. Recherchez le nom du hook pour identifier quel plugin l’a créée. Si la tâche réapparaît après l’avoir supprimée, cela signifie qu’un plugin ou un composant du site continue de la programmer.

Sur les sites avec beaucoup de trafic ou de nombreuses tâches automatiques, il peut être plus stable de programmer leur exécution directement depuis le serveur, plutôt que de dépendre des visites.

Ce changement doit être fait correctement : si vous désactivez WP-Cron sans configurer d’abord une tâche qui le remplace, les publications, les courriels et d’autres processus programmés pourraient cesser de s’exécuter.

WooCommerce a des actions programmées bloquées

Que se passe-t-il ?

WooCommerce et beaucoup de ses extensions utilisent Action Scheduler, un système qui se charge d’exécuter des tâches automatiques en arrière-plan. Par exemple, il peut envoyer des courriels, renouveler des abonnements, communiquer des informations à d’autres applications ou mettre à jour des commandes.

Lorsque ces tâches s’accumulent, WordPress ne montre pas toujours une erreur. À la place, vous pouvez remarquer que les commandes mettent du temps à se mettre à jour, les courriels arrivent en retard ou le panneau d’administration fonctionne de plus en plus lentement.

Vous pouvez examiner la file d’attente dans :

WooCommerce → État → Actions programmées

Action Scheduler peut également apparaître dans Outils → Actions programmées, selon les plugins installés. Sa documentation officielle répertorie les deux chemins.

Filtrez les actions par état :

• En attente : elles attendent d’être exécutées.
• Échouées : elles ont tenté de s’exécuter, mais ne se sont pas terminées correctement.
• En cours : elles devraient être en cours de traitement.
• Terminées : elles sont déjà terminées.

Avoir des actions en attente n’implique pas nécessairement un problème. Le signal d’alerte apparaît lorsque leur nombre augmente constamment, qu’elles attendent depuis trop longtemps ou que beaucoup échouent avec le même hook.

Comment le résoudre ?

Imaginez que vous trouvez des centaines de tâches échouées liées à une extension d’abonnements. Les supprimer peut vider la liste pendant un certain temps, mais ne résoudra pas le problème qui provoque les échecs. Si vous ne corrigez pas la cause, les tâches s’accumuleront à nouveau.

Ouvrez une des tâches échouées, localisez son nom (hook) et consultez le journal pour savoir pourquoi elle ne s’est pas terminée. Ensuite :

1. Identifiez quel plugin ou extension a créé la tâche.
2. Mettez à jour ce plugin et les compléments dont il a besoin pour fonctionner.
3. Vérifiez s’il dépend d’une connexion avec un service externe, comme une plateforme de paiements, abonnements ou courriels.
4. Corrigez l’erreur indiquée dans le journal avant d’exécuter à nouveau la tâche.
5. Vérifiez que les tâches en attente commencent à se terminer et que la file d’attente diminue.

Les files d’attente très grandes peuvent nécessiter un traitement via WP-CLI ou une intervention technique. La documentation d’Action Scheduler recommande WP-CLI pour les charges élevées car il évite certaines limitations des requêtes web habituelles. Vous pouvez consulter sa documentation sur WP-CLI.

Chez cdmon, l’accès à WP-CLI est disponible à partir du plan d’hébergement Senior. Si votre plan ne l’inclut pas ou si vous n’avez pas d’expérience avec les commandes, contactez l’équipe de Support avant d’intervenir dans la file d’attente.

La base de données accumule des transients expirés

Que se passe-t-il ?

Les transients permettent de stocker temporairement des données qui prennent plus de temps à obtenir, comme le résultat d’une requête ou la réponse d’un service externe. Ainsi, WordPress peut les réutiliser pendant un certain temps au lieu de les régénérer chaque fois que quelqu’un visite le site.

Lorsqu’ils fonctionnent bien, ils aident à la performance. Le problème apparaît lorsqu’ils expirent, mais ne sont pas supprimés correctement, ou lorsqu’un plugin en génère des milliers.

Il n’est pas nécessaire de nettoyer les transients chaque semaine. Il n’est pas non plus conseillé de les traiter comme des déchets par définition. WordPress et les plugins peuvent recréer beaucoup d’entre eux après les avoir supprimés.

Si la table wp_options a trop grandi, vérifiez combien de transients il y a, combien d’espace ils occupent et quels préfixes se répètent. Une grande quantité liée au même plugin peut indiquer où commencer à enquêter.

Comment le résoudre ?

Avec accès à WP-CLI, vous pouvez supprimer uniquement les transients qui ont déjà expiré avec cette commande :

wp transient delete –expired

Vous pouvez consulter son fonctionnement et les options disponibles dans la documentation officielle de WP-CLI.

Supprimer tous les transients est également possible, mais ne devrait pas être la première option. Certains processus devront les reconstruire et cela peut provoquer une augmentation temporaire du travail du serveur.

S’ils se réaccumulent rapidement, le nettoyage n’aura fait que masquer le symptôme. Vérifiez quel plugin les crée et s’il existe une mise à jour, une erreur ou une configuration qui explique ce comportement.

Les requêtes loopback sont bloquées

Que se passe-t-il ?

Une requête loopback se produit lorsque WordPress se connecte à son propre site pour lancer des tâches automatiques ou vérifier qu’il répond correctement. C’est, en termes simples, comme si le site se visitait lui-même.

Si elle échoue, WordPress peut afficher un avertissement dans :

Outils → Santé du site → État

Vous pouvez également détecter :

• Événements programmés qui ne s’exécutent pas.
• Publications programmées qui sont retardées.
• Actions de WooCommerce qui restent en attente.
• Processus internes qui se terminent par un délai d’attente.

WP-Cron, Action Scheduler et les requêtes loopback sont liés. Si les trois montrent des problèmes en même temps, vous voyez peut-être différentes conséquences d’un seul blocage.

Comment le résoudre ?

Ici, il convient de lire l’erreur concrète, pas seulement de se contenter de l’avertissement de loopback.

Une erreur 401 ou 403 peut indiquer qu’un mot de passe, un plugin de sécurité ou une règle du serveur empêche WordPress de se connecter à son propre site. Si un timeout apparaît, cela signifie que le serveur a mis trop de temps à compléter la requête.

Consultez l’historique des erreurs PHP et du serveur juste au moment où l’échec se produit. Ces journaux peuvent montrer quel plugin, fichier ou processus cause le problème.

Vérifiez également si un plugin de sécurité, un mode de maintenance ou une protection par mot de passe empêche WordPress d’accéder à wp-cron.php ou à l’API REST.

Si une mesure de sécurité provoque le blocage, ne la désactivez pas de manière permanente. Identifiez la règle responsable et ajoutez une exception uniquement pour la connexion que WordPress doit effectuer.

Une requête lente ralentit un écran spécifique

Que se passe-t-il ?

Si tout le site fonctionne bien sauf la liste des commandes, une recherche, l’éditeur ou une page déterminée, le problème peut être dans une requête à la base de données.

Query Monitor permet d’analyser les requêtes exécutées pendant le chargement et de les associer, lorsque c’est possible, avec le plugin, le thème ou la fonction qui les a générées.

Installez Query Monitor de manière temporaire et ouvrez la page ou section de WordPress qui fonctionne lentement. Ensuite, examinez :

• Requêtes qui prennent beaucoup plus de temps que les autres.
• La même requête exécutée des dizaines ou centaines de fois.
• Erreurs de base de données.
• Requêtes HTTP externes.
• Le composant responsable de chaque opération.

Ne vous concentrez pas uniquement sur la requête la plus lente. Une requête de 200 millisecondes peut ne pas être grave si elle s’exécute une fois. Une autre de 20 millisecondes peut devenir un problème si elle se répète 300 fois pendant un seul chargement.

Comment le résoudre ?

Si Query Monitor indique un plugin, vérifiez s’il existe une mise à jour ou si l’une de ses fonctions peut être désactivée. Vous pouvez également essayer temporairement un autre outil qui remplit la même fonction et comparer le résultat.

Dans les grandes boutiques, il peut être nécessaire de vérifier :

• La quantité d’informations que le site traite.
• Le nombre de produits ou résultats affichés sur chaque page.
• Les filtres et les recherches utilisés par les visiteurs.
• La façon dont les données sont organisées dans la base de données.

Modifier la façon dont WordPress recherche et organise les informations de la base de données nécessite des connaissances avancées. Si vous ne pouvez pas identifier quel plugin ou fonction effectue cette recherche ni à quoi elle sert, il est préférable de demander de l’aide technique avant de faire des changements.

Un plugin supprimé a laissé des données et tâches résiduelles

Que se passe-t-il ?

Désactiver un plugin empêche son code de s’exécuter normalement. Cependant, cela n’élimine pas nécessairement ses tables, options, dossiers, tâches cron ou fichiers générés.

Cela ne signifie pas que tous les plugins désactivés ralentissent WordPress. Un dossier inactif n’affecte généralement pas les performances du simple fait d’exister. Le problème réside dans les résidus qui continuent de se charger ou de se traiter.

Examinez :

• S’il reste des tâches du plugin dans WP-Cron.
• S’il conserve des options autoload.
• S’il a créé ses propres tables.
• S’il a laissé de grandes quantités de fichiers dans wp-content/uploads.
• S’il dispose d’une option pour supprimer ses données lors de sa désinstallation.

Comment le résoudre ?

Si le plugin est encore installé, consultez sa configuration avant de le supprimer. Certains outils incluent des options comme “supprimer les données lors de la désinstallation”, mais ne les activent pas par défaut pour éviter des pertes accidentelles.

Si vous l’avez déjà supprimé, vous pouvez le réinstaller temporairement en staging et utiliser son propre processus de désinstallation. Faites-le uniquement lorsque vous êtes sûr qu’il s’agit du même plugin et que vous n’avez plus besoin de ses données.

Ne supprimez pas une table uniquement en vous basant sur son nom. Elle pourrait contenir des commandes, formulaires, statistiques ou configurations que d’autres parties du site utilisent encore.

Installer un autre plugin de nettoyage ne devrait pas non plus être la réponse automatique. Identifiez d’abord les résidus concrets et décidez de l’outil dont vous avez besoin pour les retirer.

Comment savoir si vous avez résolu le problème

Après avoir corrigé l’une de ces causes, répétez exactement le test initial :

• Ouvrez la même page ou écran.
• Effectuez le test dans des conditions similaires.
• Vérifiez le temps de réponse.
• Examinez si les files d’attente et les erreurs diminuent.
• Confirmez que les fonctions liées continuent de fonctionner.

Ne vous limitez pas à vérifier la page d’accueil. Si vous êtes intervenu sur WooCommerce, testez une commande. Dans le cas où vous avez modifié WP-Cron, vérifiez que les tâches s’exécutent. Si vous avez nettoyé des données d’un plugin, examinez les fonctions qui en dépendaient.

L’objectif n’est pas d’obtenir une base de données “vide”, mais d’éliminer le travail inutile sans casser ce dont WordPress a besoin.

Questions fréquentes