Cinq mille termes de taxonomie, répartis sur douze taxonomies personnalisées (matière, usage, compatibilité, certification, et ainsi de suite) : c’est le niveau de segmentation atteint sur un catalogue technique où chaque produit peut être rattaché à plusieurs dizaines de termes simultanément. La question posée par l’équipe cliente était directe : cette segmentation fine est-elle responsable du ralentissement observé sur les pages de filtre ?
La réponse, après analyse, n’était que partiellement affirmative : le nombre de termes en lui-même pèse assez peu ; ce qui ralentit réellement les requêtes, ce sont les jointures répétées que WordPress doit effectuer pour croiser produits et termes à chaque filtre combiné.
Ce que fait vraiment une requête de filtre par taxonomie
Une requête WooCommerce filtrée par taxonomie s’appuie, en interne, sur une jointure entre wp_posts, wp_term_relationships et wp_term_taxonomy. Cette jointure reste rapide pour un seul critère de filtre. Le problème apparaît quand plusieurs taxonomies sont combinées dans une même requête, ce qui multiplie les jointures ou oblige à des sous-requêtes imbriquées, chacune parcourant wp_term_relationships.
Sur ce catalogue, un filtre combinant trois critères simultanés (matière, usage, certification) provoquait une requête dont le plan d’exécution, visible via EXPLAIN, révélait un balayage complet d’une table intermédiaire plutôt qu’une utilisation efficace des index existants.
La taille réelle de wp_term_relationships
La table wp_term_relationships ne grossit pas proportionnellement au nombre de termes, mais au nombre de relations entre produits et termes. Un produit rattaché à quinze termes différents crée quinze lignes dans cette table, et non une seule. Sur un catalogue de plusieurs milliers de produits, chacun rattaché à une quinzaine de termes en moyenne, cette table dépasse rapidement plusieurs centaines de milliers de lignes, bien au-delà du nombre de termes déclarés lui-même.
- 5 000 termes déclarés ne posent, seuls, aucun problème de performance mesurable.
- Le nombre de relations produit-terme, souvent bien plus élevé, détermine la taille réelle de la table sollicitée à chaque filtre.
- Un index composite adapté aux requêtes fréquentes réduit nettement le temps de réponse, sans réduire le nombre de termes eux-mêmes.
Le rôle aggravant d’un filtre à facettes mal indexé
Un plugin de filtre à facettes, qui affiche en temps réel le nombre de produits correspondant à chaque combinaison possible de critères, multiplie encore la charge : il doit calculer, pour chaque terme affiché dans l’interface, le nombre de produits qui resteraient disponibles si ce terme était sélectionné en plus des critères déjà actifs. Sans mise en cache de ces comptages, cette opération peut représenter plusieurs dizaines de requêtes supplémentaires par affichage de page.
Vérifier le plan d’exécution avant d’agir
EXPLAIN SELECT DISTINCT p.ID
FROM wp_posts p
INNER JOIN wp_term_relationships tr1 ON p.ID = tr1.object_id
INNER JOIN wp_term_taxonomy tt1 ON tr1.term_taxonomy_id = tt1.term_taxonomy_id
INNER JOIN wp_term_relationships tr2 ON p.ID = tr2.object_id
INNER JOIN wp_term_taxonomy tt2 ON tr2.term_taxonomy_id = tt2.term_taxonomy_id
WHERE tt1.taxonomy = 'matiere'
AND tt2.taxonomy = 'usage'
AND p.post_type = 'product';
Cette lecture du plan d’exécution a permis de confirmer que l’index existant sur term_taxonomy_id était bien utilisé, mais que la jointure sur object_id nécessitait un balayage plus large que prévu faute d’un index composite couvrant simultanément les deux colonnes les plus sollicitées par ce type de requête.
Ce qui a réellement amélioré la situation
La correction ne portait donc pas sur une réduction du nombre de termes, ce qui aurait dégradé la richesse de navigation du catalogue, mais sur deux leviers distincts : la mise en cache des comptages de facettes via un cache objet persistant, et une revue des index de la table wp_term_relationships avec l’équipe d’hébergement, pour s’assurer qu’ils couvraient réellement les schémas de requêtes les plus fréquents observés en production.
Réduire arbitrairement le nombre de termes d’une taxonomie pour « gagner en performance » revient souvent à traiter le mauvais symptôme : la vraie question porte sur le nombre de relations produit-terme sollicitées simultanément, pas sur le nombre de termes déclarés.
Une limite volontairement laissée de côté
Les plugins commerciaux de filtre à facettes, qui proposent souvent leur propre système d’index parallèle pour contourner ces limites natives, n’ont pas été évalués dans le cadre de cet audit, qui se concentrait uniquement sur le comportement natif des taxonomies WordPress et de WooCommerce.
En résumé
Sur un catalogue fortement segmenté, la lenteur ressentie ne vient presque jamais du nombre brut de termes, mais du volume de relations produit-terme sollicitées par des filtres combinés, aggravé par des plugins de facettes qui recalculent ces comptages sans mise en cache adaptée. C’est ce couple, relations et absence de cache, qu’il faut diagnostiquer en priorité avant d’envisager une refonte de la structure de taxonomie elle-même.
