Cache web : le guide pour ne plus jamais dire "ça marche chez moi"

Imaginez que vous corrigez un bug critique sur votre site. Vous déployez le correctif, tout semble bon... mais un utilisateur continue à voir l'ancienne version. Pire : Google indexe la page cassée. Ce scénario, frustrant mais courant, est souvent dû à une mauvaise gestion du cache web.

Le cache, c'est un peu comme la mémoire courte du web. Il sert à accélérer l'affichage des pages, à soulager les serveurs, et à améliorer l'expérience utilisateur. Mais mal maîtrisé, il peut devenir un cauchemar : pages obsolètes, SEO en berne, erreurs persistantes.

Dans cet article, on fait le tour complet, mais digeste, des mécanismes de cache à connaître en 2025 : côté client, côté serveur, via les headers HTTP ou les service workers. L'objectif : vous aider à gagner en performance sans perdre le contrôle. Let's go.

Les différents types de cache : qui fait quoi ?

Le cache navigateur (client)

C'est le premier niveau, activé via les headers HTTP Cache-Control, Expires, ou ETag. Il permet de stocker des fichiers (HTML, CSS, JS, images) dans le navigateur de l'utilisateur, pour éviter de les re-télécharger à chaque visite.

Exemple (le navigateur garde la ressource 1 jour en cache) :

Cache-Control: public, max-age=86400

Astuce : utilisez un système de versioning dans les URLs (style.v2.css) ou un hash (app.abc123.js) pour forcer un nouveau téléchargement quand nécessaire.

Le cache proxy ou reverse proxy (serveur)

Des outils comme Varnish, NGINX, ou les CDN (Cloudflare, Fastly, etc.) agissent comme des intermédiaires entre l'utilisateur et le serveur d'origine. Ils peuvent stocker des pages HTML entières ou des assets.
Leur intérêt : répondre aux requêtes sans solliciter le backend.

RAM ou disque : deux types de cache serveur

Si vous gérez vous-même un serveur, la méthode de stockage du cache peut varier :

• Cache RAM : les données sont gardées en mémoire vive. Très performant, mais limité par la taille disponible
• Cache disque : les fichiers sont stockés sur le disque dur (ou SSD), ce qui est plus lent, mais adapté aux gros volumes

Exemple : une image de fond de 1 Mo n'a pas besoin d'être en RAM. Une page HTML demandée 10 fois par seconde, si.

Cache applicatif

Il est aussi possible d'utiliser des caches côté applicatif (Redis, memcached, ...) pour éviter de recalculer les mêmes données directement côté backend.

Invalidation du cache : le nerf de la guerre

Le cache est performant... tant qu'il est à jour. Invalider une ressource (c'est-à-dire la supprimer du cache ou la forcer à se mettre à jour) est souvent le point faible.

TTL et max-age

Par défaut, beaucoup de caches expirent au bout d'un temps défini. Exemple :

Cache-Control: max-age=3600

Une heure de validité pour la ressource. Mais si vous avez besoin de forcer une mise à jour immédiate, ce n'est pas suffisant.

PURGE ou BAN (Varnish, Fastly, etc)

Les reverse proxies avancés permettent de purger une ressource manuellement :

PURGE /ma-page.html HTTP/1.1

Ou mieux : utiliser une clé logique, souvent appelée xkey, pour purger plusieurs ressources en une seule commande.

C'est quoi une xkey ?
C'est un identifiant que vous pouvez attacher à plusieurs pages ou contenus liés. Par exemple : toutes les pages liées à un article (xkey: article-123) peuvent être invalidées d'un coup, sans vider tout le cache.

X-Cache-Tags: article-123, categorie-news

Pratique : on évite les purges globales, et on garde le cache chaud pour les autres pages.

Cache busting (navigateur)

Ici, l'invalidation est plus complexe, car vous n'avez pas la main sur le cache utilisateur.
Solution courante : le cache busting, via une URL versionnée ou un hash :

<script src="/js/app.abcd1234.js"></script>

Changez le nom du fichier = le navigateur le re-télécharge

Service workers : proxy côté navigateur

Depuis l'avènement des Progressive Web Apps (PWA), les service workers sont devenus un outil clé dans la gestion du cache.
C'est un script JS qui intercepte les requêtes réseau du navigateur. Il peut :

• Servir des fichiers depuis un cache local (via l'API Cache)
• Gérer une stratégie de cache personnalisée : cache first, network first, stale-while-revalidate, etc.

Exemple :

event.respondWith(
  caches.match(request).then(cached => cached || fetch(request))
);

Attention : le cache d'un service worker persiste même après un refresh. Il faut donc bien penser à le mettre à jour sur chaque déploiement.

Le header Vary : subtil, mais crucial

Le header Vary indique aux caches sur quoi varier la version stockée. En clair, il dit : “Attention, cette réponse change selon tel ou tel paramètre.”

Cas classiques

Vary: Accept-Encoding

Une version GZIP et une version Brotli peuvent coexister.

Vary: User-Agent

Permet de servir une version mobile ou desktop du même URL.

Risques

• SEO : Vary: User-Agent mal utilisé peut empêcher Google d'accéder à certaines versions de vos pages.
• Sécurité : Vary: Cookie peut générer une version du cache par session utilisateur. Résultat : surcharge mémoire et possible fuite de données.

Bon réflexe : ne variez que si c'est nécessaire, et testez l'impact avec curl -I ou WebPageTest.

Directives avancées : stale-while-revalidate et stale-if-error

Cache-Control: max-age=60, stale-while-revalidate=30, stale-if-error=300 

• stale-while-revalidate : sert une version périmée pendant qu’une nouvelle est récupérée en arrière-plan.
• stale-if-error : sert l’ancienne version si le serveur est en erreur.

Bonnes pratiques à appliquer en 2025

Adoptez une stratégie claire

• Assets statiques (JS, CSS, images) : versionnés, avec Cache-Control: max-age=31536000, immutable
• HTML : TTL court ou désactivé (no-store, must-revalidate)
• APIs : activer ETag ou Last-Modified
• Sécurité : no-store, private pour tout contenu sensible.
• HTTP2 / HTTP3 : attention au multiplexage et au push, qui peuvent modifier la pertinence de certaines stratégies de cache

Contrôlez vos caches intermédiaires

• CDN ou reverse proxy : configurez les TTL selon le type de contenu
• Activez les PURGE, BAN, ou xkey pour invalider au bon niveau

Automatisez l'invalidation

Sur chaque déploiement, purgez les pages ou ressources concernées, ou activez des headers conditionnels :

ETag: "v1.3.5"

C'est quoi un ETag ?
Un ETag (Entity Tag) est une sorte d'empreinte (hash) du contenu. Quand un navigateur refait une requête, il peut envoyer :

If-None-Match: "v1.3.5"

Si le contenu n’a pas changé, le serveur répond 304 Not Modified: moins de charge, plus de rapidité.

Surveillez ce qui est vraiment caché

• Utilisez les DevTools du navigateur (onglet Réseau -> colonne "Size" ou "From Cache")
• Testez en ligne (Lighthouse, WebPageTest), ou avec curl -I en ligne de commande
  

Gérez vos service workers proprement

• Mettez à jour le service-worker.js à chaque release (via un nom ou un hash)
• Dans le handler activate, supprimez les anciens caches

Maîtriser le cache, c'est dompter la vitesse

Le cache n'est pas une optimisation secondaire. C'est le levier central pour garantir des performances web de haut niveau en 2025.
Mais pour qu'il fonctionne à votre avantage, il faut :

• Le comprendre
• Le configurer précisément
• L'invalider intelligemment
• Et surtout, le tester régulièrement

Parce que oui : "ça marche chez moi" n'a jamais été un indicateur fiable.
Mais avec un cache bien pensé, ça peut enfin marcher partout.