# ETag et Cache-Control sur les points d’entrée de la Store API pour réduire les appels réseau

> Un front headless qui interroge la Store API à chaque interaction multiplie les appels réseau. Ajouter des en-têtes de validation de cache change la donne, étape par étape.

- Auteur : Clément Hadrot
- Publié le : 2025-05-15
- Mis à jour le : 2025-05-15
- Catégorie : E-commerce
- URL : https://wpmoderne.dev.wordpress-developpement.fr/ecommerce/etag-cache-control-store-api-woocommerce/

## L’essentiel

- L'ETag évite de retransmettre un panier inchangé
- 304 Not Modified coûte bien moins qu'une réponse complète
- Le cache de page complète reste hors sujet ici

`HTTP/1.1 200 OK` à chaque requête, même quand rien n'a changé dans le panier depuis le dernier appel : c'est le comportement par défaut d'un point d'entrée REST sans en-têtes de validation de cache. Sur un frontal détaché qui interroge la Store API à chaque interaction de l'interface, ce comportement multiplie inutilement le volume de données retransmises pour un contenu pourtant identique à la requête précédente.

Voici, étape par étape, comment ajouter des en-têtes de validation adaptés à un panier qui change peu entre deux interactions.

## Étape 1 : distinguer validation de cache et cache de page complète

Il ne s'agit pas ici de mettre en cache le panier de façon prolongée sur un serveur intermédiaire, ce qui serait dangereux pour un contenu propre à chaque visiteur : il s'agit uniquement de permettre au client de vérifier, en une requête légère, si le contenu qu'il possède déjà est toujours valide. Cette distinction est essentielle : un cache de page complète partagerait une réponse entre plusieurs visiteurs, ce qui n'est pas souhaitable pour un panier individuel.

## Étape 2 : générer un ETag représentatif du contenu du panier

Un ETag doit changer dès que le contenu réel de la réponse change, et rester identique sinon. Pour un panier, une empreinte calculée à partir des éléments, quantités et totaux constitue une base fiable :

```
add_filter( 'rest_pre_serve_request', function ( $served, $result, $request ) {
    if ( strpos( $request->get_route(), '/wc/store/v1/cart' ) === false ) {
        return $served;
    }

    $donnees = $result->get_data();
    $empreinte = '"' . md5( wp_json_encode( $donnees ) ) . '"';
    header( 'ETag: ' . $empreinte );

    $entete_recue = $_SERVER['HTTP_IF_NONE_MATCH'] ?? '';
    if ( $entete_recue === $empreinte ) {
        status_header( 304 );
        return true;
    }

    return $served;
}, 10, 3 );
```

Lorsque l'en-tête `If-None-Match` transmis par le client correspond à l'empreinte calculée côté serveur, la réponse se limite à un code `304 Not Modified`, sans corps de réponse, ce qui économise l'intégralité du volume de données qu'aurait représenté le panier complet.

> L'essentiel à retenir : L'ETag évite de retransmettre un panier inchangé ; 304 Not Modified coûte bien moins qu'une réponse complète ; Le cache de page complète reste hors sujet ici

## Étape 3 : ajouter un en-tête Cache-Control adapté

Un en-tête `Cache-Control: private, no-cache` indique explicitement au client qu'il doit revalider le contenu à chaque nouvelle requête plutôt que de le considérer comme valable pendant une durée fixe, tout en autorisant la mise en cache locale du navigateur pour la seule vérification par ETag. Le mot-clé `private` précise qu'aucun cache intermédiaire partagé, comme un serveur mandataire, ne doit conserver cette réponse.

```
header( 'Cache-Control: private, no-cache' );
```

## Étape 4 : vérifier le comportement côté client

Un client construit avec une bibliothèque de requêtes HTTP moderne transmet automatiquement l'en-tête `If-None-Match` lors d'une requête répétée vers la même ressource, à condition d'avoir conservé l'ETag reçu lors de la réponse précédente. Cette vérification se fait dans l'onglet réseau des outils de développement : une requête répétée sans changement de panier doit afficher un code `304` et un temps de transfert quasi nul comparé à la requête initiale.

## Étape 5 : mesurer le gain réel

- Comparer le volume total de données transférées sur une session type, avec et sans validation de cache activée.
- Vérifier que le comportement reste correct après une modification réelle du panier : l'ETag doit alors changer et la réponse complète doit être renvoyée normalement.
- S'assurer qu'aucun serveur mandataire intermédiaire ne conserve la réponse au-delà de ce que permet l'en-tête `Cache-Control` défini.

## En résumé

Cette approche ne remplace pas un cache de page complète, dont l'usage reste inadapté à un contenu individuel comme un panier : elle réduit uniquement le volume transféré lors des requêtes répétées vers un contenu inchangé. Sur un front headless qui interroge fréquemment la Store API, ce gain se traduit directement par moins de données transférées et des réponses perçues comme plus rapides par l'utilisateur final.