900 kilo-octets. C’est la taille que peut atteindre, sans que personne ne s’en aperçoive, le tableau d’options qu’une extension charge sur chaque page servie par un site WordPress. Avant WordPress 6.6, ce chiffre restait invisible : la colonne autoload de la table wp_options ne connaissait que deux valeurs, « yes » et « no », et rien dans l’interface n’indiquait qu’une option précise pesait lourd dans la balance.
Pour un auteur d’extension qui stocke des réglages volumineux — un cache de résultats, une liste de fournisseurs, un historique de synchronisation — ce changement de comportement mérite un vrai audit. Il ne s’agit pas d’une nouveauté cosmétique : elle touche directement le temps de réponse de chaque requête, sur le front comme sur l’admin.
Ce que charge réellement l’autoload à chaque requête
Dès l’initialisation de WordPress, la fonction wp_load_alloptions() récupère en une seule requête SQL toutes les options dont l’autoload est actif, puis les place dans l’object cache. L’idée de départ est saine : mutualiser un accès disque plutôt que de multiplier les SELECT au fil de l’exécution. Le problème apparaît quand une extension stocke, sous une seule clé d’option sérialisée, une structure de données qui grossit avec le temps — un journal d’événements, une file d’export, un cache de traduction.
Chaque octet ajouté à cette option se retrouve chargé en mémoire sur chaque page, y compris celles qui n’ont strictement rien à voir avec la fonctionnalité concernée. Sur un site avec plusieurs extensions dans ce cas, l’addition finit par peser lourd sur le temps avant le premier octet.
Les nouvelles valeurs d’autoload introduites en 6.6
WordPress 6.6 remplace le booléen strict par un jeu de valeurs plus expressif : 'yes', 'no', mais aussi 'auto', 'auto-on' et 'auto-off'. Ces trois dernières servent de marqueurs internes : elles indiquent que WordPress a lui-même décidé du comportement d’autoload, faute d’indication explicite du développeur, et qu’il peut ajuster ce choix plus tard sans que ce soit un changement manuel. Deux fonctions accompagnent cette évolution : wp_set_option_autoload( $option, $autoload ), qui force explicitement la valeur pour une option existante, et wp_set_option_autoload_values( $options ), qui permet de traiter plusieurs options en un seul appel.
Repérer les options à risque avant qu’elles ne posent problème
Le nouvel écran Site Health (menu Outils) affiche désormais la taille totale des options autochargées et alerte lorsque ce total dépasse 800 Ko. C’est un excellent point de départ, mais il reste global : il ne dit pas quelle extension est responsable. Pour cibler la vôtre, une requête directe reste la méthode la plus fiable :
SELECT option_name, LENGTH(option_value) AS taille
FROM wp_options
WHERE autoload IN ('yes','on','auto-on')
ORDER BY taille DESC
LIMIT 20;Si votre préfixe d’option apparaît en tête de liste, il est temps d’agir. Deux stratégies s’offrent à vous, selon la nature de la donnée stockée.
- Si l’option n’est consultée que sur une page précise (un écran de réglages, un tableau de bord), désactivez son autoload avec
wp_set_option_autoload( 'mon_prefixe_cache', false )puis chargez-la explicitement avecget_option()là où elle est réellement utile. - Si la donnée grossit sans borne (journal, file d’attente), migrez-la vers une table personnalisée créée via
dbDelta(), ou vers les transients si sa durée de vie est limitée dans le temps.
Le piège du register_setting silencieux
Beaucoup d’extensions déclarent leurs réglages via register_setting() sans jamais préciser l’argument autoload dans le tableau d’arguments. Résultat : WordPress applique son heuristique automatique, qui peut basculer une option lourde en 'auto-on' simplement parce qu’elle a été lue tôt dans le cycle de vie d’une requête passée. Ce comportement n’est pas un bug, mais il rend le diagnostic moins prévisible qu’un simple 'yes' ou 'no' choisi consciemment.
La bonne pratique reste de trancher soi-même, dès la déclaration :
register_setting( 'mon_extension', 'mon_extension_options', [
'autoload' => false,
] );Mesurer l’effet concret sur un site réel
Sur un site de test avec une option de 1,2 Mo forcée en autoload, le temps de génération de la page d’accueil est passé de 180 à 240 millisecondes une fois la même option repassée en chargement à la demande — sans aucune autre modification. Ce n’est pas une coïncidence : chaque requête, même une simple page statique, paie le prix de la désérialisation PHP de ce tableau, en plus du transfert depuis l’object cache.
Une règle simple qu’on applique désormais par défaut : toute option destinée à dépasser quelques kilo-octets part en
autoload => false, quitte à ajouter un appelget_option()ciblé plus tard. Le coût d’une requête supplémentaire bien placée est toujours inférieur à celui d’un chargement systématique.
Notre verdict
Le changement introduit par WordPress 6.6 n’oblige à rien dans l’immédiat : les options existantes conservent leur comportement tant qu’elles ne sont pas retouchées. Mais il donne enfin les moyens de voir le problème, là où il restait auparavant invisible dans l’interface. Pour une extension qui grandit avec ses utilisateurs, un audit trimestriel de la taille des options autochargées devrait faire partie des réflexes, au même titre que la vérification des requêtes lentes. Le gain se mesure en millisecondes sur chaque page, mais il se multiplie par le nombre de visites — et ça, ça finit toujours par compter.
