Comprendre le cache CDN : quoi mettre en cache et quoi éviter

Un cache CDN stocke les réponses HTTP éligibles dans des emplacements edge afin que les requêtes ultérieures reçoivent une réponse plus proche des utilisateurs et sans trajet jusqu'à l'origine. Mettez agressivement en cache les ressources statiques lorsque leurs URL sont versionnées, mettez le contenu public en cache pour une durée de fraîcheur délibérément définie et gardez les réponses personnalisées ou sensibles hors des caches partagés. La difficulté n'est pas d'activer le cache : elle consiste à prouver que la même réponse mise en cache est sûre pour chaque requête susceptible de la recevoir.

Comment un cache CDN décide

Pour une requête, le CDN calcule une clé de cache, recherche une réponse stockée et vérifie si cette réponse est fraîche et valide pour la requête. Un hit peut éviter la latence de l'origine. Un miss récupère la réponse, applique les règles de mise en cache et peut la stocker pour les requêtes suivantes. Une réponse obsolète peut être revalidée auprès de l'origine avec ETag ou Last-Modified, ou être servie dans le cadre d'une politique d'utilisation de contenu obsolète explicitement autorisée.

L'URL est souvent l'entrée minimale de la clé de cache, mais les systèmes réels peuvent aussi varier selon l'hôte, la chaîne de requête, la méthode, la langue, l'encodage, les indications d'appareil, les cookies, l'autorisation ou certains en-têtes de requête. Chaque dimension supplémentaire peut fragmenter le cache. Chaque dimension omise peut faire servir une représentation incorrecte.

Que mettre en cache

Ressources statiques versionnées

Mettez longtemps en cache le JavaScript, le CSS, les polices, les icônes et les médias immuables dont le nom est haché. Une politique générique est :

Cache-Control: public, max-age=31536000, immutable

Cette longue durée de vie n'est sûre que si un fichier modifié reçoit une nouvelle URL. N'écrasez pas /app.js alors que les navigateurs et les edges sont autorisés à conserver les anciens octets pendant un an. Utilisez un hash de contenu, un numéro de version ou une autre URL versionnée, et supprimez les anciennes versions conformément à votre politique de déploiement.

Images et médias publics

Les images, segments vidéo, affiches et documents publics téléchargeables constituent souvent de bons candidats pour un CDN. Choisissez une durée de fraîcheur adaptée aux mises à jour éditoriales, prenez en charge les requêtes par plages lorsque nécessaire et faites varier intentionnellement les représentations d'images selon la largeur, le format ou l'appareil. Évitez de créer une clé de cache unique pour chaque en-tête de requête accessoire. La diffusion d'images adaptatives montre pourquoi des variantes à la bonne taille comptent autant pour le poids que pour la vitesse.

Réponses HTML et API publiques

Les pages publiques et les réponses d'API en lecture seule peuvent être mises en cache lorsque leur sortie n'est pas personnalisée et que leur fraîcheur est acceptable. Utilisez un TTL court, une revalidation conditionnelle ou stale-while-revalidate pour le contenu qui tolère une courte fenêtre de fraîcheur. Un CDN tel que Cloudflare ou Fastly peut proposer des contrôles équivalents de TTL edge et de purge, mais la politique de l'origine et les règles effectivement appliquées par le fournisseur doivent être testées ensemble.

Exemple :

Cache-Control: public, max-age=60, stale-while-revalidate=30
ETag: "article-42-v7"

La fenêtre d'obsolescence permet à un cache de servir la réponse précédente pendant sa revalidation lorsque l'implémentation prend ce comportement en charge. Utilisez-la uniquement lorsqu'il est acceptable de servir un contenu légèrement ancien. Si les durées de vie du navigateur et du cache partagé doivent différer, utilisez s-maxage comme politique distincte et vérifiez comment le CDN retenu gère son interaction avec les directives de contenu obsolète.

Ce qu'il ne faut pas mettre en cache dans un CDN partagé

Gardez les pages de compte, l'historique des commandes, les paniers, le paiement, les réponses de paiement, les tableaux de bord privés et les réponses contenant des données personnelles hors des caches partagés. Une base sûre pour les contenus sensibles est :

Cache-Control: private, no-store

Utilisez no-store lorsqu'une réponse ne doit pas être stockée. Si une réponse peut être stockée dans un cache privé de navigateur mais ne doit pas être réutilisée par un CDN partagé, private est la directive importante. no-cache a une signification différente : il autorise le stockage mais exige une validation avant réutilisation.

Soyez prudent avec les réponses qui définissent des cookies. Une réponse qui contient un cookie de session ou de personnalisation ne doit pas devenir un objet partagé uniquement parce qu'une règle edge indique « mettre le HTML en cache ». Vérifiez explicitement le comportement de Authorization, Cookie, Set-Cookie et Vary. Si vous avez une enveloppe publique et des données privées, mettez ces couches en cache séparément et rendez leur frontière évidente.

Ne mettez pas par défaut en cache les requêtes qui modifient l'état. POST, PUT, PATCH et DELETE nécessitent une sémantique et une invalidation spécifiques à l'application. La plupart des caches CDN sont conçus autour de récupérations sûres telles que GET et HEAD.

Concevoir soigneusement la clé de cache

Normalisez les paramètres de requête qui ne modifient pas le contenu, tels que les paramètres de suivi, mais ne supprimez pas les paramètres qui sélectionnent un produit, une locale, un filtre ou une représentation. Décidez si l'ordre des paramètres doit avoir une importance. Si la réponse varie selon la langue ou l'encodage, utilisez une politique Vary correcte ou une configuration de fournisseur équivalente. Assurez-vous que le CDN respecte réellement les en-têtes que vous envoyez ; certains produits ont des valeurs par défaut propres au fournisseur.

Évitez de faire varier le cache selon l'intégralité de l'en-tête Cookie. Cela crée de nombreux objets avec un faible taux de hit et peut mêler l'état de l'application au comportement edge. Extrayez uniquement le signal requis pour une variante publique, ou contournez le cache partagé lorsque la réponse est réellement personnalisée.

Si une réponse est négociée par Accept, Accept-Encoding ou des client hints, validez le chemin complet de l'origine à l'edge puis au navigateur. Une réponse correcte pour un appareil ou une langue ne l'est pas pour toutes les clés de cache.

L'invalidation fait partie de la conception

Un TTL n'est pas une stratégie de purge. Décidez comment les corrections urgentes, la disponibilité produit, les changements de sécurité et les versions invalident les objets mis en cache. Utilisez des URL versionnées pour les ressources, des purges ciblées pour le contenu connu et une procédure de purge plus large documentée pour les incidents. Comprenez si une purge est mondiale, asynchrone, souple ou spécifique au fournisseur. Testez ce qu'un utilisateur voit pendant la propagation.

Conservez des validateurs tels que ETag ou Last-Modified sur les réponses qui peuvent être revalidées. Une réponse 304 Not Modified peut actualiser les métadonnées du cache sans transférer le corps complet. Surveillez le taux de hit, les requêtes à l'origine, les réponses obsolètes, la fin des purges et les erreurs de cache au lieu de considérer un taux de hit élevé comme le seul indicateur de succès.

Erreurs courantes

N'assimilez pas un cache hit à une réponse correcte. Ne mettez pas tout le HTML en cache parce que les ressources statiques sont sûres. N'utilisez pas no-cache lorsque vous voulez dire no-store. N'appliquez pas un TTL d'un an à des URL mutables. N'ignorez pas les chaînes de requête ni les cookies dans la clé de cache. N'appliquez pas stale-if-error à un contenu qui devient dangereux ou trompeur lorsqu'il est ancien. Ne supposez pas qu'un paramètre du tableau de bord Cloudflare ou Fastly a la même priorité que les en-têtes d'origine sans vérifier sa documentation et les en-têtes de réponse.

Checklist de validation

Testez un miss à froid, un hit à chaud, une revalidation d'une réponse obsolète, un objet purgé et une erreur d'origine. Répétez l'opération pour des requêtes anonymes, authentifiées, localisées, mobiles et portant des cookies. Inspectez Cache-Control, Age, ETag, Last-Modified, Vary, Set-Cookie, le statut, l'encodage du contenu, l'état du cache et le corps de la réponse. Confirmez qu'une mise à jour devient visible dans le délai promis et que les données sensibles n'apparaissent jamais dans un objet partagé.

Pour des exemples de politiques directive par directive, consultez Comment configurer Cache-Control. Pour la couche réseau autour du cache, consultez le guide CDN managé d'Optimi et le DNS managé. Pour une séquence plus large d'amélioration de la vitesse d'un site, consultez la checklist de performance des sites lents.

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