Analyseur gratuit d'en-têtes Cache-Control

Le Cache-Control Header Analyzer est un outil en ligne gratuit qui analyse et aide à comprendre les en-têtes cache-control, avec un constructeur visuel et des recommandations de bonnes pratiques. Il fonctionne entièrement dans votre navigateur, sans installation ni inscription.

Toutes les directives Cache-Control, dont max-age, no-cache, no-store, public, private, must-revalidate et bien d'autres.

Oui — activez les directives dans le mode constructeur pour générer la chaîne de l'en-tête.

Oui, entièrement gratuit.

Absolument. Le Cache-Control Header Analyzer traite tout côté client, dans votre navigateur. Aucune donnée n'est téléversée ni stockée sur un serveur. Votre contenu reste privé sur votre appareil à tout moment.

Oui, le Cache-Control Header Analyzer est entièrement responsive et fonctionne sur les smartphones et tablettes. Vous pouvez l'utiliser sur tout appareil doté d'un navigateur web moderne, sans aucun téléchargement d'application.

Aucun compte ni inscription n'est nécessaire. Ouvrez simplement le Cache-Control Header Analyzer dans votre navigateur et commencez à l'utiliser immédiatement. Il n'y a ni page d'inscription ni restriction d'utilisation.

Saisissez simplement vos données dans le champ prévu, ajustez les réglages selon vos préférences, et l'outil les traitera instantanément. Vous pouvez ensuite copier le résultat dans le presse-papiers ou le télécharger.

Le Cache-Control Header Analyzer fonctionne dans tous les navigateurs modernes, dont Chrome, Firefox, Safari, Edge et Opera. Pour une expérience optimale, utilisez la dernière version de votre navigateur préféré.

Les deux définissent une durée de fraîcheur en secondes, mais elles visent des caches différents. max-age indique à tous les caches — y compris le navigateur du visiteur — combien de temps la réponse reste fraîche avant de devoir être récupérée à nouveau ou revalidée. s-maxage s'applique uniquement aux caches partagés comme les CDN et les proxys, et lorsqu'elle est présente, elle remplace max-age pour ces caches tout en laissant le max-age du navigateur inchangé. Cela permet de mettre en cache une réponse de façon agressive au niveau du nœud CDN tout en conservant une durée différente, souvent plus courte, dans le navigateur — par exemple public, max-age=3600, s-maxage=86400 pour un cache navigateur d'une heure et un cache edge d'un jour. Cet analyseur affiche le cache navigateur et le cache CDN sous forme de deux badges distincts : collez votre en-tête ci-dessus pour voir exactement combien de temps chaque couche conservera la réponse.

Malgré des noms proches, ces directives font des choses opposées. no-store interdit toute mise en cache : ni le navigateur ni aucun CDN ne peuvent conserver de copie, donc chaque requête retourne à l'origine. C'est le bon choix pour les réponses sensibles comme les pages bancaires ou les données de compte personnel. no-cache autorise en revanche le stockage de la réponse, mais le cache doit la revalider auprès du serveur d'origine avant de la resservir, de sorte que l'utilisateur reçoit toujours un contenu vérifié comme frais sans retéléchargement complet lorsque rien n'a changé. Un schéma courant consiste à utiliser no-cache pour le HTML afin que les nouvelles références de ressources apparaissent immédiatement après un déploiement, et à réserver no-store aux cas où la confidentialité l'exige. Collez un en-tête ci-dessus et l'analyseur classe chaque directive par catégorie — fraîcheur, revalidation ou audience — pour que le comportement soit clair en un coup d'œil.

max-age s'exprime toujours en secondes, et 31 536 000 secondes équivalent exactement à une année (60 x 60 x 24 x 365). C'est le maximum conventionnel car la plupart des recommandations en matière de cache considèrent qu'une année équivaut, en pratique, à une durée permanente. On la retrouve associée à immutable sur les ressources statiques avec empreinte — des fichiers dont le nom contient un hash du contenu, comme app.4f2a9c.js — car une nouvelle version produit un nouveau nom de fichier, si bien que l'ancien fichier n'a jamais besoin de changer et peut être mis en cache aussi longtemps que possible. La directive immutable indique en plus aux navigateurs de ne pas envoyer de requêtes de revalidation au rechargement pendant cette période. Calculer des durées à la main est source d'erreurs, c'est pourquoi cet outil reconvertit toute valeur de max-age ou s-maxage en unités lisibles comme des heures et des jours, ce qui permet de vérifier un en-tête avant de le déployer. Collez-en un ci-dessus pour le décoder instantanément.

Un contenu obsolète après un déploiement provient presque toujours d'un en-tête Cache-Control trop agressif sur le document HTML. Si la page a été envoyée avec un max-age élevé et sans directive de revalidation, les navigateurs et les CDN continuent de servir la copie mise en cache — avec ses anciennes références vers votre CSS et votre JavaScript — jusqu'à l'expiration de cette durée, si bien que les utilisateurs ne voient jamais le correctif. La solution sûre consiste à servir le HTML avec no-cache (ou un max-age très court associé à must-revalidate) afin qu'il soit revalidé à chaque visite et reflète immédiatement les nouvelles références de ressources, tout en réservant une mise en cache longue et immutable aux fichiers statiques hachés. Gardez à l'esprit que les caches edge des CDN obéissent à s-maxage indépendamment, si bien qu'un edge obsolète peut durer plus longtemps qu'un cache navigateur déjà rafraîchi. Collez l'en-tête Cache-Control de la page ci-dessus pour voir s'il est mis en cache trop longtemps.

stale-while-revalidate permet à un cache de servir instantanément une réponse légèrement obsolète pendant qu'il récupère une copie fraîche depuis l'origine en arrière-plan, de sorte que le visiteur suivant obtient la mise à jour sans que personne n'attende un aller-retour lent. Vous définissez une fenêtre en secondes — par exemple public, max-age=300, stale-while-revalidate=60 signifie que la réponse est fraîche pendant cinq minutes, puis peut être servie obsolète pendant une minute supplémentaire au maximum pendant qu'elle se rafraîchit en coulisses. C'est idéal pour un contenu qui tolère une brève obsolescence, comme les pages mises en cache par un CDN et les réponses d'API où la vitesse perçue compte plus que la fraîcheur absolue. Une directive apparentée, stale-if-error, sert une copie obsolète lorsque l'origine renvoie une erreur, ce qui améliore la résilience. Collez ci-dessus un en-tête contenant l'une ou l'autre directive, et l'analyseur explique le comportement exact et le minutage.