# Compter les articles d’une taxonomie à la volée coûte plus cher que prévu

> Un compteur de taxonomie recalculé à chaque affichage d'archive alourdit chaque page, alors que WordPress tient déjà ce chiffre à jour tout seul.

- Auteur : WordPress Développement
- Publié le : 2022-12-04
- Mis à jour le : 2022-12-04
- Catégorie : Performance
- URL : https://www.wpmoderne.fr/performance/compter-articles-taxonomie-cout-cache/

## L’essentiel

- Le compteur est déjà stocké dans wp_term_taxonomy
- Le recalcul à la volée ajoute une requête par page
- Le différé coûte moins cher que le temps réel

Douze mille requêtes SQL supplémentaires par jour : c'est ce qu'a révélé l'audit d'un site d'annonces immobilières après l'ajout d'un simple compteur « X biens dans cette catégorie » sur chaque page d'archive. La cause n'était pas exotique : une fonction maison relançait un `WP_Query` complet à chaque chargement, juste pour connaître le nombre d'articles rattachés à un terme de taxonomie.

Ce réflexe est courant, et pourtant WordPress résout déjà ce problème depuis longtemps. Comprendre pourquoi ce comptage est redondant, et comment le cœur du logiciel le gère en différé, évite d'empiler des requêtes inutiles sur des pages qui n'en ont pas besoin.

## Ce que fait un développeur pressé

Le scénario type ressemble à ceci : un template d'archive de taxonomie doit afficher « 84 articles dans cette rubrique ». Le développeur écrit une requête dédiée, par exemple avec `WP_Query` et l'option `'fields' => 'ids'`, ou pire, une requête `SQL_CALC_FOUND_ROWS` couplée à `found_posts`, exécutée à chaque visite, pour chaque terme affiché sur la page (souvent plusieurs dizaines dans un menu latéral de filtres).

Le problème s'aggrave sur les pages qui listent plusieurs taxonomies à la fois : un filtre à facettes avec quinze catégories et huit tags peut déclencher vingt-trois requêtes de comptage rien que pour l'affichage du nombre d'éléments par filtre, avant même d'avoir chargé le contenu principal.

## Ce que WordPress fait déjà tout seul

La table `wp_term_taxonomy` possède une colonne `count`, maintenue à jour automatiquement par le cœur de WordPress à chaque fois qu'un article change de statut ou de terme associé. Cette mise à jour passe par la fonction interne `_update_post_term_count()`, appelée sur les hooks `save_post`, `delete_post`, `edited_terms` et quelques autres liés à la publication.

Concrètement, récupérer ce chiffre ne nécessite qu'un appel simple :

```
$term = get_term_by( 'slug', 'literature', 'category' );
echo $term->count; // Nombre d'articles publiés dans ce terme
```

Aucune requête de comptage additionnelle, aucun `WP_Query` instancié pour rien : la valeur est déjà en mémoire dans l'objet `WP_Term`, chargé une seule fois via le cache d'objets de WordPress (le groupe `terms`).

> L'essentiel à retenir : Le compteur est déjà stocké dans wp_term_taxonomy ; Le recalcul à la volée ajoute une requête par page ; Le différé coûte moins cher que le temps réel

## Pourquoi ce compteur reste fiable même différé

La mise à jour du compteur se fait de façon événementielle, pas en temps réel au sens strict, mais le décalage est de l'ordre de la milliseconde qui suit une publication ou une suppression, pas d'un cron horaire. Dès qu'un article change de statut, `wp_update_term_count_now()` recalcule immédiatement la valeur pour les termes concernés, en filtrant sur les statuts publiés définis par `_update_post_term_count()`.

Ce mécanisme suffit pour l'immense majorité des usages : une archive de catégorie, un widget de filtres, un fil d'Ariane avec compteur. Il ne convient en revanche pas si le besoin porte sur un sous-ensemble arbitraire (par exemple « articles publiés cette semaine dans cette catégorie »), qui nécessite alors une vraie requête, mais celle-ci doit être mise en cache elle-même, pas exécutée à chaque affichage.

## Quand une requête reste justifiée

- Comptage croisé entre plusieurs taxonomies (catégorie ET tag précis) : le champ `count` ne couvre qu'une seule taxonomie à la fois.
- Filtrage par métadonnée en plus du terme : le compteur natif ne connaît pas les `meta_query`.
- Comptage restreint à une période ou à un type de contenu particulier non standard.

Dans ces cas, la bonne pratique consiste à calculer la valeur une fois, puis à la stocker dans un transient avec une durée de vie raisonnable, ou à l'invalider explicitement via le hook `save_post` plutôt que de la recalculer à chaque requête HTTP entrante.

## Mettre en place un compteur différé pour les cas particuliers

```
function get_cached_term_count( $term_id, $taxonomy ) {
    $cache_key = 'term_count_custom_' . $term_id;
    $count = get_transient( $cache_key );

    if ( false === $count ) {
        $query = new WP_Query( array(
            'tax_query' => array( array(
                'taxonomy' => $taxonomy,
                'field'    => 'term_id',
                'terms'    => $term_id,
            ) ),
            'meta_query' => array( array(
                'key'     => 'is_premium',
                'value'   => '1',
            ) ),
            'fields' => 'ids',
        ) );
        $count = $query->found_posts;
        set_transient( $cache_key, $count, HOUR_IN_SECONDS );
    }

    return (int) $count;
}
```

Cette fonction ne calcule qu'une fois par heure, quel que soit le nombre de visiteurs, et ne pèse plus sur le temps de génération des pages d'archive.

## En résumé

Avant d'écrire une requête de comptage, vérifiez si WordPress ne connaît pas déjà la réponse. Le champ `count` de `wp_term_taxonomy` couvre la grande majorité des besoins d'affichage, sans coût supplémentaire, puisqu'il est maintenu par le cœur à chaque changement de statut d'article. Réservez les requêtes de comptage personnalisées aux cas réellement spécifiques, et mettez-les systématiquement en cache plutôt que de les exécuter à chaque chargement de page.