Les articles sur l'accélération de WordPress parlent tous des images, du cache et des scripts bloquants. Presque aucun ne parle de la base de données.
C'est dommage, parce que c'est souvent là que se cache la lenteur qui résiste à tout le reste. Le genre de site qui a WP Rocket bien configuré, des images en WebP, un hébergement correct, et qui met quand même une seconde et demie à répondre avant d'afficher quoi que ce soit.
Ce qu'est une base de données WordPress
Un serveur MySQL ou MariaDB, une base, et des tables qui contiennent des lignes. C'est l'une des quatre briques décrites dans comment est fait un site WordPress.
Chaque fois qu'un visiteur ouvrez une page non mise en cache, PHP interroge cette base plusieurs dizaines de fois. Le temps de ces requêtes s'ajoute directement au TTFB, la latence avant que le premier octet parte vers le navigateur.
Un cache page masque ce coût pour les visiteurs anonymes. Il ne le masque pas pour vous quand vous êtes connecté à l'administration, ni pour les pages qui ne peuvent pas être mises en cache : panier, compte client, tunnel de commande.
D'où la règle : sur un site vitrine, une base lourde se voit peu. Sur une boutique WooCommerce, elle se voit partout.
Les douze tables par défaut
Une installation neuve de WordPress crée douze tables. Quatre méritent que vous les connaissiez.
wp_posts contient vos articles et vos pages. Elle contient aussi les révisions, les brouillons automatiques, les éléments en corbeille, les entrées de menu, et les fichiers médias (une entrée par image). Sur un site de trois ans sans réglage de révisions, le contenu réellement publié représente souvent une minorité des lignes.
wp_postmeta contient les champs personnalisés attachés à ces contenus. Avec ACF, WooCommerce ou un constructeur de pages, elle dépasse largement wp_posts en volume. C'est normal.
wp_options contient les réglages du site et ceux de chaque extension. C'est la table qui pose problème, on y vient.
wp_users et wp_usermeta contiennent les comptes. Les mots de passe y sont hachés, jamais stockés en clair.
Les autres concernent les commentaires, les catégories et les étiquettes. WooCommerce, ACF et les extensions de formulaire ajoutent leurs propres tables, ce qui est sain : une extension qui stocke ses données dans wp_options au lieu de créer sa table est une extension mal conçue.
wp_options et l'autoload : la cause de lenteur la plus sous-estimée
Dans wp_options, chaque ligne a une colonne autoload. Quand elle vaut yes, la valeur est chargée en mémoire à chaque requête PHP. Sur chaque page. Pour chaque visiteur.
L'intention est bonne : éviter d'aller rechercher cent fois les réglages de base. Le problème arrive quand des extensions y stockent des volumes importants avec l'autoload activé, ou quand une extension désinstallée laisse ses options derrière elle.
Vous pouvez mesurer ça en une requête, depuis phpMyAdmin ou Adminer :
SELECT SUM(LENGTH(option_value)) AS taille_autoload
FROM wp_options
WHERE autoload = 'yes';Le résultat est en octets. Sous 500 000, vous n'avez pas de sujet. Au-delà du million, ça mérite un regard. Ce seuil est un repère d'usage, pas une valeur officielle publiée par WordPress.
Et pour voir les coupables :
SELECT option_name, LENGTH(option_value) AS poids
FROM wp_options
WHERE autoload = 'yes'
ORDER BY poids DESC
LIMIT 20;Adaptez le préfixe wp_ si le vôtre est différent.
Ce qui remonte en tête de liste, ce sont presque toujours des options laissées par des extensions désinstallées, ou des caches d'extensions stockés au mauvais endroit.
Pourquoi une base grossit
Quatre sources, par ordre de fréquence.
Les révisions d'articles. WordPress en crée une à chaque enregistrement, sans limite par défaut. Ça se règle dans le fichier wp-config.php avec WP_POST_REVISIONS.
Les transients expirés. Ce sont des données temporaires stockées dans wp_options avec une date d'expiration. WordPress les ignore une fois périmées, mais ne les supprime pas systématiquement. Elles s'accumulent.
Les commentaires indésirables. Même marqués comme spam, ils restent en base tant qu'ils ne sont pas supprimés définitivement.
Les restes d'extensions désinstallées. Désactiver et supprimer une extension depuis l'interface ne supprime pas ses données. C'est même rarement le cas. Une boutique qui a testé quatre extensions de livraison en garde souvent les quatre jeux d'options.
Nettoyer sans casser
L'ordre compte.
- Sauvegarde complète, fichiers et base. Non négociable, un nettoyage raté ne se rattrape pas.
- Réglage préventif dans
wp-config.php: limite des révisions, corbeille vidée plus vite. Ça évite que le problème revienne. - Nettoyage des révisions, transients expirés et spams avec une extension dédiée (WP-Optimize, Advanced Database Cleaner).
- Suppression des options orphanes, une par une, après avoir identifié à quelle extension elles appartiennent. Cette étape se fait à la main. Un outil qui promet de détecter automatiquement les tables et options « inutilisées » se trompe parfois, et l'erreur casse une fonctionnalité.
- Optimisation des tables, l'équivalent d'une défragmentation.
Un point sur lequel je suis catégorique : ne lancez jamais un nettoyage automatique sur une boutique WooCommerce sans passer par un environnement de test d'abord. Les tables de commandes ne se réparent pas.
Quand la base n'est pas le problème
Une base propre sur un hébergement mutualisé saturé reste lente. Un TTFB élevé peut venir du serveur, pas des requêtes.
La méthode de diagnostic : installez Query Monitor, ouvrez une page en étant connecté, et regardez le nombre de requêtes et le temps total passé en base. Si vous voyez trois cents requêtes sur une page d'accueil, le problème vient d'une extension mal codée, pas du volume de données. Si vous voyez quarante requêtes en douze millisecondes et que le TTFB reste à une seconde, regardez ailleurs.
Je ne peux pas vous donner de gain moyen chiffré après un nettoyage de base. Ça dépend trop de l'état de départ, de l'hébergement et du type de site. Méfiez-vous de quiconque vous annonce un pourcentage avant d'avoir regardé. La démarche complète est décrite sur la page optimisation de la vitesse WordPress.
FAQ
Combien de tables contient une base WordPress ?
Douze pour une installation par défaut. Les extensions comme WooCommerce ou ACF en ajoutent d'autres, ce qui est un bon signe de conception.
Qu'est-ce que l'autoload dans wp_options ?
Une colonne qui indique si l'option doit être chargée en mémoire à chaque requête PHP. Un volume autoloadé important ralentit toutes les pages du site, y compris celles qui sont en cache pour les visiteurs connectés.
Nettoyer la base de données accélère-t-il vraiment un site WordPress ?
Ça aide quand la base est le goulot d'étranglement, typiquement sur un site ancien avec beaucoup de révisions et d'options orphelines. Sur un site jeune et propre, le gain est faible. Un diagnostic avant intervention évite de perdre du temps.
Puis-je supprimer les tables d'une extension désinstallée ?
Oui, après avoir identifié avec certitude à quelle extension elles appartiennent, et après une sauvegarde. Ne vous fiez pas uniquement à la détection automatique d'un outil de nettoyage.
Où sont stockées les images dans la base de données WordPress ?
Nulle part. Les fichiers sont sur le disque, dans wp-content/uploads. La base ne contient que le chemin d'accès et les métadonnées.
Comment savoir si ma base ralentit mon site ?
Query Monitor affiche le nombre de requêtes et le temps passé en base sur chaque page. Un TTFB élevé avec peu de requêtes rapides pointe vers l'hébergement plutôt que vers la base.
Ce qu'il faut retenir
- La base ralentit surtout les pages non mises en cache : panier, compte client, administration.
wp_optionset ses données autoloadées sont le premier endroit à mesurer.- Les restes d'extensions désinstallées se suppriment à la main, jamais en aveugle.
- Sauvegarde avant tout nettoyage, sans exception.
Sur un site d'hôtel ou d'hébergement avec moteur de réservation, ces requêtes passent sur des pages non mises en cache : la base y pèse sur chaque affichage.
Lancez la requête SQL du chapitre autoload sur votre site. Deux minutes, et vous saurez si le sujet vous concerne.
