Optimiser un thème WordPress : réduire les requêtes SQL inutiles

Un thème WordPress peut sembler léger côté design, mais lourd côté base de données. Quelques appels mal placés, plusieurs boucles secondaires, des widgets trop bavards, et le nombre de requêtes SQL grimpe vite.

Sur une ancienne optimisation de thème, j’avais gagné une trentaine de requêtes SQL en passant d’environ 52 requêtes à 21. C’était déjà énorme. Aujourd’hui, l’approche reste la même : mesurer, identifier les requêtes inutiles, puis corriger proprement. La différence, c’est que l’on dispose de meilleurs outils et de meilleures pratiques.

Voici une méthode moderne pour optimiser un thème WordPress et réduire ses requêtes SQL sans bricoler le cœur, sans casser les plugins, et sans transformer le template en musée de valeurs codées en dur.

Commencer par mesurer les requêtes SQL

Avant d’optimiser, mesurez. Sinon, vous risquez d’améliorer une partie du thème qui ne ralentit rien, pendant qu’une requête absurde continue de faire du rameur dans la cave.

Installez d’abord Query Monitor sur un environnement de développement ou de staging. Il affiche le nombre de requêtes SQL, leur durée, leur origine, les hooks, les scripts, les styles, les erreurs PHP et beaucoup d’autres informations utiles.

Regardez surtout :

• le nombre total de requêtes SQL ;
• les requêtes lentes ;
• les requêtes dupliquées ;
• les requêtes déclenchées par le thème ;
• les requêtes déclenchées par les widgets ;
• les requêtes déclenchées dans header.php, footer.php, sidebar.php ou les template parts ;
• les requêtes liées aux menus, aux metas, aux termes et aux options.

Le but n’est pas d’obtenir zéro requête. WordPress a besoin de la base. Le but est de supprimer les requêtes inutiles, répétées, ou déclenchées trop tôt.

Activer SAVEQUERIES uniquement en développement

Pour analyser les requêtes SQL sans plugin, WordPress peut stocker les requêtes exécutées si SAVEQUERIES est actif. Ajoutez ceci dans wp-config.php, uniquement en développement :

define( 'SAVEQUERIES', true );Code language: JavaScript (javascript)

Ensuite, vous pouvez inspecter $wpdb->queries. Exemple rapide dans un template de développement :

<?php
global $wpdb;

if ( defined( 'SAVEQUERIES' ) && SAVEQUERIES && current_user_can( 'manage_options' ) ) {
	printf(
		'<pre>%s</pre>',
		esc_html( print_r( $wpdb->queries, true ) )
	);
}Code language: HTML, XML (xml)

Ne laissez pas SAVEQUERIES actif en production. Il ajoute de la mémoire et du travail sur chaque requête. C’est un outil de diagnostic, pas une décoration permanente.

Identifier les appels WordPress répétés dans le thème

Les vieux thèmes WordPress appelaient souvent les mêmes fonctions plusieurs fois par page. Certaines fonctions sont légères. D’autres peuvent déclencher des requêtes selon le contexte, les caches et les plugins actifs.

Cherchez notamment les appels répétés à :

• get_option() ;
• get_bloginfo() ;
• get_categories() ;
• get_terms() ;
• get_pages() ;
• wp_get_nav_menu_items() ;
• get_post_meta() dans une boucle ;
• get_the_terms() dans une boucle ;
• WP_Query dans plusieurs template parts.

Une requête isolée n’est pas forcément grave. Une requête répétée sur chaque article d’une boucle, elle, peut devenir très coûteuse. C’est là que les choses se gâtent gentiment.

Ne pas tout remplacer par des valeurs statiques

Une ancienne technique consistait à remplacer certains appels dynamiques par des valeurs statiques. Par exemple, remplacer :

<?php echo esc_url( home_url( '/' ) ); ?>Code language: HTML, XML (xml)

par :

https://www.example.com/Code language: JavaScript (javascript)

Ce n’est pas toujours une bonne idée. Si le site change de domaine, passe en staging, utilise un multisite, ou force une URL différente selon l’environnement, votre valeur statique devient une dette technique.

En revanche, vous pouvez stocker la valeur une seule fois dans une variable locale si vous l’utilisez plusieurs fois dans le template :

<?php
$home_url = home_url( '/' );
?>

<a href="<?php echo esc_url( $home_url ); ?>" rel="home">
	<?php echo esc_html( get_bloginfo( 'name' ) ); ?>
</a>Code language: HTML, XML (xml)

C’est un bon compromis : le thème reste portable, mais vous évitez les appels répétés dans le même fichier.

Optimiser les boucles secondaires WP_Query

Les boucles secondaires sont l’une des causes les plus fréquentes de requêtes SQL inutiles dans un thème. Exemple typique : “articles récents”, “articles populaires”, “articles de la même catégorie”, “à lire aussi”, “derniers produits”.

Quand vous créez une WP_Query, dites explicitement à WordPress ce dont vous avez besoin. Si vous n’avez pas besoin de pagination, ajoutez no_found_rows. Si vous n’avez pas besoin des metas ou termes, désactivez leur préchargement.

<?php
$related_posts = new WP_Query(
	array(
		'post_type'              => 'post',
		'post_status'            => 'publish',
		'posts_per_page'         => 3,
		'ignore_sticky_posts'    => true,
		'no_found_rows'          => true,
		'update_post_meta_cache' => false,
		'update_post_term_cache' => false,
	)
);

if ( $related_posts->have_posts() ) : ?>
	<ul>
		<?php while ( $related_posts->have_posts() ) : $related_posts->the_post(); ?>
			<li>
				<a href="<?php the_permalink(); ?>">
					<?php the_title(); ?>
				</a>
			</li>
		<?php endwhile; ?>
	</ul>
<?php endif; ?>

<?php wp_reset_postdata(); ?>Code language: HTML, XML (xml)

Dans cet exemple, on affiche seulement trois liens. On n’a pas besoin de pagination. On n’a pas besoin de metas. On n’a pas besoin des termes. On demande donc moins de travail à WordPress.

Utiliser fields => ids quand les IDs suffisent

Si vous avez seulement besoin des IDs, utilisez fields => ids. WordPress récupérera moins de données.

<?php
$post_ids = get_posts(
	array(
		'post_type'              => 'post',
		'post_status'            => 'publish',
		'posts_per_page'         => 10,
		'fields'                 => 'ids',
		'no_found_rows'          => true,
		'ignore_sticky_posts'    => true,
		'update_post_meta_cache' => false,
		'update_post_term_cache' => false,
	)
);Code language: HTML, XML (xml)

Cette approche est utile pour construire une liste, alimenter une autre requête, exclure certains articles, ou faire un traitement léger sans charger des objets WP_Post complets.

Éviter query_posts()

Si votre thème utilise encore query_posts(), remplacez-le. Cette fonction modifie la requête principale et crée souvent plus de problèmes qu’elle n’en résout.

Pour modifier la requête principale, utilisez plutôt pre_get_posts. Exemple : afficher 12 articles sur les archives de catégorie.

<?php
add_action( 'pre_get_posts', 'skyminds_adjust_category_archive_query' );

/**
 * Adjust the main query on category archives.
 *
 * @param WP_Query $query Current query instance.
 *
 * @return void
 */
function skyminds_adjust_category_archive_query( WP_Query $query ): void {
	if ( is_admin() || ! $query->is_main_query() || ! $query->is_category() ) {
		return;
	}

	$query->set( 'posts_per_page', 12 );
	$query->set( 'ignore_sticky_posts', true );
}Code language: HTML, XML (xml)

Pour une boucle secondaire, utilisez WP_Query ou get_posts(). Pour la requête principale, modifiez-la avant son exécution avec pre_get_posts. Chacun son métier.

Éviter les requêtes dans la boucle

Le piège classique : appeler des metas ou des termes dans une boucle sans cache adapté.

<?php while ( have_posts() ) : the_post(); ?>
	<?php $rating = get_post_meta( get_the_ID(), '_rating', true ); ?>
	<?php $terms  = get_the_terms( get_the_ID(), 'category' ); ?>
<?php endwhile; ?>Code language: HTML, XML (xml)

Ce code peut être acceptable si WordPress a déjà préchargé les metas et termes. Mais dans une boucle custom où vous avez désactivé les caches, ou dans un contexte complexe, cela peut multiplier les requêtes.

Si vous avez besoin des metas et termes, ne désactivez pas leur cache dans la requête :

<?php
$query = new WP_Query(
	array(
		'post_type'              => 'post',
		'post_status'            => 'publish',
		'posts_per_page'         => 10,
		'no_found_rows'          => true,
		'update_post_meta_cache' => true,
		'update_post_term_cache' => true,
	)
);Code language: HTML, XML (xml)

La bonne optimisation n’est pas de désactiver tous les caches. C’est de désactiver uniquement ce que vous n’utilisez pas.

Mettre en cache les fragments coûteux du thème

Certains blocs du thème changent rarement : liste d’articles populaires, footer enrichi, menu secondaire calculé, nuage de tags, liste de catégories, derniers contenus d’une rubrique, etc.

Vous pouvez les mettre en cache avec un transient. Exemple avec une liste d’articles récents :

<?php
/**
 * Render and cache recent post links.
 *
 * @return string Cached HTML output.
 */
function skyminds_get_cached_recent_posts_markup(): string {
	$cache_key = 'skyminds_recent_posts_markup_v1';
	$markup    = get_transient( $cache_key );

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

	$posts = 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,
		)
	);

	if ( empty( $posts ) ) {
		return '';
	}

	$items = '';

	foreach ( $posts as $post_id ) {
		$items .= sprintf(
			'<li><a href="%s">%s</a></li>',
			esc_url( get_permalink( $post_id ) ),
			esc_html( get_the_title( $post_id ) )
		);
	}

	$markup = sprintf( '<ul class="recent-posts">%s</ul>', $items );

	set_transient( $cache_key, $markup, HOUR_IN_SECONDS );

	return $markup;
}Code language: HTML, XML (xml)

Vous pouvez ensuite l’afficher dans le thème :

<?php echo wp_kses_post( skyminds_get_cached_recent_posts_markup() ); ?>Code language: HTML, XML (xml)

Ce cache évite de recalculer le même fragment à chaque page vue. Sur un site avec cache objet persistant, les transients peuvent devenir encore plus intéressants.

Invalider le cache quand un article change

Un cache sans invalidation finit toujours par mentir. Supprimez donc le transient quand un article est créé, modifié ou supprimé.

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

/**
 * Clear cached recent posts markup.
 *
 * @return void
 */
function skyminds_clear_recent_posts_markup_cache(): void {
	delete_transient( 'skyminds_recent_posts_markup_v1' );
}Code language: HTML, XML (xml)

Le cache devient alors fiable : il accélère le thème, mais il se rafraîchit quand le contenu change.

Éviter get_posts() en cascade dans plusieurs template parts

Un thème moderne découpe souvent l’affichage en template parts. C’est bien. Mais si chaque template part lance sa propre requête, la page devient vite lourde.

Exemple typique :

• header.php lance une requête pour le dernier article ;
• sidebar.php lance une requête pour les articles populaires ;
• footer.php lance une requête pour les catégories ;
• un template part lance une requête pour les articles liés ;
• un bloc custom lance encore une requête pour les mêmes données.

La solution : centraliser les données ou les fragments. Une fonction de thème peut récupérer les données une fois, les cacher, puis les partager. Moins spectaculaire, mais beaucoup plus propre.

Préférer les menus WordPress bien cachés aux listes dynamiques bricolées

Certains vieux thèmes construisaient leur navigation avec get_pages(), get_categories() ou des requêtes custom. Aujourd’hui, il vaut mieux utiliser le système de menus WordPress ou les blocs de navigation quand c’est pertinent.

Exemple classique :

<?php
wp_nav_menu(
	array(
		'theme_location' => 'primary',
		'container'      => 'nav',
		'container_class' => 'site-navigation',
		'fallback_cb'    => false,
	)
);Code language: HTML, XML (xml)

Les menus WordPress sont déjà conçus pour être réutilisables et mis en cache par WordPress. Une requête maison pour reconstruire la navigation à chaque page est rarement une victoire.

Optimiser les sidebars et widgets

Les sidebars historiques peuvent être très bavardes : derniers articles, archives, catégories, commentaires récents, tags, widgets sociaux, formulaires, publicités, shortcodes, embeds.

Avec Query Monitor, vérifiez les requêtes déclenchées par chaque widget. Supprimez les widgets inutiles, remplacez les listes dynamiques par des menus statiques quand le contenu change rarement, et mettez en cache les fragments coûteux.

Si vous utilisez encore des shortcodes dans les widgets ou template parts, relisez aussi le guide sur l’exécution d’un shortcode dans une fonction PHP. Un shortcode appelé partout peut vite devenir une usine à requêtes si son callback est mal écrit.

Surveiller les options autoloadées

Chaque requête WordPress charge les options autoloadées. Si wp_options contient trop d’options lourdes en autoload, chaque page paie l’addition.

Pour auditer la taille des options autoloadées :

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

Cette requête ne corrige rien. Elle identifie les suspects. Ensuite, vérifiez à quel plugin, thème ou ancien snippet appartient chaque option avant de modifier quoi que ce soit.

Pour prolonger cet audit, vous pouvez lire l’article sur l’identification des options de plugins dans la base WordPress. C’est souvent le chaînon manquant entre “le site est lent” et “voici l’option qui gonfle tout”.

Éviter les requêtes SQL directes dans le thème

Un thème ne devrait presque jamais lancer des requêtes SQL directes. WordPress fournit déjà des APIs : WP_Query, get_posts(), get_terms(), get_users(), Metadata API, Options API, Transients API.

Si vous devez vraiment utiliser $wpdb, préparez toujours les requêtes avec $wpdb->prepare() quand des valeurs dynamiques entrent dans la requête.

<?php
global $wpdb;

$author_id = 123;

$count = (int) $wpdb->get_var(
	$wpdb->prepare(
		"
		SELECT COUNT(ID)
		FROM {$wpdb->posts}
		WHERE post_author = %d
		AND post_type = %s
		AND post_status = %s
		",
		$author_id,
		'post',
		'publish'
	)
);Code language: HTML, XML (xml)

Même là, demandez-vous si une API WordPress ne ferait pas mieux le travail. Le SQL direct est parfois nécessaire. Mais dans un thème, c’est souvent une odeur de code.

Utiliser un cache objet persistant

Réduire les requêtes côté thème est utile. Mais sur un site dynamique, un cache objet persistant peut faire une grosse différence. Redis ou Memcached permettent de conserver en mémoire des résultats que WordPress n’a pas besoin de recalculer à chaque requête.

Pour vérifier le type de cache objet avec WP-CLI :

wp cache type

Pour vider le cache objet :

wp cache flush

Si vous utilisez Redis, vous pouvez consulter le guide sur l’installation de Redis pour accélérer WordPress sous Debian. Le thème doit rester sobre, mais le serveur peut aussi aider intelligemment.

Ne pas optimiser uniquement le nombre de requêtes

Le nombre de requêtes SQL compte, mais il ne dit pas tout. Une page avec 25 petites requêtes rapides peut être plus performante qu’une page avec 8 requêtes énormes, non indexées, et lentes.

Regardez donc aussi :

• la durée totale des requêtes SQL ;
• les requêtes lentes ;
• les requêtes dupliquées ;
• les requêtes sans index ;
• le temps PHP total ;
• le cache hit ratio si Redis est actif ;
• le Time To First Byte ;
• les variations entre page anonyme et page connectée.

Pour analyser le serveur dans son ensemble, l’article sur l’analyse des performances d’un serveur dédié complète naturellement cette optimisation côté thème.

Tester avec WP-CLI Profile

Pour aller plus loin, WP-CLI peut profiler le chargement de WordPress avec le package wp profile. Il permet d’identifier les hooks, plugins et thèmes qui consomment du temps pendant le bootstrap.

Si vous l’avez installé, testez par exemple :

wp profile stage --all
wp profile hook --all

C’est particulièrement utile quand Query Monitor vous montre un problème, mais que vous voulez confirmer où le temps part pendant le chargement WordPress.

Pour cette partie, vous pouvez aussi consulter le guide sur l’audit des performances WordPress avec wp profile.

Comparer avant et après optimisation

Ne vous contentez pas de “ça semble plus rapide”. Notez les chiffres avant et après.

• nombre de requêtes SQL ;
• durée totale SQL ;
• requête la plus lente ;
• mémoire PHP ;
• temps de génération serveur ;
• TTFB ;
• cache hits/misses ;
• résultat en navigation anonyme ;
• résultat en utilisateur connecté.

Sur un site WordPress réel, optimisez toujours sur une page représentative : page d’accueil, article, archive de catégorie, recherche, page produit ou panier. Une optimisation visible uniquement sur une page que personne ne visite, c’est du tuning de garage.

Checklist d’optimisation du thème

• Mesurer avec Query Monitor sur staging.
• Repérer les requêtes SQL lentes ou dupliquées.
• Identifier les requêtes déclenchées par le thème.
• Supprimer les appels répétés dans les templates.
• Optimiser les boucles secondaires avec no_found_rows.
• Désactiver les caches meta/term uniquement si vous ne les utilisez pas.
• Utiliser fields => ids quand les IDs suffisent.
• Remplacer query_posts() par pre_get_posts ou WP_Query.
• Mettre en cache les fragments coûteux avec des transients.
• Invalider les transients quand les contenus changent.
• Éviter les requêtes SQL directes dans le thème.
• Auditer les options autoloadées.
• Activer un cache objet persistant si le site le justifie.
• Comparer les métriques avant et après.

Commandes utiles

Compter les requêtes avec Query Monitor reste le plus confortable. Pour les audits côté base, gardez aussi ces commandes.

Voir les plus grosses options autoloadées :

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

Vérifier la base :

wp db check

Voir le type de cache objet :

wp cache type

Purger le cache objet :

wp cache flush

Profiler WordPress si wp profile est installé :

wp profile stage --all
wp profile hook --all

Exemple complet : articles liés optimisés et mis en cache

Voici un exemple réutilisable pour afficher trois articles liés de la même catégorie, avec une requête optimisée et un transient par article.

<?php
/**
 * Render cached related posts markup for the current post.
 *
 * @param int $post_id Current post ID.
 *
 * @return string Related posts HTML.
 */
function skyminds_get_related_posts_markup( int $post_id ): string {
	$post_id = absint( $post_id );

	if ( 0 === $post_id ) {
		return '';
	}

	$cache_key = 'skyminds_related_posts_' . $post_id;
	$markup    = get_transient( $cache_key );

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

	$category_ids = wp_get_post_categories( $post_id );

	if ( empty( $category_ids ) ) {
		return '';
	}

	$related_posts = get_posts(
		array(
			'post_type'              => 'post',
			'post_status'            => 'publish',
			'posts_per_page'         => 3,
			'post__not_in'           => array( $post_id ),
			'category__in'           => array_map( 'absint', $category_ids ),
			'fields'                 => 'ids',
			'no_found_rows'          => true,
			'ignore_sticky_posts'    => true,
			'update_post_meta_cache' => false,
			'update_post_term_cache' => false,
		)
	);

	if ( empty( $related_posts ) ) {
		return '';
	}

	$items = '';

	foreach ( $related_posts as $related_post_id ) {
		$items .= sprintf(
			'<li><a href="%s">%s</a></li>',
			esc_url( get_permalink( $related_post_id ) ),
			esc_html( get_the_title( $related_post_id ) )
		);
	}

	$markup = sprintf(
		'<aside class="related-posts" aria-label="%s"><h2>%s</h2><ul>%s</ul></aside>',
		esc_attr__( 'Related posts', 'skyminds' ),
		esc_html__( 'À lire aussi', 'skyminds' ),
		$items
	);

	set_transient( $cache_key, $markup, 12 * HOUR_IN_SECONDS );

	return $markup;
}

/**
 * Clear related posts cache when a post is updated.
 *
 * @param int $post_id Post ID.
 *
 * @return void
 */
function skyminds_clear_related_posts_cache( int $post_id ): void {
	delete_transient( 'skyminds_related_posts_' . absint( $post_id ) );
}
add_action( 'save_post_post', 'skyminds_clear_related_posts_cache' );
add_action( 'deleted_post', 'skyminds_clear_related_posts_cache' );Code language: HTML, XML (xml)

Dans votre template single :

<?php
echo wp_kses_post( skyminds_get_related_posts_markup( get_the_ID() ) );
?>Code language: HTML, XML (xml)

Ce code évite la pagination inutile, récupère seulement les IDs, désactive les caches non utilisés, échappe les sorties, puis met le rendu en cache. C’est exactement le genre d’optimisation qui reste saine dans le temps.

Conclusion

Optimiser un thème WordPress ne consiste pas à supprimer des requêtes au hasard. Il faut d’abord mesurer, puis corriger les vrais points chauds : boucles secondaires, appels répétés, widgets bavards, options autoloadées, shortcodes coûteux et fragments non cachés.

Le gain peut être spectaculaire. Passer de 52 à 21 requêtes SQL reste une vraie amélioration. Mais l’objectif moderne ne doit pas être uniquement “moins de requêtes”. Il doit être : moins de requêtes inutiles, moins de duplication, moins de temps SQL, et un thème plus prévisible.

Un bon thème WordPress ne se contente pas d’être joli. Il doit aussi savoir se taire quand la base de données n’a rien à dire.

Sources

• Query Monitor — WordPress plugin
• WordPress Developer Resources — WP_Query
• WordPress Developer Resources — Transients API
• WordPress Developer Blog — An introduction to the Transients API
• WordPress Developer Resources — pre_get_posts
• WordPress Developer Resources — wpdb::prepare()

Report a typo