Cache navigateur

Le cache navigateur est l'espace où un navigateur conserve une copie des ressources déjà téléchargées (images, feuilles de style, scripts, polices, pages HTML) pour les réutiliser lors d'une visite suivante sans repasser par le réseau. Il est piloté par des en-têtes HTTP envoyés par le serveur, Cache-Control, ETag, Last-Modified, Expires, et normalisé par la RFC 9111. Bien réglé, il accélère les visites répétées, allège le serveur et améliore les Core Web Vitals mesurés sur le terrain.

Définition détaillée du cache navigateur

Aller chercher une ressource sur le réseau est lent et coûteux : chaque fichier demande un ou plusieurs allers-retours avec le serveur, la page ne s'affiche pas tant que ses ressources critiques ne sont pas arrivées, et chaque octet compte pour un visiteur au forfait mobile limité. Le cache HTTP du navigateur est la première ligne de défense contre les requêtes inutiles : avant d'envoyer une requête, le navigateur regarde s'il possède déjà une réponse valide pour cette URL et, si oui, l'utilise sans contacter le serveur.

La spécification HTTP distingue deux familles de caches. Le cache privé est lié à un seul client, typiquement le cache du navigateur : il peut stocker des réponses personnalisées (une page de compte, un panier). Le cache partagé se situe entre le client et le serveur (proxy, CDN, cache applicatif) et sert la même copie à de nombreux utilisateurs. Les en-têtes envoyés par le serveur s'adressent aux deux, avec des directives pour les distinguer.

Le cache navigateur ne doit pas être confondu avec trois autres mécanismes qui portent le même mot. Le cache serveur (ou cache applicatif) conserve des pages générées pour ne pas les recalculer à chaque requête : il accélère le serveur, pas le navigateur. Le cache du CDN est un cache partagé placé au plus près des visiteurs. Le cache Google, enfin, était la copie d'une page telle que Googlebot l'avait vue, accessible depuis les résultats de recherche ; Google l'a retiré de ses résultats en 2024. Ce sont trois sujets distincts, réglés à des endroits différents.

Comment fonctionne le cache HTTP

La fraîcheur : Cache-Control et Expires

Le serveur indique combien de temps une réponse peut être réutilisée sans vérification. L'en-tête de référence est Cache-Control, dont les directives principales sont :

• max-age=N : la réponse est « fraîche » pendant N secondes. max-age=31536000 correspond à un an.
• no-cache : la réponse peut être stockée, mais doit être revalidée auprès du serveur avant chaque réutilisation. Le nom prête à confusion : ce n'est pas une interdiction de mise en cache.
• no-store : la réponse ne doit être stockée nulle part. À réserver aux contenus sensibles, car cette directive rend aussi la page inéligible au cache de navigation avant/arrière (voir plus bas).
• private : seul le cache du navigateur peut stocker la réponse, pas les caches partagés. public : tout cache peut la stocker.
• immutable : la ressource ne changera jamais, inutile de la revalider même quand l'utilisateur recharge la page.
• stale-while-revalidate=N : le cache peut servir la copie périmée pendant N secondes, le temps d'aller en chercher une neuve en arrière-plan.

L'en-tête Expires est l'ancêtre de max-age, hérité de HTTP/1.0 : il donne une date absolue d'expiration plutôt qu'une durée. Si les deux sont présents, max-age l'emporte, et MDN juge qu'il « n'est plus nécessaire de fournir Expires » maintenant que HTTP/1.1 est généralisé.

La validation : ETag et Last-Modified

Quand une réponse en cache n'est plus fraîche, le navigateur ne la jette pas : il demande au serveur si elle est encore bonne. Deux en-têtes de réponse rendent cette question possible. ETag est un identifiant de version du contenu (souvent une empreinte) ; Last-Modified est la date de dernière modification. Le navigateur les renvoie dans une requête conditionnelle, If-None-Match pour l'ETag ou If-Modified-Since pour la date. Si la ressource n'a pas changé, le serveur répond par un code HTTP 304 Not Modified, sans corps : quelques centaines d'octets au lieu du fichier entier. L'ETag, fondé sur le contenu, est en général préféré à la date, dont la précision se limite à la seconde.

Sans en-tête : le cache heuristique

Une idée reçue veut qu'une réponse sans Cache-Control ne soit pas mise en cache. C'est l'inverse : HTTP est conçu pour mettre en cache autant que possible, et la RFC 9111 autorise un cache à calculer lui-même une durée de fraîcheur « heuristique » à partir de la date Last-Modified, en suggérant une fraction de l'intervalle écoulé depuis cette date, « typiquement 10 % ». Une page non modifiée depuis un an pourrait ainsi être servie depuis le cache pendant plus d'un mois, sans que l'éditeur l'ait décidé. D'où la recommandation de MDN : donner explicitement un Cache-Control à toutes les réponses.

La stratégie recommandée

MDN et la documentation Lighthouse convergent vers une même règle en deux volets, selon que l'URL d'une ressource change ou non quand son contenu change.

• Ressources versionnées (URL portant une empreinte du contenu, comme style.a1b2c3.css) : cache long et sans revalidation, Cache-Control: max-age=31536000, immutable. Quand le fichier change, son nom change, et le navigateur va chercher la nouvelle URL. Lighthouse conseille de « mettre en cache les ressources statiques immuables pendant longtemps, un an ou plus ».
• Ressources non versionnées (la page HTML elle-même, un fichier dont l'URL est stable) : durée courte ou nulle, avec revalidation, Cache-Control: no-cache accompagné d'un ETag ou d'un Last-Modified. Le navigateur garde la copie, vérifie à chaque fois, et ne retélécharge que si le contenu a changé.

Cette règle vaut aussi pour Google. Sa documentation sur le SEO JavaScript (mise à jour le 4 mars 2026) indique que « Googlebot met en cache de façon agressive afin de réduire les requêtes réseau et l'usage de ressources », que son service de rendu « peut ignorer les en-têtes de cache », et recommande pour cette raison l'empreinte de contenu dans le nom des fichiers : un script mis à jour sous la même URL peut rester dans l'ancienne version du côté de Google pendant longtemps.

Un cas à part concerne les réponses qui varient selon la requête. L'en-tête Vary indique quels en-têtes de requête différencient les versions : Vary: Accept-Language évite qu'une page en anglais soit servie depuis le cache à un visiteur qui demande le français. MDN déconseille en revanche Vary: User-Agent, dont les variantes sont si nombreuses que le cache ne sert plus à rien.

Ce que le cache change en SEO et en performance

Le cache navigateur ne joue aucun rôle sur la première visite : tout est à télécharger. Son effet se mesure sur les visites suivantes et sur la navigation à l'intérieur du site, où les ressources communes (feuilles de style, scripts, polices, logo) sont déjà présentes. C'est précisément ce que mesurent les données de terrain du CrUX (Chrome User Experience Report), qui agrègent toutes les visites, alors qu'un test de laboratoire dans Lighthouse ou PageSpeed Insights part d'un cache vide. Un site dont les ressources sont bien mises en cache voit son LCP de terrain s'améliorer sans que le score de laboratoire ne bouge.

Lighthouse signale les ressources statiques mal mises en cache dans l'audit « Serve static assets with an efficient cache policy » : sont concernés les polices, images, médias, scripts et feuilles de style renvoyés avec un code 200, 203 ou 206, et sans politique no-cache explicite. Le rapport liste chaque URL, sa durée de cache actuelle et une estimation des octets économisés.

Un second cache, distinct du cache HTTP, compte pour la navigation : le cache avant/arrière (back/forward cache, bfcache). Il conserve en mémoire un instantané complet de la page quittée, JavaScript compris, pour la restaurer instantanément quand l'utilisateur revient en arrière. Selon les données d'usage de Chrome citées par web.dev, une navigation sur dix sur ordinateur et une sur cinq sur mobile est un retour ou une avance. Deux pratiques rendent une page inéligible : un Cache-Control: no-store sur le document HTML lui-même, et un écouteur d'événement unload. Les outils qui collectent les Core Web Vitals, dont le CrUX, comptent les restaurations depuis le bfcache comme des visites distinctes, très rapides.

Mettre en place et vérifier

• Côté serveur : les en-têtes se règlent dans la configuration d'Apache (mod_expires, mod_headers), de Nginx (expires, add_header), ou dans les règles du CDN. La plupart des extensions de cache pour CMS ajoutent aussi ces en-têtes.
• Le versionnement : les outils de construction (Webpack, Vite et équivalents) génèrent les empreintes dans les noms de fichiers ; beaucoup de thèmes et d'extensions ajoutent à défaut un paramètre ?ver=, moins fiable puisque certains caches ignorent la chaîne de requête.
• La vérification : l'onglet Réseau des outils de développement de Chrome affiche, pour chaque ressource, l'en-tête Cache-Control reçu et, dans la colonne Taille, la mention « (memory cache) » ou « (disk cache) » quand la réponse vient du cache. Un rechargement normal revalide les ressources ; un rechargement forcé les ignore.
• Le bfcache : l'onglet Application des outils de développement de Chrome comporte un test « Back/forward cache » qui indique les raisons d'inéligibilité d'une page.

Les erreurs fréquentes

• Un cache long sur une URL stable : la feuille de style est modifiée, mais les visiteurs réguliers voient l'ancienne pendant des mois. Cache long et versionnement vont ensemble.
• Aucun en-tête du tout, qui laisse chaque navigateur et chaque proxy appliquer son propre calcul heuristique.
• no-store partout par prudence, qui interdit tout cache, y compris le bfcache, et pénalise chaque navigation.
• Croire que no-cache désactive le cache : il impose une revalidation, ce qui est précisément la bonne pratique pour le HTML.
• Un ETag qui change à chaque serveur derrière un équilibreur de charge, ce qui rend la validation inopérante.
• Juger le cache sur un test de laboratoire, qui part toujours d'un cache vide et ne voit donc aucun de ses bénéfices.

FAQ

Le cache navigateur a-t-il un effet sur le référencement ?

Indirectement. Il n'entre pas dans les critères de classement, mais il améliore les Core Web Vitals mesurés sur le terrain (visites répétées, navigation interne), qui font partie de l'expérience sur la page évaluée par Google. Il allège aussi le serveur, ce qui profite à toutes les requêtes, dont celles de Googlebot. Google lui-même met en cache de façon agressive et recommande le versionnement des fichiers pour que ses robots voient les mises à jour.

Quelle durée de cache choisir ?

Un an (max-age=31536000) avec immutable pour toute ressource dont l'URL change quand le contenu change : scripts, styles, images et polices versionnés. Pour la page HTML et tout fichier à URL stable, no-cache avec un ETag ou un Last-Modified : le navigateur garde la copie mais vérifie à chaque fois. La documentation Lighthouse rappelle qu'une durée plus longue n'est pas toujours meilleure, c'est le couple durée et versionnement qui compte.

Quelle différence entre no-cache et no-store ?

no-cache autorise le stockage mais impose une revalidation avant chaque réutilisation : c'est un réglage de fraîcheur, pas une interdiction. no-store interdit tout stockage, dans le navigateur comme dans les caches intermédiaires, et rend la page inéligible au cache avant/arrière. no-store se réserve aux contenus sensibles.

Que se passe-t-il si le serveur n'envoie aucun en-tête de cache ?

Le navigateur calcule lui-même une durée de fraîcheur à partir de la date Last-Modified, en général 10 % du temps écoulé depuis cette date, comme le décrit la RFC 9111. Une page non modifiée depuis un an peut donc être servie depuis le cache pendant un mois sans revalidation. Pour garder la main, il faut envoyer un Cache-Control explicite sur toutes les réponses.

Comment vérifier qu'une ressource vient du cache ?

Dans l'onglet Réseau des outils de développement de Chrome, la colonne Taille affiche « (memory cache) » ou « (disk cache) » pour les réponses servies sans réseau, et le code 304 pour celles revalidées sans retéléchargement. Lighthouse et PageSpeed Insights signalent par ailleurs les ressources statiques dont la durée de cache est jugée trop courte.

En résumé

• Cache navigateur : la copie locale des ressources déjà téléchargées, réutilisée sans réseau lors des visites suivantes ; normalisé par la RFC 9111.
• Fraîcheur : Cache-Control (max-age, no-cache, no-store, private, public, immutable, stale-while-revalidate) ; Expires est l'ancêtre de max-age.
• Validation : ETag et Last-Modified, requêtes conditionnelles If-None-Match et If-Modified-Since, réponse 304 sans corps.
• Stratégie : un an et immutable sur les fichiers versionnés, no-cache avec ETag sur le HTML ; sans en-tête, le navigateur applique une heuristique (environ 10 % de l'âge).
• SEO et performance : effet sur les visites répétées et les Core Web Vitals de terrain, pas sur la première visite ni sur les tests de laboratoire ; Googlebot met en cache de façon agressive.
• À distinguer : cache serveur, cache CDN, cache Google, et cache avant/arrière (bfcache), rendu inopérant par no-store et par l'événement unload.

Abondance c'est aussi des audits SEO, un service de contenus et des formations en e-learning !