Nettoyer wp_options et réduire les autoload gourmands

Si vous voyez des pages admin qui mettent 3 à 10 secondes à s’ouvrir alors que le front-end “va à peu près”, j’ai souvent retrouvé le même coupable : la table wp_options et, plus précisément, des options marquées autoload = yes qui gonflent la charge à chaque requête.

Le problème

Le symptôme n’est pas toujours une erreur “visible”. Souvent, vous n’avez que des lenteurs… et des logs qui racontent une autre histoire. Voici des messages typiques que je vois sur des hébergements PHP-FPM quand l’autoload devient énorme.

PHP Fatal error:  Allowed memory size of 268435456 bytes exhausted (tried to allocate 20480 bytes)
in /wp-includes/option.php on line XXXX

PHP Warning:  mysqli_real_connect(): (HY000/2006): MySQL server has gone away
in /wp-includes/wp-db.php on line XXXX

PHP Fatal error:  Maximum execution time of 30 seconds exceeded
in /wp-includes/wp-db.php on line XXXX

Où ça apparaît :

Admin : ouverture de “Extensions”, “Réglages”, “Apparence”, éditeur de blocs, écran des widgets.
Front-end : Time To First Byte (TTFB) élevé, surtout sur les pages non mises en cache.
WP-Cron : tâches planifiées qui dépassent le time limit, en particulier si elles chargent WordPress complet.
REST API / AJAX : endpoints lents (Elementor, Divi, Avada, WooCommerce, etc.).

Circonstances typiques :

Après l’installation/désinstallation répétée de plugins “builder”, cache, SEO, stats, sécurité.
Après une migration (staging → prod) où des options de debug, de cache, ou des transients ont été importés tels quels.
Après une mise à jour majeure d’un plugin qui change sa stratégie de stockage (options sérialisées plus grosses).

À la fin, vous saurez :

mesurer la taille réelle de l’autoload,
identifier les options problématiques,
désactiver l’autoload sans casser le site,
corriger le code (ou le plugin) qui recrée le problème.

Résumé rapide

Ce qui ralentit : WordPress charge en mémoire toutes les options autoload=yes très tôt dans l’exécution.
Le seuil “à surveiller” : au-delà de quelques Mo d’autoload, l’admin commence souvent à souffrir (ça dépend du serveur, des plugins et du cache objet).
Le bon réflexe : auditer avant de supprimer. Beaucoup d’options “grosses” sont critiques (cache de config, routes, schémas).
La correction durable : remplacer les “gros tableaux” autoloadés par des options non autoloadées, ou par des entrées dédiées (transients, custom tables, fichiers, cache objet).
Outils : Query Monitor + Health Check, puis WP-CLI/SQL si besoin.

Les symptômes

Voici ce que vous pouvez observer quand wp_options est saturée d’autoload, du plus courant au plus trompeur.

Admin lente (même sur des pages “simples” comme la liste des articles).
TTFB élevé sur le front-end, surtout quand le cache page est contourné (utilisateur connecté, panier WooCommerce, preview, etc.).
Pic mémoire dès le début de la requête PHP (avant même que votre thème ne fasse quoi que ce soit).
Requêtes MySQL plus lourdes : une requête “options autoload” ramène beaucoup de données.
Timeouts intermittents : ça passe sur certaines pages, ça casse sur d’autres (ex. éditeur Elementor/Divi).
Comportements bizarres après “optimisation” : un plugin qui perd sa config, des permaliens qui sautent, une API REST qui renvoie 404/500 (souvent parce que quelqu’un a supprimé une option critique).

Tableau de diagnostic rapide

Symptôme	Cause probable	Vérification	Solution
Admin très lente, CPU OK	Autoload énorme	Mesurer la taille autoload (SQL/WP-CLI)	Désactiver autoload sur options non critiques
Erreur mémoire sur `option.php`	Autoload + options sérialisées trop grosses	Logs + top options par taille	Découper / non-autoload / refactor stockage
REST/AJAX lent (builder)	Chargement WP complet + autoload	Query Monitor sur endpoint	Réduire autoload + cache objet
Lenteur seulement pour utilisateurs connectés	Cache page contourné, autoload visible	Comparer TTFB connecté/déconnecté	Réduire autoload + optimiser plugins
Après “nettoyage”, plugin cassé	Option supprimée au lieu de désautoload	Regarder l’historique (backup), logs	Restaurer puis corriger proprement

Pourquoi ça arrive

Version simple : WordPress garde des réglages dans wp_options. Certains réglages sont marqués autoload = yes, ce qui veut dire “chargez-moi automatiquement à chaque requête”. Si des plugins mettent là-dedans des données volumineuses, WordPress les charge tout le temps, même quand elles ne servent pas.

Version technique (WordPress 6.9.4, PHP 8.1+) : au bootstrap, WordPress appelle le chargement des options autoloadées via l’API Options (Options API). L’objectif est de réduire le nombre de requêtes SQL en récupérant en une fois un ensemble d’options fréquemment utilisées. L’effet pervers : plus la “payload” autoload grossit, plus vous payez :

du temps SQL (réponse plus lourde),
du temps PHP (désérialisation),
de la mémoire (variables conservées dans le cache interne des options),
et parfois du réseau (si DB distante).

Les causes probables (du plus fréquent au plus rare)

Plugins qui stockent des caches volumineux dans une option autoloadée (anti-pattern classique : un tableau géant sérialisé).
Builders (Divi/Elementor/Avada) + add-ons : ils ajoutent beaucoup d’options, et certains add-ons stockent des “registries” énormes.
Transients mal gérés : des transients “options” laissés en base, parfois autoloadés selon la façon dont ils ont été créés (ou migrés).
Options orphelines après désinstallation : l’uninstall n’a pas nettoyé.
Mauvaise migration : import d’une base de staging avec des options de debug/cache activées, ou d’un plugin de cache qui a stocké des données dans options.
Cache objet absent : même un autoload “raisonnable” peut devenir visible quand rien n’amortit.

Prérequis avant de commencer

Sauvegarde complète fichiers + base. Si vous n’avez pas de snapshot, ne touchez pas aux options “à l’aveugle”.
Un staging : faites vos tests sur une copie. Les options cassées sont pénibles à restaurer proprement.
Versions : WordPress 6.9.4, PHP 8.1+ (idéalement 8.2/8.3 si votre stack le permet), MySQL/MariaDB à jour.
Outils recommandés :
- Query Monitor (profiling requêtes, hooks, erreurs PHP),
- Health Check & Troubleshooting (mode dépannage sans impacter les visiteurs),
- WP-CLI si vous avez l’accès SSH : WP-CLI Commands.

Activer les logs correctement (sans afficher aux visiteurs)

Dans wp-config.php, sur staging, j’active souvent :

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false ); // Ne pas afficher les erreurs aux visiteurs
@ini_set( 'display_errors', '0' );

Référence : Debugging in WordPress.

Solution 1 : auditer les autoload (sans rien casser)

Avant de modifier quoi que ce soit, mesurez. Beaucoup de gens “nettoient” en supprimant des options au hasard, puis passent deux heures à réparer un plugin qui ne retrouve plus sa configuration.

Mesurer la taille totale de l’autoload

En SQL (via phpMyAdmin/Adminer). Adaptez le préfixe si vous n’êtes pas en wp_.

SELECT 
  ROUND(SUM(LENGTH(option_value)) / 1024 / 1024, 2) AS autoload_mb,
  COUNT(*) AS autoload_count
FROM wp_options
WHERE autoload = 'yes';

Interprétation pratique (observations terrain) :

< 1 Mo : généralement OK.
1–5 Mo : surveillez, surtout sans cache objet persistant.
5–20 Mo : l’admin commence souvent à devenir pénible, et les endpoints REST/AJAX aussi.
> 20 Mo : j’ai fréquemment des timeouts/mémoire sur des hébergements mutualisés.

Lister les options autoload les plus lourdes

SELECT 
  option_name,
  autoload,
  ROUND(LENGTH(option_value)/1024, 1) AS size_kb
FROM wp_options
WHERE autoload = 'yes'
ORDER BY LENGTH(option_value) DESC
LIMIT 50;

Ce que vous cherchez :

des options > 100–300 Ko (souvent suspect),
des options sérialisées énormes (valeurs commençant par a:),
des options qui ressemblent à des caches (mots-clés cache, transient, feed, schema, routes, registry).

Diagnostic côté WordPress (Query Monitor)

Avec Query Monitor, regardez :

le temps total DB,
les requêtes “options”,
la mémoire peak,
les hooks lents (souvent des plugins qui font get_option() en boucle).

Query Monitor ne vous affichera pas toujours “la requête autoload” clairement selon la configuration, mais il vous donne la dynamique : DB lourde + mémoire qui monte très tôt.

Code AVANT / APRÈS : un audit safe via mu-plugin

J’évite de coller ce genre de snippet dans un thème (trop facile de le perdre au changement de thème). Utilisez plutôt un mu-plugin : wp-content/mu-plugins/autoload-audit.php.

AVANT (cassé / anti-pattern) : pas d’audit, on “nettoie” à l’aveugle en supprimant des options.

<?php
// Mauvaise pratique : suppression au hasard en production (exemple)
delete_option( 'mon_plugin_settings' );
delete_option( 'elementor_some_option' );

APRÈS (audit) : on logge les plus grosses options autoload, sans modifier la DB.

<?php
/**
 * Plugin Name: Autoload Audit (mu-plugin)
 * Description: Journalise les options autoload les plus lourdes (staging uniquement).
 */

// Sécurité : ne pas exécuter si WordPress n'est pas chargé
if ( ! defined( 'ABSPATH' ) ) {
	exit;
}

add_action( 'admin_init', function () {
	// Évitez de faire ça en production : ça ajoute une requête et du log.
	if ( ! defined( 'WP_DEBUG' ) || ! WP_DEBUG ) {
		return;
	}

	global $wpdb;

	// On limite à l'admin pour éviter de polluer les logs front
	$limit = 30;

	// phpcs:ignore WordPress.DB.DirectDatabaseQuery.DirectQuery
	$rows = $wpdb->get_results(
		$wpdb->prepare(
			"SELECT option_name, LENGTH(option_value) AS bytes
			 FROM {$wpdb->options}
			 WHERE autoload = %s
			 ORDER BY bytes DESC
			 LIMIT %d",
			'yes',
			$limit
		)
	);

	if ( empty( $rows ) ) {
		return;
	}

	error_log( '--- Autoload Audit : TOP ' . $limit . ' ---' );
	foreach ( $rows as $row ) {
		error_log( sprintf( '%s = %0.1f KB', $row->option_name, ( $row->bytes / 1024 ) ) );
	}
}, 20 );

Pourquoi ça aide : vous obtenez une shortlist fiable, répétable, et vous pouvez corréler avec l’activation/désactivation de plugins (Health Check) pour trouver le responsable.

Solution 2 : corriger le code qui abuse de autoload

Le vrai problème n’est pas “wp_options est grosse”. Le problème, c’est des données volumineuses chargées automatiquement. La correction durable consiste à :

mettre autoload = no pour les options lourdes non nécessaires à chaque requête,
ou changer la stratégie de stockage (cache objet, transients, fichiers, table dédiée).

Cas fréquent : un plugin stocke un gros tableau en autoload

J’ai souvent vu ça sur des plugins maison, ou des snippets copiés d’un vieux tutoriel : on met une config + un cache dans une seule option, marquée autoload par défaut.

AVANT (cassé) : option énorme et autoloadée

<?php
// Exemple typique : on stocke un cache volumineux dans une option autoloadée.
function monplugin_rebuild_cache() {
	$cache = array();

	// ... génération d'un gros tableau (ex : 10 000 entrées) ...
	for ( $i = 0; $i < 10000; $i++ ) {
		$cache[] = array(
			'id'    => $i,
			'title' => 'Entrée ' . $i,
			'data'  => str_repeat( 'x', 200 ),
		);
	}

	// Mauvaise pratique : update_option() autoload "yes" par défaut si l'option n'existe pas.
	update_option( 'monplugin_big_cache', $cache );
}

Pourquoi c’est mauvais : si l’option n’existait pas, WordPress la crée avec autoload = yes par défaut (comportement historique). Résultat : vous chargez ce cache à chaque requête, même quand vous n’en avez pas besoin.

APRÈS (corrigé) : option non-autoload + cache objet

<?php
/**
 * Stockage corrigé :
 * - l'option persiste, mais n'est pas autoloadée
 * - le cache est servi depuis le cache objet quand possible
 */

function monplugin_get_big_cache() {
	$cache = wp_cache_get( 'big_cache', 'monplugin' );
	if ( false !== $cache ) {
		return $cache;
	}

	// Option non-autoloadée : ne pèse pas sur chaque requête
	$cache = get_option( 'monplugin_big_cache', array() );

	// On remet en cache objet pour accélérer les hits
	wp_cache_set( 'big_cache', $cache, 'monplugin', 300 ); // 5 minutes

	return $cache;
}

function monplugin_rebuild_cache() {
	$cache = array();

	for ( $i = 0; $i < 10000; $i++ ) {
		$cache[] = array(
			'id'    => $i,
			'title' => 'Entrée ' . $i,
			'data'  => str_repeat( 'x', 200 ),
		);
	}

	// On force autoload = false à la création/mise à jour
	update_option( 'monplugin_big_cache', $cache, false );

	// On garde le cache objet cohérent
	wp_cache_set( 'big_cache', $cache, 'monplugin', 300 );
}

Pourquoi ça corrige :

update_option( ..., false ) empêche l’autoload à la création et à la mise à jour.
Le cache objet (Redis/Memcached si présent) absorbe la charge au lieu de la DB.
Même sans cache objet persistant, vous évitez de charger le gros blob à chaque requête.

Références utiles :

Cas builder (Divi 5 / Elementor / Avada) : options lourdes “légitimes”

Avec Divi 5, Elementor ou Avada, vous aurez forcément beaucoup d’options. Le but n’est pas de “tout réduire”, mais d’identifier :

les add-ons qui stockent des bibliothèques/registries énormes en autoload,
les options d’import/export (templates) qui restent en autoload,
les caches internes qui auraient dû être transients.

Approche que j’utilise :

Health Check → “Mode dépannage” → activer uniquement le builder + le thème → mesurer autoload.
Réactiver les add-ons un par un → repérer celui qui fait exploser la taille.

Si vous identifiez un plugin tiers responsable, la meilleure “correction” est souvent :

un ticket au support du plugin avec la preuve (nom d’option + taille + autoload),
ou un snippet temporaire qui bascule autoload à no (voir Solution 3),
et une surveillance, car certaines extensions recréent l’option à chaque update.

Solution 3 : nettoyage avancé (WP-CLI et SQL)

Cette partie est celle qui fait gagner le plus de temps… et celle qui casse le plus de sites quand elle est faite sans méthode. Travaillez sur staging, puis déployez.

3.1 Basculer une option de autoload=yes vers autoload=no (sans supprimer)

Supprimer une option est risqué. Dans la majorité des cas, basculer l’autoload suffit à récupérer des performances sans perdre la config.

En SQL :

UPDATE wp_options
SET autoload = 'no'
WHERE option_name = 'monplugin_big_cache'
LIMIT 1;

Ensuite, purge des caches (voir section vérifications).

3.2 Identifier les transients “options” qui traînent

Les transients stockés en base créent des entrées _transient_* et _transient_timeout_* dans wp_options. Normalement, ils ne devraient pas être autoloadés, mais selon l’historique (plugins, migrations), vous pouvez en retrouver en autoload.

Requête de repérage :

SELECT option_name, autoload, ROUND(LENGTH(option_value)/1024, 1) AS size_kb
FROM wp_options
WHERE option_name LIKE '_transient_%'
AND autoload = 'yes'
ORDER BY LENGTH(option_value) DESC
LIMIT 50;

Si vous trouvez des transients autoloadés, c’est presque toujours un bug côté plugin ou un héritage de migration. Vous pouvez souvent :

basculer autoload à no,
ou supprimer les transients concernés (moins risqué que supprimer des options de config).

Suppression ciblée (exemple) :

DELETE FROM wp_options
WHERE option_name IN (
  '_transient_monplugin_heavy',
  '_transient_timeout_monplugin_heavy'
);

Référence : Transients API.

3.3 WP-CLI : audit et export avant modification

WP-CLI n’a pas une commande “autoload top 50” native universelle qui remplace toutes les requêtes ci-dessus, mais il excelle pour sécuriser votre workflow : export, search-replace, et exécution SQL.

Export de la table options (ou au minimum) :

wp db export options-backup.sql --tables=wp_options

Mesurer la taille autoload via WP-CLI SQL :

wp db query "SELECT ROUND(SUM(LENGTH(option_value))/1024/1024,2) AS autoload_mb, COUNT(*) AS autoload_count FROM wp_options WHERE autoload='yes';"

Lister les plus lourdes :

wp db query "SELECT option_name, ROUND(LENGTH(option_value)/1024,1) AS size_kb FROM wp_options WHERE autoload='yes' ORDER BY LENGTH(option_value) DESC LIMIT 50;"

Références :

3.4 Quand vous devez supprimer (rare) : critères

Je ne supprime une option que si :

elle appartient clairement à un plugin désinstallé,
elle est manifestement un cache (pas une config),
et je sais comment la régénérer.

Sinon, je préfère :

désactiver autoload,
ou laisser en place et corriger le code source.

Vérifications après correction

Mesurez à nouveau la taille autoload (la même requête qu’au début). Attendez une baisse tangible.
Videz les caches :
- cache plugin (LiteSpeed Cache, WP Rocket, etc.),
- cache serveur (Varnish),
- cache objet (Redis/Memcached),
- OPcache si vous avez la main (rare en mutualisé).
Testez admin + builder :
- éditeur de blocs,
- Elementor editor / Divi Visual Builder / Avada Live,
- customizer si utilisé.
Surveillez les logs (wp-content/debug.log) pendant 10–20 minutes de navigation.
Contrôlez le “peak memory” avec Query Monitor : vous cherchez une baisse, surtout au début de la requête.

Résultat attendu

moins de mémoire consommée,
moins de temps DB,
admin plus réactive,
moins de timeouts sur REST/AJAX.

Si ça ne marche toujours pas

Quand l’autoload est sous contrôle mais que le site reste lent, voici la procédure que j’applique, dans cet ordre.

1) Vérifier un conflit plugin/thème sans impacter les visiteurs

Activez Health Check → mode dépannage.
Gardez uniquement le thème + les plugins indispensables.
Mesurez à nouveau : si la lenteur disparaît, vous avez un plugin responsable (même si l’autoload est “OK”).

2) Vérifier le cache objet persistant

Sans Redis/Memcached, WordPress refait beaucoup de travail à chaque requête. Un autoload réduit aide, mais ne compense pas tout. Sur des sites builders + WooCommerce, un cache objet persistant change souvent la donne.

Contrôle : si vous utilisez un plugin Redis, vérifiez qu’il est bien “connecté” et actif. Sinon, vous avez un faux sentiment de cache.

3) Vérifier la santé DB et les index

Une table wp_options énorme n’est pas forcément un problème si elle est bien utilisée, mais si votre DB est à bout (I/O, CPU, buffer pool), tout ralentit.

Regardez les métriques côté hébergeur.
Vérifiez que vous n’avez pas des requêtes lentes répétées (Query Monitor, slow query log si disponible).

4) Vérifier PHP : mémoire, timeouts, OPcache

Une autoload énorme se manifeste plus vite avec :

memory_limit trop bas,
max_execution_time agressif,
OPcache désactivé.

Référence PHP : PHP core directives.

5) Vérifier les permaliens et règles de réécriture (effets secondaires)

Après certaines manipulations, vous pouvez avoir des 404 REST ou admin-ajax qui ressemblent à “une lenteur”. Test rapide : Réglages → Permaliens → Enregistrer (sans changer). Si vous automatisez, utilisez flush_rewrite_rules() uniquement en activation, jamais à chaque requête.

Référence : flush_rewrite_rules().

Pièges et erreurs courantes

Symptôme	Cause probable	Erreur observée	Solution recommandée
Plugin “perd” ses réglages	Option supprimée	Vous avez fait `DELETE` au lieu de `autoload=no`	Restaurer depuis backup, puis basculer autoload uniquement
Lenteur revient après 24h	Plugin recrée l’option en autoload	Correction faite en DB mais pas dans le code	Corriger `update_option(..., false)` ou ouvrir un ticket plugin
Erreur 500 après ajout d’un snippet	Snippet cassé	Point-virgule manquant, code collé au mauvais endroit	Mettre en mu-plugin, valider sur staging, vérifier logs
Aucune amélioration malgré autoload réduit	Cache page/objet, CPU, DB	Vous n’avez pas vidé les caches ou vous testez connecté uniquement	Purger caches, comparer connecté/déconnecté, profiler avec Query Monitor
Autoload “faible” mais site lent	Hooks lents / requêtes custom	Vous vous focalisez sur `wp_options` alors que le problème est ailleurs	Profiling : Query Monitor, endpoints REST, requêtes lentes

Erreurs que je vois souvent (et qui coûtent cher)

Tester en production sans sauvegarde : une option critique supprimée peut casser l’admin ou le checkout.
Copier un SQL trouvé sur un forum qui supprime “tous les transients” sans vérifier : ça peut déclencher des régénérations massives et empirer la charge.
Confondre “option lourde” et “option inutile” : certaines options volumineuses sont nécessaires (elles ne devraient juste pas être autoloadées).
Oublier le cache : vous mesurez avant/après sans purger, et vous concluez à tort que “ça ne marche pas”.
Snippet placé dans le mauvais fichier (functions.php du thème parent, ou plugin de snippets qui se désactive) : vous perdez la correction au prochain update.

Variante / alternative

Méthode sans code : plugin de nettoyage (avec prudence)

Il existe des plugins qui affichent les options autoload et aident à les gérer. Je reste prudent : certains outils encouragent la suppression plutôt que la désactivation d’autoload. Si vous passez par un plugin :

faites-le sur staging,
exportez wp_options avant,
n’appliquez que des changements réversibles (autoload no),
documentez ce que vous avez changé (liste d’options).

Méthode plus avancée : refactor “stockage” (développeurs)

Quand vous contrôlez le code (plugin maison, ou projet client), la meilleure approche long terme est :

Options autoload : uniquement des scalaires et petites configs nécessaires à chaque requête.
Données volumineuses : cache objet, transients avec expiration, ou table dédiée si c’est structurel.
Nettoyage : hook d’uninstall (fichier uninstall.php) pour supprimer options/transients propres au plugin.

Référence : Uninstall methods.

Éviter ce problème à l’avenir

1) Forcer autoload=false dès la création des options “lourdes”

C’est la mesure la plus simple et la plus efficace. Beaucoup de devs oublient le 3e paramètre de update_option().

<?php
// Bon réflexe : toute option susceptible de grossir doit être non-autoloadée.
update_option( 'monplugin_big_cache', $data, false );

2) Ne pas faire de `get_option()` en boucle sans cache

J’ai vu des plugins faire 200 appels get_option() par requête, parfois dans des boucles de rendu. Même si l’option est autoloadée, ça ajoute du travail inutile. Regroupez, ou mettez en cache applicatif.

3) Mettre en place un contrôle périodique (staging ou maintenance)

Sur des sites qui bougent beaucoup (builders + marketing + A/B tests), je planifie un audit mensuel :

taille autoload,
top 20 options,
nouveaux préfixes d’options (nouveaux plugins),
vérification des transients “anormaux”.

4) Règle simple pour les builders

Divi 5, Elementor et Avada multiplient les couches (widgets/modules, templates, bibliothèques). Le risque vient surtout des add-ons. Si vous devez installer un add-on, vérifiez :

sa fréquence de mise à jour,
sa réputation sur wordpress.org,
et surveillez wp_options la semaine qui suit.

5) Sécurité : ne jamais exposer la liste des options en front

Les options peuvent contenir des clés API, des tokens, des URLs internes. Si vous écrivez un outil d’audit, gardez-le :

en admin uniquement,
derrière des capacités (ex. manage_options),
et évitez d’afficher des valeurs brutes.

Ressources

Questions fréquentes

Quelle est une “bonne” taille d’autoload sur WordPress 6.9.4 ?

Il n’y a pas de seuil officiel, mais en pratique : < 1 Mo est confortable, 1–5 Mo se surveille, > 5–10 Mo commence souvent à impacter l’admin, surtout sans cache objet persistant.

Est-ce que je peux supprimer toutes les options d’un plugin désinstallé ?

Parfois oui, mais faites-le après export/backup. Certains plugins partagent des librairies ou laissent des données utilisées par un autre module. Si vous avez un doute, basculez d’abord autoload à no au lieu de supprimer.

Pourquoi l’admin est plus lente que le front-end ?

Le front-end est souvent servi par un cache page. L’admin ne l’est pas. Du coup, tout ce qui alourdit le bootstrap (autoload, hooks, requêtes) se voit immédiatement dans l’admin.

Est-ce que WooCommerce est souvent responsable ?

WooCommerce ajoute beaucoup d’options, mais le problème vient plus souvent d’extensions WooCommerce ou de caches/configs volumineux stockés en autoload. Auditez les options les plus lourdes au lieu d’accuser un plugin “généraliste”.

Est-ce risqué de passer une option de autoload=yes à autoload=no ?

C’est nettement moins risqué que de supprimer. L’option reste disponible via get_option(), elle n’est juste plus chargée automatiquement. Le risque principal : un code qui suppose que l’option est déjà en mémoire (mauvaise pratique), mais c’est rare.

Pourquoi le problème revient après une mise à jour ?

Parce que le plugin recrée l’option (ou la migre) avec le comportement par défaut (autoload yes). Tant que le code n’est pas corrigé (ou tant que le plugin n’a pas patché), vous devrez surveiller et éventuellement réappliquer la bascule.

Dois-je optimiser la table (OPTIMIZE TABLE) ?

Parfois, mais ce n’est pas le levier principal. Le gain vient surtout de réduire la quantité de données autoloadées. OPTIMIZE TABLE peut aider après de grosses suppressions, mais il peut verrouiller la table selon le moteur et la configuration.

Les transients sont-ils le même problème que autoload ?

Pas exactement. Les transients sont des données temporaires avec expiration. Le souci arrive quand des transients volumineux traînent en base, ou (plus rare) se retrouvent autoloadés à cause d’un bug ou d’une migration.

Est-ce que ça aide si j’ai Redis ?

Oui, mais ça ne justifie pas un autoload énorme. Redis amortit, mais vous payez quand même la désérialisation et la mémoire PHP si vous chargez des blobs géants. Le bon combo : autoload raisonnable + cache objet persistant.

Je suis sur Divi 5 / Elementor / Avada : je fais quoi en priorité ?

Mesurez l’autoload, listez le top 50, puis utilisez Health Check pour isoler l’add-on qui fait exploser la taille. Les builders eux-mêmes sont rarement “le bug”, ce sont les extensions qui stockent trop en autoload.