Un plugin WordPress peut ajouter une fonctionnalité indispensable. Il peut aussi ajouter dix requêtes SQL sur chaque page, trois appels AJAX, une option autoloadée énorme, un cron bavard, et une petite migraine en cadeau.

Réduire les requêtes SQL des plugins ne consiste pas à supprimer tout ce qui bouge. Il faut mesurer, identifier les vrais coupables, comprendre pourquoi les requêtes partent en vrille, puis décider : configurer, remplacer, optimiser, mettre en cache ou supprimer.

Voici une méthode moderne pour analyser et optimiser les requêtes SQL générées par les plugins WordPress, sans casser le site et sans partir en chasse au plugin au hasard.

Pourquoi les plugins ajoutent des requêtes SQL ?

Un plugin WordPress peut avoir besoin de la base de données pour beaucoup de raisons légitimes :

• lire ses réglages ;
• charger des données personnalisées ;
• récupérer des métadonnées ;
• afficher des contenus liés ;
• gérer des formulaires ;
• afficher des produits WooCommerce ;
• charger des règles SEO, sécurité ou cache ;
• traiter des tâches planifiées ;
• stocker des logs, statistiques ou événements.

Le problème commence quand ces requêtes sont trop nombreuses, trop lourdes, dupliquées, exécutées sur toutes les pages, ou lancées même quand la fonctionnalité n’est pas utilisée.

Ne pas confondre nombre de requêtes et lenteur réelle

Le nombre de requêtes SQL reste un bon indicateur, mais il ne dit pas tout. Une page avec 30 petites requêtes rapides peut être plus saine qu’une page avec 8 requêtes très lentes.

Surveillez plutôt plusieurs métriques ensemble :

• nombre total de requêtes SQL ;
• temps total passé en SQL ;
• requêtes lentes ;
• requêtes dupliquées ;
• plugin ou composant responsable ;
• requêtes lancées sur toutes les pages ;
• impact sur utilisateur connecté et anonyme ;
• effet du cache objet ;
• impact des requêtes AJAX et REST.

Le but n’est pas de gagner un concours de “moins de requêtes”. Le but est de supprimer le travail inutile et de raccourcir le temps serveur.

Étape 1 : installer Query Monitor sur staging

Le premier outil à utiliser est Query Monitor. Il permet de voir les requêtes SQL, leur durée, leur origine, les requêtes dupliquées, les erreurs PHP, les appels HTTP, les hooks, les scripts et les styles chargés.

Installez-le sur un environnement de développement ou de staging :

wp plugin install query-monitor --activate

Ensuite, ouvrez une page représentative du site, puis regardez l’entrée Query Monitor dans la barre d’administration.

Analysez au minimum :

• Database Queries pour les requêtes SQL ;
• Duplicate Queries pour les requêtes répétées ;
• Queries by Component pour identifier les plugins responsables ;
• HTTP API Calls pour les appels externes ;
• Hooks & Actions pour les callbacks coûteux ;
• Scripts & Styles pour les assets chargés par les plugins.

Ne testez pas uniquement la page d’accueil. Testez aussi un article, une archive, une recherche, une page produit, le panier, le checkout, une page compte, et une page vue par utilisateur connecté.

Étape 2 : comparer avec et sans certains plugins

Une méthode simple consiste à mesurer une page, désactiver un plugin suspect sur staging, puis mesurer à nouveau. Pas en production. Pas un vendredi soir. Pas avec WooCommerce pendant les soldes.

Avec WP-CLI, listez les plugins actifs :

wp plugin list --status=active --fields=name,status,version

Désactivez temporairement un plugin sur staging :

wp plugin deactivate nom-du-plugin

Réactivez-le après test :

wp plugin activate nom-du-plugin

Notez avant/après :

• nombre de requêtes ;
• temps SQL total ;
• mémoire PHP ;
• temps de génération ;
• requêtes lentes ;
• requêtes dupliquées ;
• fonctionnalité cassée ou non.

Un plugin peut ajouter beaucoup de requêtes mais fournir une fonctionnalité essentielle. L’objectif n’est pas forcément de le supprimer. L’objectif est de décider avec des chiffres.

Étape 3 : repérer les requêtes dupliquées

Les requêtes dupliquées sont souvent le signe d’un plugin qui redemande plusieurs fois la même donnée pendant une seule page vue.

Exemples classiques :

• lecture répétée de la même option ;
• même WP_Query dans plusieurs widgets ;
• même liste de termes recalculée plusieurs fois ;
• mêmes métadonnées relues dans une boucle ;
• même configuration chargée dans plusieurs callbacks ;
• plugin qui ne garde pas ses résultats en mémoire locale.

Dans Query Monitor, regardez le composant responsable. Si la même requête vient toujours du même plugin, vous avez une piste claire.

Si vous développez le plugin, corrigez le code. Si c’est un plugin tiers, cherchez un réglage, contactez l’auteur, remplacez le plugin, ou limitez son chargement.

Étape 4 : repérer les requêtes lentes

Une requête lente peut venir d’un mauvais index, d’un meta_query trop large, d’un tri coûteux, d’une table énorme, ou d’un plugin qui fait des recherches dans des champs non adaptés.

Les coupables fréquents :

• LIKE '%terme%' sur de grosses tables ;
• ORDER BY RAND() ;
• meta_query sur des milliers de contenus ;
• tri sur meta_value non indexé ;
• requêtes sur wp_postmeta ou wp_options gonflées ;
• logs de plugins jamais nettoyés ;
• tables WooCommerce ou Action Scheduler trop volumineuses.

Une requête lente répétée sur chaque page vue mérite une attention immédiate. Une requête lente dans l’admin, lancée une fois par mois, peut attendre. Priorisez avec le trafic réel.

Étape 5 : nettoyer les plugins inutiles ou redondants

Le meilleur plugin SQL est parfois celui que vous supprimez. Faites un audit simple :

• plugins désactivés depuis des mois ;
• plugins dont la fonctionnalité existe maintenant dans WordPress ;
• plugins remplacés par le thème ;
• plugins doublons ;
• anciens constructeurs ou widgets inutilisés ;
• plugins d’analytics qui stockent trop en base ;
• plugins de sécurité qui loggent trop ;
• plugins de formulaire gardant trop d’entrées ;
• plugins WooCommerce inutilisés.

Désactivez d’abord sur staging. Vérifiez le front, l’admin, les formulaires, WooCommerce, les emails et les tâches cron. Puis seulement, supprimez le plugin si tout est bon.

Si un plugin n’apparaît pas ou semble mal installé, l’article sur les plugins absents de la liste WordPress peut aider à diagnostiquer l’installation.

Étape 6 : auditer les options autoloadées

Les options autoloadées sont chargées à chaque requête WordPress. Certains plugins stockent trop de données en autoload : réglages énormes, caches sérialisés, logs, anciennes configurations, données temporaires mal nettoyées.

Listez les plus grosses options autoloadées :

wp db query "
SELECT
	option_name,
	LENGTH(option_value) AS size_bytes,
	autoload
FROM wp_options
WHERE autoload IN ('yes', 'on', 'auto-on', 'auto')
ORDER BY size_bytes DESC
LIMIT 30;
"

Ensuite, identifiez le plugin responsable. Ne supprimez pas une option parce qu’elle est grosse. Vérifiez son rôle, le plugin qui l’a créée, et le risque fonctionnel.

Pour prolonger cet audit, consultez l’article sur l’identification des options de plugins dans la base WordPress.

Étape 7 : vérifier les tables créées par les plugins

Beaucoup de plugins créent leurs propres tables : formulaires, sécurité, logs, analytics, WooCommerce, membership, LMS, newsletters, backups, cache, redirections, SEO, automatisations.

Listez les plus grosses tables de la base :

wp db query "
SELECT
	table_name,
	ROUND((data_length + index_length) / 1024 / 1024, 2) AS size_mb,
	table_rows
FROM information_schema.TABLES
WHERE table_schema = DATABASE()
ORDER BY size_mb DESC
LIMIT 30;
"

Les tables énormes ne sont pas forcément un problème, mais elles méritent une vérification. Une table de commandes WooCommerce volumineuse est normale. Une table de logs d’un vieux plugin désinstallé depuis trois ans, beaucoup moins.

Étape 8 : surveiller les tâches cron des plugins

Un plugin peut être très discret en front-end, mais très coûteux en tâche planifiée. C’est fréquent avec les plugins de sauvegarde, sécurité, synchronisation, newsletter, import, SEO, analytics ou WooCommerce.

Listez les tâches cron WordPress :

wp cron event list --fields=hook,next_run_relative,recurrence --format=table

Filtrez par plugin si le hook est identifiable :

wp cron event list | grep -i plugin

Si un plugin lance des tâches très fréquentes, vérifiez ses réglages. Un scan toutes les minutes, un import trop agressif ou une purge cache mal réglée peut charger inutilement MySQL.

Pour l’analyse serveur plus large, consultez aussi l’article sur l’analyse des performances d’un serveur dédié.

Étape 9 : vérifier AJAX et REST API

Certains plugins ne chargent pas beaucoup de requêtes pendant le rendu initial, mais déclenchent ensuite des appels AJAX ou REST coûteux.

Surveillez dans DevTools :

• /wp-admin/admin-ajax.php ;
• /wp-json/ ;
• ?wc-ajax=... ;
• requêtes de formulaires ;
• requêtes de filtres produits ;
• requêtes de recherche instantanée ;
• requêtes de tracking ou stats.

Un plugin peut sembler léger dans Query Monitor au chargement initial, puis envoyer des requêtes coûteuses après coup. Testez avec l’onglet Réseau ouvert, surtout sur les pages WooCommerce et formulaires.

Optimiser un plugin que vous développez

Si vous contrôlez le plugin, vous pouvez corriger le problème à la source. Les optimisations les plus fréquentes sont simples.

• Ne chargez les requêtes que sur les pages concernées.
• Évitez les requêtes dans les boucles.
• Évitez les requêtes identiques répétées.
• Cachez les résultats coûteux.
• Utilisez les APIs WordPress avant le SQL direct.
• Préparez toujours les requêtes SQL dynamiques.
• Ne stockez pas de gros objets en autoload.
• Nettoyez vos logs et données temporaires.

Optimiser WP_Query dans un plugin

Quand un plugin lance une requête secondaire, il doit demander uniquement ce dont il a besoin.

Exemple pour récupérer seulement quelques IDs d’articles :

<?php
/**
 * Get recent published post IDs with a lightweight query.
 *
 * @return array<int, int> Post IDs.
 */
function skyminds_plugin_get_recent_post_ids(): array {
	$post_ids = get_posts(
		array(
			'post_type'              => 'post',
			'post_status'            => 'publish',
			'posts_per_page'         => 5,
			'fields'                 => 'ids',
			'no_found_rows'          => true,
			'ignore_sticky_posts'    => true,
			'update_post_meta_cache' => false,
			'update_post_term_cache' => false,
		)
	);

	return array_map( 'absint', $post_ids );
}

Ici, on évite la pagination inutile, on récupère seulement les IDs, et on ne précharge pas les metas ou termes si le plugin ne les utilise pas.

Mettre en cache un résultat coûteux avec un transient

Si un plugin calcule souvent la même donnée, utilisez un transient. C’est utile pour les listes, statistiques, appels API, données agrégées, menus dynamiques, exports partiels ou blocs coûteux.

<?php
/**
 * Get cached plugin statistics.
 *
 * @return array<string, int> Statistics.
 */
function skyminds_plugin_get_cached_stats(): array {
	$cache_key = 'skyminds_plugin_stats_v1';
	$stats     = get_transient( $cache_key );

	if ( is_array( $stats ) ) {
		return $stats;
	}

	global $wpdb;

	$stats = array(
		'published_posts' => (int) $wpdb->get_var(
			"SELECT COUNT(ID) FROM {$wpdb->posts} WHERE post_type = 'post' AND post_status = 'publish'"
		),
	);

	set_transient( $cache_key, $stats, HOUR_IN_SECONDS );

	return $stats;
}

Un transient évite de recalculer la même information à chaque page vue. Mais il doit être invalidé quand les données changent.

<?php
add_action( 'save_post_post', 'skyminds_plugin_clear_stats_cache' );
add_action( 'deleted_post', 'skyminds_plugin_clear_stats_cache' );

/**
 * Clear cached plugin statistics.
 *
 * @return void
 */
function skyminds_plugin_clear_stats_cache(): void {
	delete_transient( 'skyminds_plugin_stats_v1' );
}

Un cache sans invalidation finit par mentir. Et un cache menteur finit toujours par vous rappeler son existence au pire moment.

Utiliser le cache objet WordPress

Pour des données valables seulement pendant l’exécution ou faciles à invalider, utilisez aussi l’Object Cache API.

<?php
/**
 * Get a cached value using the WordPress Object Cache API.
 *
 * @param int $post_id Post ID.
 *
 * @return string Cached value.
 */
function skyminds_plugin_get_cached_value( int $post_id ): string {
	$post_id   = absint( $post_id );
	$cache_key = 'value_' . $post_id;
	$group     = 'skyminds_plugin';

	$cached = wp_cache_get( $cache_key, $group );

	if ( false !== $cached ) {
		return (string) $cached;
	}

	$value = (string) get_post_meta( $post_id, '_skyminds_value', true );

	wp_cache_set( $cache_key, $value, $group, HOUR_IN_SECONDS );

	return $value;
}

Sans cache objet persistant, ce cache vit surtout pendant la requête courante. Avec Redis ou Memcached, il peut éviter des lectures répétées entre plusieurs pages vues.

Pour mettre en place Redis côté WordPress, vous pouvez lire le guide d’installation de Redis pour accélérer WordPress sous Debian.

Éviter les SELECT *

Une mauvaise requête classique consiste à demander toutes les colonnes alors que le plugin n’en utilise qu’une ou deux.

À éviter :

SELECT * FROM wp_users WHERE user_login = 'matt' LIMIT 1

Préférez une requête ciblée :

SELECT ID, user_login, user_email FROM wp_users WHERE user_login = 'matt' LIMIT 1

Et dans un plugin, utilisez $wpdb->prepare() pour toute valeur dynamique :

<?php
global $wpdb;

$user_login = 'matt';

$user = $wpdb->get_row(
	$wpdb->prepare(
		"
		SELECT ID, user_login, user_email
		FROM {$wpdb->users}
		WHERE user_login = %s
		LIMIT 1
		",
		$user_login
	)
);

Demander moins de colonnes ne sauvera pas toujours un site. Mais c’est une base saine, surtout sur des tables volumineuses.

Ne pas lancer un plugin partout si une seule page l’utilise

Un plugin de formulaire n’a pas forcément besoin de charger ses scripts et requêtes sur chaque page. Un plugin de réservation n’a pas besoin d’analyser tout le site si le formulaire n’apparaît que sur une page. Un plugin de slider ne devrait pas charger sa logique sur les articles sans slider.

Si vous développez le plugin, conditionnez vos chargements :

<?php
add_action( 'wp_enqueue_scripts', 'skyminds_plugin_enqueue_assets' );

/**
 * Enqueue plugin assets only when needed.
 *
 * @return void
 */
function skyminds_plugin_enqueue_assets(): void {
	if ( ! is_page( 'contact' ) ) {
		return;
	}

	wp_enqueue_style(
		'skyminds-plugin',
		plugins_url( 'assets/plugin.css', __FILE__ ),
		array(),
		'1.0.0'
	);

	wp_enqueue_script(
		'skyminds-plugin',
		plugins_url( 'assets/plugin.js', __FILE__ ),
		array(),
		'1.0.0',
		true
	);
}

Cette logique ne réduit pas seulement les requêtes SQL. Elle réduit aussi le CSS, le JavaScript, les callbacks, les dépendances, et parfois les appels AJAX.

Cas WooCommerce : attention aux plugins qui cassent le cache

Sur WooCommerce, certains plugins de prix dynamiques, badges, filtres, recherche, personnalisation produit ou panier peuvent ajouter beaucoup de requêtes. Ils peuvent aussi empêcher le cache page de fonctionner correctement.

Testez séparément :

• page boutique ;
• catégorie produit ;
• fiche produit ;
• panier ;
• checkout ;
• compte client ;
• utilisateur anonyme ;
• utilisateur connecté ;
• client avec panier rempli.

WooCommerce a des pages qui doivent rester dynamiques. Mais les archives produits et fiches produit peuvent souvent être optimisées. Pour la maintenance WooCommerce côté base, consultez le guide de mise à jour de la base WooCommerce avec WP-CLI.

Cas formulaires : entrées, uploads et logs

Les plugins de formulaires peuvent stocker beaucoup d’entrées, de fichiers uploadés, de brouillons, de logs, de notifications et de métadonnées.

Vérifiez régulièrement :

• nombre d’entrées stockées ;
• taille des tables du plugin ;
• uploads associés ;
• logs d’erreurs ;
• notifications échouées ;
• règles de rétention.

Pour Gravity Forms, l’article sur la conservation des fichiers uploadés Gravity Forms complète bien cette logique. Les uploads et les entrées doivent avoir une vraie politique de conservation.

Cas SEO : éviter les scans et recalculs permanents

Les plugins SEO peuvent être très efficaces, mais certains modules ajoutent des traitements : analyse de contenu, liens internes, redirections, sitemap, schema, indexables, statistiques, scan d’erreurs.

Gardez seulement les modules utiles. Désactivez les fonctionnalités redondantes. Vérifiez que les sitemaps répondent vite et ne déclenchent pas des requêtes inutiles.

Si vous utilisez The SEO Framework avec nginx, vous pouvez aussi lire le guide de correction des sitemaps TSF en erreur 404 sous nginx.

Quand remplacer un plugin ?

Il ne faut pas réécrire chaque plugin qui ajoute trois requêtes. En revanche, certains signaux justifient un remplacement.

• Le plugin ajoute des requêtes lourdes sur toutes les pages.
• Il charge des données inutiles même quand la fonctionnalité n’est pas affichée.
• Il stocke des logs énormes sans rétention.
• Il duplique des requêtes simples plusieurs dizaines de fois.
• Il n’est plus maintenu.
• Il casse le cache page ou objet.
• Il bloque les performances WooCommerce.
• Il fait la même chose qu’un autre plugin déjà installé.

Un plugin indispensable peut mériter une optimisation. Un plugin marginal qui ralentit tout le site mérite souvent la sortie. Merci pour les services rendus, rideau.

Documenter les résultats avant/après

Pour un site client, notez les chiffres. Cela évite les discussions floues et montre la valeur de l’optimisation.

• page testée ;
• utilisateur anonyme ou connecté ;
• plugins actifs ;
• nombre de requêtes SQL ;
• temps SQL total ;
• requête la plus lente ;
• mémoire PHP ;
• temps serveur ;
• cache actif ou non ;
• plugin modifié, remplacé ou supprimé.

Pour compléter côté thème, lisez aussi l’article sur l’optimisation des requêtes SQL dans un thème WordPress. Plugins et thème doivent être audités ensemble, sinon vous ne voyez qu’une moitié du tableau.

Checklist d’optimisation des requêtes SQL des plugins

• Installer Query Monitor sur staging.
• Tester plusieurs types de pages.
• Comparer utilisateur anonyme et connecté.
• Identifier les requêtes par plugin.
• Repérer les requêtes lentes.
• Repérer les requêtes dupliquées.
• Auditer les options autoloadées.
• Auditer les tables créées par plugins.
• Vérifier les tâches cron.
• Vérifier AJAX et REST API.
• Désactiver les modules inutiles.
• Supprimer les plugins redondants.
• Remplacer les plugins non maintenus.
• Ajouter du cache si vous contrôlez le code.
• Mesurer avant/après.

Commandes utiles

Lister les plugins actifs :

wp plugin list --status=active --fields=name,status,version

Installer Query Monitor :

wp plugin install query-monitor --activate

Voir les plus grosses options autoloadées :

wp db query "
SELECT
	option_name,
	LENGTH(option_value) AS size_bytes,
	autoload
FROM wp_options
WHERE autoload IN ('yes', 'on', 'auto-on', 'auto')
ORDER BY size_bytes DESC
LIMIT 30;
"

Voir les plus grosses tables :

wp db query "
SELECT
	table_name,
	ROUND((data_length + index_length) / 1024 / 1024, 2) AS size_mb,
	table_rows
FROM information_schema.TABLES
WHERE table_schema = DATABASE()
ORDER BY size_mb DESC
LIMIT 30;
"

Lister les tâches cron WordPress :

wp cron event list --fields=hook,next_run_relative,recurrence --format=table

Vérifier le cache objet :

wp cache type

Purger le cache objet :

wp cache flush

Vérifier la base :

wp db check

Sauvegarder avant nettoyage :

wp db export "backup-before-plugin-sql-optimisation-$(date +%F-%H%M%S).sql"

Conclusion

Optimiser les requêtes SQL des plugins WordPress commence par une règle simple : mesurez avant d’agir. Query Monitor permet d’identifier les plugins responsables, les requêtes lentes, les doublons et les composants qui travaillent trop.

Ensuite, agissez selon le cas : supprimer un plugin inutile, désactiver un module, nettoyer des options, purger des logs, ajuster une tâche cron, remplacer un plugin trop lourd, ou corriger le code avec WP_Query, transients et cache objet.

Un bon plugin doit faire son travail, puis se faire oublier. S’il monopolise MySQL sur chaque page vue, il ne s’intègre pas au site : il le squatte.

Sources

• Query Monitor — How to use Query Monitor
• Query Monitor sur WordPress.org
• WordPress Developer Resources — WP_Query
• Make WordPress Core — Improvements to WP_Query performance in WordPress 6.1
• WordPress Developer Resources — Transients API
• WordPress Developer Resources — wpdb::prepare()
• WP-CLI — wp plugin list

Report a typo