Comprendre ce que WordPress charge automatiquement
Une alerte d’options autoload volumineuses apparaît dans Santé du site, ou une analyse de lenteur met en évidence un chargement commun très important. WordPress conserve des réglages de site, de thèmes et d’extensions dans sa table d’options. Certaines données sont chargées automatiquement pour être disponibles pendant la génération d’une page. Cette propriété, appelée autoload, évite des lectures séparées lorsque l’information est souvent nécessaire. Elle devient moins utile pour un gros volume rarement consulté.
Désactiver autoload ne supprime pas la valeur de l’option. Une extension qui la demande avec l’API WordPress peut encore la lire. En revanche, déplacer hors du chargement commun une donnée utilisée partout peut ajouter du travail au lieu d’en retirer. Il faut donc connaître son usage, pas seulement sa taille.
Le résultat recherché est un chargement adapté aux besoins réels, avec les fonctions et réglages conservés. Ce guide commence par Santé du site, propose un inventaire sans afficher les valeurs, puis une modification ciblée sur copie. Il ne demande ni suppression de table, ni nettoyage de tous les préfixes, ni passage de toutes les options à off.
Confirmer l’alerte dans Santé du site
Avec un compte administrateur, ouvrez Outils, Santé du site, puis l’onglet État. Dépliez le résultat relatif aux options chargées automatiquement. Notez le nombre, la taille indiquée et la date. Si ce contrôle n’est pas présent, relevez votre version de WordPress et poursuivez l’inventaire avec les accès disponibles.
Le contrôle natif utilise un seuil de 800 000 octets par défaut pour signaler un volume élevé ; ce seuil peut être modifié par du code. Il s’agit d’un signal d’analyse, pas d’une preuve qu’une option précise est inutile ni d’un objectif universel à atteindre en supprimant des données.
Comparez aussi le symptôme réel : génération de pages, administration, mémoire ou attente initiale. Un volume autoload important peut participer au coût, mais une API externe lente ou une file PHP reste une autre cause possible. Conservez deux écrans ou pages représentatifs pour la comparaison. Une page publique déjà en cache ne constitue pas à elle seule une mesure du travail WordPress.
Sauvegarder et viser la bonne installation
L’inventaire demande un accès de lecture à la base ou WP-CLI, l’outil en ligne de commande de WordPress. La modification demande une copie de test avec sauvegarde exploitable de sa base et des fichiers utiles. Gardez ces sauvegardes hors de l’espace public, car les options peuvent contenir des identifiants de service, des paramètres privés ou des données personnelles.
Confirmez le domaine, le répertoire WordPress et la base associés. Dans les exemples, le chemin /chemin/wordpress-copie est fictif et doit être remplacé. En multisite, les options ordinaires appartiennent au site ciblé et les réglages réseau constituent un autre ensemble. Utilisez le ciblage adapté avant toute commande ; ne supposez pas qu’une seule table wp_options représente tous les sites.
Neutralisez les effets externes de la copie avant de charger ses extensions : courriels, paiements et synchronisations. N’utilisez pas les options de saut de toutes les extensions pour une mesure censée refléter leur fonctionnement normal. Ces options peuvent changer la politique d’autoload ou le contexte. Les premières commandes et la requête SQL ci-dessous servent uniquement à lire l’inventaire, pas à nettoyer les données.
Inventorier avec WP-CLI sans afficher les valeurs
Sur la copie, ouvrez le terminal fourni par l’hébergeur ou une connexion autorisée, puis vérifiez que WP-CLI reconnaît cette installation. Consultez l’aide locale de option list avant de reprendre les paramètres : une ancienne version peut avoir un comportement différent. Les commandes suivantes utilisent la sélection actuelle des options chargées automatiquement et demandent seulement leurs noms, leur indicateur et leur taille.
La première donne le total en octets. La seconde fournit l’inventaire, sans la colonne option_value que la sortie ordinaire peut contenir. Conservez cette sortie dans un dossier privé si vous avez besoin de comparer avant et après. Les noms eux-mêmes peuvent révéler les services utilisés : évitez de publier une capture complète sur un forum.
Le tableau n’est pas trié ici par taille. N’ajoutez pas un paramètre de tri inventé sur size_bytes : ce champ de sortie ne fait pas partie des colonnes de tri documentées. Pour obtenir les vingt valeurs les plus volumineuses sans exporter leurs contenus, utilisez plutôt la requête de la section suivante. En multisite, ajoutez le paramètre global --url avec l’adresse exacte du site de test concerné.
wp --path='/chemin/wordpress-copie' option list --autoload=on --format=total_bytes
wp --path='/chemin/wordpress-copie' option list --autoload=on --fields=option_name,autoload,size_bytes --format=tableLire les plus grandes options avec une requête SQL
Si vous disposez de phpMyAdmin, choisissez la base correspondant à la copie, puis identifiez sa vraie table d’options. Le préfixe dépend de la configuration ; prefixe_options est un nom fictif à remplacer. Dans cPanel, phpMyAdmin se trouve dans la rubrique des bases de données lorsqu’il est proposé par l’hébergeur. L’accès au panneau ne garantit pas que toutes les bases affichées appartiennent au site recherché.
Ouvrez l’onglet SQL de la bonne base, adaptez uniquement le nom de table, puis exécutez ce SELECT. Il lit les noms, les indicateurs et la longueur des valeurs en octets, sans afficher ces valeurs. Il ne comporte aucune instruction de modification. Ne cliquez pas ensuite sur Modifier ou Supprimer pour les lignes obtenues.
Les quatre états correspondent au chargement automatique par défaut de WordPress actuel. Un filtre peut réduire cette liste, ce qui explique certains écarts avec Santé du site. Une ancienne recherche limitée à autoload = yes peut manquer des lignes récentes. Cette lecture peut aussi demander du travail à la base : faites un inventaire ponctuel, pas une boucle de requêtes sur un serveur saturé.
SELECT option_name, autoload, LENGTH(option_value) AS taille_octets
FROM prefixe_options
WHERE autoload IN ('yes', 'on', 'auto-on', 'auto')
ORDER BY LENGTH(option_value) DESC
LIMIT 20;Attribuer chaque candidate à son usage réel
Commencez par quelques lignes volumineuses, sans sélectionner tout le tableau. Recherchez le nom exact dans la documentation ou le code du thème et des extensions concernés. Un préfixe reconnaissable est un indice, pas une preuve : plusieurs composants peuvent partager une bibliothèque ou avoir conservé des réglages après une migration.
Pour chaque candidate, déterminez qui l’écrit, qui la lit et à quel moment. Une option contenant une configuration indispensable sur toutes les pages peut rester pertinente en autoload malgré sa taille. Un gros résultat de calcul utilisé uniquement sur un écran administratif occasionnel mérite davantage d’examen. Une donnée régulièrement reconstruite doit être traitée avec son propriétaire, sinon votre réglage peut disparaître à la prochaine exécution.
Ne déduisez pas l’abandon d’une option du seul fait qu’une extension est désactivée. Vous pouvez vouloir la réactiver, et ses réglages peuvent encore être utiles. Si l’auteur propose une procédure de nettoyage documentée, évaluez-la séparément avec sa portée et son retour arrière. Si l’origine reste inconnue, conservez la donnée et demandez une analyse. Le classement par octets ne constitue jamais une liste de suppressions.
Choisir entre conserver, changer autoload et supprimer
Trois décisions différentes sont possibles. Conserver une option souvent utilisée évite de remplacer un chargement commun par des lectures répétées. Retirer seulement son autoload peut convenir à une donnée rarement demandée, dont le propriétaire a confirmé cet usage. Supprimer la valeur relève d’une autre opération, avec perte potentielle de configuration ou de contenu ; ce guide ne l’utilise pas comme raccourci.
Les transients, les sessions et les options ordinaires ne se nettoient pas tous de la même manière. Une expiration ou une désinstallation documentée doit être respectée. Ne transposez pas une recette visant un ancien composant à toutes les lignes contenant cache, transient ou un préfixe commercial dans leur nom.
Pour la suite, choisissez une seule option de la copie dont le rôle est connu et dont la valeur brute d’autoload est actuellement on. Ce dernier critère permet le retour à la même valeur d’indicateur avec les commandes montrées. Si elle vaut yes, auto ou auto-on, ne présentez pas le passage ultérieur à on comme une restauration identique : l’état initial est différent et peut participer à une politique automatique.
Préparer une correction ciblée sur la copie
Fixez le périmètre avant toute écriture : site de test, nom exact de l’option, propriétaire, écran qui l’utilise et comportement attendu. Dans les commandes suivantes, option_a_confirmer est un exemple fictif. Remplacez-le par le nom vérifié ; ne collez pas une liste trouvée sur Internet et ne transformez pas la commande en boucle sur des centaines d’options.
Gardez le total initial, l’état brut de la candidate et une sauvegarde restaurable de la copie. Ouvrez les pages représentatives une première fois pour repérer les fonctions à contrôler. Si la candidate concerne une extension de boutique, préparez les parcours correspondants avec des données fictives et sans transaction externe réelle.
La commande set-autoload existe dans WP-CLI depuis la version 2.8.0. Consultez son aide locale et vérifiez que les valeurs on et off utilisées ici y sont reconnues. Si votre environnement ne fournit pas cette commande ou cette syntaxe, arrêtez cette approche et demandez l’intervention de la personne qui maintient WP-CLI. N’improvisez pas un UPDATE SQL ni une mise à jour d’outils sur le site public pour poursuivre l’exemple.
Contrôler une dernière fois l’option sélectionnée
Relisez une seule ligne avant d’écrire. La commande ci-dessous recherche le nom fictif choisi et conserve les trois colonnes de l’inventaire. Adaptez le chemin et le nom. Le paramètre search peut accepter des motifs ; n’ajoutez pas d’astérisque pour cette vérification et assurez-vous que la sortie contient bien l’unique candidate attendue.
L’indicateur doit être on pour suivre exactement le scénario de retour arrière décrit ici. La taille doit aussi correspondre à votre relevé, sans variation inattendue entre deux lectures. Une valeur recréée en permanence ou une option qui change de rôle après une mise à jour demande une analyse supplémentaire. Un résultat vide n’autorise pas à créer une nouvelle option portant ce nom.
Vous n’avez pas besoin d’afficher le contenu pour changer son indicateur. Si une investigation exige ultérieurement la valeur, faites-la dans un environnement privé avec les précautions adaptées à son contenu. Ne copiez pas une valeur sérialisée dans un éditeur pour essayer de raccourcir ses chaînes : cela peut la rendre inutilisable et ne répond pas à la question de son chargement.
wp --path='/chemin/wordpress-copie' option list --search='option_a_confirmer' --fields=option_name,autoload,size_bytes --format=tableDésactiver seulement le chargement automatique de la candidate
Sur la copie confirmée, exécutez set-autoload avec le nom exact et off, puis relisez la ligne. La commande modifie la propriété de chargement automatique sans remplacer le contenu de l’option. WordPress prévoit aussi la mise à jour des caches d’options via son API ; c’est une raison de préférer ce chemin à une écriture SQL directe qui ignorerait ces mécanismes.
Le résultat attendu est un indicateur off pour cette seule candidate. Sa taille doit rester cohérente avec le relevé initial, puisque la valeur n’a pas été volontairement réduite. Une autre activité de l’extension peut néanmoins l’avoir réécrite ; dans ce cas, ne confondez pas cette variation avec l’effet de la commande.
Retournez ensuite à Santé du site et refaites l’inventaire total dans les mêmes conditions. Vous cherchez une baisse compatible avec la candidate, sans disparition de réglages. Si une erreur apparaît, si un écran perd sa configuration ou si la commande touche un autre site, interrompez l’essai et appliquez le retour arrière. Un message de réussite dans le terminal ne prouve ni gain de vitesse ni compatibilité fonctionnelle.
wp --path='/chemin/wordpress-copie' option set-autoload option_a_confirmer off
wp --path='/chemin/wordpress-copie' option list --search='option_a_confirmer' --fields=option_name,autoload,size_bytes --format=tableRevenir à l’état initial de cet essai
Si l’essai est inutile ou provoque un défaut, remettez on pour la seule option qui avait initialement cet état, puis relisez-la. Vérifiez ensuite les écrans et fonctions concernés. Le retour de l’indicateur ne garantit pas qu’une autre action effectuée pendant le test ait été annulée : comparez aussi les réglages attendus et les journaux disponibles.
Ce retour arrière est volontairement borné. L’API actuelle normalise les choix de chargement en on ou off. Elle ne restaure pas forcément le libellé historique yes ni les états automatiques quand on lui demande simplement de réactiver autoload. Pour une candidate portant un de ces autres états à l’origine, faites préparer une procédure adaptée et contrôlée à partir de sa sauvegarde avant tout changement.
Si la valeur elle-même a été altérée par une autre manipulation, remettre autoload ne la répare pas. La restauration de la copie depuis sa sauvegarde peut alors être nécessaire, avec la personne qui gère cet environnement. Ne restaurez pas une vieille base complète sur un site public ayant reçu entre-temps des commandes, des comptes ou des messages.
wp --path='/chemin/wordpress-copie' option set-autoload option_a_confirmer on
wp --path='/chemin/wordpress-copie' option list --search='option_a_confirmer' --fields=option_name,autoload,size_bytes --format=tableMesurer le résultat sans confondre les caches
Comparez le total autoload, le temps de génération et les fonctions dans des conditions semblables. Une baisse du volume indique que le chargement commun a changé ; elle ne mesure pas à elle seule le temps gagné. Une option demandée peu après peut être lue individuellement, ce qui déplace le travail au lieu de le supprimer.
Avec un cache d’objets persistant, les lectures de la base peuvent déjà être réduites, tandis que le transport et la manipulation de grandes données restent possibles. Un cache de page peut masquer toute génération WordPress pour le visiteur. Distinguez donc une page publique servie en cache, une requête qui reconstruit la page et l’administration. Ne purgez pas tous les caches entre chaque clic sans noter cet effet sur les mesures.
Répétez quelques parcours identiques plutôt que de conclure sur une seule durée favorable. Contrôlez aussi le cas où la donnée est réellement utilisée : c’est là qu’un retrait d’autoload peut ajouter une lecture. Si le gain est négligeable ou si le coût se déplace vers une fonction importante, revenez à l’état initial et examinez une autre cause de lenteur. La disparition de l’avertissement ne justifie pas une régression.
Comprendre les états automatiques et les valeurs réécrites
Depuis WordPress 6.6, la politique par défaut peut éviter de charger automatiquement une grande option lors de son ajout ou de sa mise à jour lorsque le développeur n’a pas explicitement demandé ce chargement. Le seuil de taille concerné est de 150 000 octets par défaut et peut être filtré. Ce mécanisme n’est pas un nettoyage rétroactif de toutes les anciennes lignes.
Les états auto, auto-on et auto-off reflètent cette gestion, alors que on et off expriment un choix explicite dans le fonctionnement actuel. N’essayez pas de les uniformiser seulement pour simplifier un tableau. Une extension peut aussi imposer son propre choix à chaque enregistrement : votre correction locale sera alors réécrite, parfois après une opération qui semble sans rapport.
Quand l’indicateur revient régulièrement, documentez le nom, la version du composant et l’action qui déclenche ce retour. Adressez cette preuve au mainteneur pour qu’il examine la politique de stockage ou la taille de la donnée. Un script périodique qui remet toutes les options à off masque le problème, peut provoquer des écritures répétées et empêche de comprendre les besoins réels du composant.
Prévenir l’accumulation et transmettre un dossier utile
Après un essai concluant sur copie, préparez une intervention limitée avec la personne responsable du site public : sauvegarde récente, option exacte, état attendu, parcours de contrôle et possibilité de retour arrière. Consignez la date et le résultat de cette intervention pour pouvoir comprendre une variation ultérieure. Contrôlez de nouveau le parcours concerné après la prochaine mise à jour du composant propriétaire.
Gardez un relevé périodique raisonnable du volume, en particulier après une migration ou l’ajout d’un composant important. Comparez les variations plutôt que de nettoyer systématiquement chaque semaine. Lors d’une désinstallation, lisez ce que l’éditeur propose de conserver ou d’effacer et décidez en fonction du besoin de réutiliser les réglages.
Pour demander de l’aide, transmettez les versions, le contexte de lenteur, le total autoload, quelques noms de candidates avec leurs tailles et l’action qui les réécrit éventuellement. Masquez les informations privées et ne joignez pas une exportation intégrale de la table. Un dossier précis permet de choisir entre garder le chargement, revoir une donnée trop volumineuse ou corriger son propriétaire, avec une justification pour chaque option.
Vérifier une option témoin de bout en bout sur la copie
Sur une copie WordPress de démonstration, une option fictive de 880 000 octets était chargée automatiquement. L’inventaire WP-CLI et la requête SQL donnaient le même nom, le même indicateur et la même taille. L’inventaire n’affichait aucune valeur. Cette option servait de témoin pour distinguer la baisse du volume chargé de la disparition d’une donnée.
Comparez aussi les résultats lorsque WordPress doit réellement générer la page. La recette valide la modification d’une option et son retour arrière. Pour savoir si elle améliore la vitesse sur votre installation, mesurez les mêmes pages dans les mêmes conditions.
- Relevez le total initial, la taille et l’état exact de la candidate. Notez un écran qui lit cette option et un écran qui doit continuer à fonctionner indépendamment.
- Passez la candidate de on à off. Le total doit baisser d’un volume compatible avec la ligne retirée. Dans la recette, la baisse était de 880 000 octets et WordPress pouvait toujours lire la valeur à la demande.
- Remettez on si l’essai est terminé ou si la lecture ajoute un coût gênant. Relisez l’état et le total. Sur la copie, les deux étaient revenus à leur valeur initiale et l’option témoin secondaire était restée intacte.
