Comment régler Cache-Control pour les ressources statiques ?

Par l’équipe Limpi. Les faits externes sont distingués des méthodes Limpi et aucune visibilité, position ou citation automatique n’est garantie.

Comprendre le problème

Cache-Control définit comment navigateurs et caches intermédiaires peuvent conserver ou revalider une réponse. Pour les ressources statiques, la stratégie dépend surtout de la capacité à changer l’URL lorsque le contenu change. Un fichier versionné peut généralement être gardé longtemps ; une URL stable susceptible de changer demande une politique plus prudente.

Inspecter le comportement réellement servi

Relevez Cache-Control, ETag, Last-Modified, Age et le statut des requêtes sur CSS, JavaScript, images et polices. Refaites un chargement à chaud pour voir si la ressource vient du cache, est revalidée ou retransférée. Comparez les assets fingerprintés avec les fichiers à nom stable et vérifiez les règles du CDN comme celles de l’origine.

Distinguer les mécanismes proches

Un cache long ne signifie pas qu’une ressource ne pourra jamais changer : avec un nom versionné, on publie une nouvelle URL lorsque les octets changent. La revalidation, via des validateurs HTTP, est différente d’un cache qui considère la réponse fraîche. Distinguez aussi le cache des assets du cache HTML, qui porte des contraintes de mise à jour différentes.

Identifier les causes probables

Une règle globale peut appliquer un max-age très long à des fichiers non versionnés, laissant d’anciennes ressources chez certains utilisateurs. À l’inverse, no-cache ou max-age=0 sur tous les assets force des validations répétées. Les CDN peuvent écraser les en-têtes de l’origine ou conserver une configuration historique après une migration.

Corriger à la bonne couche

Pour les assets dont l’URL contient une empreinte de contenu, utilisez une politique de fraîcheur longue cohérente avec votre déploiement et changez l’URL à chaque nouvelle version. Pour une ressource à URL stable, choisissez une durée adaptée et conservez un mécanisme de revalidation si elle peut évoluer. Ne recopiez pas la même directive sur HTML et assets sans analyse.

Traiter les cas limites sans automatisme

Les réponses privées, personnalisées ou dépendantes d’un cookie demandent une politique différente des fichiers publics immuables. Un service worker peut aussi intercepter la requête et créer une couche de cache supplémentaire. Vérifiez enfin les erreurs et redirections : leur politique de cache peut compliquer un incident si elle est trop agressive.

Valider sur des cas réels

Testez un déploiement simulé : demandez un asset, rechargez, puis publiez une version avec nouvelle URL. L’ancien fichier peut rester cacheable tandis que la page référence le nouveau. Sur une URL non versionnée, vérifiez que le changement devient visible dans le délai prévu ou après revalidation. Inspectez les headers réellement servis par le CDN.

Conserver une preuve reproductible

Pour chaque catégorie, conservez URL, Cache-Control, validateur, statut du second chargement et indication memory/disk cache des DevTools. Ajoutez la convention de versionnement utilisée par le build. Cette trace permet de distinguer un problème d’en-tête d’un problème de nommage ou d’invalidation CDN.

Prévenir la régression

Formalisez une matrice de cache par type de ressource et liez-la au pipeline de build. Un asset fingerprinté doit pouvoir recevoir une politique longue sans opération manuelle de purge pour chaque release. Surveillez les changements de CDN et les nouveaux types MIME afin qu’ils n’échappent pas aux règles prévues.

Clôturer le diagnostic

La bonne durée de cache dépend de la stabilité de l’URL et de votre capacité à la versionner. Favorisez la cohérence entre nom de fichier, en-têtes et processus de déploiement. Mesurez la réponse réellement servie et évitez aussi bien de figer une URL mutable que de revalider inutilement des octets immuables.

Construire une matrice de contrôle

Pour Cache-Control des ressources statiques, construisez une matrice qui sépare constat, intention, couche propriétaire et preuve finale. Le périmètre documentaire de cette page est volontairement borné : Distinguer cache long des fichiers versionnés et revalidation des ressources susceptibles de changer sous la même URL. Ajoutez au minimum le contexte de test, la valeur observée, le résultat attendu, l'origine technique supposée puis confirmée, et la méthode de revalidation. Quand plusieurs gabarits partagent le même composant, échantillonnez des cas représentatifs plutôt que de multiplier des constats identiques. Une anomalie ambiguë doit rester en revue jusqu'à ce qu'une preuve distingue clairement configuration, contenu et comportement réellement servi. Cette matrice permet aussi de vérifier qu'une correction locale ne masque pas un problème global et qu'un changement d'infrastructure n'est pas confondu avec une décision éditoriale.

Relier ce contrôle au reste du diagnostic

Ce sujet ne doit pas être traité isolément. Vérifiez les pages et contrôles liés /seo/performance-technique, /seo/cache-navigateur-performance, /seo/compression-brotli-gzip-performance, puis comparez leurs conclusions avec l'intention « cache control assets statiques performance ». Les sources officielles associées à cette page sont webdev_cache; elles bornent les affirmations externes et doivent être revalidées si leur documentation évolue. Ne transformez pas une recommandation Limpi en règle universelle : distinguez ce qui est imposé par une spécification, ce qui dépend d'un moteur ou navigateur et ce qui relève d'un choix d'implémentation. Terminez par un contrôle de cohérence entre title, H1, contenu visible, canonical, maillage et données structurées. Si deux signaux se contredisent, conservez le cas en revue au lieu de conclure sur la base d'un seul outil. Consignez enfin la date du contrôle, le gabarit concerné et le propriétaire de la correction afin de pouvoir rejouer exactement le même scénario après une évolution du site.

Sources officielles

Les règles des moteurs et des fournisseurs de crawlers peuvent évoluer. Les affirmations techniques de cette page sont bornées par les documentations officielles ci-dessous.

• webdev cache