Optimiser le cache pour les visites répétées
Servez la bonne version de vos fichiers tout en limitant les requêtes réseau lors des visites répétées grâce à une stratégie de cache moderne.
Les performances du premier chargement sont importantes, mais elles ne disent pas tout. Lorsqu’un visiteur revient sur votre site, son navigateur s’appuie sur le cache HTTP pour afficher le contenu plus vite et économiser des données. Or les métriques de performance comme les Core Web Vitals tiennent compte de toutes les visites, pas uniquement de la première. Soigner le comportement de votre cache HTTP lors des visites répétées est donc un levier SEO direct : des pages qui se rechargent vite et affichent toujours la bonne version envoient un signal de qualité aux moteurs comme aux internautes.
L’enjeu est double : garantir que vos utilisateurs reçoivent la version la plus récente de votre site, tout en téléchargeant le moins de données possible pour y parvenir. Trouver cet équilibre demande de comprendre comment le navigateur décide de réutiliser ou non un fichier déjà stocké.
On parle beaucoup du premier chargement et on oublie que les Core Web Vitals tiennent compte de toutes les visites, y compris les retours. Un cache mal configuré sert des versions incohérentes et gâche ce gain facile. Ma règle : revalider ce qui change, mettre en cache durablement avec des URL à empreinte ce qui ne bouge pas.
Pourquoi le cache par défaut crée des versions incohérentes
En l’absence de directive explicite, de nombreux serveurs appliquent encore un comportement hérité fondé sur l’en-tête Last-Modified. Chaque fichier est alors conservé pendant environ 10 % de son âge actuel. Un fichier créé il y a un mois est ainsi mis en cache pour trois jours supplémentaires environ.
Le problème, avec des sites étroitement imbriqués, c’est que les fichiers ne sont pas tous modifiés au même instant. Un visiteur peut se retrouver avec le JavaScript d’une version et le CSS d’une autre, ce qui produit ce fameux cache obsolète. Les développeurs savent forcer le rechargement, mais l’internaute ordinaire, lui, reste bloqué sur une version cassée sans le savoir.
La valeur par défaut moderne : revalider à chaque visite
L’approche recommandée aujourd’hui consiste à ne rien mettre en cache durablement par défaut et à laisser un CDN rapprocher le contenu de vos utilisateurs ; le cache précédent/suivant complète utilement ce dispositif. À chaque visite, le navigateur interroge le réseau pour vérifier si le fichier est à jour. Cette vérification est peu coûteuse en octets : si rien n’a changé, le serveur répond par une courte réponse 304. L’inconvénient reste la latence, car l’aller-retour réseau est toujours nécessaire.
Configurez votre hébergement pour répondre avec cet en-tête de revalidation systématique.
Cache-Control: max-age=0,must-revalidate,publicLes URL à empreinte pour une mise en cache durable
À l’opposé, les fichiers dont le nom inclut un hachage de leur contenu, comme sitecode.af12de.js, ont toujours un nom unique. Vous pouvez donc demander au navigateur de les conserver très longtemps sans risque d’obsolescence : si le contenu change, le nom change aussi. Générez ces empreintes automatiquement avec un bundler (Webpack, Rollup), jamais à la main. Ce principe vaut aussi pour le CSS, les icônes et les fichiers de données immuables.
Voici les principales stratégies selon le type de ressource et l’en-tête Cache-Control associé.
| Type de ressource | En-tete Cache-Control | Comportement |
|---|---|---|
Valeur par défaut (HTML, contenu d’actualité) |
max-age=0,must-revalidate,public |
Revalidation réseau à chaque visite |
Fichier à empreinte (JS, CSS, icônes) |
max-age=31536000,immutable |
Conservé un an, considéré comme permanent |
Ressource intermédiaire à durée de vie |
max-age=3600,immutable,public |
Conservé une heure sans nouvelle requête |
La directive no-cache est trompeuse : elle n’interdit pas le stockage, elle impose une revalidation avant chaque réutilisation. Pour une mise en cache longue, le mot-clé immutable est indispensable, sans quoi Safari et Firefox peuvent ignorer votre max-age et interroger quand même le serveur.
À faire
- définir une valeur par défaut de revalidation
- réserver le cache long aux fichiers à empreinte
- choisir une durée intermédiaire pour les ressources à durée de vie connue
À éviter
- laisser le comportement par défaut hérité de 1999
- mettre en cache durablement vos pages HTML conviviales
- générer les hachages manuellement
- cacher longuement des contenus d’actualité consultés une seule fois
Points clés à retenir
- Adopter une valeur Cache-Control par défaut de revalidation systématique.
- Mettre en cache pour un an les seuls fichiers dont le nom porte une empreinte de contenu.
- Réserver les durées intermédiaires aux ressources à durée de vie prévisible.
- Ne jamais figer durablement les URL HTML conviviales que vous ne pouvez pas renommer.
- Penser que votre site mis en cache existe par morceaux chez vos utilisateurs.
Une stratégie de cache réfléchie accélère les visites répétées sans servir de versions obsolètes.
Quiz : testez vos connaissances
Quiz : testez vos connaissances
-
Quelle est l'approche par défaut recommandée aujourd'hui pour le cache ?
- Laisser le comportement hérité fondé sur Last-Modified
- Mettre en cache durablement tout le site par défaut
- Ne rien mettre en cache durablement par défaut et revalider à chaque visite
L’approche moderne consiste à ne rien mettre en cache durablement par défaut et à revalider à chaque visite, en laissant un CDN rapprocher le contenu des utilisateurs.
-
Que fait réellement la directive no-cache ?
- Elle interdit tout stockage de la réponse
- Elle autorise le stockage mais impose une revalidation avant chaque réutilisation
- Elle force une mise en cache de longue durée
La directive
no-cacheest trompeuse : elle n’interdit pas le stockage, elle impose une revalidation avant chaque réutilisation. Pour interdire le stockage, il fautno-store. -
Sur quels fichiers réserver une mise en cache durable ?
- Sur les contenus d'actualité consultés une seule fois
- Sur les pages HTML conviviales
- Sur les fichiers à empreinte, dont le nom inclut un hachage du contenu
Les fichiers à empreinte, comme
sitecode.af12de.js, ont un nom unique qui change avec le contenu. Vous pouvez donc les conserver très longtemps sans risque d’obsolescence.
À propos de l'auteur
Besoin d'un accompagnement SEO ?
Votre stratégie de cache freine peut-être vos visites répétées sans que vous le sachiez.