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.
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-Agentde l’en-têteVary, 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.
