# Autoload des options WooCommerce : une table wp_options qui alourdit chaque requête

> Chaque requête PHP charge en mémoire toutes les options marquées autoload=yes. Sur une boutique WooCommerce chargée d'extensions, cette table finit par peser lourd.

- Auteur : WordPress Développement
- Publié le : 2023-09-29
- Mis à jour le : 2023-09-29
- Catégorie : E-commerce
- URL : https://www.wpmoderne.fr/ecommerce/autoload-options-woocommerce-wp-options-alourdit-requetes/

## L’essentiel

- WordPress charge toutes les options autoload en une seule requête au démarrage
- Certaines extensions marquent des données volumineuses en autoload sans nécessité
- wp option list --autoload=on permet d'identifier les coupables

`SELECT option_name, option_value FROM wp_options WHERE autoload = 'yes'` : cette requête, ou son équivalent produit par le cœur de WordPress, s'exécute au tout début de pratiquement chaque chargement de page, qu'il s'agisse d'une page publique, d'un écran d'administration ou d'un appel à l'API REST. Plus cette table pèse, plus chaque page en pâtit, même celles qui n'ont rien à voir avec WooCommerce.

Sur une boutique auditée récemment, cette requête ramenait plus de huit cents kilo-octets de données à chaque exécution, alors que la quasi-totalité de ces options n'étaient jamais consultées sur la majorité des pages du site.

## Comprendre le mécanisme d'autoload

Chaque entrée de la table `wp_options` porte une colonne `autoload`, historiquement à `yes` ou `no`. Les options marquées `yes` sont chargées systématiquement en mémoire dès le début de l'exécution PHP, via la fonction interne `wp_load_alloptions()`, avant même que le code métier n'en ait besoin. Ce mécanisme accélère l'accès aux options fréquemment utilisées, comme les réglages généraux du site, en évitant une requête séparée à chaque appel de `get_option()`.

Le problème survient quand une extension marque en autoload une donnée volumineuse ou peu consultée : un tableau sérialisé de plusieurs milliers d'entrées, un journal d'événements, ou un cache de résultats qui devrait plutôt vivre dans un transient ou une table dédiée.

## Identifier les options coupables avec WP-CLI

> L'essentiel à retenir : WordPress charge toutes les options autoload en une seule requête au démarrage ; Certaines extensions marquent des données volumineuses en autoload sans nécessité ; wp option list --autoload=on permet d'identifier les coupables

La commande WP-CLI `wp option list` permet de cibler précisément les options autoloadées et leur poids respectif :

```
wp option list --autoload=on --fields=option_name,size_bytes --orderby=size_bytes --order=desc | head -n 20
```

Sur la boutique auditée, cette commande a fait remonter en tête de liste une option créée par une extension de rapprochement comptable, contenant l'historique complet des transactions rapprochées des deux dernières années, marquée en autoload alors qu'elle n'était consultée que depuis un unique écran d'administration peu fréquenté.

## Extensions WooCommerce fréquemment en cause

Certaines catégories d'extensions reviennent régulièrement dans ce type d'audit :

- Les extensions de tarification dynamique qui stockent l'intégralité des règles de remise dans une seule option sérialisée, plutôt que dans une taxonomie ou une table dédiée.
- Les extensions de suivi analytique maison qui accumulent un journal d'événements directement dans `wp_options` au lieu d'une table personnalisée.
- Les extensions de synchronisation avec un service tiers qui conservent un cache de correspondance produit-fournisseur volumineux, marqué en autoload par défaut faute d'avoir été explicitement configuré autrement.

## Corriger sans casser l'extension concernée

Modifier directement la colonne `autoload` d'une option gérée par une extension tierce reste risqué : une prochaine mise à jour de cette extension peut réécrire l'option et restaurer son comportement d'origine, ou pire, l'extension peut dépendre du chargement automatique de cette donnée pour fonctionner correctement sur certains écrans.

```
// À utiliser uniquement après avoir confirmé,
// dans le code de l'extension, que l'option n'a pas besoin
// d'être chargée sur chaque page.
global $wpdb;
$wpdb->update(
    $wpdb->options,
    array( 'autoload' => 'no' ),
    array( 'option_name' => 'nom_de_loption_concernee' )
);
```

La démarche la plus sûre consiste à contacter l'éditeur de l'extension, ou à consulter son dépôt de code si celui-ci est ouvert, pour confirmer que cette donnée peut légitimement passer en `autoload = no` sans effet de bord sur d'autres fonctionnalités.

## Un seuil de vigilance raisonnable

Il n'existe pas de seuil officiel documenté par WordPress, mais l'expérience de terrain situe la vigilance autour de quelques centaines de kilo-octets cumulés : au-delà, l'impact sur le temps de traitement PHP devient mesurable, en particulier sur un hébergement mutualisé où la mémoire allouée reste contrainte.

> Avant de blâmer le serveur ou l'hébergement pour une boutique lente, je vérifie systématiquement le poids cumulé des options autoloadées : c'est souvent la piste la plus rapide à corriger, et l'une des plus négligées.

## Ce que cet audit ne couvre pas

Ce diagnostic porte uniquement sur la table `wp_options` et son mécanisme d'autoload. Le cache objet, qui agit à un tout autre niveau en évitant de répéter des requêtes coûteuses sur d'autres tables, relève d'une problématique distincte, avec ses propres outils de diagnostic.

## Notre verdict

Un allègement de la table d'autoload figure parmi les optimisations les plus rentables sur une boutique WooCommerce chargée d'extensions : elle demande peu de développement, mais nécessite une vérification prudente extension par extension avant toute modification, pour ne pas casser un comportement qui dépendait, sans le documenter, de ce chargement automatique.