Comment vérifier le cache navigateur d’un site ?

Par l’équipe Limpi. Les faits externes sont distingués des méthodes Limpi et aucune visibilité, position ou citation automatique n’est garantie.

Séparer les ressources qui peuvent vivre longtemps de celles qui changent

Le cache navigateur n’a pas une règle unique adaptée à tout le site. Un fichier JavaScript fingerprinté comme app.8f31c2.js peut être conservé longtemps parce qu’une nouvelle version produit une autre URL. Un document HTML ou une réponse personnalisée doit souvent être rafraîchi plus fréquemment. Commencez donc par classer CSS, JavaScript, images, polices, HTML, JSON et contenus dynamiques. Cette séparation évite d’appliquer un max-age massif à une ressource non versionnée ou, à l’inverse, de recharger systématiquement des assets qui restent identiques pendant des mois.

Lire les en-têtes réellement reçus par le navigateur

Inspectez Cache-Control, ETag, Last-Modified, Age et, selon l’architecture, les en-têtes propres au CDN. Distinguez no-cache, qui autorise le stockage mais impose une revalidation, de no-store qui interdit la conservation. Regardez aussi s-maxage pour les caches partagés. Une configuration peut être différente entre serveur d’origine et edge ; le navigateur ne voit que le résultat final. Testez une première visite puis une seconde pour observer si la ressource est réutilisée, revalidée avec une 304 ou téléchargée à nouveau. Cette observation est plus fiable qu’une lecture isolée de la configuration.

Vérifier le versionnement avant d’allonger la durée

Un cache long devient sûr lorsque l’URL change avec le contenu. Les hashes dans les noms de fichiers ou un manifeste de build permettent cette invalidation naturelle. Sans versionnement, un utilisateur peut conserver une ancienne feuille CSS ou un ancien script après un déploiement. Avant d’augmenter max-age, vérifiez donc comment le pipeline produit et référence les assets. Testez aussi une session ayant déjà visité le site : elle doit charger le nouveau HTML ou manifeste puis demander les nouvelles URLs. Une stratégie qui fonctionne seulement pour les nouveaux visiteurs reste incomplète.

Prendre en compte le CDN et les clés de cache

Les caches partagés peuvent utiliser hostname, chemin, paramètres, en-têtes ou cookies dans leur clé. Une mauvaise variation peut créer des copies inutiles ou, au contraire, servir un contenu personnalisé à la mauvaise audience. Vérifiez Vary et la politique du CDN pour les routes dynamiques. Lorsque vous utilisez des purges, testez leur portée et leur délai. Un cache navigateur efficace n’exige pas nécessairement les mêmes durées au niveau edge. Documenter les deux couches permet de comprendre pourquoi une ressource semble fraîche dans DevTools alors que l’origine a déjà publié une version différente.

Prioriser les fichiers lourds et répétés

Les gains sont généralement plus intéressants sur les ressources partagées par de nombreuses pages et téléchargées à chaque visite. Une image de quelques kilo-octets utilisée une fois a moins de portée qu’un bundle JavaScript, une police ou une feuille CSS répétée. Mesurez le volume transféré avec cache froid et chaud. Le cache améliore surtout les visites récurrentes ; il ne réduit pas nécessairement le coût du tout premier chargement. Cette distinction aide à expliquer pourquoi une optimisation peut être utile sans modifier une métrique de première visite de la même manière.

Tester la mise à jour après correction

Après avoir changé les en-têtes, chargez la page, rechargez-la puis déployez une nouvelle version d’un asset de test. Vérifiez que l’ancienne ressource est réutilisée quand elle doit l’être et que la nouvelle est récupérée dès que son URL change. Contrôlez les 304, la mémoire cache et les réponses du CDN. Si un purge est nécessaire pour un correctif urgent, testez cette procédure avant d’en avoir besoin en production. Une politique n’est réellement validée que lorsqu’elle gère à la fois la réutilisation normale et l’invalidation lors d’un changement.

Documenter la politique par famille de ressources

Écrivez une règle lisible pour les assets fingerprintés, images stables, polices, HTML et APIs. Reliez chaque règle au pipeline qui gère leur version. Lors d’un changement de CDN, framework ou build, rejouez les tests plutôt que supposer que les anciennes directives sont encore adaptées. Un suivi simple de quelques URLs représentatives peut détecter une régression. La clôture de l’alerte signifie que la durée de cache correspond au cycle de vie de la ressource et que le site sait toujours distribuer une nouvelle version de façon prévisible.

Checklist opérationnelle de validation

Pour clôturer ce contrôle sur cache navigateur, conservez au minimum une URL représentative, l’état avant modification, la règle ou le composant responsable et le résultat du test après correction. Vérifiez également la cohérence avec le parent /seo/performance-technique et les pages liées /seo/performance-technique, /seo/pourquoi-site-est-lent, /seo/ttfb-eleve. La décision doit respecter cette limite : Présenter Cache-Control et la réutilisation des ressources sans recommander une durée identique partout. Distinguer ressources versionnées et contenu susceptible de changer. Si plusieurs occurrences partagent la même cause, testez un échantillon puis confirmez le résultat par un crawl global. Si un cas reste ambigu, laissez-le en revue plutôt que d’appliquer une correction mécanique. Cette trace permettra de reproduire le diagnostic lors d’une prochaine refonte, migration ou évolution du CMS.

Sources officielles

Les règles des moteurs et des fournisseurs de crawlers peuvent évoluer. Les affirmations techniques de cette page sont bornées par les documentations officielles ci-dessous.

• webdev cache