Passer au contenu 
J'analyse Chargement automatique de WordPress-J'identifie les entrées surdimensionnées dans le tableau wp_options et je supprime les candidats critiques. Je réduis ainsi la taille totale des options chargées automatiquement, j'appuie sur TTFB, je décharge la RAM et j'accélère de manière fiable le backend et le frontend.
Points centraux
Les points suivants te donneront un aperçu compact avant que je n'aille plus loin.
- Taille de l'autochargeur rester petit (idéal : moins de 1-2 Mo)
- Top des pollueurs trouver (transitoires, grands tableaux, restes de plugins)
- Contrôles SQL pour la taille, le nombre et les meilleures entrées
- Ciblé définir sur autoload=’no‘ ou supprimer
- Suivi et établir un entretien mensuel
J'ai délibérément choisi une liste restreinte et ciblée afin que tu puisses identifier immédiatement les principaux leviers. Chaque mesure a un impact direct sur les temps de chargement. Les étapes peuvent être testées en toute sécurité et annulées si nécessaire. Je combine l'analyse, le nettoyage et le suivi dans un processus clair. Tu obtiendras ainsi des temps de chargement rapides et durables. Pages vues.
Pourquoi les données d'autoload ralentissent les performances
À chaque requête, WordPress charge toutes les options avec chargement automatique=’yes’ dans la mémoire - indépendamment du fait que ton thème ou un plugin en ait besoin à ce moment-là. Si la somme de ces valeurs atteint plusieurs mégaoctets, la latence, le TTFB et les besoins en RAM augmentent considérablement. Les grands tableaux sérialisés, les transients obsolètes et les restes de plugins désinstallés font particulièrement gonfler la quantité d'autoload. Cela entraîne un travail inutile pour PHP et MySQL et rend le backend sensiblement plus lent. Je donne donc la priorité à tout ce qui va en mémoire à chaque appel de page et je supprime systématiquement le fichier Ballast.
Mesurer l'état réel : Vérifier rapidement la taille et le nombre
Avant de modifier quoi que ce soit, je détermine la situation actuelle des données des options chargées automatiquement dans la wp_options-de la table de données. Pour cela, j'utilise une simple requête SQL sur la taille totale et je la complète par le nombre d'entrées. Je traduis le résultat en Mo, je me fixe des objectifs et je planifie les prochaines étapes. Si le total est supérieur à 1-2 Mo ou si le nombre est nettement supérieur à 500, je lance une analyse ciblée. Ce premier coup d'œil permet déjà de clarifier les choses et de fixer les objectifs. Priorités fixe.
-- taille totale (octets) des données d'autochargement
SELECT SUM(LENGTH(option_value)) AS autoload_size
FROM wp_options
WHERE autoload = 'yes' ;
-- Nombre d'entrées d'autoload
SELECT COUNT(*) AS autoload_count
FROM wp_options
WHERE autoload = 'yes;
Identifier et prioriser les entrées critiques
J'identifie d'abord les plus gros morceaux, car quelques options causent souvent la majeure partie des Dernier. Je trouve souvent des transients (_transient_*, _site_transient_*), des définitions de rôles (_user_roles_) ou des logs et statistiques de plugins qui ne sont pas utilisés en permanence. Les plugins WooCommerce ou SEO aiment également stocker des tableaux qui s'étendent. Je regarde de près tout ce qui dépasse 100-200 KB par option, je supprime systématiquement les transitoires de plus de 50 KB. Pour ceux qui souhaitent aller plus loin, je vous invite à lire mon article sur le sujet. Booster le tuning de la base de données utiliser comme guide supplémentaire pour traiter judicieusement l'ordre des mesures.
-- Rendre visible le top des pollueurs dans MB
SELECT nom_option, autoload,
ROUND(LENGTH(option_value) / 1024 / 1024, 2) AS size_mb
FROM wp_options
WHERE autoload = 'yes'.
ORDER BY size_mb DESC
LIMIT 20 ;
Analyse approfondie : modèles, préfixes et sérialisation
Pour faire le ménage de manière ciblée, je découpe la quantité d'autoload par Préfixes et les formes de données. Je vois ainsi rapidement quels plug-ins ou domaines fonctionnels contribuent particulièrement et si les grands tableaux sérialisés dominent. Je reconnais les données sérialisées à un modèle de départ tel que a :... (tableau) ou O :... (objet). Les grands tableaux imbriqués sont des candidats typiques pour les autoload=non ou une division en unités plus petites.
-- Distribution par préfixe (simple)
SELECT
SUBSTRING_INDEX(nom_option, '_', 1) AS préfixe,
COUNT(*) AS cnt,
ROUND(SUM(LENGTH(option_value)) / 1024 / 1024, 2) AS size_mb
FROM wp_options
WHERE autoload = 'yes'.
GROUP BY prefix
ORDER BY size_mb DESC
LIMIT 20 ;
-- Identifier les grands tableaux sérialisés
SELECT nom_option,
LENGTH(option_value) AS len
FROM wp_options
WHERE autoload = 'yes'.
AND option_value REGEXP '^a :[0-9]+:'.
ORDER BY len DESC
LIMIT 20 ;
-- Vérifier le contenu de type JSON (filtre grossier uniquement)
SELECT nom_option,
LENGTH(option_value) AS len
FROM wp_options
WHERE autoload = 'yes'.
AND option_value LIKE '{%'.
ORDER BY len DESC
LIMIT 20 ;
Si tu trouves plusieurs très grandes options d'un plugin, la plupart du temps, la Stratégie de stockage le problème (par exemple, des caches ou des logs dans une seule option). Il est souvent possible de désamorcer ce problème : Diviser les données, supprimer les parties inutiles ou réduire la journalisation par le biais d'un paramètre de plug-in.
Nettoyer de manière ciblée : Transients, Autoload=no, options orphelines
Pour les transients obsolètes, je supprime les entrées expirées, car elles occupent souvent inutilement Mémoire. Je règle les grandes options rarement utilisées sur autoload=’no’ et je teste le fonctionnement de la page directement après. Si je trouve des traces de plugins distants, je nettoie leurs préfixes de manière contrôlée dans le tableau wp_options. Chaque étape se fait avec une sauvegarde actuelle et un niveau de repli clair, afin que tu sois sûr à tout moment. Ainsi, la somme d'autoload se réduit rapidement et le TTFB les bénéfices.
-- Supprimer les transients expirés (sauvegarder avant !)
DELETE FROM wp_options
WHERE option_name LIKE '_transient_%'.
OR option_name LIKE '_site_transient_%' ;
-- Libérer une seule grande option de l'autoload
UPDATE wp_options
SET autoload = 'no'.
WHERE nom_option = 'EXEMPLE_OPTION' ;
-- Supprime les options de plugin orphelines avec un préfixe reconnaissable.
DELETE FROM wp_options
WHERE nom_option LIKE 'altplugin_%;
Supprimer en toute sécurité au lieu de supprimer à l'aveuglette
Si je seulement ceux qui ont expiré Transients, j'utilise des requêtes ciblées qui tiennent compte des options de timeout. C'est plus doux et cela réduit les effets de page lors de la mise en cache. Alternativement, WP-CLI fait le travail en une seule commande.
-- Supprime uniquement les transitoires (de site) expirés (plus sûr)
DELETE a, b
FROM wp_options a
JOIN wp_options b
ON b.option_name = REPLACE(a.option_name, '_transient_', '_transient_timeout_')
WHERE a.nom_option LIKE '_transient_%
AND a.option_name NOT LIKE '_transient_timeout_%'.
AND b.option_value < UNIX_TIMESTAMP() ;
DELETE a, b
FROM wp_options a
JOIN wp_options b
ON b.option_name = REPLACE(a.option_name, '_site_transient_', '_site_transient_timeout_')
WHERE a.nom_option LIKE '_site_transient_%
AND a.option_name NOT LIKE '_site_transient_timeout_%'.
AND b.option_value < UNIX_TIMESTAMP() ;
-- WP-CLI (recommandé) : supprimer les transients expirés
# site unique
wp transient delete --expired
# multisite
wp transient delete --expired --network
Pour un Retour en arrière je sauvegarde les options les plus importantes séparément : collecte des noms, exportation des contenus, journalisation des modifications. Ainsi, en cas de problème, je peux récupérer des valeurs individuelles en quelques secondes.
# Exporter les noms du Top 50 des autoloads
wp db query "
SELECT nom_option
FROM wp_options
WHERE autoload='yes'.
ORDER BY LENGTH(option_value) DESC
LIMIT 50
" --skip-column-names > big_options.txt
# Sauvegarde du contenu (format texte simple)
while read -r NAME ; do
printf '=== %s ===n' "$NAME" >> backup_options.txt
wp option get "$NAME" >> backup_options.txt
done < big_options.txt
Gestion des tableaux et hygiène de la mémoire
Après le nettoyage, j'optimise le tableau pour libérer les blocs de données supprimés et Base de données fonctionne à nouveau efficacement. Cette étape réduit la fragmentation et aide MySQL pour les prochaines requêtes. Ensuite, je vérifie à nouveau la taille de l'autoload pour que le succès reste mesurable. En option, un cache d'objets comme Redis ou Memcached accélère encore le chargement des options restantes. Même sans cache, tu ressens immédiatement l'effet, car moins de données par requête sont stockées dans le cache. RAM faire de la randonnée.
-- Libérer de la mémoire et mettre à jour les statistiques
OPTIMIZE TABLE wp_options ;
Automatiser avec des outils et WP-CLI
Sur les installations récurrentes, je gagne du temps en utilisant des Outils et des scripts. WP-CLI me permet de faire des mises à jour en masse, par exemple pour régler plusieurs grandes options sur autoload=’no’ et les vérifier directement. Pour le nettoyage régulier des transitions et l'optimisation des tableaux, j'utilise des plugins légers avec une journalisation claire. Avant chaque automatisation, je documente les valeurs de départ afin de pouvoir évaluer les avantages et les risques. Pour ceux qui veulent aller plus vite avec wp_options, vous trouverez des informations sous Réglage des performances de wp_options des idées supplémentaires pour combiner judicieusement l'analyse et le script.
# Exemple : parcourir la liste des grands noms d'options et désactiver l'autoload
while read -r NAME ; do
wp option update "$NAME" "$(wp option get "$NAME")" --autoload=no
done < names.txt
Suivi et prévention : le TTFB et le RAM en ligne de mire
Après avoir fait le ménage, j'établis une routine simple pour que la somme d'autoload ne soit pas à nouveau augmente. Un contrôle mensuel de la taille totale, complété par les dix premières options, est souvent suffisant. Si la valeur augmente sensiblement, je vérifie les derniers plugins installés et leurs paramètres. En parallèle, j'observe le TTFB, l'utilisation de la mémoire PHP et le temps de la base de données afin de mettre en évidence les améliorations. Sur un bon hébergement, ces mesures ont un effet plus important, car la performance I/O est le facteur le plus important. Gains est encore renforcée.
Aperçu des seuils et des mesures
Pour classer les prochaines étapes, je me sers de termes clairs et précis. Frontières, qui permettent de prendre des décisions rapides. Ainsi, je donne d'abord la priorité aux plus gros pollueurs sans perdre de temps avec des entrées non critiques. Le tableau te montre les valeurs seuils typiques et ma réaction standard à celles-ci. Il ne remplace pas une analyse, mais il te donne une sécurité d'action pour les premiers tours. Celui qui va plus loin peut ensuite ajuster plus finement et Contrôles comprimer.
| Type | Valeur seuil | Action |
|---|---|---|
| Taille totale de l'autochargeur | < 1-2 MO | Maintenir, vérifier mensuellement |
| Taille totale de l'autochargeur | 2-5 MO | Vérifier les 10 plus grandes options, nettoyer les transitoires |
| Taille totale de l'autochargeur | > 5 MO | Viser une réduction immédiate, autoload=no pour les options rarement utilisées |
| Option unique | > 100-200 KB | Vérifier la cause, le cas échéant, régler sur Autoload=no |
| Transients | > 50 KO | Effacer, faire recréer plus tard avec un cache propre |
Éviter les risques et tester en toute sécurité
Je ne modifie jamais les options critiques sans un nouveau Sauvegarde et sans plan pour le retour. Avant de supprimer, je vérifie qu'il ne s'agit pas d'options centrales comme siteurl ou home, car je n'y touche pas. Après chaque modification, je charge le frontend et le backend dans une session fraîche afin de détecter rapidement les effets de page. En cas de problème, je rétablis l'état précédent à partir de la sauvegarde et je procède par petites étapes. Ainsi, l'optimisation reste contrôlable et tu préserves l'intégrité du site. Stabilité de ton installation.
Exemple pratique : de l'inertie à la réactivité
Dans une installation avec plus de 20 Mo de données d'autoload, j'ai d'abord supprimé de gros transitoires, puis j'ai réduit trois options encombrantes à autoload=non ont été mis en place. Après un OPTIMIZE TABLE, les temps d'attente du TTFB et du backend sont devenus visibles, sans que des fonctions ne soient perdues. J'ai ensuite réduit les restes de plugins orphelins qui restaient après les désinstallations. La nouvelle mesure a montré une somme d'autoload proche de 2 Mo, ce qui a sensiblement accéléré les pages. Chaque action était mesurable, réversible et a permis d'obtenir immédiatement Avantages.
Options de base et pièges typiques
En plus des morceaux évidents, il y a des options que tu dois traiter avec une attention particulière. Il s'agit notamment siteurl, home, active_plugins, feuille de style/template, permalink_structure, rewrite_rules, cron et wp_user_roles. Certains sont grands (par exemple. rewrite_rules) et souvent autoload=’yes’. Je réduis leur taille, mais je les découple pas à la légère de l'autochargeur. En cas de taille inhabituelle rewrite_rules je vérifie les Custom Post Types, les taxonomies et les plugins avec mes propres réécritures et je fais le ménage au lieu de travailler uniquement sur le symptôme. Est-ce que cron je désactive les événements en double et je nettoie les hooks ; une simple conversion en autoload=non résout les Cause pas.
Meilleures pratiques des développeurs : Utiliser correctement les options
De nombreux problèmes d'autoload surviennent dès le développement. Mes lignes directrices :
- Données éphémères (caches, résultats, listes temporaires) en Transients enregistrer et, si possible, ne pas autocharger.
- Décomposer les grandes structures en options plus petites et ciblées ; pas de „conteneurs collectifs“ de plusieurs mégaoctets.
add_option( $name, $value, '', 'no' )si quelque chose n'est pas utilisé à chaque demande.- Aucune Logs ou parquer les dumps de débogage dans des options ; utiliser pour cela des tables propres ou Files/Observability.
- Au lieu de tableaux géants sérialisés, opter le cas échéant pour plusieurs options ou un tableau propre - meilleur Chargement partiel.
- Invalidation exacte : effacer les caches de manière ciblée au lieu de „clear all“. Cela permet de garder les données petites et stables.
// Exemple : créer délibérément une option sans autoload
add_option( 'mon_plugin_cache', $données, '', 'no' ) ;
// S'assurer que les grands tableaux ne grossissent pas inutilement
update_option( 'mon_plugin_cache', array_slice( $data, 0, 1000 ), false ) ;
Cache d'objets : utilité et limites
Un cache d'objets persistant (Redis/Memcached) réduit la charge de la base de données, mais n'élimine pas les Blocage de l'autoload. Les grandes sommes d'autoload passent alors directement du cache à la mémoire PHP. Cela permet d'économiser des requêtes, mais continue d'augmenter le besoin en RAM et le travail de désérialisation. C'est pourquoi il faut d'abord réduire, puis mettre en cache. Après le nettoyage, vider une fois le cache pour que des jeux de données propres et plus petits se constituent.
Indices, moteur et intégrité des wp_options
Par défaut, il existe des indices pertinents sur option_name et chargement automatique. Dans le cas d'installations migrées manuellement, ils ont parfois été supprimés ou endommagés. Je vérifie les index et les redéfinis si nécessaire. En outre, je fais attention à InnoDB en tant que Moteur de stockage et un format de rangée approprié, afin que les grandes valeurs puissent être transférées efficacement.
-- Vérifier les index
SHOW INDEX FROM wp_options ;
-- (Seulement si manquant !) Créer un nouvel index sur autoload
CREATE INDEX autoload ON wp_options (autoload) ;
-- (Facultatif) Passer à InnoDB et au format moderne Row
ALTER TABLE wp_options ENGINE=InnoDB, ROW_FORMAT=DYNAMIC ;
Important : n'effectuer des modifications de structure qu'avec une sauvegarde et une fenêtre de maintenance. Souvent, la réduction de l'autoload suffit déjà, plus OPTIMIZE TABLE, Pour obtenir des effets significatifs, il est nécessaire d'utiliser un logiciel de gestion de la qualité.
Dépistage des erreurs en cas de recours : procéder de manière mesurable
Après des modifications, j'observe de manière ciblée les indicateurs suivants par requête : TTFB, nombre/temps de requêtes, peak memory et temps d'exécution PHP. Pour des analyses approfondies, il vaut la peine d'activer brièvement un Slow-Query-Log sur la base de données et - sur les environnements de développement - un Profiler. Il est important d'enregistrer chaque modification isolé tester : d'abord les transitoires, puis les grandes options individuelles, ensuite la gestion des tables.
-- Exemple : Rendre les requêtes sur les options d'autoload visibles dans le log
SET GLOBAL slow_query_log = 1 ;
SET GLOBAL long_query_time = 0.2 ; -- 200ms
-- Désactiver après les tests
Cas particuliers : WooCommerce, SEO & plugins de statistiques
Les plug-ins d'e-commerce et d'analyse génèrent souvent de grandes options (index de produits, rapports, historique). Je vérifie si les caches peuvent être reconstruits, s'il existe des paramètres pour la taille des caches et si certaines fonctions de rapport sont vraiment utilisées en permanence. Pour WooCommerce, il vaut la peine de jeter un coup d'œil sur les transitoires de session et d'inventaire ; pour les plug-ins SEO, je fais attention aux caches d'index et de métadonnées. Principe de base : Conserver la fonction, limiter la mémoire - il est préférable de se régénérer plus souvent de manière ciblée plutôt que d'autocharger durablement des valeurs géantes.
Mise en place, déploiement et contrôles répétables
J'effectue d'abord toutes les démarches plus risquées sur une Environnement de staging et j'y assure l'ordre concret des commandes. Je mets ensuite ce playbook en œuvre dans la production. Pour les contrôles récurrents, je crée deux mini-rapports : taille totale/nombre et top 10 des tailles. Cela permet d'alléger le monitoring et de réagir rapidement lorsqu'une mise à jour du plugin augmente à nouveau la quantité d'autoload.
# Rapport rapide 1 : taille & nombre
wp db query "SELECT SUM(LENGTH(option_value)) FROM wp_options WHERE autoload='yes' ;"
wp db query "SELECT COUNT(*) FROM wp_options WHERE autoload='yes' ;"
# Rapport rapide 2 : Top 10
wp db query "
SELECT nom_option, ROUND(LENGTH(valeur_option)/1024/1024,2) AS mb
FROM wp_options WHERE autoload='yes'
ORDER BY mb DESC LIMIT 10 ;
"
Ajustement fin : données multisite et à l'échelle du réseau
Dans les configurations multisite, je vérifie en outre les wp_sitemeta-car il contient les paramètres de tout le réseau. Les grandes entrées s'y comportent de manière similaire et peuvent ralentir plusieurs sites. Je mesure les totaux et les entrées principales, puis je décide du nettoyage et de la proportion d'autoload par réseau. Le contrôle est effectué séparément pour chaque site, afin que les particularités locales ne soient pas perdues. Cela me permet de maintenir la réactivité des grands réseaux et de protéger les sites communs. Ressources.
-- Vérifier les données à l'échelle du réseau (multisite)
SELECT SUM(LENGTH(meta_value)) AS network_meta_size FROM wp_sitemeta ;
SELECT meta_key, LENGTH(meta_value) AS len
FROM wp_sitemeta
ORDER BY len DESC
LIMIT 10 ;
Aide supplémentaire pour une mise en œuvre structurée
Si tu souhaites mettre en œuvre la procédure étape par étape, utilise un guide compact de l'utilisateur. Guide en complément de tes propres notes. Commence par mesurer, sauvegarde, nettoie les transitoires et examine ensuite progressivement les grandes options. Ainsi, tu peux gérer les risques et voir des améliorations claires après chaque tour. Pour une structure supplémentaire, tu peux utiliser cet aperçu : wp_options-optimisation. Avec cette grille, tu restes cohérent et tu ne perds pas de Étapes hors de vue.
Bilan rapide : les principaux leviers pour des pages rapides
Je limite systématiquement les options chargées automatiquement, je nettoie les transitions, je mets en place des blocs rarement utilisés autoload=non et optimise le tableau. La mesure avant et après chaque tour rend l'effet visible et crée de la sécurité. Avec des valeurs seuils claires, je trouve les plus grandes causes en quelques minutes et j'interviens d'abord à ce niveau. Un monitoring simple évite que la somme d'autoload ne remonte plus tard. Ainsi, j'amène durablement ton installation WordPress à la vitesse supérieure et je renforce la Performance perceptible.
