La première visite sur un site télécharge forcément toutes ses ressources. Mais la deuxième visite, elle, peut aller beaucoup plus vite — à condition que le serveur ait correctement indiqué au navigateur ce qu'il a le droit de réutiliser sans repasser par le réseau. C'est exactement le rôle de l'en-tête Cache-Control.
Cache-Control plutôt que Expires
L'ancien en-tête Expires indiquait une date fixe d'expiration, ce qui posait un problème pratique : il fallait recalculer cette date pour chaque fichier. L'en-tête Cache-Control, plus moderne, raisonne en durée relative via la directive max-age, exprimée en secondes à partir du moment de la requête. Les deux en-têtes peuvent coexister pour des raisons de compatibilité, mais Cache-Control a priorité et reste la référence actuelle.
Les directives qui comptent vraiment
- max-age=31536000 : indique au navigateur de conserver la ressource jusqu'à un an sans revérifier auprès du serveur. Adapté aux fichiers qui ne changent jamais une fois publiés (images, polices, scripts versionnés).
- public vs private : public autorise la mise en cache par des intermédiaires partagés (CDN, proxy) en plus du navigateur ; private réserve la mise en cache au seul navigateur de l'utilisateur, pertinent pour du contenu personnalisé.
- no-cache : autorise la mise en cache, mais impose une revalidation auprès du serveur avant chaque réutilisation (via ETag ou Last-Modified). Ce n'est pas l'équivalent de « ne jamais mettre en cache », contrairement à ce que son nom suggère.
- no-store : interdit totalement la mise en cache, à réserver aux contenus sensibles qui ne doivent jamais être conservés (données bancaires, informations confidentielles).
- immutable : signale qu'un fichier ne changera jamais pendant sa durée de vie, ce qui évite même la revalidation en arrière-plan que certains navigateurs effectuent par prudence.
Le casse-tête des fichiers qui changent
Le vrai défi arrive quand un fichier CSS ou JavaScript est mis à jour après une modification du site : si le navigateur l'a mis en cache pour un an, comment lui faire comprendre qu'une nouvelle version existe ? La solution standard consiste à inclure un identifiant de version dans le nom du fichier lui-même (par exemple style.a3f21c.css au lieu de style.css), généré automatiquement par l'outil de build du site. Chaque modification produit un nouveau nom de fichier, donc une nouvelle URL que le navigateur n'a jamais vue, ce qui contourne proprement le cache long sans jamais servir une version périmée.
Ce qui doit rester en cache court, voire sans cache
Toutes les ressources ne doivent pas être mises en cache longtemps. Le document HTML principal d'une page qui affiche du contenu dynamique (prix, stock, contenu personnalisé) demande généralement une durée de cache très courte, voire aucune, pour éviter d'afficher une version obsolète à l'utilisateur. La règle générale : plus une ressource est statique et versionnée, plus son cache peut être long ; plus son contenu change souvent, plus le cache doit rester court.
L'en-tête Vary, un complément souvent oublié
Quand un serveur peut renvoyer des versions différentes d'une même ressource selon le contexte (par exemple une version compressée en Brotli et une version non compressée pour un vieux navigateur), l'en-tête Vary indique aux caches intermédiaires (navigateur, CDN) sur quels critères distinguer ces versions, le plus courant étant Vary: Accept-Encoding. Sans cet en-tête, un cache intermédiaire pourrait servir par erreur une version compressée à un client qui ne sait pas la décompresser, ou inversement gaspiller de la bande passante en servant une version non compressée à tout le monde par prudence.
Ce détail compte particulièrement dès qu'un CDN est placé devant votre hébergement : une mauvaise gestion de Vary peut provoquer un affichage cassé pour certains visiteurs, alors que le réglage de Cache-Control lui-même était pourtant correct.
Quelle différence entre no-cache et no-store ?
No-cache autorise la conservation de la ressource mais exige une vérification auprès du serveur avant réutilisation. No-store interdit toute conservation, même temporaire, et convainc le navigateur de toujours tout retélécharger.
Comment vérifier les en-têtes de cache actifs sur mon site ?
Les outils de développement du navigateur affichent les en-têtes de réponse de chaque requête dans l'onglet réseau. Des outils en ligne comme GTmetrix ou PageSpeed Insights signalent aussi explicitement les ressources sans en-tête de cache approprié.
Une configuration de cache cohérente demande souvent d'ajuster la configuration du serveur web (Apache ou Nginx) ou d'utiliser un plugin de cache adapté selon votre CMS. Les offres d'hébergement mutualisé et d'hébergement WordPress de VSP TECH intègrent déjà des réglages de cache pertinents par défaut, et un VPS Linux permet de les personnaliser finement selon les besoins spécifiques de votre site.
