Base de données WordPress gonflée : nettoyer l’autoload wp_options sans tout casser

janvier 24, 2026 • février 3, 2026 • Lecture : 27 min • Views: 17

Cet article vous a aidé ?

Quand WordPress devient « mystérieusement lent », le coupable n’est souvent pas PHP, pas le thème, et parfois pas même votre serveur de base de données. C’est un schéma sur une seule ligne de table : wp_options rempli de mégaoctets de données autoload inutiles que WordPress charge en mémoire à chaque requête.

Vous le remarquez via une augmentation du TTFB, des pics aléatoires lors des rafales de trafic, des pages d’administration qui donnent l’impression d’un modem 56k, et une CPU de base de données qui est inactive jusqu’à ce qu’elle ne le soit plus. Le meilleur, c’est que le site peut encore « fonctionner », jusqu’au moment où il ne fonctionne plus. Nettoyons cela en toute sécurité, comme des responsables qui gèrent un environnement de production.

Table des matières

Ce que signifie réellement l’autoload (et pourquoi c’est problématique)
Procédé de diagnostic rapide
Faits et historique utiles à exploiter
Mesurer d’abord : à quoi ressemble le « gonflement » en chiffres réels
Tâches pratiques : commandes, sorties, décisions (12+)
Modifications sûres : ce que vous pouvez supprimer vs. ce qu’il faut maîtriser
Trois mini-récits du monde corporate
Erreurs courantes : symptôme → cause racine → correctif
Listes de contrôle / plan étape par étape
Prévention : empêcher le retour du gonflement autoload
FAQ
Étapes suivantes à faire aujourd’hui

Ce que signifie réellement l’autoload (et pourquoi c’est problématique)

wp_options est le « tiroir fourre-tout » de WordPress. Paramètres, état des extensions, caches, drapeaux de fonctionnalités, jetons API, tâches cron et valeurs « temporaires » qui vivent éternellement — la plupart finissent ici.

Le champ clé : autoload. Si une option a autoload='yes', WordPress tentera de la charger tôt (via wp_load_alloptions()) pour éviter de nombreuses petites requêtes. C’est une bonne idée quand les données autoloadées sont petites et stables. C’est une mauvaise idée quand il s’agit de 10–100+ Mo de tableaux sérialisés, de configurations de widgets, de caches d’extensions géants et des rêves brisés d’un plugin marketing qui n’a jamais rencontré une base de données qu’il ne voulait pas sur-partager.

Voici le mode de défaillance : les options autoloadées sont récupérées sur la plupart des requêtes (front-end et admin). Même si vous avez un cache d’objets, ces valeurs doivent quand même être chargées en mémoire au moins une fois par cycle de cache et sont souvent copiées/sérialisées. Plus c’est volumineux, plus vous brûlez de CPU et de mémoire, et plus vous amplifiez la latence lors des pertes de cache, des déploiements, des redémarrages de pods ou des basculements.

Une vérité sèche : vous n’allez pas « optimiser MySQL » pour régler ça. Vous arrêtez d’autoloader les déchets.

Petite blague #1 : Le gonflement autoload, c’est comme un tiroir à bazar : ça commence par une pile de rechange et ça finit avec trois clés mystères et un petit tournevis que vous n’arrivez pas à jeter.

Autoload n’est pas un « cache »

Les options autoloadées ne sont pas un cache intelligent avec TTL. Elles signifient « charger ceci à chaque fois parce que quelqu’un a supposé que c’est nécessaire ». Cette hypothèse est souvent fausse, surtout pour les plugins qui stockent de grosses structures calculées ou des logs en tant qu’options.

Pourquoi ça impacte les performances de façon bizarre et par rafales

Démarrages à froid : redémarrages FPM, replanification de conteneurs, nouvelles instances à l’échelle — les options autoloadées doivent être réchauffées. C’est là que le site devient le plus lent.
Usure du cache d’objets : si votre cache d’objets évince fréquemment, vous rechargez les données autoloadées plus souvent que vous ne le pensez.
Retard de réplication : les grosses mises à jour d’options génèrent des binlogs/changesets plus importants, augmentant le lag sous charge.
Verrouillage/IO : les mises à jour de grosses options signifient de gros écrits et, sur un stockage partagé ou des disques saturés, vous payez en latence.

Procédé de diagnostic rapide

Si un site WordPress est lent et que vous suspectez un gonflement de wp_options autoload, ne vous égarez pas. Vérifiez trois choses dans cet ordre :

1) Les données autoloadées sont-elles énormes ?

Exécutez une somme rapide des tailles des options autoloadées. Si c’est au-delà de quelques Mo, vous avez une piste. Si c’est des dizaines de Mo, vous avez votre coupable.

2) Quelles options causent le problème ?

Trouvez les principaux responsables par taille. Vous cherchez des gros tableaux sérialisés, des caches d’extensions et tout ce qui n’a clairement pas besoin d’être chargé à chaque requête.

3) La lenteur est-elle liée aux pertes de cache / redémarrages ?

Corrélez les pics avec les redémarrages FPM, la replanification de conteneurs ou les évictions Redis/Memcached. Le gonflement autoload amplifie la douleur des démarrages à froid.

Puis décidez : supprimez les déchets évidents (transients expirés, restes d’extensions) et passez les éléments « gros mais parfois nécessaires » de autoload à non-autoload, idéalement en les remplaçant par un cache approprié.

Faits et historique utiles à exploiter

Les options WordPress précèdent de nombreux plugins modernes : l’API d’options a été conçue pour de petits réglages, pas pour des blobs de plusieurs mégaoctets.
Autoload visait à réduire le nombre de requêtes : à l’époque, beaucoup de petites requêtes étaient pire que le gonflement mémoire.
Les tableaux PHP sérialisés ont facilité le stockage de n’importe quoi : mais aussi le stockage de tout, pour toujours, sans pression schématique.
Les transients ont été introduits comme « cache temporaire » : mais sans cache d’objets persistant, les transients vivent souvent dans wp_options et peuvent s’accumuler.
Beaucoup de plugins utilisent wp_options comme décharge : parce que c’est universellement disponible, pas parce que c’est approprié.
Les sites WooCommerce sont souvent victimes : pas parce que WooCommerce est particulièrement mauvais, mais parce que la densité de plugins augmente le churn d’options.
Le gonflement autoload peut être masqué par un CDN : les pages semblent « rapides » depuis le cache, jusqu’à l’expiration du cache ou lorsqu’un utilisateur connecté accède à des points dynamiques.
La taille de la base de données n’est pas le bon indicateur : une base de 2 Go peut aller ; un payload autoload de 20 Mo à chaque requête ne va pas.
Certaine hébergeurs « optimisent » via OPTIMIZE TABLE : ce qui ne résout pas le gonflement autoload et peut ajouter des problèmes d’IO/verrouillage si exécuté au mauvais moment.

Mesurer d’abord : à quoi ressemble le « gonflement » en chiffres réels

Le travail en production commence par la mesure. Pas par les impressions. L’objectif est de répondre :

Quelle est la taille du payload autoloadé ?
Qui sont les principaux responsables ?
Est-ce que cela augmente ?
Qu’est-ce qui est sûr à supprimer vs. simplement désactiver l’autoload ?

Règles empiriques (opinées, parce que vous l’avez demandé) :

< 1 Mo autoload total : probablement acceptable. N’ajoutez pas de tâches inutiles.
1–5 Mo : gardez un œil ; investigatez quelques éléments principaux.
5–20 Mo : vous payez une taxe de latence. Nettoyez.
> 20 Mo : vous êtes en zone incident ; les cold starts seront désagréables.

Ces seuils varient selon le matériel et le caching. Mais en pratique, une fois que l’autoload dépasse « quelques Mo », cela devient un risque de fiabilité car ça multiplie le coût de chaque événement de miss de cache.

Et un mantra de fiabilité du terrain : Tout échoue tout le temps. — idée paraphrasée de Werner Vogels. Le gonflement autoload transforme ces défaillances routinières (redémarrages, évictions) en lenteur visible par l’utilisateur.

Tâches pratiques : commandes, sorties, décisions (12+)

Ces tâches sont rédigées pour les opérateurs. Elles incluent la commande, la sortie d’exemple, ce que ça signifie et la décision à prendre. Supposez que vous avez un accès shell et WP-CLI ou un client MySQL. Ajustez les noms de BD / préfixes de table selon besoin.

Task 1: Confirm table prefix and DB credentials (don’t guess)

cr0x@server:~$ cd /var/www/html && wp config get table_prefix
wp_

Ce que ça signifie : Votre préfixe de table est wp_. Si vous avez supposé wp_ et qu’en réalité c’est wpx9_, chaque requête SQL que vous exécuterez sera erronée ou dangereuse.

Décision : Utilisez le préfixe retourné dans toutes les requêtes suivantes. Si WP-CLI ne peut pas lire la config, arrêtez-vous et corrigez l’accès d’abord.

Task 2: Find autoload payload size (quick and decisive)

cr0x@server:~$ wp db query "SELECT ROUND(SUM(LENGTH(option_value))/1024/1024,2) AS autoload_mb FROM wp_options WHERE autoload='yes';"
+------------+
| autoload_mb|
+------------+
| 28.74      |
+------------+

Ce que ça signifie : ~29 Mo sont chargés comme « alloptions ». Ce n’est pas « un peu lent ». C’est une taxe récurrente sur chaque requête à froid.

Décision : Identifiez les principaux responsables ; planifiez une fenêtre de nettoyage contrôlée.

Task 3: Identify top autoloaded options by size

cr0x@server:~$ wp db query "SELECT option_name, ROUND(LENGTH(option_value)/1024/1024,2) AS mb FROM wp_options WHERE autoload='yes' ORDER BY LENGTH(option_value) DESC LIMIT 20;"
+------------------------------+------+
| option_name                  | mb   |
+------------------------------+------+
| plugin_x_cache_blob          | 12.40|
| widget_custom_html           | 4.12 |
| rewrite_rules                | 2.33 |
| some_builder_global_settings | 1.98 |
| cron                         | 1.21 |
+------------------------------+------+

Ce que ça signifie : Une ou deux options dominent. C’est une bonne nouvelle : vous pouvez obtenir de gros gains sans jouer à whack-a-mole.

Décision : Pour chaque principal responsable : décider suppression vs. désactivation de l’autoload vs. laisser tel quel. Commencez par les blobs de cache évidents et les options laissées par des plugins.

Task 4: Check if a suspicious option is a transient (usually safe to purge)

cr0x@server:~$ wp db query "SELECT option_name, autoload FROM wp_options WHERE option_name LIKE '\_transient\_%' LIMIT 5;"
+------------------------------+----------+
| option_name                  | autoload |
+------------------------------+----------+
| _transient_timeout_feed_123  | no       |
| _transient_feed_123          | no       |
| _transient_timeout_xxx       | no       |
| _transient_xxx               | no       |
| _transient_timeout_abc       | no       |
+------------------------------+----------+

Ce que ça signifie : La plupart des transients ne sont pas autoloadés, mais ils alourdissent la table et ralentissent les scans/sauvegardes. Certains plugins autoloadent par erreur des transients ou stockent des données « similaires à des transients » sans le préfixe.

Décision : Planifiez la suppression des transients expirés. Si beaucoup existent, automatisez le nettoyage.

Task 5: Count expired transients (cheap win)

cr0x@server:~$ wp db query "SELECT COUNT(*) AS expired FROM wp_options WHERE option_name LIKE '\_transient\_timeout\_%' AND option_value < UNIX_TIMESTAMP();"
+---------+
| expired |
+---------+
| 18742   |
+---------+

Ce que ça signifie : Vous avez beaucoup de transients expirés. WordPress ne les supprime pas toujours de façon agressive, et les plugins peuvent être négligents.

Décision : Supprimez-les (et leurs paires) de manière contrôlée.

Task 6: Delete expired transients via WP-CLI (safe-ish and reversible by regeneration)

cr0x@server:~$ wp transient delete --expired
Success: Deleted 18742 expired transients.

Ce que ça signifie : Vous avez supprimé des entrées de cache expirées. Si quelque chose casse, c’est un bug du plugin qui dépendait d’une donnée expirée (oui, ça arrive).

Décision : Re-vérifiez la taille de la table et de l’autoload. Si les performances s’améliorent, poursuivez.

Task 7: Re-measure autoload payload after transient cleanup

cr0x@server:~$ wp db query "SELECT ROUND(SUM(LENGTH(option_value))/1024/1024,2) AS autoload_mb FROM wp_options WHERE autoload='yes';"
+------------+
| autoload_mb|
+------------+
| 27.90      |
+------------+

Ce que ça signifie : Les transients n’étaient pas la cause principale ; le gros reste des options autoloadées comme des blobs de cache.

Décision : Ciblez directement les principaux coupables.

Task 8: Snapshot the option value before changing it (you want rollback)

cr0x@server:~$ wp option get plugin_x_cache_blob --format=json | head -c 200
{"version":"4.2.1","generated_at":1735230932,"data":{"items":[{"id":1,"name":"..."}]}}

Ce que ça signifie : Vous voyez que c’est une structure de cache générée, pas un réglage cœur. Ça ressemble aussi à quelque chose qui pourrait être déplacé hors de l’autoload.

Décision : Sauvegardez la valeur complète dans un fichier (ou prenez un backup BD) avant d’y toucher. Ensuite, envisagez de désactiver l’autoload d’abord, plutôt que de supprimer.

Task 9: Disable autoload for a known cache blob (minimal functional risk)

cr0x@server:~$ wp db query "UPDATE wp_options SET autoload='no' WHERE option_name='plugin_x_cache_blob' LIMIT 1;"
Query OK, 1 row affected (0.02 sec)
Rows matched: 1  Changed: 1  Warnings: 0

Ce que ça signifie : L’option existe toujours ; WordPress ne la chargera plus automatiquement. Le plugin la récupérera quand nécessaire.

Décision : Testez immédiatement les flux clés (page d’accueil, panier, connexion, admin). Si le plugin supposait l’autoload, vous le découvrirez vite.

Task 10: Validate autoload payload after de-autoloading one big offender

cr0x@server:~$ wp db query "SELECT ROUND(SUM(LENGTH(option_value))/1024/1024,2) AS autoload_mb FROM wp_options WHERE autoload='yes';"
+------------+
| autoload_mb|
+------------+
| 15.50      |
+------------+

Ce que ça signifie : Vous venez de réduire presque de moitié le payload autoload. C’est le type de changement qui se voit sur le p95 de latence.

Décision : Continuez avec la liste des principaux responsables. Préférez autoload=no plutôt que la suppression, sauf si vous êtes sûr.

Task 11: Find orphaned options from deactivated plugins (cleanup candidates)

cr0x@server:~$ wp plugin list --status=inactive
+----------------------+----------+-----------+---------+
| name                 | status   | update    | version |
+----------------------+----------+-----------+---------+
| old-gallery-plugin   | inactive | none      | 1.9.0   |
| legacy-seo-tool      | inactive | available | 2.3.1   |
+----------------------+----------+-----------+---------+

Ce que ça signifie : Les plugins inactifs laissent souvent des options. Certaines sont inoffensives. D’autres sont volumineuses. Inactif + volumineux + autoload=yes est un cadeau.

Décision : Recherchez les préfixes d’option associés aux plugins inactifs, puis supprimez ces options après sauvegarde.

Task 12: Locate options by name pattern and size before deleting

cr0x@server:~$ wp db query "SELECT option_name, autoload, ROUND(LENGTH(option_value)/1024/1024,2) AS mb FROM wp_options WHERE option_name LIKE 'old_gallery_%' ORDER BY LENGTH(option_value) DESC LIMIT 10;"
+---------------------------+----------+------+
| option_name               | autoload | mb   |
+---------------------------+----------+------+
| old_gallery_cache         | yes      | 3.70 |
| old_gallery_settings      | yes      | 0.05 |
+---------------------------+----------+------+

Ce que ça signifie : C’est probablement du poids mort si le plugin est inactif et que vous ne comptez pas le réactiver.

Décision : Exportez les lignes, puis supprimez-les. Si vous êtes nerveux, passez d’abord autoload=no et observez pendant une semaine.

Task 13: Back up specific rows (surgical rollback)

cr0x@server:~$ wp db query "SELECT * FROM wp_options WHERE option_name IN ('old_gallery_cache','old_gallery_settings')\G"
*************************** 1. row ***************************
option_id: 8812
option_name: old_gallery_cache
option_value: a:3:{s:7:"version";s:5:"1.9.0";...}
autoload: yes
*************************** 2. row ***************************
option_id: 8813
option_name: old_gallery_settings
option_value: a:2:{s:5:"theme";s:6:"light";...}
autoload: yes

Ce que ça signifie : Vous avez capturé les valeurs exactes. Si la suppression cause des problèmes, vous pouvez les réinsérer.

Décision : Supprimez seulement après avoir sauvegardé cette sortie ou pris un snapshot BD.

Task 14: Delete known-orphan options (commit)

cr0x@server:~$ wp db query "DELETE FROM wp_options WHERE option_name IN ('old_gallery_cache','old_gallery_settings') LIMIT 2;"
Query OK, 2 rows affected (0.01 sec)

Ce que ça signifie : Les lignes sont parties. Si le plugin est vraiment inutilisé, aucun impact. S’il était encore référencé, vous verrez rapidement des erreurs/avertissements.

Décision : Validez le fonctionnement du site ; surveillez les logs d’erreur et les requêtes lentes.

Task 15: Inspect `rewrite_rules` size (common, sometimes legitimate)

cr0x@server:~$ wp option get rewrite_rules --format=json | head -c 120
{"^wp-json/?$":"index.php?rest_route=/","^product/(.+?)/?$":"index.php?product=$matches[1]","^..."}

Ce que ça signifie : rewrite_rules est normalement autoloadé et peut croître avec des routages complexes (e-commerce, multilingue, etc.). Ne le désactivez pas aveuglément ; cela peut ralentir le routage ou causer des comportements étranges.

Décision : S’il est énorme, un plugin génère probablement trop de règles. Corrigez la source, pas seulement le symptôme. Envisagez de vider les règles de réécriture en maintenance.

Task 16: Flush rewrite rules (only when you know why)

cr0x@server:~$ wp rewrite flush --hard
Success: Rewrite rules flushed.

Ce que ça signifie : WordPress a régénéré les règles de réécriture. Cela peut réduire l’option si des règles obsolètes se sont accumulées, mais cela peut aussi régénérer la même taille si le générateur reste bruyant.

Décision : Si ça réduit la taille, tant mieux. Si ça revient, chassez le plugin/thème qui génère trop de règles.

Task 17: Check whether object cache is enabled (it changes the blast radius)

cr0x@server:~$ wp plugin list --status=active | grep -E "redis|memcached|object"
redis-cache             active   none      2.5.3

Ce que ça signifie : Un cache d’objets persistant est vraisemblablement en place. Ça aide, mais ça n’excuse pas un payload autoload de 30 Mo — surtout lors des flushs et évictions de cache.

Décision : Continuez le nettoyage. Vérifiez aussi la taille et l’éviction du cache pour réduire le churn.

Task 18: Measure request-level impact via a simple before/after TTFB sample

cr0x@server:~$ for i in {1..5}; do curl -s -o /dev/null -w "%{time_starttransfer}\n" https://example.com/; done
0.842
0.790
0.811
0.775
0.798

Ce que ça signifie : Ce n’est pas un benchmark de laboratoire, mais ça détecte les gros gains. Répétez après les changements (et après les vidages de cache) pour voir si les réponses à froid s’améliorent.

Décision : Si le TTFB diminue significativement et reste stable, vous corrigez la bonne chose. Sinon, le goulot d’étranglement est ailleurs — poursuivez le diagnostic (requêtes lentes, CPU, PHP, appels API externes).

Modifications sûres : ce que vous pouvez supprimer vs. ce qu’il faut maîtriser

Tier 1: Usually safe to delete (with backups)

Transients expirés : Ils sont expirés. Ils ne devraient pas être requis.
Options orphelines de plugins : Pour les plugins que vous avez supprimés ou que vous ne réactiverez jamais.
Ancres cron : Si elles sont bloquées (manipulez avec précaution), mais confirmez d’abord que le site n’est pas en cours d’exécution d’un job.

Même le « sûr » nécessite une sauvegarde. Supprimer des lignes est permanent, et vous n’êtes qu’à un on-call fatigué d’avoir supprimé le mauvais préfixe.

Tier 2: Prefer switching autoload from yes → no

Caches générés stockés comme options : S’ils sont gros mais que le plugin peut les régénérer.
Grosses configurations UI : Paramètres de widgets ou builder qui ne servent pas à chaque requête front-end.
Blobs d’analytics ou de type log : Ils n’ont pas leur place dans options ; désactiver l’autoload est un premier pas plus sûr.

Pourquoi c’est plus sûr ? Parce que les données restent présentes. Vous changez « quand ça se charge », pas « si ça existe ». La plupart des plugins appellent simplement get_option() quand c’est nécessaire et continuent de fonctionner.

Tier 3: Don’t touch casually

siteurl, home, active_plugins : pas besoin d’explications. Si vous cassez ça, vous gagnez du temps d’indisponibilité.
cron : un gros cron est suspect, mais le supprimer peut faire disparaître des tâches planifiées. Mieux vaut corriger ce qui spamme le cron.
rewrite_rules : autoloadé pour une raison ; un volume important indique une complexité en amont.

Petite blague #2 : Supprimer active_plugins pour accélérer WordPress est une optimisation de performance avec l’effet secondaire « plus de site web ».

Le vrai objectif : réduire le « hotset autoload »

Pensez comme un ingénieur cache. L’autoload est un hotset : les données que vous chargez tôt en mémoire. Le hotset devrait être petit, stable et réellement chaud. Tout le reste devrait être chargé paresseusement ou mis en cache correctement (cache d’objets, transient avec TTL, ou table dédiée).

Trois mini-récits du monde corporate

Mini-récit 1 : L’incident causé par une mauvaise hypothèse

Une entreprise de taille moyenne utilisait WordPress derrière un reverse proxy et un CDN. Le site semblait rapide dans les tests synthétiques parce que la page d’accueil était toujours mise en cache. La direction en a conclu que l’origine importait peu. C’était « juste l’admin » qui était lent, ce qui n’apparaissait pas sur les dashboards.

Puis ils ont lancé une fonctionnalité d’adhésion. Les utilisateurs connectés contournaient la plupart des caches CDN, et l’origine est devenue critique. Le jour du lancement, le site n’a pas planté. Il est devenu une lente catastrophe : les pages de profil prenaient des secondes ; les appels de paiement expiraient ; les tickets de support ont afflué avant même le post-mortem.

L’hypothèse erronée était subtile : « la base de données va bien parce que la CPU est faible ». En réalité, les options autoloadées avaient grossi pour devenir un payload de plusieurs mégaoctets. Chaque nouveau worker PHP à froid devait charger l’ensemble, et tout miss de cache frappait la BD avec une grosse requête suivie d’une grosse désérialisation.

La correction a été ennuyeuse et efficace : mesurer la taille autoload, désactiver l’autoload pour les plus gros caches d’extensions, et supprimer les options orphelines de deux plugins retirés. L’amélioration principale n’a pas été la latence moyenne, mais le p95 et p99 pendant les rafales et les déploiements. Ils ont cessé de « sentir aléatoire » parce que ce n’était plus aléatoire.

Mini-récit 2 : L’optimisation qui a mal tourné

Une équipe marketing d’entreprise voulait des pages plus rapides, alors elle a ajouté un plugin promettant « réduction des requêtes BD ». Il a réduit le nombre de requêtes — en cachant agressivement des données calculées dans une unique option et en la mettant en autoload. Les auteurs du plugin l’avaient probablement testé sur un petit site vitrine et avaient déclaré victoire.

En production, l’option a grandi avec chaque variation de campagne et de localisation. Le payload a gonflé. Le nombre de requêtes a baissé. L’empreinte mémoire a augmenté. Le TTFB s’est empiré, surtout après les flushs de cache post-déploiement.

L’optimisation a échoué parce qu’elle ciblait le mauvais indicateur. L’équipe célébrait moins de requêtes dans un panneau de debug tandis que les clients regardaient des loaders tournoyer. En termes ops : ils ont optimisé le tableau de bord, pas le système.

Ils ont finalement remplacé l’approche « cache dans les options » par un cache d’objets persistant et ont mis cette option en autoload=no. Le nombre de requêtes a légèrement augmenté. La latence a chuté. Tout le monde a fait comme si c’était le plan initial.

Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la situation

Un groupe de services financiers utilisait WordPress comme plateforme de contenu adjacente à des systèmes transactionnels. Leur plus grande peur n’était pas un billet de blog lent ; c’était un incident qui distrairait l’équipe on-call pendant une vraie panne ailleurs.

Ils ont mis en place deux pratiques banales : (1) un job hebdomadaire qui enregistre la taille autoload et les 20 principaux responsables dans une série temporelle, et (2) une règle de contrôle des changements exigeant qu’une installation de plugin passe une période de staging avec vérification de la croissance de l’autoload.

Des mois plus tard, une mise à jour de plugin a introduit une nouvelle option autoloadée qui a rapidement commencé à croître. La tendance hebdomadaire l’a repérée avant que cela ne devienne visible par les utilisateurs. Ils ont rollbacké, ouvert un ticket fournisseur et figé la version. Pas d’appel d’incident. Pas d’héros nocturnes. Juste une correction discrète dont personne hors SRE n’a entendu parler.

C’est le but. Le meilleur incident est celui qui n’ouvre jamais un canal Slack.

Erreurs courantes : symptôme → cause racine → correctif

1) L’admin est lent, le front-end « semble OK »

Symptôme : les pages wp-admin bloquent ; les éditeurs se plaignent ; le front-end semble correct (merci le CDN).

Cause racine : Le gonflement autoload pénalise le trafic non mis en cache et authentifié. Les pages admin chargent aussi plus de plugins et de réglages.

Fix : Mesurez les Mo autoload ; désactivez l’autoload pour les gros caches d’extensions ; nettoyez les options orphelines. Validez avec des tests curl en authentifié ou des timings navigateur réels.

2) Pics de latence aléatoires après déploi ou montée en charge

Symptôme : juste après un déploi ou un redémarrage de pod, pics de latence puis stabilisation.

Cause racine : workers à froid + cache d’objets vide signifient que le payload autoload doit être récupéré et désérialisé à plusieurs reprises.

Fix : Réduisez le payload autoload ; assurez un dimensionnement du cache d’objets persistant ; envisagez des scripts de warm-up après déploi.

3) La CPU DB est basse mais les requêtes « semblent lentes »

Symptôme : pas de saturation évidente de la CPU DB ; pourtant lent.

Cause racine : Toute la douleur n’est pas CPU. Les grosses valeurs d’option signifient des paquets plus volumineux, plus de copies mémoire et l’overhead PHP d’unserialize.

Fix : Réduisez la taille du payload ; inspectez les principaux responsables ; vérifiez la mémoire/CPU des workers PHP lors des requêtes à froid.

4) Vous avez supprimé une option et un plugin « s’est mystérieusement » cassé

Symptôme : fonctionnalité disparue ; réglages réinitialisés ; erreurs fatales.

Cause racine : Vous avez supprimé un état non régénérable, ou l’auteur du plugin supposait que l’option existait toujours.

Fix : Restaurez depuis la sauvegarde ; préférez d’abord autoload=no ; pour les suppressions, ne retirez que les transients connus et options orphelines confirmées.

5) OPTIMIZE TABLE a empiré les choses

Symptôme : pics IO, retard de réplication, ou ralentissements pendant la « maintenance ».

Cause racine : OPTIMIZE ne traite pas la sémantique autoload ; il peut reconstruire des tables et générer beaucoup d’IO, surtout sur de grands jeux de données.

Fix : N’utilisez pas OPTIMIZE comme premier remède. Réduisez d’abord le payload autoload et les lignes poubelles. Planifiez la maintenance de table intentionnellement et parcimonieusement.

6) La taille autoload baisse, mais la perf n’améliore pas

Symptôme : vous avez réduit l’autoload de 20 Mo à 5 Mo ; les utilisateurs se plaignent toujours.

Cause racine : Le goulot est ailleurs : API externe lente, système de fichiers lent, CPU PHP saturé, index manquant sur postmeta, ou pool de connexions BD saturé.

Fix : Activez le slow query log ; profilez PHP ; vérifiez la latence disque ; validez la santé du cache d’objets ; mesurez de bout en bout avec des schémas de trafic réels.

Listes de contrôle / plan étape par étape

Phase 0: Safety rails (do this before touching data)

Confirmez le préfixe de table via WP-CLI (Task 1).
Prenez un snapshot ou un dump de la base de données (BD complète si possible ; au minimum wp_options).
Ayez un plan de rollback : restaurer le dump ou réinsérer les lignes sauvegardées.
Décidez de votre posture de maintenance : changements en direct avec supervision ou une courte fenêtre de maintenance.

Phase 1: Baseline and target selection

Mesurez les Mo autoload (Task 2).
Listez les 20 principales options autoloadées par taille (Task 3).
Classez chaque option principale en : supprimer, désautoloader, laisser.
Notez l’impact attendu et le risque pour chaque changement. Si vous ne pouvez pas expliquer une option, ne la supprimez pas.

Phase 2: Low-risk cleanup (wins that almost never hurt)

Supprimez les transients expirés (Tasks 5–6).
Retirez les options orphelines des plugins supprimés (Tasks 11–14).
Re-mesurez les Mo autoload et les principaux responsables après chaque lot de modifications.

Phase 3: High-impact tuning (where the real gains are)

Pour chaque grosse option non-core : définissez autoload=no d’abord (Task 9).
Testez immédiatement les chemins clés après chaque changement (page d’accueil, connexion, panier, recherche, wp-admin).
Surveillez les logs d’erreurs PHP et les logs applicatifs pour notices/avertissements/fatals.
Ne supprimez de grosses options que lorsque vous êtes sûr qu’elles sont régénérables ou réellement orphelines.

Phase 4: Verify improvement the right way

Mesurez l’état final des Mo autoload.
Capturez des échantillons TTFB avant/après (Task 18) et comparez le p95/p99 dans votre APM si disponible.
Simulez un démarrage à froid : redémarrez PHP-FPM et videz le cache d’objets en staging, puis retestez (ne pas faire cela à la légère en prod).

Phase 5: Make it stick

Ajoutez une surveillance de la taille autoload et des principaux responsables.
Générez une barrière pour les installations/mises à jour de plugins avec une vérification de croissance autoload en staging.
Éduquez : l’autoload n’est pas un compacteur à déchets.

Prévention : empêcher le retour du gonflement autoload

1) Traitez les installations de plugins comme des changements de code

Si votre organisation a un processus de changement pour le code, mais pas pour les plugins, félicitations : vos plugins sont maintenant du code non relu. Beaucoup des pires coupables autoload viennent de plugins qui « cachent » en bourrant des tableaux massifs dans les options.

Politique pratique : chaque mise à jour de plugin passe par un passage en staging où vous enregistrez les Mo autoload avant et après des workflows typiques (sauvegarde admin, import produit, warm-up du cache). Si l’autoload augmente sensiblement, bloquez ou atténuez.

2) Préférez le cache d’objets persistant, mais ne laissez pas cacher la corruption

Redis/Memcached réduisent les hits BD répétitifs. Ils ne rendent pas acceptable l’autoload de 30 Mo. Ils changent juste le moment où vous payez.

Ce que vous voulez : un hotset autoload petit plus un cache pour les données calculées avec TTL raisonnable et comportement d’éviction sain.

3) Mettez des limites de taille dans votre playbook opérationnel

Décidez d’un seuil déclencheur. Pour beaucoup de sites WordPress en production, une ligne de départ raisonnable est :

Alerte : autoload > 5 Mo
Appeler quelqu’un (heures ouvrables) : autoload > 10–15 Mo
Critère d’incident : autoload > 20 Mo plus pics de latence corrélés

4) Demandez-vous « ceci doit-il être dans les options ? »

Certaines données n’appartiennent pas dans options :

Logs (utilisez fichiers, service de logs ou table personnalisée)
Grands index calculés (utilisez des transients avec cache d’objets ou des tables personnalisées)
État par-utilisateur / session (utilisez user meta, sessions ou stockage dédié)

5) Surveillez la croissance du cron et de l’action scheduler

L’option cron peut grossir si des événements s’accumulent ou si un plugin planifie trop de hooks. WooCommerce a aussi des tables d’action scheduler (pas wp_options) qui peuvent devenir un projet de nettoyage à part. Ne les confondez pas ; diagnostiquez séparément.

FAQ

1) Quelle taille devraient faire les options autoloadées ?

Idéalement sous 1 Mo. Sous 5 Mo est souvent acceptable. Au-dessus de 10 Mo il vaut généralement mieux intervenir. Au-delà de 20 Mo c’est un risque de fiabilité lors des démarrages à froid.

2) Désactiver l’autoload va-t-il casser mon site ?

Ça peut, mais c’est généralement plus sûr que supprimer. Désactiver l’autoload signifie que l’option existe toujours ; le code peut la récupérer quand nécessaire. Le risque vient des plugins qui supposent que l’option est préchargée. Atténuez en changeant une option à la fois et en testant les flux critiques.

3) Est-il sûr de supprimer des transients ?

Les transients expirés sont sûrs à supprimer en conditions normales. Les transients non expirés sont généralement sûrs aussi (ils devraient être régénérables), mais certains plugins les utilisent à tort comme stockage persistant. Pour un risque minimal, supprimez d’abord les transients expirés.

4) Pourquoi `rewrite_rules` est-il si volumineux ?

Un routage complexe (produits, langues, types de contenu personnalisés) augmente les règles de réécriture. Certains plugins génèrent des règles excessives ou ne nettoient pas correctement. Si c’est énorme, identifiez ce qui ajoute des routes ; vider les règles peut aider temporairement, mais corriger le générateur est la vraie solution.

5) Dois-je lancer OPTIMIZE TABLE après le nettoyage ?

Pas automatiquement. InnoDB ne bénéficie pas toujours comme on l’imagine, et OPTIMIZE peut être perturbateur. Réduisez d’abord les données et observez les performances. Si vous devez récupérer de l’espace disque ou défragmenter significativement, planifiez-le délibérément.

6) J’ai Redis en cache d’objets. Pourquoi me soucier encore de l’autoload ?

Parce que les caches missent, redémarrent, évictent et flushent. Le gonflement autoload rend ces événements normaux coûteux. De plus, un gros autoload doit toujours être désérialisé et traité en PHP.

7) Et si la plus grosse option autoload vient d’un plugin indispensable ?

Mettez-la en autoload=no et testez. Si le plugin fonctionne toujours, vous avez gagné. S’il casse, trois options : ajuster les réglages du plugin pour réduire les données stockées, remplacer le plugin, ou accepter le coût et atténuer avec du caching et de la capacité.

8) Comment savoir si une option est sûre à supprimer ?

Si c’est clairement un cache (souvent nommé cache, ressemblant à un transient, ou contenant des timestamps) et régénérable, la suppression est généralement sûre. Si c’est une configuration, une clé de licence ou un réglage cœur, ne supprimez pas. En cas d’hésitation : sauvegardez et mettez d’abord autoload=no.

9) Le gonflement autoload peut-il provoquer des erreurs out-of-memory en PHP ?

Oui. Les gros payloads autoload augmentent l’usage mémoire par requête, surtout lorsqu’il y a des copies multiples pendant la désérialisation/traitement. Si vous voyez des OOM ou des erreurs fatales mémoire PHP corrélées aux misses de cache, la taille autoload est un suspect majeur.

10) À quelle fréquence auditer wp_options ?

Mensuellement pour les sites stables, hebdomadairement pour du e-commerce très actif ou des installations riches en plugins. Si vous déployez ou mettez à jour des plugins souvent, surveillez en continu et alertez sur la croissance.

Étapes suivantes à faire aujourd’hui

Faites trois choses, dans l’ordre :

Mesurez les Mo autoload (Task 2) et notez-les. Si vous ne suivez pas, vous ne pourrez pas empêcher les régressions.
Prenez le principal responsable (Task 3) et passez-le en autoload=no (Task 9). Testez immédiatement les flux essentiels.
Nettoyez les poubelles faciles : transients expirés et options orphelines de plugins (Tasks 5–6, 11–14).

Après cela, traitez l’autoload comme un budget de performance. Gardez-le petit. Gardez-le ennuyeux. Votre futur vous — probablement la personne on-call à 2h du matin — vous remerciera.