Votre site retélécharge son logo à chaque visite ? Le cache navigateur est mal réglé
Un visiteur qui revient sur votre site le lendemain ne devrait pas retélécharger votre logo, vos polices et vos scripts. Pourtant, sur une grande partie des sites vitrines que nous auditons, chaque page coûte autant à la dixième visite qu'à la première. À l'inverse, d'autres sites gardent tout en cache si longtemps que le client ne voit jamais les nouveaux tarifs. Dans les deux cas, la cause est la même : des en-têtes de cache posés au hasard, ou jamais posés.
Dans cet article, vous allez découvrir :
- •Ce que votre navigateur garde en mémoire, et pourquoi une seconde visite devrait être quasi instantanée
- •Les en-têtes Cache-Control, ETag et Last-Modified expliqués simplement, avec les valeurs à utiliser selon le fichier
- •La différence concrète entre cache navigateur et cache CDN, et pourquoi il vous faut les deux
- •Comment Next.js et Vercel règlent tout ça à votre place (assets hashés, ISR) : la mécanique derrière le Lighthouse 100 de Sudparebrise
- •Les erreurs qui bloquent les mises à jour chez vos clients, et la vérification en deux minutes dans Chrome
Un bon cache ne fait pas gagner des millisecondes : il supprime des requêtes entières.
Qu'est-ce que le cache navigateur ?
Le cache navigateur est un espace de stockage local, sur l'appareil du visiteur, dans lequel Chrome, Safari ou Firefox conservent une copie des fichiers déjà téléchargés (images, CSS, JavaScript, polices, parfois pages HTML) pour les réutiliser sans les redemander au serveur. Son objectif : éviter un aller-retour réseau pour un fichier qui n'a pas changé.
Chaque fichier mis en cache est accompagné de règles envoyées par le serveur : combien de temps la copie reste valable, et comment vérifier si elle est toujours à jour. Sans ces règles, le navigateur improvise, et c'est rarement ce que vous voulez.
Ce qui se passe à la seconde visite
Quand une page demande un fichier, le navigateur regarde d'abord dans son cache. Trois scénarios sont possibles :
- •Copie fraîche : la durée de validité n'est pas écoulée. Le fichier est servi localement, aucune requête ne part. C'est le cas idéal, affiché « memory cache » ou « disk cache » dans les outils de développement.
- •Copie périmée, mais revalidable : le navigateur envoie une requête conditionnelle. Si le fichier n'a pas changé, le serveur répond
304 Not Modifiedsans renvoyer le contenu. Un aller-retour, mais pas de téléchargement. - •Absence ou interdiction de cache : requête complète, réponse
200, téléchargement intégral.
L'impact est direct sur le LCP (Largest Contentful Paint), la métrique Core Web Vitals qui mesure l'affichage de l'élément principal, souvent une image héro. Si elle sort du cache, le LCP d'un visiteur récurrent tombe à quelques dizaines de millisecondes. Nous détaillons ces métriques dans notre guide des Core Web Vitals ; retenez que le cache est le levier le moins coûteux pour les améliorer chez les visiteurs qui reviennent, ceux qui sont le plus près d'acheter.
Cache-Control, ETag, Last-Modified : les trois en-têtes à comprendre
La mise en cache d'un site web se pilote avec des en-têtes HTTP envoyés dans chaque réponse. Trois d'entre eux font l'essentiel du travail.
Cache-Control : la durée de vie
Cache-Control est l'en-tête qui dit au navigateur (et aux caches intermédiaires) combien de temps conserver une réponse et dans quelles conditions. Il remplace l'ancien en-tête Expires, qui fixait une date d'expiration absolue : si les deux sont présents, Cache-Control l'emporte.
| Directive | Ce qu'elle fait | Quand l'utiliser |
|---|---|---|
max-age=31536000 | Copie valable 1 an (en secondes) | Fichiers dont le nom contient un hash |
s-maxage=3600 | Durée valable uniquement pour les caches partagés (CDN) | HTML servi via CDN, à régler indépendamment du navigateur |
no-cache | Mettre en cache, mais revalider à chaque fois avant usage | HTML, données qui changent souvent |
no-store | Ne jamais stocker, nulle part | Pages privées, réponses contenant des données personnelles |
public / private | Autorise ou interdit les caches partagés | private pour tout contenu lié à un utilisateur connecté |
immutable | Promet que le fichier ne changera jamais à cette URL | Combiné à max-age long sur les assets hashés |
stale-while-revalidate=60 | Servir la copie périmée pendant 60 s tout en rafraîchissant en arrière-plan | HTML et API où un léger délai de mise à jour est acceptable |
no-cache : contrairement à ce que son nom suggère, il n'empêche pas la mise en cache, il impose une revalidation. Seul no-store interdit le stockage.
ETag et Last-Modified : la revalidation
Quand une copie est périmée, le navigateur doit pouvoir demander « est-ce que ça a changé ? » sans tout retélécharger. Deux en-têtes de validation s'en chargent :
- •
Last-Modified: la date de dernière modification du fichier. Le navigateur la renvoie dansIf-Modified-Since. - •
ETag: une empreinte (généralement un hash du contenu) qui identifie précisément une version. Le navigateur la renvoie dansIf-None-Match.
Si la version correspond, le serveur répond 304 Not Modified, sans corps de réponse. L'ETag est plus fiable que la date, car il ne dépend pas de l'horloge du serveur.
Expires et l'heuristique par défaut
Si un serveur n'envoie ni Cache-Control ni Expires, le navigateur ne renonce pas au cache : il applique une durée heuristique, en général 10 % du temps écoulé depuis Last-Modified. Un fichier modifié il y a dix mois peut donc rester en cache un mois entier sans que vous l'ayez décidé. C'est l'une des causes les plus courantes du fameux « le site ne se met pas à jour chez moi ».
À lire aussi : Vitesse de chargement : guide Core Web Vitals 2026 - les leviers qui pèsent le plus sur LCP, INP et CLS, et dans quel ordre les actionner.
Cache navigateur vs cache CDN : deux couches, pas une
Le cache CDN est une copie de vos réponses conservée sur les serveurs d'un réseau de diffusion de contenu (Vercel, Cloudflare, Fastly), au plus près de vos visiteurs. Là où le cache navigateur sert un seul utilisateur, le cache CDN sert tous les visiteurs d'une région à partir d'une seule réponse d'origine.
| Critère | Cache navigateur | Cache CDN |
|---|---|---|
| Où | Sur l'appareil du visiteur | Sur les serveurs de bordure du CDN |
| Qui en profite | Ce visiteur uniquement, sur ses visites suivantes | Tous les visiteurs, y compris la première visite |
| Directive principale | max-age | s-maxage (prioritaire sur max-age pour le CDN) |
| Purge | Impossible à distance : on ne vide pas le cache de milliers de navigateurs | Instantanée (purge par URL, par tag, ou redéploiement) |
Comment Next.js et Vercel gèrent le cache
C'est là que le choix de la stack compte. Sur un site WordPress classique, les en-têtes de cache dépendent de l'hébergeur et d'un plugin, et il faut les régler à la main. Avec Next.js sur Vercel, la stratégie décrite ci-dessus est appliquée par défaut.
Les assets immuables avec hash
Au moment du build, Next.js génère chaque fichier CSS et JavaScript sous un nom qui contient une empreinte de son contenu, dans le dossier /_next/static/. Si une ligne de code change, le hash change, donc l'URL change. Le serveur peut alors répondre sans risque :
Cache-Control: public, max-age=31536000, immutable
Un an de cache, et la promesse qu'il est inutile de revalider. Le problème de la mise à jour disparaît par construction : la nouvelle version du site référence de nouveaux fichiers, l'ancienne copie devient simplement inutilisée. C'est le cache busting par empreinte, la seule technique fiable.
Les pages HTML : revalidation côté navigateur, ISR côté CDN
Pour le HTML, Vercel impose au navigateur une revalidation à chaque chargement : le visiteur ne reste jamais bloqué sur une version obsolète. Côté CDN, en revanche, la page peut rester en cache pendant la durée que vous définissez.
C'est le rôle de l'ISR (Incremental Static Regeneration) : une page est générée une fois, servie depuis le cache CDN à tous les visiteurs, puis régénérée en arrière-plan quand sa durée de revalidation est écoulée (revalidate = 3600 pour une heure). Le premier visiteur après expiration reçoit encore l'ancienne version, instantanément, pendant que la nouvelle se construit : c'est le comportement stale-while-revalidate.
Pour les contenus qui doivent changer immédiatement, la revalidation à la demande (revalidatePath, revalidateTag) purge la page au moment où le contenu est modifié. Sur nos sites Strapi + Next.js, un webhook la déclenche à chaque publication : le client voit sa modification en ligne quelques secondes après avoir cliqué sur « Publier ».
Les images passées par next/image suivent la même logique : converties en WebP ou AVIF à la volée, puis mises en cache sur le CDN et dans le navigateur pour une durée réglée par minimumCacheTTL.
C'est cette combinaison (assets immuables, HTML revalidé, images optimisées et cachées) qui a permis au site de Sudparebrise d'atteindre un score Lighthouse de 100 après sa refonte, sans optimisation manuelle du cache. Découvrez la refonte et le SEO du site Sudparebrise pour voir ce que donne cette approche sur un site vitrine de PME.
Si vous hésitez sur la technologie de votre prochain site, notre article sur Next.js, le framework de référence pour un site en 2026 détaille les autres raisons de ce choix.
Les erreurs classiques et comment les corriger
Les mêmes problèmes reviennent d'un audit à l'autre. Ils tiennent presque tous en quatre cas.
Erreur 1 : le site ne se met pas à jour chez le client
Symptôme : vous avez changé le CSS ou publié une nouvelle photo, et le client voit toujours l'ancienne version. Vous lui dites de « vider le cache », et vous recommencez la semaine suivante.
Cause : un fichier a été mis en cache avec une durée longue alors que son URL ne change pas quand son contenu change : style.css avec un max-age d'un mois, une image remplacée sous le même nom, ou une page HTML sans en-tête, livrée à l'heuristique.
Correction : hash dans le nom des fichiers à durée longue ; no-cache sur le HTML et tout fichier à URL fixe. Dire aux visiteurs de vider leur cache n'est pas une solution : c'est l'aveu qu'il manque une règle.
Erreur 2 : aucun cache du tout
À l'opposé, certains sites envoient no-store partout, souvent pour corriger l'erreur 1 au plus vite. Chaque visite retélécharge tout, et Lighthouse le signale avec l'audit « Diffuser des ressources statiques avec une politique de cache efficace ». Correction : réserver no-store aux réponses réellement privées, et donner une durée longue à tout ce qui est statique et versionné.
Erreur 3 : mettre en cache ce qui ne doit pas l'être
Une page « Mon compte », un panier, une réponse d'API contenant un nom : marquées public derrière un CDN, elles peuvent être servies à un autre visiteur. Ces réponses doivent porter private, no-store.
Erreur 4 : confondre vider le cache navigateur et purger le CDN
Quand une modification n'apparaît pas, beaucoup vident leur cache navigateur, constatent que rien ne change, et concluent à un bug. En réalité, c'est souvent le cache CDN qui sert encore l'ancienne version. Vérifiez son en-tête (sur Vercel, x-vercel-cache: HIT, MISS ou STALE) avant d'accuser le navigateur.
Vérifier le cache dans les outils du navigateur
Pas besoin d'outil payant : Chrome ou Firefox suffisent, en deux minutes.
- 1.Ouvrez les outils de développement (F12) et l'onglet Réseau (Network).
- 2.Rechargez la page deux fois de suite, sans rechargement forcé.
- 3.Regardez la colonne Taille : les fichiers servis depuis le cache affichent « (memory cache) » ou « (disk cache) » au lieu d'un poids. Un
304indique une revalidation réussie, un200avec un poids un téléchargement complet. - 4.Cliquez sur un fichier et lisez ses en-têtes de réponse :
Cache-Control,ETag,Last-Modified,Age, et l'en-tête du CDN (x-vercel-cache,cf-cache-status). - 5.Cochez « Désactiver le cache » uniquement pour tester la première visite, puis décochez : sinon vous mesurez un comportement que vos visiteurs n'ont jamais.
En ligne de commande, curl -I https://votresite.fr/ renvoie les mêmes en-têtes, et l'audit Lighthouse liste les fichiers dont la politique de cache est trop courte. Sur un site bien configuré, vous devez voir des assets en max-age=31536000, immutable servis depuis le cache, un HTML revalidé côté navigateur et en HIT côté CDN, et aucune réponse personnalisée sans private ou no-store.
FAQ : cache navigateur
Sur chaque projet de création de site internet, ces en-têtes sont définis dès le déploiement, avec des assets versionnés et un HTML revalidé : c'est l'une des raisons du score Lighthouse 100 obtenu sur le site Sudparebrise.
Combien de temps faut-il garder un fichier en cache navigateur ?
max-age=31536000) pour tout fichier dont l'URL change avec son contenu : CSS, JavaScript et polices hashés, images versionnées. Une simple revalidation (no-cache) pour les fichiers à URL fixe comme les pages HTML. La durée dépend moins du type de fichier que de votre capacité à changer son URL.Comment vider le cache de son navigateur ?
Quelle est la différence entre no-cache et no-store ?
no-cache autorise le navigateur à stocker la réponse, mais l'oblige à vérifier auprès du serveur (via ETag ou Last-Modified) qu'elle est toujours valable avant de l'utiliser. no-store interdit tout stockage : la réponse n'est jamais écrite sur le disque. Le premier convient aux pages HTML, le second aux données privées.Le cache navigateur améliore-t-il le référencement ?
Un site rapide à la première visite, instantané à la seconde
Le cache navigateur n'est pas une optimisation de confort réservée aux gros sites. C'est la règle qui décide si vos visiteurs réguliers, ceux qui reviennent comparer ou prendre rendez-vous, trouvent un site instantané ou un site qui recharge tout. Trois en-têtes (Cache-Control, ETag, Last-Modified), deux couches (navigateur et CDN), un principe (durée longue seulement si l'URL change) : c'est tout ce qu'il y a à retenir.
Avec Next.js et Vercel, cette stratégie est appliquée par défaut, et c'est en partie pour cela que le site de Sudparebrise atteint un score Lighthouse de 100 sans bricolage. Si votre site présente l'un des symptômes décrits ici, un audit de ses en-têtes dit rapidement où agir.
Votre site se met mal à jour, ou charge tout à chaque visite ? Parlons de votre projet : nous auditons votre configuration de cache et vous disons ce qu'il faut corriger, ou refondre.
