Données d'autoload WordPress : ce que c'est et comment les nettoyer

La santé du site signalait un problème critique sur l'un de mes sites depuis des mois : Les options autoloadées peuvent affecter les performances.

Je l'ai ignoré. Le site semblait bien fonctionner.

Puis quelqu'un m'a demandé pourquoi le tableau de bord mettait près de dix secondes à se charger alors que la page d'accueil se chargeait instantanément. J'ai donc finalement vérifié la taille de l'autoload et trouvé des mégaoctets d'options dans la base de données, la plupart écrites par des plugins que j'avais désinstallés des années auparavant.

Le plus frustrant, c'est que la plupart des conseils sur ce sujet sont obsolètes. WordPress 6.6 a modifié le fonctionnement de l'autoload, et la requête que presque tous les guides publient encore renvoie maintenant le mauvais nombre.

Beaucoup des conseils de nettoyage standards ne réduisent pas non plus la taille de l'autoload, pour des raisons enfouies dans le cœur de WordPress.

Dans cet article, je vais vous montrer ce que sont les données d'autoload de WordPress, comment les mesurer correctement sur une installation moderne, ce qui peut être supprimé en toute sécurité, et comment les nettoyer sans casser votre site.

Voici les points clés à retenir :

• Les données d'autoload sont chargées à chaque requête qui atteint WordPress, y compris les pages d'administration, les appels REST et les tâches cron, donc la mise en cache de page ne vous les cachera jamais.
• WordPress signale un problème critique de santé du site au-delà de 800 Ko d'options autoloadées, ce qui est la chose la plus proche d'une limite officielle que vous trouverez.
• La requête SQL dans la plupart des guides sous-estime maintenant. WordPress 6.6 a remplacé les anciennes valeurs autoload oui/non par cinq valeurs possibles, donc filtrer sur autoload='yes' manque les lignes plus récentes.
• La suppression des transients expirés change à peine la taille de votre autoload. Les transients créés avec une date d'expiration ne sont pas autoloadés en premier lieu, c'est pourquoi les plugins de nettoyage de base de données semblent ne rien faire ici.
• Le véritable gonflement provient généralement des options de plugins orphelines, laissées par des plugins que vous avez supprimés il y a des années, car rien ne les nettoie automatiquement.
• Le DB Optimizer de Duplicator mesure la taille de l'autoload dans le cadre de son score de santé de base de données, ce qui en fait le moyen le plus simple de suivre le nombre au fil du temps. La suppression des options autoloadées reste un travail manuel.
• Désactiver l'autoload est plus sûr que de supprimer. Les données restent dans la base de données au cas où un plugin en aurait besoin, et le changement est réversible.
• Ne modifiez jamais wp_options sans une sauvegarde actuelle. Vous travaillez dans la seule table qui peut mettre tout votre site hors ligne.
• Si la taille de l'autoload remonte en quelques jours après un nettoyage, un plugin la réécrit à chaque exécution, et aucun nettoyage ne sera efficace.

Table des matières

Qu'est-ce que les données autoload dans WordPress ?

Chaque site WordPress stocke ses paramètres dans une table de base de données appelée wp_options. L'URL de votre site s'y trouve. Il en va de même pour votre liste de plugins actifs, les paramètres du thème et la configuration de presque tous les plugins que vous avez installés.

Chaque ligne de cette table a une colonne autoload. Cette colonne répond à une seule question : WordPress doit-il charger cette ligne sur chaque page, ou seulement lorsque quelque chose la demande ?

Lorsque la réponse est oui, l'option est chargée automatiquement. C'est tout ce que le terme signifie. Elle est chargée automatiquement, que la page actuelle en ait besoin ou non.

WordPress fait cela pour une bonne raison. Plutôt que d'exécuter une requête de base de données distincte chaque fois qu'un plugin demande un paramètre, il récupère toutes les options chargées automatiquement en une seule requête au début de la requête et les conserve en mémoire. Une requête vaut mieux que quelques centaines de petites.

Voici ce qui finit généralement par être stocké comme options chargées automatiquement :

• Paramètres principaux dont votre site ne peut pas se passer, tels que siteurl, home, active_plugins, template et stylesheet
• Configuration des plugins, souvent stockée sous forme d'un grand tableau sérialisé par plugin
• Clés de licence et données d'activation des plugins et thèmes premium
• Réponses mises en cache de l'API qu'un plugin a enregistrées comme une option normale au lieu d'un transitoire approprié
• Vestiges de plugins que vous avez supprimés, que rien ne nettoie de lui-même
• Transitoires créés sans délai d'expiration, qui sont chargés automatiquement par défaut

La conception est bonne. C'est l'accumulation qui cause des problèmes.

Pourquoi les données autoload ralentissent-elles votre site ?

Chaque requête qui atteint WordPress paie pour la taille de votre autoload. Cela affecte non seulement les vues de page des visiteurs, mais aussi les écrans d'administration, les appels à l'API REST, les tâches WP-Cron, les requêtes AJAX et toutes les tâches d'arrière-plan que vos plugins déclenchent.

Le coût n'est pas seulement la requête. Les valeurs des options sont stockées sérialisées, donc PHP doit toutes les désérialiser en mémoire à chaque chargement. Une table autoload de 3 Mo signifie que votre site reconstruit 3 Mo de tableaux PHP avant d'afficher un seul mot de contenu.

C'est de la mémoire et du CPU, à chaque requête, pour toujours.

La mise en cache de page n'aide pas ici. Un cache sert aux visiteurs une page HTML terminée, donc ces requêtes contournent WordPress entièrement. Vos propres requêtes ne le font pas.

Voici où une table autoload gonflée se manifeste en premier :

• wp-admin est lent tandis que le front-end reste rapide, car les pages d'administration ne sont jamais mises en cache
• L'éditeur de blocs est lent lors de la sauvegarde ou du chargement car chaque requête de l'éditeur passe par un chargement WordPress complet
• Les paniers et la page de paiement WooCommerce sont lents, car ces pages sont exclues de la mise en cache par conception
• Les utilisateurs connectés ont un site plus lent que les autres, ce qui rend le problème difficile à reproduire
• Les tâches Cron s'accumulent, car chacune supporte la même surcharge

Si votre hébergeur vous a déjà dit que la base de données semblait correcte alors que votre tableau de bord ralentissait, c'est généralement la raison. La taille de l'autoload ne s'affiche pas dans les métriques que la plupart des hébergeurs vérifient.

Je veux cependant être honnête quant à la portée. Le gonflement de l'autoload est rarement la seule chose qui ralentit un site, et le nettoyer ne sauvera pas un site avec un hébergement lent et des images non optimisées.

C'est juste la partie que presque personne ne vérifie, et elle grossit silencieusement chaque mois où vous continuez à faire fonctionner votre site.

Quelle quantité de données autoload WordPress est trop importante ?

Recherchez cette question, et vous obtiendrez cinq réponses différentes. Certains guides disent 300 Ko, d'autres 1 Mo.

WordPress 6.6 a fixé la limite pour tout le monde. L'état du site affiche désormais un problème critique lorsque la taille totale de vos options autoload dépasse 800 Ko.

Voici comment je lis les plages en pratique :

• Moins de 800 Ko : sain. L'état du site reste silencieux, et vous n'avez rien à corriger.
• 800 Ko à 1 Mo : mérite un coup d'œil. Vous dépassez le seuil de base, et ce sont généralement un ou deux plugins qui en sont responsables.
• 1 Mo à 3 Mo : un vrai problème. Attendez-vous à des écrans d'administration sensiblement plus lents, surtout sur un hébergement mutualisé.
• Plus de 3 Mo : quelque chose écrit activement des données inutiles selon un calendrier, et le nettoyage ne sera pas suffisant tant que vous ne l'aurez pas trouvé.

Vous pouvez augmenter le seuil avec le filtre site_status_autoloaded_options_size_limit, mais cela ne fait que masquer l'avertissement. Les requêtes s'exécutent toujours à la même taille.

La taille seule ne vous dit pas tout non plus. Une centaine de petites lignes orphelines méritent moins votre attention qu'un seul tableau sérialisé de 2 Mo provenant d'un plugin de slider que vous avez arrêté d'utiliser en 2022.

Ciblez les plus gros contrevenants, pas le nombre.

Une autre bonne pratique à connaître : depuis WordPress 6.6, toute nouvelle option de plus de 150 Ko est définie pour ne pas s'autoload par défaut.

Le cœur de WordPress a pris cette décision car les options autoload surdimensionnées étaient un problème de performance si courant. C'est filtrable via wp_max_autoloaded_option_size, bien que l'augmenter soit une mauvaise idée.

Cette protection ne s'applique qu'à l'avenir. Tout ce qui se trouve déjà dans votre base de données depuis avant continue de s'autoload exactement comme il l'a toujours fait.

Pourquoi la plupart des guides sur l'autoload vous donnent-ils maintenant le mauvais chiffre ?

Pendant la majeure partie de l'histoire de WordPress, la colonne autoload contenait l'une des deux valeurs : yes ou no. Simple. Tous les tutoriels jamais écrits sur les données autoload reposaient sur cette hypothèse.

WordPress 6.6 l'a remplacé par cinq valeurs possibles :

• on : explicitement défini pour s'autoload, et il le fera toujours
• off : explicitement défini pour ne pas s'autoload, et il ne le fera jamais
• auto : aucune préférence explicite n'a été donnée, donc WordPress décide (et l'autoload actuellement)
• auto-on : WordPress a décidé dynamiquement qu'il devrait s'autoload
• auto-off : WordPress a décidé dynamiquement qu'il ne devrait pas, généralement parce que la valeur est supérieure à 150 Ko

Les lignes existantes n'ont pas été migrées. Les options créées avant le changement conservent leurs valeurs d'origine yes et no, que le cœur de WordPress traite comme équivalentes à on et off.

Ainsi, tout site qui a été mis à niveau vers la version 6.6 contient désormais un mélange d'anciennes et de nouvelles valeurs dans la même colonne.

Beaucoup de gens vous diront d'exécuter une requête filtrée sur autoload='yes'. Sur un site moderne, cette requête ignore silencieusement toutes les options écrites depuis la version 6.6, ainsi que tout ce que le cœur du système a marqué comme auto ou auto-on.

Vous obtenez un nombre. Ce n'est tout simplement pas votre nombre, et il est toujours trop bas.

La solution consiste à vérifier toutes les valeurs que WordPress considère comme étant en autoload. Le cœur du système expose exactement cette liste via wp_autoload_values_to_autoload(), qui renvoie par défaut yes, on, auto-on et auto.

Quelle requête SQL devriez-vous exécuter à la place ?

Si vous avez accès à phpMyAdmin ou à l'outil de base de données de votre hébergeur, ces deux requêtes vous diront presque tout ce dont vous avez besoin. Exécutez-les sur la base de données de votre site dans l'onglet SQL.

Avant d'exécuter quoi que ce soit sur wp_options, créez une sauvegarde. Ces deux requêtes ne font que lire des données et ne changent rien, mais la section suivante vous amène à modifier des lignes, et il vaut mieux être prudent que désolé.

Commencez par la taille totale de votre autoload :

SELECT ROUND(SUM(LENGTH(option_value)) / 1024, 2) AS autoload_kb,

COUNT(*) AS option_count

FROM wp_options

WHERE autoload IN ('yes', 'on', 'auto', 'auto-on');

Cela renvoie votre total en kilo-octets ainsi que le nombre d'options concernées. Comparez-le au seuil de 800 Ko de la section précédente.

Ensuite, découvrez ce qui est responsable :

SELECT option_name,

ROUND(LENGTH(option_value) / 1024, 2) AS size_kb,

autoload

FROM wp_options

WHERE autoload IN ('yes', 'on', 'auto', 'auto-on')

ORDER BY LENGTH(option_value) DESC

LIMIT 20;

Cela vous donne les vingt plus grandes options en autoload par nom, avec leurs tailles individuelles et leur valeur d'autoload actuelle. Sur la plupart des sites, les trois ou quatre premières lignes représentent la majorité du problème.

Deux choses à surveiller avant de copier ceci :

• Le préfixe de votre table n'est peut-être pas wp_. De nombreuses installations utilisent quelque chose de personnalisé pour des raisons de sécurité. Vérifiez wp-config.php pour la valeur de $table_prefix et remplacez-la dans la requête.
• Le multisite fonctionne différemment. Chaque sous-site a sa propre table d'options (wp_2_options, wp_3_options, etc.), plus une table wp_sitemeta pour l'ensemble du réseau. Vous devrez les vérifier séparément.

Si vous préférez utiliser la ligne de commande, WP-CLI gère les deux tâches en une seule ligne chacune. Ceci renvoie votre total en octets :

wp option list --autoload=on --format=total_bytes

Et ceci liste les options en autoload avec leurs tailles stockées :

wp option list --autoload=on \

--fields=option_name,autoload,size_bytes \

--format=table

Tout le monde ne souhaite pas toucher à une console de base de données, et vous n'êtes pas obligé de le faire. La section suivante couvre deux méthodes qui restent dans le tableau de bord WordPress.

Comment vérifier la taille de vos données autoload WordPress ?

Vous ne pouvez pas corriger ce que vous n'avez pas mesuré, et vous voudrez mesurer à nouveau après chaque modification que vous apportez.

Il existe trois façons d'obtenir le nombre, en fonction de la proximité avec la base de données que vous souhaitez atteindre.

Option 1 : Santé du site (La voie la plus rapide)

WordPress vérifie déjà cela pour vous. Allez dans Outils » Santé du site et ouvrez l'onglet État, puis recherchez Les options en autoload pourraient affecter les performances dans la liste.

Développez-le et vous obtiendrez votre taille totale.

Le hic, c'est que cette vérification n'apparaît qu'une fois que vous dépassez 800 Ko. Le silence ne signifie pas que vous êtes à zéro ; cela signifie que vous êtes en dessous du seuil. Il vous donne également un seul instantané sans historique et sans moyen d'agir sur ce qu'il vous montre.

Option 2 : Score de santé de DB Optimizer (le plus facile à suivre)

Si vous souhaitez suivre la taille de l'autoload au fil du temps plutôt que de la vérifier une seule fois, DB Optimizer la place sur un tableau de bord.

Ouvrez DB Optimizer, et vous obtiendrez un score de santé de la base de données de 0 à 100. Cinq barres codées par couleur décomposent le score : surcharge de table, transitoires, révisions, taille de l'autoload et éléments indésirables.

Soyons clairs sur ce que cela fait et ne fait pas. DB Optimizer mesure votre taille d'autoload et la signale. Il ne nettoie pas les options autoloadées.

La suppression des données autoloadées reste un travail manuel, et je vais vous guider ci-dessous.

Ce qu'il nettoie, ce sont les révisions de publication, les brouillons automatiques, le contenu mis à la corbeille, les commentaires spam, les transitoires expirés, les pings, les trackbacks et le cache oEmbed. Ceux-ci valent vraiment la peine d'être nettoyés. C'est juste un problème différent de l'autoload.

Avant de commencer un nettoyage manuel, cela ne peut pas faire de mal de faire un nettoyage rapide de la base de données. Ouvrez l'onglet Nettoyage et exécutez toutes les optimisations disponibles.

Ensuite, allez dans l'onglet Tables. Optimisez toutes les tables avec surcharge.

Cliquez sur Actualiser le score dans le tableau de bord, et regardez ce qui arrive à la taille de l'autoload :

• Le score augmente sensiblement : les transitoires non expirés faisaient partie de votre problème, et vous en avez résolu une partie.
• Le score bouge à peine : votre gonflement est constitué d'options de plugins orphelines, et aucun outil de nettoyage ne pourra y toucher. Passez directement aux méthodes manuelles.
• Le score augmente et redescend en quelques jours : un plugin actif réécrit les options autoloadées à chaque exécution.

Ce dernier cas vaut la peine d'être détecté tôt. Cela vous évite de nettoyer les mêmes lignes chaque mois et de vous demander pourquoi rien ne reste.

DB Optimizer vous avertit également lorsque vous n'avez pas de sauvegarde récente et vous permet d'en créer une directement. Il est inclus gratuitement avec les plans Duplicator Pro et Elite, afin que vous puissiez garder votre site en sécurité et qu'il fonctionne sans problème.

Option 3 : Exécutez vous-même la requête (La plus précise)

Les commandes SQL et WP-CLI de la section précédente vous donnent le nombre exact et la liste classée complète, sans aucun seuil vous cachant quoi que ce soit.

C'est la méthode que j'utilise lorsque je suis sur le point de changer quelque chose, car c'est la seule qui vous montre la valeur actuelle de l'autoload de chaque ligne. Vous en avez besoin avant de commencer à modifier.

Pourquoi un nettoyage de base de données n'a-t-il pas corrigé votre taille d'autoload ?

Voici le conseil que vous trouverez dans presque tous les articles sur ce sujet : nettoyez vos transitoires, et votre taille d'autoload diminuera.

C'est en grande partie faux, et le cœur de WordPress est l'endroit où vous pouvez le prouver.

Regardez ce que fait set_transient() lorsqu'il crée un transitoire. Si vous spécifiez un délai d'expiration, WordPress stocke ce transitoire avec autoload défini sur false. Seuls les transitoires créés sans date d'expiration sont autoloadés, et ceux-ci sont minoritaires.

Les transitoires expirés sont, par définition, des transitoires qui avaient une date d'expiration. Cela signifie qu'ils n'ont jamais été autoloadés. Vous pouvez en supprimer cinquante mille, réduire votre table wp_options de cent mégaoctets et ne faire bouger votre nombre d'autoload que très peu.

Les deux nettoyages valent la peine. Une énorme table wp_options ralentit les requêtes, gonfle vos sauvegardes et fait expirer les migrations. C'est juste un problème différent avec une solution différente, et confondre les deux explique pourquoi tant de gens pensent que leur plugin de nettoyage est cassé.

Alors, que reste-t-il une fois que les transients ont disparu ? D'après mon expérience, c'est presque toujours l'un de ceux-ci :

• Tableaux de paramètres sérialisés de plugins que vous avez désinstallés. La plupart des plugins ne font pas le ménage après eux lors de la suppression, et ces paramètres continuent de se charger automatiquement pour toujours.
• Données de licence et d'activation de plugins premium, y compris ceux dont les licences ont expiré il y a des années.
• Réponses API mises en cache stockées comme options simples plutôt que comme transients appropriés, généralement par des plugins de flux sociaux, d'analyse ou de référencement.
• Options de type journal qui grossissent sans limite, où un plugin ajoute à une seule ligne d'option à chaque événement au lieu d'utiliser sa propre table.
• Transients sans expiration, qui sont la véritable exception ici et le seul type pour lequel un nettoyage des transients aidera.

Aucun de ceux-là ne sort avec un outil en un clic. C'est la réponse honnête, et c'est pourquoi la section suivante est pratique.

Comment nettoyer les données d'autoload de WordPress ?

Il n'existe aucun plugin qui résout ce problème en un clic. Vider les options autoload signifie identifier des lignes spécifiques et décider quoi faire de chacune d'elles.

Cela semble pire que ça ne l'est. Sur la plupart des sites, trois ou quatre lignes représentent la majeure partie du problème, vous prenez donc trois ou quatre décisions plutôt que des centaines.

Voici les trois méthodes, classées de la plus sûre à la plus impliquée :

• Désactiver l'autoload pour les options lourdes : change la valeur d'une seule colonne sans rien supprimer, et c'est entièrement réversible.
• Supprimer les options orphelines des plugins supprimés : efface définitivement les lignes laissées par les plugins qui ont disparu pour de bon.
• Remplacer le plugin qui continue de l'écrire : la seule solution qui tient lorsque quelque chose régénère le gonflement à chaque exécution.

Faites une sauvegarde complète avant de commencer l'une d'elles. Duplicator Pro crée une copie complète de votre base de données et de vos fichiers en quelques minutes, et sa restauration en un clic signifie qu'une mauvaise instruction UPDATE vous coûte dix minutes au lieu de votre week-end.

Méthode 1 : Désactiver l'autoload pour les options lourdes

Commencez ici, car rien n'est supprimé. Vous modifiez la valeur d'une seule colonne, et vous pouvez la rétablir.

Prenez la liste des principaux contrevenants de votre requête et travaillez à partir de là. Pour chaque grande option, la question est de savoir si le site a besoin de ces données à chaque chargement de page.

Avant de désactiver l'autoload, vérifiez comment et où le plugin lit l'option. Certains tableaux de configuration sont légitimement nécessaires lors des requêtes front-end ; d'autres sont réservés à l'administration ou rarement consultés et sont mieux chargés à la demande.

Pour arrêter l'autoload d'une option, mettez à jour sa valeur autoload :

UPDATE wp_options

SET autoload = 'off'

WHERE option_name = 'your_option_name_here'

AND autoload IN ('yes', 'on', 'auto', 'auto-on');

Sur WordPress 6.6+, utilisez off. WordPress reconnaît également la valeur héritée no comme non-autoload, elle reste donc compatible avec les installations plus anciennes.

WP-CLI s'en charge en une seule commande, et il accepte on, off, yes ou no :

wp option set-autoload your_option_name_here off

Les données restent exactement là où elles sont. WordPress arrête simplement de les charger à chaque requête et les récupère à la demande lorsque quelque chose appelle get_option() à la place.

Lorsque vous ne parvenez pas du tout à identifier une ligne, ne la supprimez pas. Basculez son autoload sur désactivé en utilisant la Méthode 1 et laissez-la là.

Ne regroupez pas vingt modifications puis ne testez pas. Si quelque chose tourne mal, vous voulez savoir quelle ligne en est responsable.

Une chose à surveiller : si une option revient à l'autoloading après une mise à jour de plugin, ce plugin réécrit la valeur lors de l'activation ou de la mise à niveau. Votre modification n'a pas échoué ; elle a été écrasée.

Cela vaut la peine d'ouvrir un ticket de support auprès des développeurs du plugin, et c'est un signal fort que vous vous dirigez vers la Méthode 3.

Méthode 2 : Supprimer les options orphelines des plugins supprimés

La suppression est permanente, donc cette méthode nécessite plus de précautions que la précédente.

Parcourez votre liste des principaux contrevenants et associez chaque nom d'option au plugin qui l'a créée. La plupart utilisent un préfixe reconnaissable, bien qu'ils ne soient pas tous évidents.

Recherchez le nom de l'option avant de le toucher, car un nom qui semble abandonné appartient parfois à quelque chose qui fonctionne encore.

Confirmez ensuite que le plugin a bien disparu.

Désactivé n'est pas disparu. Un plugin désactivé a toujours ses fichiers sur le disque et reprendra ses paramètres lorsqu'il sera réactivé, donc supprimer ses options en cours de désactivation ne fait que perdre votre configuration.

Avant de supprimer une option, vérifiez que vous avez ciblé la ligne exacte que vous avez l'intention de supprimer. Cette requête en lecture seule affiche l'ID de l'option, son nom, son statut autoload actuel et sa taille stockée sans rien modifier :

SELECT option_id, option_name, autoload, LENGTH(option_value) AS size_bytes

FROM wp_options

WHERE option_name = 'orphaned_option_name_here';

Une fois que vous êtes sûr, supprimez la ligne :

DELETE FROM wp_options

WHERE option_name = 'orphaned_option_name_here';

N'exécutez jamais de DELETE avec un joker LIKE sur cette table à moins d'avoir lu toutes les lignes correspondantes au préalable. Un motif qui semble spécifique peut correspondre à beaucoup plus que ce que vous attendez, et wp_options est la seule table où une erreur fait planter tout le site plutôt que de casser une fonctionnalité.

Lorsque vous ne parvenez pas du tout à identifier une ligne, ne la supprimez pas. Désactivez son chargement automatique à l’aide de la méthode 1 et laissez-la ainsi.

Vous bénéficiez pleinement des avantages en termes de performances, les données survivent, et vous pouvez l'inverser en quelques secondes si quelque chose s'avère en avoir besoin.

C'est à ce stade que la sauvegarde cesse d'être une formalité. Vous supprimez des lignes de la table la plus importante de votre base de données WordPress, et l'URL de récupération d'urgence de Duplicator Pro restaurera le site même si une mauvaise requête vous bloque l'accès à wp-admin.

Méthode 3 : Remplacer le plugin qui continue de l'écrire

Si la taille de votre autoload remonte au-dessus de 1 Mo quelques jours après un nettoyage, arrêtez le nettoyage. Quelque chose écrit activement à chaque exécution, et vous ferez cela pour toujours.

Les suspects habituels, basés sur ce que je trouve constamment :

• Plugins de sliders et constructeurs de pages qui stockent d'énormes tableaux de configuration sérialisés
• Plugins d'analyse et de statistiques qui enregistrent dans une ligne d'option au lieu de leur propre table
• Plugins de sécurité qui conservent les journaux d'événements comme options
• Gestionnaires de redirection abandonnés, où chaque règle de redirection vit dans une option croissante
• Plugins de flux sociaux qui mettent en cache les réponses des API sous forme d'options autoloadées simples

Trouver le coupable est plus facile qu'il n'y paraît. Notez vos principaux responsables, attendez quelques jours, puis relancez la requête. Tout ce qui a grandi est votre réponse.

Échanger un plugin sur un site en production est là où cela devient risqué, et c'est la seule partie de ce processus que je ne ferais jamais sur la production en premier.

Duplicator Pro vous permet de transformer n'importe quelle sauvegarde complète de site en un site de staging en quelques clics, sans compte d'hébergement séparé ni transferts de fichiers manuels.

Testez le remplacement là-bas, confirmez que le site fonctionne toujours et que la taille de l'autoload reste stable, puis effectuez le changement en production.

Comment empêcher les données d'autoload de WordPress de revenir ?

Le nettoyage n'est pas un travail ponctuel, car les données d'autoload de WordPress se développent comme un effet secondaire de la maintenance normale du site. Chaque plugin que vous essayez laisse quelque chose derrière.

Quelques habitudes l'empêchent de vous échapper à nouveau :

• Vérifiez votre score chaque mois, ou après tout lot de modifications de plugins. Le tableau de bord de DB Optimizer rend cela facile en dix secondes, mais Site Health fonctionne bien si vous préférez ne pas ajouter de plugin.
• Supprimez les plugins correctement au lieu de les désactiver. La désactivation laisse toutes les options en place. La suppression donne au moins à un plugin bien construit la chance de nettoyer, bien que beaucoup ne le fassent toujours pas.
• Vérifiez l'option avant de désinstaller. Si vous savez qu'un plugin laisse des données derrière, notez les noms de ses options pendant qu'il est encore installé et facile à identifier.
• Installez moins de plugins. C'est le conseil le moins satisfaisant de cette liste et le plus efficace. Chaque plugin que vous n'essayez pas est une donnée d'autoload que vous n'avez jamais à nettoyer.
• Maintenez une sauvegarde actuelle en cours selon un calendrier, de sorte que le nettoyage de la base de données soit une décision à faible risque au lieu d'une décision nerveuse.
• Surveillez la santé du site plutôt que d'attendre que le site devienne lent. Au moment où vous remarquez le décalage, vous êtes généralement bien au-delà de 2 Mo.

Questions fréquemment posées (FAQ)

Les données d'autoload de WordPress sont une habitude de maintenance, pas une solution unique

Le bloat autoload est le coût accumulé de chaque plugin que votre site a jamais essayé. Cela vaut la peine d’y réfléchir, car cela recadre le problème.

Ce n’est pas un bug ni un signe que vous avez mal fait quelque chose. C’est le résidu ordinaire de l’exploitation d’un site WordPress pendant quelques années, et rien dans WordPress ne le nettoie pour vous.

Je préférerais être franc sur le travail à accomplir. Modifier wp_options manuellement comporte un risque réel, les outils disponibles mesureront le problème plus facilement qu’ils ne le résoudront, et vous serez de retour ici dans six mois si vous continuez à installer des plugins (ce que vous ferez).

Réglez un rappel, vérifiez le nombre trimestriellement et traitez-le comme toute autre tâche de maintenance.

Voici une chose de plus qui vaut la peine d’être faite et que je n’ai pas encore mentionnée : vérifiez la taille de votre autoload juste avant une migration. C’est le moyen le moins cher possible de réduire une archive de sauvegarde et de réduire le temps d’importation de l’autre côté.

Une table wp_options gonflée est l’une des raisons les plus courantes pour lesquelles une importation de base de données bloque ou expire sur un nouvel hôte, et il est vraiment frustrant de déboguer une migration échouée. Dix minutes de nettoyage avant l’exportation évitent cela entièrement.

Avant de toucher à wp_options, assurez-vous que votre site est protégé

Nettoyer les données autoload signifie exécuter des instructions UPDATE et DELETE sur la seule table qui peut mettre votre site entier hors ligne. Un joker mal placé dans une requête, et vous vous retrouvez avec un écran blanc sans moyen d’accéder à wp-admin pour le réparer.

Duplicator Pro transforme cette erreur récupérable en une catastrophe. Faites une sauvegarde complète avant de commencer, et restaurez en quelques minutes en un clic si quelque chose tourne mal.

Son URL de récupération d’urgence ramène un site même lorsque WordPress est complètement verrouillé, ce qui est exactement le scénario qu’une mauvaise requête de base de données crée. Essayez-le dès aujourd’hui !

Si cet article vous a fait réfléchir à ce qui d’autre se trouve dans votre base de données, ces guides valent la peine d’être lus ensuite.

• Comment supprimer tous les transients dans WordPress (4 méthodes)
• Comment optimiser votre base de données WordPress : obtenez un site rapide en 10 étapes
• Nettoyage de la base de données WordPress : un guide pour débutants pour supprimer les indésirables
• 7  signes avant-coureurs de la base de données WordPress que la plupart des propriétaires de sites manquent
• Comment réparer une base de données WordPress lente : une liste de contrôle en 4 étapes
• Maintenance de la base de données WordPress : Ce qu'il faut faire chaque semaine, chaque mois et chaque trimestre