Quand on pense à la vitesse d’un site WordPress, la base de données reste souvent à l’arrière-plan. Pourtant, chaque page qui n’est pas servie depuis le cache de page passe par elle : WordPress lit les réglages, les contenus, les métadonnées, les menus, les données des plugins, et chaque lecture a un coût. Sur un site fraîchement installé, ce coût est négligeable. Après quelques années d’activité, avec des dizaines de plugins installés et supprimés, des milliers de révisions, des sessions, des logs et des données temporaires jamais supprimés, la base de données peut devenir la principale raison pour laquelle le panier, l’espace client, la recherche et l’administration répondent lentement.
Dans cet article, nous voyons les causes les plus courantes d’une base de données lente dans WordPress, comment les trouver avec des outils à la portée de tous et comment intervenir en sécurité, sans recourir à des nettoyages agressifs qui risquent de supprimer des données importantes.
Quand la base de données compte
La base de données influence le TTFB de toutes les requêtes que WordPress doit traiter : pages pour les utilisateurs connectés, panier et paiement de la boutique, recherches internes, appels AJAX et API REST, tableau de bord d’administration, opérations planifiées. Les pages servies depuis le cache de page n’y touchent pas, de sorte qu’un site vitrine entièrement mis en cache peut avoir une base de données négligée sans conséquences visibles pour les visiteurs. Une boutique en ligne, un site avec des utilisateurs inscrits ou avec de nombreuses fonctions dynamiques en dépend en revanche à chaque étape, comme nous l’avons vu à propos des Core Web Vitals pour WooCommerce.
Les options en autoload
La table wp_options contient les réglages du site, du thème et des plugins. Certaines options sont marquées pour le chargement automatique (autoload) : WordPress les lit toutes ensemble, avec une seule requête, au début de chaque requête HTTP. C’est un mécanisme efficace tant que les options sont peu nombreuses et petites. Le problème apparaît quand leur taille totale atteint plusieurs mégaoctets : chaque requête non mise en cache doit les lire, les transférer de MySQL vers PHP et les décoder, même si elle n’en utilisera qu’une infime partie.
Il y a trois causes typiques. Les plugins désinstallés qui ont laissé leurs réglages derrière eux, parfois très volumineux. Les plugins actifs qui utilisent des options comme cache ou comme journal, en enregistrant des données qui grossissent avec le temps. Les transients, c’est-à-dire des données temporaires avec une date d’expiration, qui sans object cache sont enregistrées dans la même table. L’outil Santé du site, dans les versions récentes de WordPress, signale quand la taille totale des options en autoload dépasse un seuil recommandé ; pour une analyse plus précise, une requête liste les plus grosses options :
-- Les 20 plus grosses options en autoload
SELECT option_name, ROUND( LENGTH( option_value ) / 1024 ) AS kb
FROM wp_options
WHERE autoload IN ( 'yes', 'on', 'auto-on', 'auto' )
ORDER BY LENGTH( option_value ) DESC
LIMIT 20;À partir du nom de l’option, on peut presque toujours remonter au plugin qui l’a créée. Les options de plugins qui ne sont plus installés peuvent être supprimées, après une sauvegarde ; celles de plugins actifs mais rarement utilisés peuvent être exclues de l’autoload, et WordPress propose des fonctions dédiées pour changer le réglage sans toucher à la valeur.
// Exclure de l’autoload une option volumineuse et rarement utilisée
wp_set_option_autoload( 'plugin_statistiche_cache', false );Métadonnées et requêtes lentes
WordPress conserve beaucoup d’informations supplémentaires sur les articles, les produits, les utilisateurs et les commandes dans des tables de métadonnées, comme wp_postmeta, où chaque information est une ligne avec une clé et une valeur. C’est un modèle flexible, qui permet à n’importe quel plugin d’ajouter des champs sans modifier les tables, mais il se prête mal aux recherches : la colonne des valeurs n’est pas indexée, et une recherche qui filtre sur la valeur, comme « tous les produits avec un certain attribut » ou « tous les événements après une certaine date », oblige la base de données à parcourir un nombre énorme de lignes. Sur un catalogue de dizaines de milliers de produits, la table de métadonnées peut compter des millions de lignes, et une seule requête de ce type peut prendre des centaines de millisecondes.
Les solutions dépendent du cas. Certains plugins dédiés ajoutent des index plus efficaces aux tables de métadonnées de WordPress, avec des bénéfices importants sur les grands sites. WooCommerce a déplacé les commandes dans ses propres tables, optimisées pour les recherches, avec le stockage des commandes haute performance (HPOS). Pour les fonctions sur mesure, mieux vaut éviter les recherches par valeur de métadonnée quand il existe une alternative, comme une taxonomie pour les attributs sur lesquels on filtre souvent.
Révisions, transients, sessions et logs
D’autres tables grossissent en silence. Les révisions : WordPress conserve une copie de chaque enregistrement des articles et des pages, et sur un site éditorial actif depuis des années elles peuvent atteindre des dizaines de milliers, avec leurs métadonnées. Limiter leur nombre est facile, et les plus anciennes peuvent être supprimées :
// wp-config.php : conserver au maximum 10 révisions par contenu
define( 'WP_POST_REVISIONS', 10 );Les transients expirés, sans object cache, restent dans la table des options jusqu’à ce que quelqu’un les lise : sur les sites avec beaucoup de plugins, des milliers peuvent s’accumuler. Les sessions d’une boutique en ligne, les logs des plugins de sécurité, d’e-mail et de statistiques, et les tables d’opérations planifiées, comme celles d’Action Scheduler utilisé par WooCommerce et de nombreux autres plugins, peuvent atteindre des millions de lignes si personne ne fixe une durée de conservation. Chacune de ces tables ralentit les requêtes qui la touchent et pèse sur les sauvegardes et les restaurations.
Avec WP-CLI, l’outil en ligne de commande de WordPress, certains nettoyages se font en une seule commande :
# Supprimer les transients expirés
wp transient delete --expired
# Taille des tables, pour trouver celles qui ont trop grossi
wp db size --tables --size_format=mbComment diagnostiquer
L’outil le plus utile pour comprendre ce qui se passe dans la base de données est Query Monitor, un plugin gratuit qui affiche, pour chaque page visitée par un administrateur, toutes les requêtes exécutées, leur durée, le composant qui les a générées (noyau, thème ou plugin) et les requêtes en double. En triant par durée, on trouve les requêtes les plus lentes en quelques secondes ; en regroupant par composant, on découvre quel plugin génère le plus de travail. Utilisez-le sur les pages dynamiques qui comptent, comme le panier ou une recherche, pas sur la page d’accueil mise en cache.
Côté serveur, le slow query log de MySQL ou de MariaDB, si l’hébergeur permet de l’activer, collecte toutes les requêtes qui dépassent une certaine durée, y compris celles exécutées par les opérations planifiées et les appels en arrière-plan que Query Monitor ne voit pas. Enfin, la taille des tables et le nombre de lignes, visibles avec WP-CLI ou depuis le panneau de gestion de la base de données, montrent où le poids s’est accumulé.
Nettoyer en sécurité
Certains plugins promettent d’optimiser la base de données en un clic. Certains font du bon travail sur les éléments les plus sûrs, comme les révisions, les transients expirés et les commentaires indésirables ; d’autres proposent de supprimer les tables et options « orphelines » selon des critères approximatifs, avec le risque d’effacer des données de plugins encore utilisés. Quelques règles évitent les mauvaises surprises.
- Sauvegarder d’abord. Une copie complète et vérifiée de la base de données avant toute suppression.
- Mesurer d’abord. Utiliser Query Monitor et la taille des tables pour trouver où se situe vraiment le problème, au lieu de tout nettoyer au hasard.
- Une chose à la fois. Travailler sur une table ou un groupe d’options, vérifier que le site fonctionne, mesurer l’effet, puis passer au suivant.
- Préférer les réglages aux suppressions. Durées de conservation des logs et des opérations planifiées, plafond de révisions, nettoyage automatique des sessions : empêcher la croissance vaut mieux que nettoyer périodiquement.
- Essayer d’abord sur une copie. Pour les opérations les plus invasives, comme l’ajout d’index ou la conversion de tables, un environnement de préproduction (staging) évite de découvrir les problèmes en production.
Le rôle du serveur et de l’object cache
Tout ne dépend pas du contenu de la base de données. La version de MySQL ou de MariaDB, la mémoire attribuée au cache interne de la base de données et le moteur des tables influencent la performance : les tables avec l’ancien moteur MyISAM, encore présent sur certains sites anciens, gèrent moins bien les accès concurrents et doivent être converties au moteur InnoDB, désormais le standard. Sur un hébergement managé, ces aspects sont en général pris en charge par le fournisseur ; sur vos propres serveurs, ils doivent être vérifiés.
Un object cache comme Redis réduit le nombre de requêtes répétées et sort les transients de la table des options, mais il ne corrige pas les requêtes lentes par nature, comme les recherches sur les métadonnées, et ne rend pas non plus légères les options en autoload : il les stocke, mais doit quand même les transférer et les décoder à chaque requête. Le nettoyage de la base de données et l’object cache sont complémentaires, pas alternatifs.
Un exemple
Une boutique en ligne active depuis six ans a un panier qui répond en 1,4 seconde et un tableau de bord d’administration si lent qu’il décourage les personnes qui gèrent les commandes. L’outil Santé du site signale des options en autoload de plus de 5 mégaoctets ; Query Monitor montre, sur la page du panier, une requête d’un plugin de filtres qui cherche dans les métadonnées des produits pendant plus d’une demi-seconde, et la taille des tables révèle un journal d’Action Scheduler de quatre millions de lignes et une table de sessions avec des centaines de milliers de sessions expirées. La correction, appliquée d’abord sur une copie du site, supprime les options de onze plugins désinstallés, exclut de l’autoload deux options utilisées seulement dans le tableau de bord, fixe une durée de conservation d’un mois pour le journal des opérations planifiées, supprime les sessions expirées et ajoute des index aux tables de métadonnées. Le panier passe sous les 500 millisecondes, le tableau de bord redevient fluide et les sauvegardes nocturnes prennent un tiers du temps.
Une maintenance périodique
La base de données ne se règle pas une fois pour toutes. Chaque nouveau plugin apporte ses propres options et tables, chaque campagne génère des sessions et des commandes, chaque mise à jour peut changer la façon d’enregistrer les données. Un contrôle tous les quelques mois, avec l’outil Santé du site, la taille des tables et un passage de Query Monitor sur les principales pages dynamiques, permet de repérer la croissance avant qu’elle devienne un problème. Quand on désinstalle un plugin, il vaut la peine de vérifier s’il propose une option pour supprimer ses propres données, souvent désactivée par défaut, et de l’utiliser si l’on ne prévoit pas de le réinstaller. C’est quelques minutes de travail qui évitent des interventions bien plus lourdes des années plus tard.
En bref
La base de données WordPress influence toutes les requêtes qui ne passent pas par le cache de page : paniers, espaces clients, recherches, API et administration. Avec le temps, elle s’alourdit de façon prévisible : des options en autoload qui grossissent jusqu’à des mégaoctets, des recherches sur les métadonnées sans index adaptés, des révisions, des transients, des sessions, des logs et des opérations planifiées que personne ne supprime.
Le diagnostic est à la portée de tous, avec l’outil Santé du site, Query Monitor et une mesure de la taille des tables. Les interventions doivent être menées avec méthode, après une sauvegarde et une à la fois, en préférant les réglages qui empêchent la croissance aux nettoyages agressifs. Avec un object cache et un serveur bien configuré, une base de données bien entretenue ramène les pages dynamiques à des temps de réponse que les utilisateurs ne remarquent plus.
