Comment configurer Cache-Control sans casser votre site web

Pour configurer Cache-Control de manière fiable, déterminez si une réponse est publique ou privée, si elle peut être stockée, combien de temps elle reste fraîche et si un contenu obsolète est acceptable. Émettez ensuite une politique explicite et concise depuis l'origine et vérifiez si votre CDN la préserve ou la remplace. La distinction la plus importante est que no-cache autorise le stockage mais impose une revalidation, tandis que no-store indique aux caches de ne pas stocker la réponse.

Cache-Control est un en-tête de réponse HTTP interprété par les navigateurs et les caches partagés tels que les CDN et les proxys. Cloudflare, Fastly et les fournisseurs équivalents peuvent ajouter un TTL edge, une règle de cache ou une politique de surrogate ; l'en-tête à l'origine est donc la politique de départ, pas nécessairement le comportement final.

Les directives les plus utiles

public, private et no-store

public indique qu'une réponse peut être stockée par des caches partagés. private limite le stockage à un cache privé, tel que le navigateur de l'utilisateur, et convient aux réponses personnalisées. no-store demande à tout type de cache de ne pas stocker la réponse. Utilisez-le pour les données sensibles, les identifiants, les étapes de paiement ou les réponses dont la conservation est inacceptable.

max-age et s-maxage

max-age définit la durée de fraîcheur d'une réponse en secondes. s-maxage s'applique aux caches partagés et y remplace max-age, tandis que les navigateurs l'ignorent. Ensemble, ils permettent d'attribuer au navigateur et au CDN des fenêtres de fraîcheur différentes :

Cache-Control: public, max-age=60, s-maxage=600

Utilisez des secondes entières. Gardez la fenêtre courte lorsque le contenu change fréquemment et utilisez des URL versionnées pour le contenu réellement immuable.

no-cache et les validateurs

no-cache signifie qu'une réponse stockée doit être validée avant sa réutilisation. Cela ne signifie pas « ne pas mettre en cache ». Associez-le à ETag ou Last-Modified afin que le validateur puisse produire efficacement une réponse 304 Not Modified :

Cache-Control: public, no-cache
ETag: "homepage-release-42"

Ce modèle est utile pour du HTML qui doit être vérifié à chaque navigation mais ne nécessite pas un téléchargement complet lorsqu'il n'a pas changé.

immutable

immutable indique aux clients qu'une réponse fraîche ne changera pas. Utilisez-le uniquement pour les ressources dont l'URL change lorsque leurs octets changent :

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

Ne combinez jamais une longue durée de vie immuable avec un nom de fichier mutable tel que /styles.css, sauf si vous disposez d'une stratégie fiable de versionnement et de purge qui empêche les anciennes références de rester en circulation.

stale-while-revalidate et stale-if-error

stale-while-revalidate permet à un cache de servir une réponse obsolète pendant une fenêtre limitée tout en la revalidant en arrière-plan. stale-if-error autorise le contenu obsolète lorsque l'origine échoue. Ces directives peuvent améliorer la résilience, mais elles prolongent la période pendant laquelle d'anciennes données peuvent être vues. Utilisez-les uniquement pour un contenu dont ce compromis est explicite.

Modèles de politiques sûrs

Ressources statiques avec empreinte

Pour le JavaScript, le CSS, les polices et les médias hachés :

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

Le build doit publier une nouvelle URL lorsque le contenu change. Si un déploiement conserve la même URL, choisissez plutôt une durée de vie plus courte et un processus de purge testé.

HTML public qui change régulièrement

Pour du HTML public qui peut rester brièvement frais à l'edge mais doit être mis à jour plus souvent dans les navigateurs :

Cache-Control: public, max-age=60, stale-while-revalidate=30
ETag: "page-2026-07-14-8"

Cet exemple est un point de départ, pas un TTL universel. Vérifiez la fréquence réelle de publication, les attentes des utilisateurs et la sémantique de contenu obsolète du fournisseur. Si le cache partagé nécessite une durée de fraîcheur différente, utilisez s-maxage comme politique distincte et vérifiez son interaction avec les directives de contenu obsolète. Une règle CDN qui force un TTL edge différent peut aller à l'encontre de l'intention de l'origine.

Données d'API publiques

Pour une réponse en lecture seule, identique pour chaque requête anonyme :

Cache-Control: public, max-age=30, s-maxage=120
ETag: "products-987"

Incluez dans la clé de cache les paramètres qui modifient le résultat. Ne retirez pas un paramètre de requête uniquement parce qu'il semble facultatif. Vérifiez la pagination, les filtres, la locale, la devise et le comportement d'autorisation.

Réponses personnalisées ou sensibles

Pour les données de compte ou de paiement :

Cache-Control: private, no-store

Si une réponse personnalisée non sensible peut être conservée par le navigateur mais ne doit pas être réutilisée par un CDN partagé, private, max-age=60 peut convenir après une revue de sécurité. N'utilisez pas une règle de cache publique pour compenser une réponse ambiguë de l'application.

Les en-têtes qui influencent la justesse

Vary indique aux caches quels en-têtes de requête sélectionnent une représentation différente. Si une réponse varie selon la langue ou l'encodage, rendez cette variation explicite et confirmez que le CDN la respecte. Faire varier selon un en-tête à forte cardinalité, en particulier la valeur complète de Cookie, peut détruire le taux de hit. Omettre une variation requise peut servir la mauvaise langue, le mauvais format ou la mauvaise version pour l'appareil.

Set-Cookie et Authorization demandent une attention particulière. Un cookie de session indique souvent une personnalisation. Une requête avec Authorization ne doit pas recevoir une réponse partagée, sauf si vous disposez d'une politique délibérée et sûre et que l'implémentation du cache la respecte. En cas de doute, utilisez private ou no-store et repensez la frontière entre public et privé.

ETag et Last-Modified prennent en charge les requêtes conditionnelles. Gardez-les stables pour une même représentation et modifiez-les lorsque la représentation change. Content-Encoding et la négociation de contenu doivent correspondre à la représentation livrée au client ; testez les chemins compressés et non compressés.

Configurer l'edge sans perdre le contrat de l'origine

Traitez la réponse de l'origine comme la politique source et le CDN comme une couche d'application. Si Cloudflare, Fastly ou un autre fournisseur utilise un TTL de cache edge, une règle de cache, Surrogate-Control ou un en-tête propre au fournisseur, documentez leur priorité. Un paramètre qui force la mise en cache peut contourner private ou no-store ; un paramètre qui force le contournement peut rendre une politique d'origine correcte inefficace.

Inspectez à la fois les réponses de l'origine et les réponses publiques. Comparez une requête directe à l'origine avec une requête via le CDN, puis testez un miss, un hit, une revalidation, une purge et une erreur d'origine. Ne vous fiez jamais uniquement à l'étiquette d'un tableau de bord.

Erreurs qui cassent les sites web

N'utilisez pas no-cache lorsque le besoin est l'absence de stockage. N'utilisez pas no-store partout pour ensuite vous demander pourquoi les navigations répétées et les comportements précédent-suivant du navigateur sont lents. Ne mettez pas le HTML en cache sans vérifier les cookies et l'autorisation. N'ajoutez pas immutable à une URL mutable. Ne définissez pas s-maxage sans considérer son interaction avec le comportement de contenu obsolète de votre fournisseur. N'oubliez pas qu'une purge ne peut pas atteindre un cache de navigateur qui considère toujours un objet comme frais.

Checklist de validation

Pour chaque classe de réponse, documentez son audience, sa possibilité de mise en cache, son TTL navigateur, son TTL de cache partagé, son validateur, sa clé de cache, sa politique de contenu obsolète et le responsable de la purge. Utilisez curl -I et les DevTools du navigateur pour inspecter Cache-Control, Age, ETag, Last-Modified, Vary, Set-Cookie, le statut et l'état du cache. Testez les variantes anonymes, authentifiées, localisées et avec paramètres de requête. Confirmez qu'une réponse modifiée devient visible dans le délai promis et qu'une erreur d'origine ne peut pas exposer de données sensibles ni des données dangereusement obsolètes.

Pour la conception globale du cache, consultez Comprendre le cache CDN. Pour réduire le délai à l'origine derrière un miss, consultez les guides Optimi, la diffusion CDN managée et le DNS managé.

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