Comment réparer une base de données WordPress lente : une liste de contrôle en 4 étapes

Le tableau de bord d'administration de votre WordPress ne devrait pas prendre cinq secondes à se charger. Si c'est le cas, le problème ne vient peut-être pas de votre plan d'hébergement ou de vos images. Il pourrait s'agir de votre base de données.

Votre base de données contient silencieusement des années de données accumulées comme des transients expirés, des milliers de révisions d'articles et des données autoloadées de plugins que vous avez supprimés il y a des années.

La plupart de ces données sont invisibles dans wp-admin et n'affectent pas ce que les visiteurs voient. Mais elles s'accumulent et finissent par tout ralentir.

J'ai diagnostiqué des sites où un seul plugin déclenchait 80 requêtes de base de données par chargement de page. L'hébergeur était correct. La mise en cache était correctement configurée. Rien n'a fait de différence jusqu'à ce que le problème réel de la base de données soit résolu.

Dans cet article, je vais vous montrer comment identifier le goulot d'étranglement, nettoyer l'encombrement de la base de données, corriger les tables lourdes qui survivent au nettoyage et réduire la fréquence à laquelle WordPress interroge la base de données en premier lieu.

Voici les points clés à retenir :

• Un tableau de bord d'administration lent pointe presque toujours vers la base de données, pas vers votre hébergeur ou vos images. L'administration contourne la mise en cache des pages, c'est donc le signal le plus clair dont vous disposez.
• Les révisions d'articles, les transients expirés, les données de plugins orphelines et les options autoload encombrées sont les coupables les plus courants, et ils ont tendance à être visibles dans wp-admin.
• Query Monitor (gratuit) identifie quel plugin ou quelle requête est le goulot d'étranglement avant que vous ne supprimiez quoi que ce soit.
• DB Optimizer donne à votre base de données un score de santé dans cinq catégories et montre un aperçu complet de ce qui sera supprimé avant que vous ne confirmiez un nettoyage.
• Les données autoloadées dans wp_options devraient rester en dessous de 1 Mo. Au-delà, chaque chargement de page entraîne un poids inutile.
• La mise en cache d'objets avec Redis ou Memcached peut améliorer considérablement les tableaux de bord d'administration lents que la mise en cache de pages ne peut pas toucher.
• Exécutez un nettoyage avant chaque sauvegarde ou migration majeure. Une base de données plus petite signifie un transfert plus rapide et un fichier de sauvegarde plus petit.

Table des matières

Qu'est-ce qui ralentit une base de données WordPress ?

Avant de plonger dans les solutions, il est utile de savoir à quoi vous avez affaire. Les bases de données WordPress ralentissent pour des raisons prévisibles, et la plupart des sites en ont plus d'une en même temps.

Révisions de publication

Chaque fois que vous enregistrez ou mettez à jour un article, WordPress crée une nouvelle copie. Sur un site actif, un seul article peut avoir des dizaines de copies de révision stockées indéfiniment dans la base de données.

Elles sont invisibles pour les visiteurs mais alourdissent chaque requête contre la table des articles.

Transients expirés

Les plugins utilisent des transients pour mettre temporairement en cache les données provenant d'appels API externes et de tâches planifiées. Ils sont censés expirer et se supprimer automatiquement.

Souvent, ce n’est pas le cas, et les enregistrements expirés s’accumulent dans la table wp_options longtemps après avoir servi à quelque chose.

Lignes orphelines et tables de plugins restantes

Lorsqu’un plugin est supprimé, ses données restent généralement : champs personnalisés, métadonnées utilisateur, métadonnées de publication, et parfois des tables de base de données entières portant le nom du plugin. Un site qui a utilisé une douzaine de plugins au fil des ans conserve les données fantômes de chacun.

Données autoloadées dans wp_options

Les options marquées autoload = yes se chargent à chaque requête de page avant que WordPress ne rende quoi que ce soit. Les plugins qui abusent de ce drapeau ajoutent du poids à chaque chargement de page, y compris les pages qui n’ont rien à voir avec ce plugin.

Les données autoload totales devraient rester inférieures à 1 Mo. De nombreux sites lents affichent 5 Mo ou plus.

Fragmentation des tables

Lorsque des lignes sont supprimées, MySQL ne récupère pas automatiquement l’espace qu’elles occupaient. Avec le temps, les tables deviennent fragmentées et MySQL doit travailler plus dur pour les lire.

C’est pourquoi l’exécution d’une commande « Optimiser la table » peut accélérer les choses, même lorsque les données elles-mêmes semblent propres.

Requêtes de plugins lentes ou excessives

Certains plugins sont simplement mal écrits. Ils exécutent des dizaines de requêtes lors d’un seul chargement de page, ou ils interrogent des colonnes qui ne sont pas indexées, forçant MySQL à scanner des tables entières ligne par ligne au lieu de sauter à l’enregistrement correct.

Comment réparer une base de données WordPress lente

Pour réparer une base de données WordPress lente, vous devrez identifier ce qui la ralentit, supprimer l’encombrement qui la cause, réparer les tables qui survivent au nettoyage, puis réduire la fréquence à laquelle la base de données est interrogée.

Voici ce que vous allez faire :

• Étape 1 : Identifier ce qui ralentit votre base de données : utilisez le plugin gratuit Query Monitor pour voir chaque requête exécutée sur votre site, combien de temps chacune prend, et quel plugin l’a déclenchée.
• Étape 2 : Nettoyer l’encombrement de la base de données : utilisez DB Optimizer pour évaluer votre base de données dans cinq catégories de santé, prévisualiser exactement ce qui est supprimé, et la nettoyer en toute sécurité avec un seuil de rétention intégré.
• Étape 3 : Traiter les tables lourdes : corriger l’encombrement autoload dans wp_options, activer WooCommerce HPOS si pertinent, vérifier les tables MyISAM qui devraient être InnoDB, et optimiser la surcharge des tables sans phpMyAdmin.
• Étape 4 : Réduire la fréquence à laquelle WordPress interroge la base de données : ajoutez la mise en cache de page si ce n’est pas déjà fait, puis activez la mise en cache d’objets avec Redis ou Memcached pour corriger la lenteur de l’administration que la mise en cache de page ne peut pas atteindre.

Étape 1 : Identifier ce qui ralentit votre base de données

Query Monitor est un plugin gratuit qui affiche chaque requête de base de données exécutée sur la page actuelle, combien de temps chacune prend, et quel plugin ou thème l’a déclenchée. Installez-le depuis le répertoire des plugins WordPress et activez-le comme n’importe quel autre plugin.

Une fois actif, un nouvel élément apparaît dans votre barre d’administration indiquant le nombre total de requêtes et le temps de chargement de la page pour l’écran sur lequel vous vous trouvez. Cliquez dessus pour ouvrir le panneau complet.

Allez dans l’onglet Database Queries. Recherchez les requêtes prenant plus de 0,05 seconde et tout plugin générant un nombre anormalement élevé d’appels.

Query Monitor nomme directement le plugin ou le thème responsable, vous n’avez donc pas à deviner.

Si un plugin génère 40 requêtes ou plus par page ou a des requêtes constamment supérieures à 0,05 seconde, c'est votre goulot d'étranglement. Désactivez-le et testez à nouveau.

Si aucune requête unique ne ressort, le problème est un encombrement général réparti dans la base de données, pas un acteur spécifique problématique. Passez à l'étape 2.

Une chose à vérifier avant de continuer : Query Monitor n'affiche que le comportement de la page actuelle. Exécutez-le sur le tableau de bord d'administration, sur une page produit WooCommerce si vous en avez une, et sur un article standard.

La lenteur est souvent spécifique à la page, et un problème de requête sur la page de paiement n'apparaîtra pas pendant que vous regardez le tableau de bord.

Étape 2 : Nettoyer l'encombrement de la base de données

La plupart des gens sautent le nettoyage de la base de données car ils ne savent pas ce qui peut être supprimé en toute sécurité. Cette hésitation est raisonnable. La suppression de la mauvaise chose dans une base de données ne peut pas être annulée.

DB Optimizer résout ce problème en vous montrant exactement ce qui se trouve dans votre base de données avant que vous ne supprimiez quoi que ce soit. La première chose que vous verrez est un score de santé de 0 à 100.

Il se décompose en cinq catégories : surcharge de table, transitoires, révisions, taille de l'autoload et éléments de corbeille. Chacun reçoit une barre de progression et une note codée par couleur.

Vert signifie que la catégorie est en bon état. Jaune signifie qu'elle nécessite une attention. Rouge signifie qu'elle fait baisser votre score. Appuyez sur le bouton Actualiser le score à tout moment pour le mettre à jour.

Une fois que vous savez ce qui fait baisser le score, allez dans l'onglet Nettoyage. Une barre récapitulative en haut indique le nombre d'éléments disponibles pour le nettoyage et l'espace total récupérable sur l'ensemble de votre base de données.

En dessous, chaque type de nettoyage (Articles et Pages, Commentaires, Transitoires et Cache) affiche un nombre d'éléments et une taille estimée. Vous pouvez voir exactement à quoi vous avez affaire avant que quoi que ce soit ne soit supprimé.

DB Optimizer utilise par défaut un seuil de rétention de 7 jours. Tout ce qui est créé au cours de la dernière semaine est hors limites, quels que soient les types de nettoyage que vous avez sélectionnés.

Si vous vous préparez pour une migration et que vous souhaitez une ardoise vierge, baissez-le. Si vous travaillez sur un site sensible et que vous souhaitez une prudence supplémentaire, augmentez-le. Réglez-le sur 0 uniquement si vous souhaitez tout nettoyer quel que soit l'âge. Votre préférence est enregistrée automatiquement.

Après le nettoyage, ajoutez une ligne à votre fichier wp-config.php pour limiter les futures révisions avant qu'elles ne s'accumulent à nouveau :

define('WP_POST_REVISIONS', 3);

Ajoutez-la au-dessus de la ligne qui dit « C'est tout, arrêtez d'éditer ! ». Cela limite WordPress à conserver trois révisions par article à partir de maintenant.

DB Optimizer gère ce qui existe déjà. Cette ligne empêche son retour.

Étape 3 : Traiter les tables lourdes

Le nettoyage supprime les données non liées, mais deux tables spécifiques causent une lenteur continue même après un nettoyage approfondi : wp_options et wp_postmeta. Le moteur de stockage utilisé par votre base de données est également important ici.

Données autoloadées dans wp_options

DB Optimizer affiche la taille de votre autoload comme l'une de ses cinq catégories de santé. Si elle est toujours supérieure à 1 Mo après l'exécution du nettoyage, un plugin écrit activement des options autoloadées à chaque exécution. Le nettoyage supprime les anciennes entrées mais ne peut pas empêcher l'ajout de nouvelles.

Utilisez l'onglet Query Monitor pour voir ce qui se charge actuellement, puis identifiez le plugin responsable. Le désactiver ou contacter son équipe de support est la solution.

Wp_postmeta

Cette table stocke les données des champs personnalisés et grossit rapidement sur les sites utilisant beaucoup WooCommerce ou ACF.

Query Monitor signalera les requêtes sur cette table si elle constitue un goulot d'étranglement constant. La corriger au niveau des requêtes relève du domaine des développeurs, mais savoir que c'est le problème est déjà une moitié de la bataille.

Utilisateurs WooCommerce : activer HPOS

Si vous utilisez WooCommerce, allez dans WooCommerce » Paramètres » Avancé » Fonctionnalités et activez le Stockage de commandes haute performance.

Cela déplace les données de commande de wp_postmeta vers des tables dédiées et conçues à cet effet. Cela peut considérablement accélérer les requêtes de commande sur n'importe quel magasin comportant plus de quelques centaines de commandes.

Après l'avoir activé, WooCommerce peut vous inviter à migrer les données de commande existantes. Effectuez la migration avant de continuer.

Moteur de stockage : MyISAM vs. InnoDB

MyISAM verrouille toute la table de base de données pendant chaque opération d'écriture, ce qui provoque une mise en file d'attente sous une charge d'écriture significative. InnoDB ne verrouille que la ligne spécifique en cours d'écriture.

WordPress utilise InnoDB par défaut depuis MySQL 5.7, mais les sites migrés depuis d'anciens environnements d'hébergement ont parfois encore des tables MyISAM.

L'onglet Tables de DB Optimizer affiche le moteur de stockage de chaque table. Si vous voyez des tables MyISAM, les convertir en InnoDB est une modification SQL en une seule ligne, mais il est préférable de confier cela à un développeur ou de demander à votre hébergeur s'il peut le gérer via son panneau de contrôle.

Surcharge de table

DB Optimizer met en évidence toute table portant une surcharge et affiche un bouton Optimiser à côté. Vous pouvez les traiter individuellement ou supprimer toute la surcharge en une seule fois.

Exécutez ceci après le nettoyage, car la suppression de lignes est ce qui crée la surcharge en premier lieu.

Étape 4 : Réduire la fréquence des requêtes de WordPress à la base de données

Même une base de données propre et optimisée est interrogée à chaque chargement de page. Les couches de mise en cache interceptent ces requêtes afin que la base de données effectue moins de travail globalement.

La mise en cache de page enregistre la sortie HTML complète d'une page afin que WordPress ignore complètement la base de données pour cette requête.

Si vous n'avez pas de plugin de mise en cache, ajoutez-en un avant toute autre chose. WP Rocket, W3 Total Cache et LiteSpeed Cache gèrent tous cela. La mise en cache de page est le changement ayant le plus d'impact pour les visiteurs du frontend.

Vous devriez également activer la mise en cache d'objets. La mise en cache d'objets enregistre les résultats individuels des requêtes de base de données dans la mémoire du serveur afin que les requêtes répétées accèdent au cache au lieu de la base de données.

Les requêtes d'administration, les processus de paiement WooCommerce et toute page ne pouvant pas être entièrement mise en cache en bénéficient.

Demandez à votre hébergeur si Redis ou Memcached est disponible. De nombreux hébergeurs WordPress gérés incluent l'un ou les deux.

Si Redis est disponible, installez le plugin Redis Object Cache et suivez les instructions de connexion de votre hébergeur. Le plugin affiche un statut Connecté lorsqu'il fonctionne correctement.

N'installez pas Redis Object Cache à moins que votre hébergeur ne fournisse réellement un serveur Redis. Sans connexion active, le plugin génère des erreurs et n'apporte aucun bénéfice.

Optionnel : Commandes WP-CLI pour réparer une base de données lente

Si vous gérez WordPress depuis la ligne de commande, ces commandes couvrent le même terrain que les étapes ci-dessus sans interface de plugin.

wp db optimize

Exécute l'utilitaire d'optimisation de MySQL sur chaque table de la base de données.

wp transient delete --expired

Supprime tous les transients expirés de wp_options.

wp post delete $(wp post list --post_status=trash --format=ids)

Supprime définitivement tous les articles actuellement dans la corbeille.

wp post delete $(wp post list --post_type='revision' --format=ids)

Supprime toutes les révisions d'articles stockées.

Sauvegardez avec Duplicator avant d'exécuter l'une de ces commandes. Elles s'exécutent immédiatement sans étape de prévisualisation ni invite de confirmation.

WP-CLI ne fournit pas le score de santé, les seuils de rétention ou les aperçus par catégorie que DB Optimizer fournit. Il vous offre simplement un chemin plus rapide vers les mêmes tâches de nettoyage.

Dépannage : lorsque la base de données est toujours lente

Si vous avez suivi toutes ces étapes et que le site est toujours lent, l'une des situations suivantes en est probablement la cause.

Query Monitor ne montre aucun coupable évident

Ce que vous voyez : chaque requête individuelle est inférieure à 0,05 seconde, mais la page se charge toujours lentement.

Le problème pourrait être le volume total des requêtes, et non une seule requête lente. Deux cents requêtes à 0,01 seconde chacune ajoutent toujours deux secondes complètes de temps de base de données avant que quoi que ce soit ne soit rendu.

Vérifiez la barre de résumé dans Query Monitor. Si le nombre total de requêtes est supérieur à 50 à 75 sur une page standard, cela mérite une enquête.

Désactivez les plugins un par un, rechargez la page après chaque désactivation et observez la baisse du nombre. Le plugin qui provoque la plus forte baisse est votre cible.

La taille de l'autoload reste élevée après le nettoyage

Ce que vous voyez : DB Optimizer affiche toujours une taille d'autoload supérieure à 1 Mo après l'exécution du nettoyage.

Le nettoyage supprime les entrées autoload expirées et orphelines, mais il ne peut pas empêcher un plugin d'en écrire de nouvelles. Si le nombre continue d'augmenter, quelque chose ajoute activement des éléments au pool autoload à chaque requête.

Query Monitor affiche chaque option en autoload sur la page actuelle. Recherchez les entrées de plugins que vous ne reconnaissez pas ou que vous n'utilisez pas activement, puis désactivez ces plugins un par un et actualisez le score.

Le paiement WooCommerce est toujours lent après le nettoyage

Ce que vous voyez : les pages de paiement prennent trois à cinq secondes à se charger après le nettoyage.

HPOS peut être activé, mais la migration des données peut ne pas être terminée. Allez dans WooCommerce » Statut » Outils et recherchez une option Migrer les données de commande. Si elle est présente, exécutez-la.

Les migrations incomplètes obligent WordPress à lire simultanément les anciennes et les nouvelles structures de table, ce qui est plus lent que l'une ou l'autre séparément.

Si la migration est déjà terminée, un plugin conflictuel peut forcer WooCommerce à revenir aux tables de commandes héritées. Désactivez les plugins un par un et testez la vitesse de paiement après chacun.

La mise en cache d'objets s'affiche comme connectée mais l'administration est toujours lente

Ce que vous voyez : le plugin Redis Object Cache affiche "Connecté", mais les pages d'administration sont toujours lentes.

Un plugin vide probablement le cache d'objets à chaque requête, ce qui va à l'encontre de son objectif. Ouvrez Query Monitor et vérifiez le cache. Si le taux de réussite du cache est inférieur à 80 %, quelque chose vide agressivement.

Identifiez-le en désactivant les plugins par groupes de deux ou trois, en vérifiant le ratio après chaque groupe. Lorsque le ratio de succès augmente, le dernier groupe que vous avez désactivé contient le problème.

Rien ne fonctionne

Si les quatre étapes sont terminées et que les performances ne se sont pas améliorées, le problème se situe probablement en dehors de la base de données elle-même. Une mémoire MySQL insuffisante sur un hébergement mutualisé oblige le serveur à utiliser le disque au lieu de la RAM, ce qu'aucun nettoyage ne pourra corriger.

Contactez votre hébergeur et posez des questions spécifiques sur l'allocation de mémoire MySQL et la disponibilité de la journalisation des requêtes lentes côté serveur. Un développeur examinant le journal des requêtes lentes peut identifier des problèmes que Query Monitor ne peut pas détecter.

Questions fréquemment posées (FAQ)

Votre base de données ne va pas se nettoyer toute seule

Vous avez fait ce que la plupart des propriétaires de sites WordPress ne font jamais : vous avez diagnostiqué un goulot d'étranglement de base de données, nettoyé des données qui s'accumulaient depuis des années, traité les tables spécifiques qui causent une lenteur persistante et réduit la fréquence à laquelle la base de données doit travailler.

À l'avenir, exécutez la vérification de l'état de DB Optimizer une fois par mois. L'encombrement de la base de données revient progressivement, et un passage mensuel l'empêche de s'aggraver.

Et gardez à l'esprit que l'optimisation modifie définitivement votre base de données. Une sauvegarde avant de commencer fait la différence entre une erreur réparable et une erreur permanente.

Plus de 1,5 million de professionnels WordPress utilisent Duplicator pour sauvegarder et migrer leurs sites. Le plan gratuit couvre les sauvegardes complètes du site et prend environ deux minutes à configurer. Passez à la version supérieure pour le stockage cloud, les sauvegardes automatiques et un plugin DB Optimizer gratuit avec Duplicator Pro !

Si ce guide vous a aidé, ces articles méritent également d'être mis en favoris.

• Comment optimiser votre base de données WordPress
• Voici les étapes de réparation de la base de données WordPress que j'ai moi-même effectuées
• Maintenance de la base de données WordPress : Ce qu'il faut faire chaque semaine, chaque mois et chaque trimestre
• Comment sauvegarder une base de données WordPress
• Le meilleur plugin d'optimisation de base de données WordPress que j'ai utilisé (plus 3 alternatives)