Aujourd’hui, nous allons jeter un coup d’oeil à la table wp_options dans votre base de données WordPress. C’est un domaine qui est souvent négligé lorsqu’il s’agit de la performance globale de WordPress et de la base de données. Surtout sur les sites plus anciens et plus grands, cela peut être la cause de la lenteur des requêtes sur votre site en raison des données auto-chargées qui sont laissées par des extensions et thèmes tiers. Consultez les conseils ci-dessous pour savoir comment vérifier, dépanner et nettoyer votre table wp_options.
Qu’est-ce que la table wp_options ?
La table wp_options contient toutes sortes de données pour votre site WordPress comme :
- L’URL du site, l’URL de la page d’accueil, l’adresse email de l’administrateur, la catégorie par défaut, les messages par page, le format de l’heure, etc.
- Les paramètres pour les extensions, thèmes et widgets
- Les données temporairement mises en cache
La table contient les champs suivants, l’une d’entre elles nous intéresse plus lorsqu’il s’agit de performance:
- option_id
- option_name
- option_value
- autoload
Une des choses importantes à comprendre à propos de la table wp_options est le champ autoload. Il contient la valeur oui ou non. Ceci contrôle essentiellement si elle est chargée ou non par la fonction wp_load_alloptions(). Les données chargées automatiquement sont des données qui sont chargées sur chaque page de votre site WordPress. Tout comme nous vous avons montré comment désactiver certains scripts du chargement au niveau du site, la même idée s’applique ici. L’attribut autoload est défini à « oui » par défaut pour les développeurs, mais tous les extensions ne devraient théoriquement pas charger leurs données sur chaque page.
Le problème que les sites WordPress peuvent rencontrer est que lorsqu’il y a une grande quantité de données chargées automatiquement dans la table wp_options. C’est généralement à cause de ce qui suit :
- Les données sont chargées automatiquement par une extension alors qu’elles devraient être réglées sur « non ». Un bon exemple de ceci serait une extension de formulaire de contact. A-t-elle besoin de charger des données sur chaque page ou seulement sur la page de contact ?
- Les extensions ou thèmes ont été supprimés du site WordPress, mais leurs options restent dans la table wp_options. Cela pourrait signifier que des données inutiles chargées automatiquement sont appelées à chaque demande.
- Les développeurs d’extensions et de thèmes chargent les données dans la table wp_options au lieu d’utiliser leurs propres tables. Il y a des arguments des deux côtés pour cela, car certains développeurs préfèrent les extensions qui ne créent pas de tables supplémentaires. Cependant, la table wp_options n’a pas été conçue pour contenir des milliers de lignes.
A partir de combien dit-on qu’il y a trop de données chargées automatiquement ? Cela peut varier bien sûr, mais idéalement, vous voulez que ce soit entre 300 Ko à 1Mo. Dès que vous commencez à vous approcher de 3-5Mo ou plus, il y a très probablement des choses qui peuvent être optimisées ou supprimées du chargement automatique. Et tout ce qui dépasse 10Mo devrait être traité immédiatement. Cela ne signifie pas toujours que cela va causer un problème, mais c’est un bon point de départ.
Dépannage des données chargées automatiquement dans la table wp_options.
Si vous rencontrez de la lenteur sur votre site WordPress, cela peut être dû à une requête ou à des données chargées automatiquement laissées par une ancienne extension WordPress. Ci-dessous, nous allons vous montrer comment vérifier la taille des données chargées automatiquement dans votre base de données, et aller sur un site en ligne afin de vous partager ce que nous avons fait pour le nettoyer.
Vérifier la taille des données chargées automatiquement
La première chose à faire est de vérifier la taille des données actuelles chargées automatiquement sur votre site WordPress. Pour cela, connectez-vous à phpMyAdmin. Cliquez sur votre base de données à gauche, puis sur l’onglet SQL. Ensuite, entrez la commande suivante et appuyez sur « Exécuter ».
SELECT SUM(LENGTH(option_value)) as autoload_size FROM wp_options WHERE autoload='yes';Vous devrez peut-être modifier la requête ci-dessus si votre site WordPress utilise un préfixe différent de wp_.
La taille de autoload_size sera retournée en octets. Il y a 1024 octets dans un Ko et 1024 Ko dans un Mo. Ainsi, dans notre cas, 249 025 octets équivaut à 0,25 Mo. Donc pour ce site, c’est une bonne taille ! Si vous retournez quoi que ce soit en dessous de 1 Mo, vous ne devriez pas vous inquiéter. Cependant, si le résultat était beaucoup plus grand, continuez, et lisez la suite de ce tutoriel.
Ci-dessous se trouve un site que nous avons testé, dans lequel 137,724,715 octets ont été retournés, ou plutôt 137 Mo. C’est un bon exemple d’un site où quelque chose ne va pas du tout, disons plutôt qu’il y a des choses à optimiser.
Vous pouvez également utiliser une requête plus longue comme la suivante. Cela vous affichera la taille des données chargées automatiquement, le nombre d’entrées dans la table et les 10 premières entrées par taille.
SELECT 'autoloaded data in KiB' as name, ROUND(SUM(LENGTH(option_value))/ 1024) as value FROM wp_options WHERE autoload='yes'
UNION
SELECT 'autoloaded data count', count(*) FROM wp_options WHERE autoload='yes'
UNION
(SELECT option_name, length(option_value) FROM wp_options WHERE autoload='yes' ORDER BY length(option_value) DESC LIMIT 10)
Si vous avez accès à New Relic (licence nécessaire), vous pouvez également l’utiliser pour vous aider à dépanner les requêtes liées à la table wp_options. L’onglet bases de données indiquera la table et le type de requête consommant le plus de temps. Si vous sélectionnez l’une des entrées de la liste, vous pouvez voir plus de détails, y compris des exemples de requêtes. Dans l’exemple ci-dessous, vous pouvez voir que les données chargées automatiquement dans la table wp_options sont pointées du doigt. Bien sûr, une analyse rapide du site en question a confirmé près de 250Mo de données chargées automatiquement.
Trier les plus grandes données chargées automatiquement
L’étape suivante consiste à trier rapidement les plus grands éléments des données chargées automatiquement. Voici une commande SQL rapide que vous pouvez utiliser pour lister les 10 premiers :
SELECT option_name, length(option_value) AS option_value_length FROM wp_options WHERE autoload='yes' ORDER BY option_value_length DESC LIMIT 10;Encore une fois, vous devrez peut-être modifier la requête ci-dessus si votre site WordPress utilise un préfixe différent de wp_.
Enquêter sur les données individuelles chargées automatiquement dans la table wp_options
L’étape suivante consiste à creuser dans certaines des données les plus importantes chargées automatiquement.
301_redirects
Comme nous pouvons le voir ci-dessus, l’option chargement automatique la plus lourde concerne la table 301_redirections. Ceci est probablement directement lié à une extension de redirection sur le site ou à l’extension WordPress SEO, qui possède aussi une fonction de redirection. Dans ce cas, la meilleure recommandation est de mettre en œuvre les redirections au niveau du serveur.
Pourquoi ? Parce que l’utilisation d’extensions WordPress gratuites pour créer des redirections peut parfois causer des problèmes de performance car la plupart d’entre eux utilisent la fonction wp_redirect, ce qui nécessite une exécution de code et des ressources supplémentaires. Et bien sûr, cela charge aussi automatiquement les données dans la table wp_options.
Si vous êtes un client Kinsta, vous pouvez facilement ajouter des redirections au niveau du serveur en utilisant l’outil de règles de redirection dans votre tableau de bord MyKinsta. Non seulement cela est plus performant, mais vous avez également une extension de moins à gérer !
wpurp_custom_template_
La plus grosse option suivante de données à chargement automatique était wpurp_custom_template_template_#. Nous pouvons voir qu’il y a pas mal de lignes différentes pour cela. Typiquement, vous devriez être capable de trouver le nom de cette option et faire le lien en regardant dans le dossier de vos thèmes ou extensions. Dans ce cas, nous avons fait une commande grep depuis le serveur pour voir si nous pouvions la trouver. Vous pouvez aussi le vérifier sur place via SFTP.
grep -Ri "wpurp_custom_template_"La commande ci-dessus n’a cependant rien retourné et nous sommes donc allés sur Google et avons effectué une recherche. Nous avons rapidement découvert que c’était lié à une extension WordPress qui n’était plus installée sur le site, connu sous le nom de WP Ultimate Recipe. Il s’agit d’un exemple classique de données inutiles chargées automatiquement et laissées derrière. Nous avons un long tutoriel sur la façon de désinstaller les extensions WordPress (la bonne façon). Et par bonne façon, nous voulons dire qu’il s’agit de nettoyer ce qui reste derrière.
um_cache_userdata_
L’option suivante était um_cache_userdata_userdata_#. Nous pouvons voir qu’il y a pas mal de lignes différentes pour cela. Comme c’était vers le bas, nous avons rapidement modifié notre commande MySQL pour afficher les 40 premières données chargées automatiquement :
SELECT option_name, length(option_value) AS option_value_length FROM wp_options WHERE autoload='yes' ORDER BY option_value_length DESC LIMIT 40;Ou additionner toutes les valeurs avec ce préfixe :
SELECT 'sum size in KiB', ROUND(SUM(length(option_value))/1024,0) FROM wp_options WHERE autoload='yes' AND option_name like "um_cache_userdata_%"Nous avons pu voir qu’il y avait beaucoup plus d’entrées pour um_cache_userdata_# dans la table wp_options. Nous avons de nouveau lancé une commande grep pour vérifier nos dossiers de extensions et de thèmes.
grep -Ri "um_cache_userdata_"Nous avons alors été en mesure d’identifier rapidement qu’il s’agit d’un lien avec l’extension Ultimate Member. Une autre recherche rapide sur Google a retourné quelques bonnes solutions à ce problème (voir l’article de support). Ne sous-estimez jamais la puissance d’une recherche Google ! Il s’avère qu’il y avait quelques options différentes disponibles dans l’extension pour résoudre ce problème.
- Ultimate Member > Dashboard > User Cache > Clear Cache.
- Ultimate Member -> Settings -> Advanced -> Stop caching user’s profile data (switch to ON), then Save Changes.
Une autre option pour voir ce qu’est une option chargée automatiquement est d’appuyer sur le bouton « Modifier », et cela peut lister le dossier de l’extension/theme, ou lister le site web du développeur.
Tâches cron
Une autre option fréquente que nous voyons avec une grande quantité de données chargées automatiquement est la tâche cron. Pour cela, il pourrait s’agir de tout ce qui est lié à une tâche cron. Ce que vous pouvez faire, c’est cliquer sur le bouton « Modifier » pour voir ce qui cause cela. Voici un exemple ci-dessous dans lequel il était évident que « do_pings » était à l’origine du problème. Encore une fois, une recherche rapide sur Google a révélé une solution rapide pour nettoyer les do_pings.
Nettoyage de la table wp_options
Si vous voyez beaucoup de ce que nous avons mentionné ci-dessus, alors il est probablement temps que vous fassiez un nettoyage de toutes les données chargées automatiquement dans votre table wp_options. Il est également recommandé d’essayer de réduire au minimum le nombre de lignes de votre table wp_options. Veuillez toujours faire des sauvegardes avant de supprimer des données de votre base de données. Si vous n’êtes pas à l’aise de le faire vous-même, nous vous recommandons toujours d’engager un développeur WordPress. C’est aussi un bon scénario où un environnement de staging peut s’avérer utile.
Comme nous l’avons fait plus tôt, vous devrez vous connecter à PhpMyAdmin. Cliquez sur votre base de données à gauche, puis sur l’onglet SQL. Ensuite, entrez la commande suivante et appuyez sur « Exécuter ».
SELECT * FROM `wp_options` WHERE `autoload` = 'yes'Vous devrez peut-être modifier la requête ci-dessus si votre site WordPress utilise un préfixe différent de wp_. Ceci vous montrera toutes les données de la table wp_options qui sont définies avec « autoload » sur « Yes ».
En descendant dans les lignes, nous voyons toutes sortes d’extensions qui ne sont plus installés ou utilisés par le site. Ce n’est qu’un exemple que nous allons utiliser, mais dans ce cas, nous avons remarqué un tas de ligne de Jetpack. Jetpack n’était plus utilisé sur le site concerné.
Il est toujours bon de vérifier la documentation du développeur de l’extension, car ils ont parfois la possibilité de nettoyer les tables qu’ils ont laissées derrière eux. Dans ce cas, il est parfois plus sûr et plus facile de réinstaller l’extension, de vérifier leurs options de nettoyage automatisé, puis de retirer l’extension correctement. Cependant, nous vous montrerons comment nettoyer les tables manuellement.
Ainsi, dans ce cas, nous lançons la requête suivante pour trouver les données chargées automatiquement dans la table wp_options de l’extension Jetpack. Pour modifier la requête avec la vôtre, remplacez simplement %jetpack%.
SELECT *
FROM `wp_options`
WHERE `autoload` = 'yes'
AND `option_name` LIKE '%jetpack%'Vous pouvez ensuite sélectionner toutes les lignes et cliquer sur « Supprimer ».
Ou vous pouvez exécuter la commande suivante :
DELETE
FROM `wp_options`
WHERE `autoload` = 'yes'
AND `option_name` LIKE '%jetpack%'
Vous pouvez ensuite répéter l’opération pour des données chargées automatiquement supplémentaires laissées par les extensions et les thèmes dans votre table wp_options.
Nettoyage des transients
À moins que vous n’utilisiez un cache d’objet, WordPress stocke les transients dans la table wp_options. En général, on leur donne une date de péremption et ils devraient disparaître avec le temps. Cependant, ce n’est pas toujours le cas. Nous avons vu quelques bases de données où il y a des milliers d’anciens transients. Il est également important de noter que les transients ne sont pas chargés automatiquement par défaut. Vous pouvez utiliser une requête comme celle qui suit pour voir s’il y a des données transient chargées automatiquement.
SELECT *
FROM `wp_options`
WHERE `autoload` = 'yes'
AND `option_name` LIKE '%transient%'Cependant, une meilleure et plus sûre option serait d’utiliser une extension gratuite comme Transient Cleaner qui ne peut nettoyer que les transients expirés de votre table wp_options.
Nettoyage des sessions WordPress
Un autre problème courant que nous avons vu est que parfois les tâches cron se désynchronisent ou ne se lancent pas correctement et par conséquent les sessions ne sont pas nettoyées. Vous pouvez finir par avoir des tonnes de lignes _wp_session_ dans votre base de données. Dans l’exemple ci-dessous, le site en question s’est terminé avec plus de 3 millions de lignes dans leur table wp_options. Et la taille de la table était passée à plus de 600 Mo.
Vous pouvez utiliser une requête comme celle qui suit pour voir si vous rencontrez ce problème :
SELECT *
FROM `wp_options`
WHERE `option_name` LIKE '_wp_session_%'
Dans la plupart des cas, vous pouvez les supprimer en toute sécurité (comme une tâche cron devrait l’avoir fait) avec la commande suivante:
DELETE FROM `wp_options`
WHERE `option_name` LIKE '_wp_session_%'Après avoir nettoyé toutes les autres lignes, la table _wp_session_ rows comptait moins de 1 000 lignes et sa taille a été réduite à 11 Mo.
Cela a également corrigé les pics que le site obtenait dans MySQL.
Ajouter un index au chargement automatique
Et si le nettoyage de votre table wp_options n’était pas suffisant, vous pouvez essayer d’ajouter un « index » au champ de chargement automatique. Cela peut essentiellement l’aider à être recherché plus efficacement. L’incroyable équipe de 10up a réalisé des scénarios de test sur une table wp_options avec un nombre typique d’enregistrements chargés automatiquement pour montrer comment l’ajout d’un index de chargement automatique aux requêtes wp_options peut booster les performances.
Nous recommandons également de consulter ces deux ressources supplémentaires de WP Bullet :
- Comment ajouter l’index MySQL à la table wp_options ?
- Nettoyage de la table wp_options à l’aide de WP-CLI
Pour encore plus de conseils d’optimisation, jetez un coup d’œil à notre guide détaillé : Comment accélérer votre site WordPress (Guide ultime)
