Cache misses CDN : trouver et corriger les véritables causes

Corrigez les cache misses CDN en classant d'abord la réponse, puis en retraçant sa possibilité de mise en cache et sa clé de cache. N'augmentez pas un TTL et n'activez pas largement le cache HTML comme première réaction. Une réponse peut être un miss légitime, un contournement volontaire, une revalidation ou une entrée de cache fragmentée entre les URL et les en-têtes. L'objectif sûr n'est pas le taux de hit le plus élevé ; c'est la charge la plus faible sur l'origine compatible avec des réponses correctes et privées.

Un cache edge stocke une représentation sous une clé. Lors d'une requête, il vérifie si la clé correspond, si la réponse stockée est fraîche et si la politique autorise sa réutilisation. Sinon, il contacte l'origine ou un autre niveau de cache. La réponse de l'origine alimente alors le cache, met à jour une entrée existante ou demeure non cacheable.

Identifier le résultat du cache

Inspectez les en-têtes de réponse depuis plusieurs emplacements et répétez la même requête. Avec Cloudflare, CF-Cache-Status distingue des résultats courants tels que HIT, MISS, EXPIRED, REVALIDATED, UPDATING, STALE, BYPASS et DYNAMIC. Age constitue un élément supplémentaire indiquant qu'une réponse provient d'un cache. Avec Fastly, inspectez X-Cache, X-Served-By, Age et les champs de journal que vous avez configurés. Les libellés des fournisseurs et leurs règles d'agrégation diffèrent ; ne les comparez donc pas comme s'il s'agissait d'une seule métrique standard.

Utilisez une requête avec une URL, une méthode, un hôte et des en-têtes pertinents fixes. Envoyez-la deux fois depuis le même emplacement de test, puis depuis un second emplacement. Un miss à la première requête suivi d'un hit est un remplissage normal du cache. Un miss à chaque requête suggère une clé non concordante, une réponse non cacheable, une règle de contournement, un objet trop volumineux pour le cache configuré ou un chemin de requête qui n'atteint jamais le cache attendu.

La revalidation est différente d'un miss complet. Le cache possède un objet mais doit demander à l'origine s'il a changé, souvent avec ETag ou Last-Modified. Une réponse 304 peut économiser le transfert du corps mais coûte toujours une requête à l'origine et un aller-retour. stale-while-revalidate peut servir une réponse obsolète tout en la mettant à jour en arrière-plan, si sa sémantique convient.

Trouver la véritable cause

La réponse n'est pas cacheable

Vérifiez la réponse de l'origine pour Cache-Control: private, no-store ou no-cache, ainsi que Set-Cookie. Vérifiez si la requête porte Authorization, si la méthode est GET ou HEAD et si le statut est éligible au stockage. Une réponse dynamique est souvent correcte : les pages de compte, le contenu des paniers, les étapes de paiement et les recommandations personnalisées ne doivent pas être partagées par accident.

Pour le contenu public, renvoyez une politique explicite plutôt que de vous appuyer sur une fraîcheur heuristique. Une ressource immuable typique peut utiliser un long max-age avec un nom de fichier doté d'une empreinte. Une réponse HTML publique peut utiliser une durée de vie de cache partagé plus courte et la revalidation. s-maxage peut séparer la fraîcheur du cache partagé de celle du navigateur. stale-if-error peut protéger une page publique pendant une défaillance temporaire de l'origine, mais ne doit pas masquer des changements dangereux ou sensibles au temps.

La clé de cache est trop large ou trop étroite

Les chaînes de requête sont souvent en cause. Les paramètres d'analyse peuvent créer de nombreuses clés pour une même représentation, tandis que les paramètres de langue, devise, appareil ou expérimentation de contenu peuvent réellement la modifier. Les en-têtes nommés par Vary, les cookies, l'autorisation, les noms d'hôte et la normalisation des URL peuvent aussi fragmenter le cache. Documentez chaque composant de la clé et ne retirez que les valeurs dont il est prouvé qu'elles n'affectent pas la réponse.

Les équivalents Cloudflare comprennent les Cache Rules, les clés de cache personnalisées, Cache Analytics et Trace. Les équivalents Fastly comprennent la logique de hash VCL, les surrogate keys pour l'invalidation et le shielding. Conservez le modèle de clé indépendant du fournisseur dans le contrôle de version et passez-le en revue avec l'équipe applicative. Ne retirez jamais un discriminateur d'utilisateur ou de locataire d'une clé pour améliorer une métrique de tableau de bord.

L'objet est froid, expiré ou évincé

Un objet peu demandé peut expirer avant sa prochaine requête. Un déploiement ou une purge peut refroidir un site entier. Un objet volumineux ou une pression mémoire peut conduire à une éviction. Dans un CDN multi-POP, un emplacement peut avoir un miss alors qu'un autre possède l'objet. Le cache hiérarchisé ou le shielding peut réduire le nombre de remplissages à l'origine, mais ne garantit pas que chaque POP edge conserve chaque objet.

Si le contenu est publié de manière prévisible, préchauffez un petit ensemble d'URL publiques avec un processus contrôlé. Préférez les noms de fichiers versionnés et les purges ciblées à la purge de tout un site. Des TTL plus longs réduisent les remplissages mais augmentent le risque de contenu obsolète ; associez-les donc à une méthode d'invalidation fiable.

La requête n'atteint jamais le cache

Un worker, une fonction edge, une redirection, une action WAF ou un middleware applicatif peut s'exécuter avant le cache. Une règle de cache peut être ordonnée après une règle de contournement. Un nom d'hôte, protocole, chemin ou route d'origine différent peut servir le test. Suivez la requête chez le fournisseur et comparez les journaux edge avec ceux de l'origine.

Un workflow de diagnostic sûr

1. Choisissez une URL publique déterministe et notez le statut, les en-têtes de réponse, la longueur du contenu et la version du corps.
2. Répétez la requête avec et sans paramètres de suivi inoffensifs, puis avec les en-têtes de langue ou d'appareil pertinents.
3. Comparez une requête à froid avec la seconde requête depuis le même POP ou la même région de test.
4. Inspectez ensemble les en-têtes de l'origine, les règles du fournisseur, la configuration de la clé de cache et l'historique des purges.
5. Corrigez une cause dans un chemin limité, puis vérifiez la confidentialité, la justesse du contenu, le taux de requêtes à l'origine et l'état du cache.
6. Déployez le changement par nom d'hôte, chemin ou région avant de l'appliquer globalement.

Observer ce que les utilisateurs vivent

Suivez séparément les taux de hit, miss, contournement, revalidation et contenu obsolète. Ventilez-les par route, code de statut, taille de réponse, région, CDN, version de clé de cache et déploiement. Corrélez les résultats du cache avec le CPU de l'origine, la bande passante, le TTFB et le taux d'erreur. Échantillonnez les en-têtes complets dans les journaux, mais protégez les cookies, les valeurs d'autorisation et les données personnelles.

Les erreurs comprennent la mise en cache de tout le HTML, l'assimilation de no-cache à no-store, l'ignorance de Set-Cookie, la suppression de chaque chaîne de requête, la mesure du seul taux de hit global, la purge à chaque déploiement et l'hypothèse qu'un HIT du fournisseur signifie que le navigateur n'a pas émis de requête. Un CDN réduit la charge de l'origine lorsque la politique est correcte ; le Multi-CDN ajoute un autre problème de cohérence de cache et de purge à résoudre.

Pour un comportement fondé sur les normes, consultez RFC 9111 HTTP Caching. Pour les détails d'implémentation, utilisez Cloudflare cache responses et Fastly shielding. Contactez Optimi si vous avez besoin d'une revue de clé de cache et de charge sur l'origine.

Il n'existe que deux problèmes difficiles en informatique : l'invalidation du cache et le choix des noms.