# L’en-tête Vary mal réglé multiplie les entrées d’un cache de page > Un taux de hit qui reste élevé sur le tableau de bord alors que les visiteurs perçoivent des pages lentes : l'en-tête Vary trop large en est la cause fréquente. - Auteur : WordPress Développement - Publié le : 2021-05-04 - Mis à jour le : 2021-05-04 - Catégorie : Performance - URL : https://www.wpmoderne.fr/performance/vary-header-multiplie-entrees-cache-page/ ## L’essentiel - Vary indique quelles variantes d'une même URL doivent être mises en cache séparément - Un Vary trop large fragmente le cache en autant de variantes que de combinaisons possibles - Ne varier que sur ce qui influence réellement la réponse résout le problème Le tableau de bord du cache affiche un taux de hit de 85 %, un chiffre qu'on jugerait rassurant sur n'importe quel autre projet. Pourtant, les visiteurs continuent de signaler des temps de chargement irréguliers, tantôt rapides, tantôt nettement plus lents, sur les mêmes pages visitées à quelques minutes d'intervalle. Le cache de page fonctionne bien en apparence : le taux de hit global reste correct. Le problème se cache dans la façon dont ce taux se répartit entre un très grand nombre de variantes différentes d'une même URL, chacune ayant un historique de cache pratiquement neuf, faute d'avoir accumulé suffisamment de visites identiques pour bénéficier pleinement du cache. ## Ce que fait réellement l'en-tête Vary L'en-tête HTTP `Vary`, envoyé dans la réponse du serveur, indique à tout cache intermédiaire (CDN, proxy, navigateur) quels en-têtes de la requête doivent être pris en compte pour distinguer des variantes différentes d'une même URL. Un `Vary: Accept-Encoding` est classique et sans risque : il sépare simplement les réponses compressées en gzip de celles compressées en brotli, un nombre limité de combinaisons. ## Le réglage qui posait problème sur ce site ``` Vary: Accept-Encoding, User-Agent, Accept-Language, Cookie ``` Ajouter `User-Agent` à la liste, dans l'intention initiale de servir des variantes optimisées pour mobile, a eu pour effet de créer une variante de cache distincte pour chaque combinaison de navigateur et de version rencontrée, un nombre pratiquement infini en pratique tant les chaînes `User-Agent` varient d'un visiteur à l'autre. Ajouter également `Cookie` à la liste, hérité d'une configuration copiée pour gérer un cas particulier de personnalisation, aggravait encore la fragmentation en créant une variante par valeur de cookie distincte. > L'essentiel à retenir : Vary indique quelles variantes d'une même URL doivent être mises en cache séparément ; Un Vary trop large fragmente le cache en autant de variantes que de combinaisons possibles ; Ne varier que sur ce qui influence réellement la réponse résout le problème ## Diagnostic : compter les variantes réellement stockées Sur un CDN qui expose ce type de statistique, ou en interrogeant directement le cache de page côté serveur, il devient possible de compter le nombre de variantes stockées pour une même URL logique. Sur la page d'accueil de ce site, ce comptage a révélé plusieurs centaines de variantes actives, alors qu'une poignée aurait suffi à couvrir l'ensemble des cas réellement différents (langue du visiteur, et éventuellement type d'appareil via un en-tête plus stable). ### Pourquoi Cookie ne devrait presque jamais figurer dans Vary La présence de `Cookie` dans `Vary` revient à désactiver le cache partagé pour tout visiteur ayant un cookie distinct, ce qui inclut potentiellement chaque session anonyme dès qu'un plugin de statistiques ou un consentement de cookies pose un identifiant. La bonne pratique consiste à exclure la page du cache pour les visiteurs réellement connectés, plutôt que de faire varier le cache sur le contenu du cookie lui-même. ## Correctif appliqué - Retrait de `User-Agent` de l'en-tête `Vary`, remplacé par une détection mobile côté client en CSS/JS quand elle restait nécessaire. - Retrait de `Cookie`, remplacé par une exclusion explicite du cache pour les utilisateurs authentifiés, gérée en amont. - Conservation du seul `Vary: Accept-Encoding, Accept-Language`, suffisant pour ce site multilingue à deux langues. ## Une alternative pour la détection mobile sans fragmenter le cache Plutôt que de varier le cache sur `User-Agent`, une approche plus robuste consiste à servir exactement le même HTML à tous les appareils, en laissant le CSS et les media queries gérer l'adaptation visuelle au format d'écran. Quand une différence de contenu réelle est nécessaire selon l'appareil, il est préférable de la gérer côté client en JavaScript après le premier rendu, plutôt que de multiplier les variantes de cache côté serveur pour un gain d'affichage qui reste secondaire face au coût de fragmentation observé ici. ### Ce que l'équipe a retenu pour les projets suivants Depuis cet incident, toute nouvelle directive ajoutée à `Vary` sur un projet de l'équipe fait l'objet d'une vérification préalable du nombre de valeurs distinctes que l'en-tête concerné peut prendre en pratique, avant toute mise en production. Cette simple habitude a évité de reproduire le même problème sur deux projets suivants où une tentation similaire était apparue lors de discussions techniques internes. ## En résumé Un taux de hit global élevé peut masquer une fragmentation sévère du cache entre trop de variantes distinctes. Avant d'ajouter un en-tête à la liste `Vary`, il faut se demander combien de valeurs distinctes cet en-tête peut réellement prendre côté client : au-delà d'une poignée de valeurs stables, le cache perd rapidement toute son utilité pratique.