Parmi les tables de la base de données WordPress, wp_options est souvent la plus discrète et pourtant l'une des plus critiques pour la performance globale du site. Son rôle, en apparence simple — stocker les réglages du site — cache un mécanisme qui, mal maîtrisé, peut ralentir chaque page vue, pas seulement l'administration.
Ce que contient réellement wp_options
Cette table stocke les réglages généraux du site (titre, URL, fuseau horaire), mais aussi les réglages de chaque extension active, et les transients, des données temporaires mises en cache avec une date d'expiration. Chaque ligne possède un champ autoload, qui peut valoir « yes » ou « no ». C'est ce champ qui détermine le véritable impact sur la performance.
Le mécanisme de l'autoload
Toutes les options marquées autoload='yes' sont chargées en mémoire par WordPress à chaque chargement de page, qu'elles soient réellement utilisées sur cette page ou non. C'est un mécanisme pensé pour éviter des requêtes répétées sur des réglages fréquemment consultés, mais il devient un problème si le volume total de données autoloadées grossit sans contrôle : chaque visite doit alors charger en mémoire un volume de données toujours plus important, même pour afficher une simple page d'accueil.
Pourquoi cette table grossit anormalement
- Des extensions mal codées qui stockent de gros tableaux de données sérialisées directement dans une option unique, plutôt que dans une table dédiée plus adaptée.
- Des extensions désinstallées qui laissent leurs options orphelines en base, jamais nettoyées.
- Des transients mal gérés, notamment sur un site sans cache d'objets persistant (comme Redis), où certaines extensions utilisent wp_options comme solution de repli pour du cache, créant un volume de lignes bien supérieur à ce que serait un usage normal des réglages.
Diagnostiquer et corriger
Une requête SQL simple, exécutée via phpMyAdmin, révèle rapidement les options les plus volumineuses :
SELECT option_name, LENGTH(option_value) AS taille FROM wp_options ORDER BY taille DESC LIMIT 20;
Une autre requête permet de vérifier le volume total chargé par autoload, un indicateur direct de l'impact sur chaque page vue. Une fois les options anormalement volumineuses identifiées, il s'agit généralement de données laissées par une extension désinstallée ou mal maintenue, qu'il est possible de supprimer prudemment après une sauvegarde. Pour les sites avec un volume de transients important, l'ajout d'un cache d'objets persistant comme Redis décharge wp_options de ce rôle qui ne devrait pas être le sien à l'origine.
Un indicateur à surveiller dans le temps
Un diagnostic ponctuel de la table wp_options donne une photographie utile, mais le vrai signal d'alerte se trouve dans l'évolution de ce volume au fil des mois, pas dans sa valeur à un instant donné. Un volume qui double tous les quelques mois sans justification claire (ajout de contenu, nouvelles fonctionnalités réellement utilisées) mérite une investigation, même si la valeur absolue actuelle ne paraît pas encore alarmante.
Sur un site avec un trafic suffisant pour le justifier, ajouter un cache d'objets persistant comme Redis change la donne : les extensions bien codées détectent sa présence et y stockent leurs données temporaires à la place de wp_options, ce qui retire une bonne partie de la pression de croissance sur cette table au fil du temps.
Pour cibler précisément les options chargées en autoload sans passer par une requête SQL manuelle, la commande WP-CLI wp option list --autoload=on --format=table affiche directement la liste concernée, triable par taille. C'est souvent le moyen le plus rapide de confirmer qu'une extension précise, récemment installée ou mise à jour, est responsable d'une hausse soudaine du volume de données chargées à chaque page.
Comment savoir si ma table wp_options est trop grosse ?
Il n'existe pas de seuil universel, mais un volume anormalement élevé d'options autoloadées (plusieurs mégaoctets cumulés) associé à une lenteur générale du site, y compris sur des pages simples, est un signal fort qui justifie un diagnostic approfondi.
Peut-on supprimer n'importe quelle ligne de wp_options sans risque ?
Non. Certaines options sont essentielles au fonctionnement du cœur de WordPress ; seule la suppression d'options clairement identifiées comme appartenant à une extension désinstallée, après sauvegarde, est raisonnable.
Ce type de diagnostic technique demande un accès direct à la base de données, disponible via phpMyAdmin sur nos offres d'hébergement WordPress. Pour les sites avec un trafic important qui bénéficieraient d'un cache d'objets Redis dédié, un VPS Linux permet d'installer cette couche supplémentaire de performance.
