Cartographier la politique sur la ressource, pas sur le serveur
Inventoriez des URLs représentatives avant de changer les en-têtes : une page d’accueil, une page de contenu, une coque d’application, CSS, JavaScript, images, polices, API, connexion, compte, paiement et téléchargements. Pour chacune, notez si la réponse est publique ou personnalisée, si son URL change quand ses octets changent, et à quelle vitesse une correction doit atteindre les visiteurs.
Élaborez une matrice de politiques à partir de cet inventaire. Un actif public adressé par son contenu nécessite une règle différente du HTML à adresse stable. Les réponses sans Cache-Control peuvent encore être mises en cache de manière heuristique, donc des règles explicites sont plus faciles à tester.
La période pendant laquelle une réponse stockée peut être réutilisée ; max-age la donne en secondes.
Utiliser précisément les termes Cache-Control
Cache-Control indique aux navigateurs et aux caches partagés comment stocker et réutiliser une réponse. max-age=N permet la réutilisation tant que la ressource est fraîche. s-maxage=N définit la fraîcheur pour les caches partagés et remplace max-age là-bas, mais les navigateurs ignorent s-maxage. public permet à tout cache de stocker ; private autorise le cache navigateur mais empêche le stockage partagé.
no-cache autorise le stockage mais exige la validation auprès de l’origine avant réutilisation. no-store signifie que les caches ne doivent pas stocker la réponse, mais ce n’est pas un contrôle de confidentialité complet. Utilisez must-revalidate lorsque servir du contenu périmé après expiration est inacceptable ; une origine indisponible peut alors retourner un 504 plutôt qu’un contenu périmé.
Il supprime le stockage plutôt que d’exiger simplement une vérification ; réservez-le aux réponses qui ne doivent vraiment pas être conservées.
Versionner les actifs immuables avant d’attribuer une longue durée
Une URL d’actif versionnée inclut une empreinte de contenu ou un numéro de version de release, par exemple app.4f2c.js. Quand les octets d’un actif changent, publiez une URL différente et mettez à jour la référence dans le HTML. Le cache voit une nouvelle ressource, donc les visiteurs récupèrent le nouvel actif sans qu’une invalidation doive atteindre chaque navigateur.
Pour une représentation qui ne changera pas pendant sa durée de fraîcheur, Cache-Control: max-age=31536000, immutable est un schéma pratique. immutable indique aux clients compatibles de ne pas revalider conditionnellement tant que la ressource est fraîche. Ne l’appliquez pas, ni un max-age d’un an, à un fichier mutable accessible sous la même URL. Conservez les anciens actifs fingerprintés tant que du HTML mis en cache peut encore les référencer.
Le HTML choisit les URLs des actifs, donc l’ordonnancement des releases doit conserver la génération référencée.
Rendre le HTML à jour par la validation, pas par un cache long
Le HTML a généralement une URL stable, visible par les humains, et change avec le contenu, les références d’actifs, les feature flags ou les avis de sécurité. Un schéma public conservateur pour le HTML est Cache-Control: no-cache avec ETag et Last-Modified lorsque votre plateforme peut les produire correctement. Le navigateur stocke le corps mais effectue une requête conditionnelle avant de le réutiliser ; une réponse inchangée peut retourner 304 Not Modified sans corps.
ETag identifie une version de ressource. Sur une réponse périmée, le navigateur peut l’envoyer dans If-None-Match ; si elle correspond, le serveur répond 304, sinon il envoie la nouvelle représentation. Les recommandations RFC conseillent, quand c’est possible, d’avoir à la fois ETag et Last-Modified sur une réponse 200. no-cache ne garantit pas la validation sur la navigation Précédent ou Suivant car un navigateur peut restaurer un instantané de l’historique de session.
Un ETag doit changer quand la représentation change ; testez-le entre origines et déploiements.
Séparer la diffusion publique des réponses personnalisées et sensibles
Un cache partagé, comme un CDN, peut réutiliser une réponse pour plusieurs utilisateurs. Ne le laissez pas réutiliser du HTML ou des données d’API spécifiques à un compte entre utilisateurs. Pour du contenu personnalisé susceptible d’être conservé dans le navigateur, private, no-cache est un point de départ sensé : cela empêche le stockage partagé et exige une validation. Un en-tête Set-Cookie seul n’empêche pas la mise en cache.
Pour les réponses qui ne doivent pas être stockées, utilisez no-store et passez en revue le code applicatif, les règles CDN, les service workers, les stockages côté navigateur, les logs et les pages d’erreur. Les en-têtes seuls ne constituent pas un programme de confidentialité, conformité ou sécurité des paiements. Faites examiner les flux sensibles par des spécialistes sécurité, confidentialité et paiements qualifiés selon les exigences applicables.
Testez la connexion, la déconnexion, le changement de compte et les modifications de permissions avec des caches navigateur et CDN chauds.
Déployer les changements de cache comme une release réversible
Capturez les en-têtes de base et le comportement des corps pour les requêtes non mises en cache et répétées. En préproduction, déployez d’abord les actifs versionnés, puis le HTML qui les référence, et testez le HTML mis en cache plus ancien contre la nouvelle origine. Vérifiez les chemins direct-origin et CDN si les deux existent. Les en-têtes Network de DevTools doivent montrer la politique voulue et le comportement en répétition.
Conservez un manifeste de release des URLs d’actifs, des règles d’en-tête et de la version de configuration. Si une release combine des fichiers clients incompatibles, restaurez un HTML compatible et le comportement applicatif, mais n’écrasez pas un fichier fingerprinté déjà publié. Repointiez le HTML vers la génération connue comme saine et conservez les deux générations tant que le HTML mis en cache peut les demander. Une purge de cache partagé ne peut pas forcer les navigateurs à jeter une réponse encore fraîche.
Transformez les échecs de test d’en-tête, les 404 d’actifs et les incompatibilités de version en éléments à ajouter à la checklist de la release suivante.