Cache navigateur
Le cache navigateur est la copie que le navigateur d'un visiteur conserve des fichiers déjà téléchargés, pour ne pas les redemander à chaque page.
Définition
Le cache navigateur est la copie que le navigateur d’un visiteur conserve des fichiers déjà téléchargés, pour ne pas les redemander à chaque page. Il ne se règle pas dans le navigateur mais dans la réponse du serveur, par des en-têtes qui annoncent combien de temps chaque fichier reste valable.
Que garde le navigateur, et pendant combien de temps ?
Ce que le serveur lui a autorisé à garder, pour la durée que le serveur a annoncée.
À chaque fichier servi, le serveur peut joindre des en-têtes qui décrivent sa durée de validité. Le navigateur les enregistre avec le fichier. Tant que la durée n’est pas écoulée, il réutilise sa copie sans rien demander : aucune requête n’est envoyée, le serveur ne voit même pas passer la visite. Régler ces durées de vie sans casser les mises en ligne fait partie d’un travail de performance suivi.
Deux en-têtes coexistent pour dire cette durée. Expires annonce une date d’expiration absolue, c’est le mécanisme historique. Cache-Control annonce une durée relative, exprimée en secondes par la directive max-age, et c’est celui qui fait foi aujourd’hui. La spécification est explicite : quand une réponse porte un max-age, le destinataire doit ignorer l’en-tête Expires.
Constat de terrain. Mesuré le 29 août 2026 sur ilti.fr, la feuille de style principale du thème est servie avec deux annonces de durée contradictoires : un en-tête Expires daté d’un an plus tard, produit par une règle du fichier de configuration Apache, et un en-tête Cache-Control: public, max-age=2592000, soit trente jours. C’est le second qui s’applique, et l’écart entre les deux n’est visible nulle part dans une interface d’administration. Il ne se constate qu’en lisant les en-têtes de la réponse.
Pourquoi une durée longue oblige à changer les noms de fichiers
Parce qu’un fichier gardé un an est un fichier qu’on ne peut plus corriger chez le visiteur.
C’est le compromis central, et la source de la quasi-totalité des accidents. Une durée courte permet de corriger vite, mais fait revenir le navigateur souvent. Une durée longue supprime ce trafic, mais fige la copie détenue par les visiteurs déjà venus : ils continueront de recevoir l’ancienne feuille de style ou l’ancien script jusqu’à l’expiration, sans aucun moyen de s’en apercevoir.
La façon de sortir de ce compromis n’est pas de raccourcir la durée, c’est de changer l’adresse du fichier à chaque modification. Un numéro de version dans le nom ou dans l’adresse suffit : le navigateur ne reconnaît pas cette nouvelle adresse, il télécharge le fichier neuf, et la copie ancienne devient sans objet. C’est exactement ce que fait WordPress lorsqu’il ajoute un paramètre de version aux feuilles de style et aux scripts déclarés par un thème ou une extension.
Le raccourci à éviter. Répondre à un visiteur qui voit une ancienne version en lui demandant de vider son cache. Cela règle son cas et laisse le problème entier pour tous les autres. Si un visiteur voit une ancienne version, c’est que l’adresse du fichier n’a pas changé alors que son contenu, lui, a changé. La correction se fait côté serveur, une fois, pour tout le monde.
Ce qui se met en cache, et ce qui ne doit surtout pas
Les fichiers dont l’adresse peut changer, oui. La page elle-même, presque jamais dans le navigateur.
| Type de fichier | Durée raisonnable | Condition |
|---|---|---|
| Feuilles de style, scripts | Longue | À condition que l’adresse change à chaque modification |
| Polices de caractères | Longue | Elles changent très rarement |
| Images de contenu | Longue | Un remplacement se fait par un nouveau fichier, pas par un écrasement |
| Pages HTML | Très courte ou nulle | Sinon un contenu corrigé reste invisible pour les visiteurs déjà venus |
| Pages personnalisées, panier, compte client | Aucune | Une copie conservée exposerait le contenu d’une session à une autre visite |
Cette distinction explique pourquoi le cache navigateur ne remplace pas le cache de page et ne s’y substitue jamais. Le cache de page évite au serveur de recalculer la page pour tout le monde. Le cache navigateur évite à un visiteur déjà venu de retélécharger les fichiers qui l’accompagnent. Ils agissent à deux endroits différents et se cumulent.
Ce qu’il change réellement dans la mesure
Rien pour un nouveau visiteur, beaucoup pour un visiteur qui revient.
C’est la limite qu’il faut avoir en tête avant d’en attendre trop. Un outil de test charge la page sans rien en cache, comme un visiteur qui découvre le site : le cache navigateur n’y apparaît donc pas, ou seulement sous forme de recommandation. Il n’améliore ni le temps de réponse du serveur ni le premier affichage d’un nouveau venu.
Son effet se lit ailleurs : dans les visites de retour, dans la navigation de page en page à l’intérieur du site, et dans la charge retirée au serveur. Sur un hébergement mutualisé, où le nombre de requêtes simultanées est une ressource comptée, ce trafic évité a une valeur qui ne se voit dans aucun score.
Trois caches se superposent, et purger l’un ne purge pas les autres
C’est ce qui explique la plupart des situations où une correction déployée reste invisible.
Entre le code du site et l’écran d’un visiteur, il y a rarement une seule copie. Il y en a le plus souvent trois, empilées, avec chacune sa durée de vie et son propre bouton de purge.
| Couche | Où elle vit | Comment on la vide |
|---|---|---|
| Cache d’extension | Dans les fichiers du site, sur le serveur | Depuis l’administration du site |
| Cache de bord de l’hébergeur | Devant le site, chez l’hébergeur | Par un outil de l’hébergeur, pas toujours le même bouton |
| Cache navigateur | Sur l’appareil de chaque visiteur | Hors d’atteinte, seule l’expiration ou un changement d’adresse le contourne |
Cette superposition se vérifie en lisant les en-têtes de la réponse, où la couche de bord laisse en général une trace indiquant si la page a été servie depuis sa copie ou recalculée. C’est le contrôle à faire en premier quand une modification ne se voit pas : il dit tout de suite si le problème est devant le site ou dans le navigateur du visiteur.
La conséquence est que « j’ai vidé le cache » ne veut rien dire tant qu’on n’a pas précisé lequel. Purger l’extension et constater que la page est inchangée n’indique pas que la correction a échoué : cela indique le plus souvent qu’une deuxième couche, plus proche du visiteur, sert encore l’ancienne version. Et la troisième, celle qui vit chez le visiteur, ne se purge pas à distance, ce qui ramène à la seule solution durable : faire changer l’adresse du fichier à chaque modification.
Questions fréquentes
Comment savoir quelle durée mon site annonce ?
En lisant les en-têtes de la réponse pour un fichier donné, dans l’onglet réseau des outils de développement du navigateur ou avec un client en ligne de commande. Ce sont les seuls endroits où l’information est fiable, parce que l’en-tête réellement servi peut différer de ce qu’annonce une interface de réglages.
Une extension de cache suffit-elle à le configurer ?
La plupart proposent une option qui écrit les règles nécessaires. Le point de vigilance est qu’elles ne sont pas seules à écrire ces règles : le serveur, l’hébergeur et parfois un service intermédiaire en ajoutent aussi. C’est ainsi que naissent des réponses portant deux durées contradictoires, et seule la lecture des en-têtes tranche.
Pourquoi je vois mes modifications et pas mon client ?
Parce que votre navigateur a rechargé les fichiers, souvent parce que vous êtes connecté à l’administration, et pas le sien. Tant que l’adresse du fichier modifié n’a pas changé, un visiteur venu récemment garde sa copie. La vérification se fait en navigation privée, sur un appareil qui n’est jamais venu.
Vider le cache d’une extension suffit-il ?
Non, et c’est une confusion fréquente. Purger le cache d’une extension vide les copies conservées sur le serveur. Les copies déjà déposées dans les navigateurs des visiteurs, elles, sont hors d’atteinte : rien sur le serveur ne peut les révoquer avant leur date d’expiration. Seul un changement d’adresse du fichier les contourne.
Sources
Et sur votre site ?
Une définition ne dit pas si vous êtes concerné.
L'audit gratuit répond dans votre cas : état technique, temps de chargement, et ce que Google voit réellement de vos pages. Un constat écrit, sans engagement et sans jargon.