Passer au contenu 
Options d'autochargement WordPress décider quelles options du tableau wp_options sont transférées dans la mémoire à chaque consultation de la page, ce qui influence directement le temps de chargement, le TTFB et les besoins en mémoire. Je vais vous montrer comment identifier les données Autoload trop volumineuses, les réduire de manière ciblée et les maintenir à un niveau bas de manière durable, afin que les requêtes démarrent plus rapidement et que le backend réagisse de manière nettement plus fluide.
Points centraux
De nombreuses installations téléchargent silencieusement des paquets de données de plus en plus volumineux. chargement automatique, alors que ces entrées ne sont pas nécessaires pour chaque page. Je donne la priorité à l'analyse de la taille totale, puis aux options les plus importantes, après quoi je mets les entrées non critiques en autoload=non ou les supprime de manière contrôlée. Cela me permet de réduire le TTFB et la consommation de RAM, de stabiliser les requêtes et de soulager PHP en cas de charge importante. De plus, je veille à la propreté des transients et vérifie régulièrement le tableau afin d'éviter toute nouvelle surcharge. L'hébergement, le cache d'objets et un tableau wp_options allégé fonctionnent ensemble et permettent d'obtenir des gains de performance notables sans aucun risque.
- Analyse la taille de chargement automatique et les options principales
- Faire le ménage Entrées de plugins orphelines
- Commutation grandes options rarement utilisées sur no
- Transients et supprimer les données temporaires
- Suivi et configuration de l'hébergement
J'intègre ces étapes dans mon Entretien afin que la base de données reste légère et que le site web réponde rapidement et de manière fiable, même en cas de pics de trafic.
Que sont les options d'autochargement dans WordPress ?
WordPress enregistre les configurations dans wp_options, notamment les URL, les plugins actifs, les informations sur les thèmes, les widgets, les transitoires et bien plus encore. Chaque enregistrement comporte le nom, la valeur et le champ chargement automatique, qui détermine avec yes ou no si WordPress charge l'entrée à chaque démarrage de la page. La fonction wp_load_alloptions lit toutes les entrées autoload=yes en une seule fois afin de fournir les paramètres fréquents sans trop de requêtes SQL individuelles. Ce mécanisme permet de gagner du temps lorsque les valeurs sont peu nombreuses et petites, mais alourdit le processus de démarrage lorsque les entrées sont nombreuses et volumineuses. C'est précisément là que se cache un frein que vous ne remarquez pratiquement pas au quotidien. Au fil des ans, cela crée une surcharge qui peut prolonger chaque requête de quelques millisecondes à quelques secondes.
Toutes les options ne sont pas pertinentes dans chargement automatique: Les informations de base telles que siteurl ou active_plugins oui, les données de cache ou de journal plutôt non. Si d'anciens restes de plugins restent dans le tableau et sont réglés sur « yes », WordPress continue de les charger, même si personne ne les interroge plus dans le code. Les grands champs des constructeurs de pages, des plugins de formulaire ou des suites SEO peuvent rapidement faire passer le paquet Autoload au-dessus de 1 Mo. À partir de ce moment, le TTFB et les besoins en mémoire augmentent, en particulier sur les hébergements mutualisés et en cas de charge élevée. Je vérifie donc régulièrement ce qui doit vraiment être chargé automatiquement.
Pourquoi l'autochargement nuit aux performances
Chaque consultation de page entraîne la somme de tous les autoload=yes Enregistre les valeurs dans la mémoire, que les données soient pertinentes pour la page actuelle ou non. Cela coûte de la RAM, augmente la structure PHP et ralentit l'exécution précoce avant le rendu. Plus il y a de plugins installés, plus le paquet continue de grossir sans que l'on s'en aperçoive. Les configurations WooCommerce, les plugins de suivi ou les constructeurs de pages augmentent également la probabilité d'entrées volumineuses. Si vous laissez cela se produire, le premier octet, qui détermine souvent l'impression générale, souffrira particulièrement sous la charge.
Plusieurs guides techniques recommandent de limiter la taille totale à environ 1 Mo car cela augmente sensiblement les latences. Lorsque des données Autoload volumineuses rencontrent un faible débit d'E/S ou un trafic parallèle important, les temps de réponse augmentent considérablement. Le backend semble lent, les pages d'administration s'ouvrent plus lentement et les tâches cron prennent plus de temps. Cet effet n'affecte pas directement la mise en cache, mais il retarde la génération des réponses et le remplissage du cache. Je garde donc l'autochargement aussi petit que possible et ne charge que ce dont j'ai vraiment besoin partout.
Voici comment je vérifie la taille des données d'autochargement
Je commence par un Sauvegarde de la base de données, puis je lis la taille de l'autoload. Dans le tableau de bord, l'état du site web fournit déjà une indication lorsque le nombre et la taille sont anormalement élevés. Pour obtenir une mesure exacte, j'utilise SQL et j'additionne la longueur de toutes les valeurs autoload=yes. Ce chiffre m'indique l'urgence avec laquelle je dois intervenir. S'il est supérieur à 1 Mo, je planifie immédiatement un nettoyage ciblé. Une fonction pratique Gestion des données WP-Options m'aide à agir de manière cohérente.
J'utilise les deux requêtes suivantes pour analyser les Taille et les plus gros morceaux. Je commence par calculer la somme de toutes les valeurs chargées automatiquement. Ensuite, je classe les 10 premières par taille de champ afin d'obtenir des résultats rapides. Je peux ainsi identifier en quelques minutes les pertes de mémoire et de latence. Je priorise ensuite la suppression ou le passage à autoload=no.
SELECT SUM(LENGTH(option_value)) AS autoload_size FROM wp_options WHERE autoload = 'yes';
SELECT option_name, LENGTH(option_value) AS option_value_length FROM wp_options WHERE autoload = 'yes' ORDER BY option_value_length DESC LIMIT 10;
Quelles entrées deviennent généralement volumineuses ?
Souvent ballonné Transients, les objets cache et les données de journalisation Autoload inutiles. Les mises en page Builder et les configurations de formulaire écrivent également des tableaux volumineux qui ne sont pas nécessaires pour chaque page frontale. Même les plugins désactivés laissent souvent des résidus qui restent sur « yes ». Dans la pratique, les modèles sur lesquels je base mon nettoyage se répètent. Le tableau suivant récapitule les candidats typiques et les recommandations. Cet aperçu permet de décider plus rapidement s'il est judicieux de supprimer ou de passer à « no ».
| Catégorie | Exemples option_name | Taille typique | Recommandation |
|---|---|---|---|
| Noyau Base | siteurl, home, blogname | petit | Conserver autoload=yes |
| Thème & Widgets | modèle, feuille de style, widget_* | petit-moyen | vérifier, généralement oui ok |
| Constructeur / Formulaires | builder_*, form_*, theme_mods_* | moyen à grand | Définir autoload=no |
| Transients | _transient_*, _site_transient_* | moyen à grand | Supprimer les expirations, sinon non |
| Cache & Journaux | cache_*, log_*, debug_* | grand | Ne pas charger automatiquement, supprimer si nécessaire |
| Orphelin | Anciens résidus plugin_* | petit–grand | Supprimer après sauvegarde |
Sur l'ensemble des appareils, une approche rigide Séparation des paramètres permanents et des données temporaires pour obtenir les meilleurs effets. Je ne charge que ce dont chaque page a réellement besoin. Tout le reste reste accessible, mais n'est pas chargé automatiquement. Cela permet d'alléger la phase de démarrage et la gestion des objets du processus PHP. Résultat : des temps de réponse nettement plus rapides.
Stratégies d'optimisation
Je commence par supprimer charges héritées du passé plugins orphelins, car ces étapes permettent de gagner rapidement beaucoup d'espace et de temps. Ensuite, je définis les options volumineuses et rarement utilisées sur autoload=no afin qu'elles ne soient lues qu'en cas de besoin. Les entrées temporaires ou liées au cache n'ont jamais leur place dans Autoload et sont supprimées ou transférées dans des mémoires dédiées. Je continue à supprimer systématiquement les transitoires, en particulier les enregistrements expirés. Enfin, je vérifie à nouveau la taille totale et documente le nouvel état. Cela me permet de créer de la transparence et de mettre en place un système de surveillance.
Je travaille de manière incrémentale afin de Risques : d'abord mesurer, puis modifier de manière ciblée, puis vérifier. Je garde une sauvegarde pour chaque suppression. Pour les pages productives, je prévois des créneaux horaires en dehors des heures de pointe. Je teste les modifications apportées aux champs sensibles sur une instance de staging. Ainsi, la page reste en ligne et le résultat est fiable.
Régler Autoload sur „ no “ – mise en œuvre sécurisée
Toutes les grandes options ne doivent pas nécessairement disparaître, beaucoup peuvent être remplacées par autoload=non désactiver. La configuration est ainsi conservée, seul le chargement automatique est supprimé. J'effectue la modification de manière contrôlée via SQL, puis je vérifie le comportement dans le frontend et le backend. Je teste de manière ciblée les pages critiques, telles que les formulaires ou les fonctions de la boutique. En cas d'erreurs, je rétablis immédiatement la modification. La procédure est rapide et n'entraîne généralement aucun effet secondaire.
UPDATE wp_options SET autoload = 'no' WHERE option_name = 'VOTRE_NOM_D'OPTION';
Pour plusieurs candidats, je rédige une petite Liste des noms issus du top 10 des requêtes et je les traite les uns après les autres. Après chaque mise à jour, je mesure à nouveau la taille. Si la somme diminue de manière significative, le TTFB et la consommation de RAM baissent immédiatement. Si quelque chose ne fonctionne pas, je récupère la sauvegarde ou je remets autoload sur yes. Ainsi, je reste du côté de la sécurité.
Supprimer les transitoires et les données temporaires
Les transitoires sont des phénomènes limités dans le temps. mémoire tampon et sont souvent conservées inutilement longtemps dans wp_options. Les entrées expirées restent souvent en place lorsque le nettoyage échoue. Je supprime régulièrement les entrées _transient_* et _site_transient_* expirées. De plus, je m'assure que ces données ne sont pas enregistrées avec autoload=yes. Cela réduit considérablement la taille du paquet Autoload et le maintient à un niveau faible. Cette opération doit faire partie de tout plan de maintenance.
DELETE FROM wp_options WHERE option_name LIKE '_transient_%' AND option_name NOT LIKE '_transient_timeout_%';
Ceux qui utilisent des outils font attention à Sécurité et des journaux clairs afin que les modifications restent traçables. Je teste d'abord manuellement les tâches de nettoyage automatique. Ensuite, je planifie des vérifications récurrentes, par exemple tous les trimestres. Ainsi, il n'y a pas de surprises. Et le tableau ne grossit pas à nouveau sans que l'on s'en aperçoive.
Index sur la colonne Autoload
Si les options sont très nombreuses, un index peut être créé sur la colonne chargement automatique Accélérer encore davantage les accès. La requête autoload=yes bénéficie alors d'une recherche plus rapide. Cela vaut particulièrement la peine pour les boutiques en ligne importantes et actives ou les configurations multisites. Cette intervention doit être confiée à des mains expertes, car des index incorrects peuvent créer leurs propres problèmes. Avec un plan clair et une sauvegarde, les temps de requête diminuent sensiblement. Je documente la modification et mesure l'effet.
En parallèle, je pense que Base de données De manière globale : le moteur, la mémoire tampon, les requêtes lentes et les tâches cron influencent le résultat global. L'autochargement est un levier central, mais ce n'est pas le seul. Une table bien organisée avec un bon indexage interagit avec les caches et la configuration PHP. Cela me permet de gagner quelques millisecondes supplémentaires. Les petites corrections s'additionnent.
Combiner judicieusement hébergement, cache objet et chargement automatique
Un hôte rapide atténue les effets négatifs des grands chargement automatique, mais ne remplace pas le nettoyage. Il est particulièrement efficace lorsqu'un cache d'objets gère les accès fréquents aux options. Les valeurs sont ainsi stockées en mémoire et évitent les lectures répétitives dans la base de données. Mais le levier le plus important reste une somme d'autochargement réduite. Cette comparaison fournit une brève orientation : maintenez l'autochargement à un niveau faible, puis complétez les caches de manière judicieuse. Je vous en dirai plus à ce sujet dans l'article Cache de page vs cache d'objet.
Masquer les caches Problèmes Seulement dans certaines conditions, lorsque la base de données est inutilement volumineuse. Je commence par nettoyer le tableau afin que les caches aient moins de données à traiter. Je bénéficie ensuite d'un double avantage : un démarrage plus rapide et des accès répétés plus rapides. La surveillance me permet de voir si le TTFB et la RAM restent stables à un niveau bas. Il en résulte une configuration propre avec des réserves pour les pics de trafic.
Quand autoload=yes est indispensable
Tout ne doit pas être classé dans la catégorie „ non “. Il existe Options principales, dont WordPress a besoin très tôt dans le bootstrapping ou pour pratiquement chaque requête. J'y inclus généralement :
- siteurl et home (URL de base, utilisées au début)
- active_plugins (nécessaire directement lors du chargement des plugins)
- Feuille de style et modèle (sélection du thème)
- nom du blog, description du blog, blog_charset (données générales de la page)
- rewrite_rules (nécessaire pour l'analyse des requêtes et peut être volumineux)
Je laisse généralement ces options sur autoload=yes. Dans les cas limites tels que rewrite_rules Je vérifie s'il existe des ensembles de règles exceptionnellement volumineux et si des permaliens ou des plugins incorrects augmentent la taille. Des champs tels que cron et les options complexes des plugins sont considérées comme sensible: ils peuvent atteindre une taille importante, mais sont souvent utilisés. Ici, je teste sur Staging si autoload=non A des effets secondaires avant de prendre une décision.
Particularités multisites et options réseau
À l'adresse suivante : Multisite-Environnements : chaque site dispose de ses propres tables wp_options avec champ Autoload, en plus de la table globale. wp_sitemeta pour les options réseau. Je vérifie donc la somme Autoload pour chaque site et, en complément, la taille des métadonnées réseau centrales. Les options réseau importantes n'ont certes pas d'incidence sur chaque requête individuelle du site, mais elles peuvent ralentir les processus d'administration et Cron.
-- Vérifier par site (adapter le préfixe du tableau en fonction de l'ID du blog) SELECT SUM(LENGTH(option_value)) AS autoload_size FROM wp_2_options WHERE autoload = 'yes'; -- Examiner grossièrement les métadonnées à l'échelle du réseau SELECT SUM(LENGTH(meta_value)) AS network_meta_size
FROM wp_sitemeta; -- Métadonnées réseau les plus volumineuses SELECT meta_key, LENGTH(meta_value) AS len FROM wp_sitemeta ORDER BY len DESC LIMIT 10;
Pour les sites multisites, je supprime les options les plus volumineuses de chaque site et je veille à ce que les métadonnées réseau restent légères. Les caches communs (cache d'objets) sont utiles, mais ils ne remplacent pas base de données propre.
WP-CLI : analyse et modifications en masse à partir du shell
Sur les serveurs, j'utilise WP-CLI, pour exécuter directement les analyses SQL et rendre les modifications reproductibles. Je garantis ainsi des audits rapides, même sur des configurations plus importantes.
# Déterminer la taille totale de l'autochargement wp db query " SELECT SUM(LENGTH(option_value)) AS autoload_size FROM wp_options WHERE autoload='yes'; "
# Afficher les 20 options autoload les plus importantes wp db query " SELECT option_name, LENGTH(option_value) AS len FROM wp_options WHERE autoload='yes' ORDER BY len DESC LIMIT 20; "
Pour les modifications en masse, je travaille avec une liste des candidats à partir de l'analyse et je la règle de manière contrôlée sur no. Après chaque tour, je mesure à nouveau la somme.
# Exemple : candidats (un par ligne) dans names.txt
# autoload=no pour tous les noms (attention, faites une sauvegarde au préalable !) while read -r NAME; do VAL="$(wp option get "$NAME")" wp option update "$NAME" "$VAL" --autoload=no done < names.txt
Avec cette méthode, l'historique reste traçable dans le terminal et je peux revenir en arrière de manière ciblée si nécessaire.
Entretien automatique avec le plugin MU
Pour empêcher toute croissance future, je place de petits Guardrails Un plugin MU peut par exemple régler automatiquement le drapeau Autoload sur „ no “ pour les modèles connus tels que les transients, les entrées de cache et de journal, et les nettoyer périodiquement. Je teste d'abord ces interventions sur Staging.
update($wpdb->options, array('autoload' => 'no'), array('option_name' => $option)); break; } } }, 10, 3);
// Nettoyage planifié : supprimer les transitoires expirés if (!wp_next_scheduled('autoload_housekeeping')) { wp_schedule_event(time(), 'daily', 'autoload_housekeeping'); } add_action('autoload_housekeeping', function() { global $wpdb;
// Nettoyer les transitoires expirés (sans délais d'expiration) $wpdb->query("DELETE FROM {$wpdb->options} WHERE option_name LIKE '_transient_%' AND option_name NOT LIKE '_transient_timeout_%'");
$wpdb->query("DELETE FROM {$wpdb->options} WHERE option_name LIKE '_site_transient_%' AND option_name NOT LIKE '_site_transient_timeout_%'");
// Facultatif : désactiver les options d'autochargement très volumineuses $candidates = $wpdb->get_col("SELECT option_name FROM {$wpdb->options} WHERE autoload='yes' AND LENGTH(option_value) > 500000");
foreach ($candidates as $name) { $wpdb->update($wpdb->options, array('autoload' => 'no'), array('option_name' => $name)); } });
Cela m'évite de télécharger inutilement des données volumineuses après des mises à jour ou l'installation de nouveaux plugins. Je documente les exceptions (liste blanche) si certaines options doivent rester en mode Autoload malgré leur taille.
Suppression sécurisée : exemples SQL plus précis
Je supprime ciblé et évite les dommages collatéraux. Pour les transitoires, je veille à ne pas supprimer directement les timeouts, mais les valeurs correspondantes.
-- Supprimer uniquement les transitoires expirés (approche sécurisée) DELETE o FROM wp_options o JOIN wp_options t ON o.option_name = REPLACE(t.option_name, '_timeout_', '') WHERE t.option_name LIKE '_transient_timeout_%'
AND t.option_value < UNIX_TIMESTAMP(); -- Transitoires à l'échelle du réseau (multisite) DELETE o FROM wp_options o JOIN wp_options t ON o.option_name = REPLACE(t.option_name, '_site_transient_timeout_', '_site_transient_')
WHERE t.option_name LIKE '_site_transient_timeout_%' AND t.option_value < UNIX_TIMESTAMP();
De plus, pour les options importantes mais rarement utilisées, je mets systématiquement le drapeau sur „ non “ au lieu de les supprimer. Ainsi, je limite les risques et je peux revenir en arrière à tout moment si nécessaire.
Indexation : créer, tester, supprimer
Si le tableau est volumineux, un index combiné accélère les recherches fréquentes. Je le crée, je mesure et je le supprime s'il n'apporte aucun avantage.
-- Créer un index (adapter le nom en fonction des règles de l'hôte) CREATE INDEX autoload_name_idx ON wp_options (autoload, option_name); -- Tester, mesurer, supprimer si nécessaire DROP INDEX autoload_name_idx ON wp_options;
Avant cela, je vérifie les index existants afin de ne rien créer en double. Après la création, je vérifie les plans de requête et les temps de réponse sous une charge réelle.
Mesure et validation : fournir des preuves claires avant/après
Je justifie les optimisations avec chiffres. Je mesure le TTFB sur des pages représentatives, je trace les pics de mémoire et je compte les requêtes de base de données. Pour avoir un aperçu rapide, j'utilise une brève sortie de journal pendant les tests (ne pas laisser activé en permanence) :
<?php // Ne pas utiliser en production de manière permanente – uniquement pour les tests de mesure ! add_action('shutdown', function() { if (defined('WP_DEBUG') && WP_DEBUG) { error_log(sprintf(
'WP-Run: %.3fs | Queries: %d | Peak-Mem: %.1fMB', timer_stop(0, 3), get_num_queries(), memory_get_peak_usage(true) / 1048576 )); } });
Après deux ou trois séries de mesures avant et après la correction, je vérifie si le TTFB, le nombre de requêtes et la mémoire maximale s'améliorent comme prévu. En parallèle, j'observe le backend (pages du plugin et de l'éditeur), car c'est là que les paquets Autoload volumineux sont particulièrement visibles.
Erreurs fréquentes et comment les éviter
- Tout régler sur „ non “ : Les mesures globales perturbent les fonctions ou génèrent de nombreux QSL individuels. Je procède de manière sélective et je teste.
- Modifier les options critiques du noyau : Traitez avec précaution les champs siteurl, home, active_plugins, Theme et rewrite_rules.
- Suppression incorrecte des transitoires : Supprimer les délais d'attente au lieu des valeurs ou effacer les deux au hasard. Mieux : nettoyer de manière ciblée les valeurs expirées.
- Travailler sans sauvegarde : Avant chaque tour, je sauvegarde la base de données et note les modifications.
- Ne penser qu'à „ DB “ : Le cache objet, les limites de mémoire PHP, les tâches cron lentes et les limites d'hébergement sont également pris en compte. Je considère le système dans son ensemble.
- Nettoyer une seule fois et oublier : Sans surveillance régulière, Autoload recommence à se développer. Je prévois des intervalles de maintenance fixes.
Meilleures pratiques pour l'avenir
Je choisis délibérément Plugins, qui gèrent correctement les options et suppriment les données lors de leur suppression. Après les tests, les modules complémentaires sont complètement supprimés, et non simplement désactivés. Avant toute modification importante, je sauvegarde toujours la base de données. Je vérifie ensuite à nouveau la taille de l'autochargement afin de détecter immédiatement tout nouveau problème. En particulier pour les configurations de mise en cache, je veille à ce que la configuration reste légère et j'évite les pièges typiques. Un coup d'œil sur Erreurs de configuration Redis aide à éviter les effets secondaires.
Régulièrement Soins empêche la table wp_options de grossir à nouveau. Je me fixe des échéances fixes, par exemple tous les trimestres. En notant les valeurs avant et après l'optimisation, je peux identifier les tendances. Cela me permet d'agir à temps, plutôt que de réagir sous pression plus tard. À long terme, cette routine me fait gagner du temps et m'évite du stress.
Workflow concret étape par étape
Je commence par sécuriser Base de données et les fichiers dans leur intégralité afin de pouvoir revenir en arrière à tout moment. Ensuite, je détermine la taille actuelle de l'autochargement et les 10 entrées les plus importantes à l'aide de SQL. Puis, j'identifie les données de plugins orphelines et les entrées importantes du cache, du journal ou des données transitoires. À l'étape suivante, je définis les options rarement utilisées sur autoload=no et supprime de manière ciblée les résidus superflus. Pour finir, je mesure à nouveau, documente le nouveau total et planifie une répétition du contrôle.
Dans les cas délicats Champs Je teste d'abord les modifications sur la plateforme de staging. Si des anomalies apparaissent, je réactive certaines valeurs ou je restaure la sauvegarde. Ensuite, j'adapte ma sélection de plugins afin d'éviter une nouvelle croissance. Un simple protocole par cycle suffit pour garder une vue d'ensemble. Le processus reste simple et conduit de manière fiable à des effets mesurables.
Résumé : petit tableau, grand effet
Autoload est un puissant mécanisme, qui ralentit considérablement lorsque la table wp_options est remplie de données inutiles. Si vous maintenez le total en dessous d'environ 1 Mo, le TTFB, les besoins en RAM et les latences du backend diminuent sensiblement. La marche à suivre est claire : mesurer, supprimer le superflu, utiliser autoload=no pour les valeurs rares, vider les transitoires et contrôler régulièrement. Les caches et un bon hébergement renforcent l'effet, mais ne remplacent pas une base de données propre. En intégrant cette procédure à votre routine, vous obtiendrez durablement plus de vitesse avec le même matériel.
Je considère Autoload comme vis de réglage avec un excellent rapport qualité-prix : peu de modifications, effet significatif. Les boutiques et les sites riches en contenu en tirent immédiatement profit. Un bref contrôle mensuel ou trimestriel suffit pour que le tableau reste allégé. Les pages réagissent ainsi plus rapidement, les administrateurs travaillent plus efficacement et les tâches cron s'exécutent sans stress. Il s'agit là d'une performance durable, sans risque et sans nouvelle bataille de plugins.
