Les bases de la mise en cache que tout développeur Web devrait connaître

Feb 24, 2026 · 4 min read

Les bases de la mise en cache que tout développeur Web devrait connaître

Vos utilisateurs viennent de cliquer sur un bouton, et rien ne s’est passé pendant trois secondes. La requête de base de données s’est terminée, le serveur a répondu, mais les mêmes données qui se sont chargées hier ont dû traverser tout Internet à nouveau. C’est le problème que résout la mise en cache.

Comprendre les bases de la mise en cache HTTP n’est pas optionnel pour les développeurs frontend. C’est la différence entre une application réactive et une application qui semble défaillante. Ce guide couvre ce que vous devez savoir sur le cache navigateur vs. le cache CDN, les en-têtes Cache-Control, et les mécanismes de validation comme ETag et Last-Modified.

Points clés à retenir

Définissez des en-têtes Cache-Control explicites sur chaque réponse pour éviter les heuristiques imprévisibles du navigateur.
Utilisez des valeurs max-age longues associées au cache busting (noms de fichiers avec hash de contenu) pour les ressources statiques.
Utilisez no-cache avec ETag ou Last-Modified pour le contenu qui doit rester à jour.
Marquez toujours le contenu personnalisé ou authentifié comme private pour éviter les fuites de données via les caches partagés.

Qu’est-ce que la mise en cache et pourquoi est-elle importante

La mise en cache stocke une copie des données plus près de l’endroit où elles sont nécessaires. Lorsque votre navigateur demande une image, il peut enregistrer cette image localement. La requête suivante évite complètement le réseau.

Les gains de performance sont spectaculaires. Par exemple, une requête de base de données peut prendre des dizaines de millisecondes, tandis que la lecture depuis un cache navigateur est généralement quasi instantanée et évite complètement un aller-retour réseau.

La mise en cache offre trois avantages principaux :

Réduction de la latence : Les données parcourent des distances plus courtes.
Réduction de la charge serveur : Moins de requêtes atteignent votre serveur d’origine.
Meilleure expérience utilisateur : Les pages se chargent plus rapidement lors des visites répétées.

Comprendre les couches de cache

Les requêtes passent par plusieurs caches avant d’atteindre votre serveur. Chaque couche a un objectif différent.

Cache navigateur (cache privé)

Le cache navigateur se trouve sur l’appareil de l’utilisateur. Il stocke les réponses que seul cet utilisateur devrait voir. Lorsque vous marquez une réponse comme private, elle reste ici et n’est jamais partagée avec d’autres utilisateurs.

C’est là que se trouve le contenu personnalisé — profils utilisateur, réponses API authentifiées, tout ce qui est lié à une session spécifique.

Cache CDN (cache partagé)

Un cache CDN se situe entre les utilisateurs et votre serveur d’origine, distribué à travers des emplacements géographiques. Lorsqu’un utilisateur à Tokyo demande votre bundle JavaScript, le CDN le sert depuis un serveur edge à proximité plutôt que depuis votre centre de données d’origine.

Les CDN excellent dans la mise en cache des ressources statiques : images, CSS, JavaScript et polices. Ils peuvent également mettre en cache les réponses d’API publiques, bien que cela nécessite une configuration soigneuse.

Mise en cache côté serveur

Au-delà de la mise en cache HTTP, les serveurs maintiennent souvent leurs propres caches en utilisant des outils comme Redis ou Memcached. En tant que développeur frontend, vous ne les configurerez pas directement, mais comprendre qu’ils existent vous aide à comprendre pourquoi certaines réponses API sont plus rapides que d’autres.

En-têtes Cache-Control : les directives essentielles

L’en-tête Cache-Control indique aux caches comment gérer les réponses. Voici les directives que vous utiliserez le plus souvent :

Directive	Signification
`max-age=3600`	Mettre en cache pendant 3600 secondes (1 heure)
`no-cache`	Stocker, mais revalider avant utilisation
`no-store`	Ne stocker cette réponse nulle part
`private`	Seul le cache navigateur peut stocker ceci
`public`	N’importe quel cache peut stocker ceci

Une erreur courante : no-cache ne signifie pas « ne pas mettre en cache ». Cela signifie « toujours vérifier avec le serveur avant d’utiliser la copie en cache ». Utilisez no-store lorsque vous ne voulez vraiment aucune mise en cache.

Pour les ressources statiques avec des noms de fichiers hashés, utilisez une mise en cache agressive :

Cache-Control: public, max-age=31536000

Pour les pages HTML qui changent fréquemment (et surtout pour le contenu sensible ou hautement dynamique) :

Cache-Control: no-cache, private

ETag et Last-Modified : mécanismes de validation

Lorsque le contenu en cache expire, les navigateurs n’ont pas toujours besoin de tout retélécharger. Les en-têtes de validation permettent une revalidation efficace.

Last-Modified contient un horodatage. Lors des requêtes suivantes, le navigateur envoie un en-tête If-Modified-Since avec cet horodatage. Si rien n’a changé, le serveur renvoie 304 Not Modified — pas de corps, bande passante minimale.

ETag contient un identifiant unique (souvent un hash de contenu). Lors des requêtes suivantes, le navigateur envoie un en-tête If-None-Match avec cet identifiant. Même résultat : un 304 si le contenu est inchangé.

Les ETags sont plus précis que les horodatages car ils détectent les changements réels de contenu, pas seulement les heures de modification de fichier. Un fichier pourrait être réenregistré sans changer son contenu, mettant à jour son horodatage mais pas son ETag.

Cache busting pour les ressources statiques

Vous voulez que les ressources statiques soient mises en cache le plus longtemps possible, mais vous devez également que les utilisateurs reçoivent les mises à jour lorsque vous déployez. Le cache busting résout ce problème en changeant l’URL lorsque le contenu change.

Les outils de build modernes ajoutent des hashs de contenu aux noms de fichiers :

bundle.a1b2c3d4.js
styles.e5f6g7h8.css

Lorsque vous déployez un nouveau code, le hash change, l’URL change, et les navigateurs récupèrent la nouvelle version. Les anciens fichiers en cache expirent simplement naturellement.

Pièges courants à éviter

Mettre en cache du contenu authentifié publiquement : Utilisez toujours private pour les données spécifiques à l’utilisateur. Faire fuiter les données d’un utilisateur vers un autre via un cache partagé est un problème de sécurité grave.

Sur-mise en cache des réponses API : Les données dynamiques nécessitent des TTL courts ou no-cache. Des prix obsolètes lors du paiement causent de vrais problèmes.

Oublier de définir les en-têtes : Sans en-têtes Cache-Control explicites, les navigateurs peuvent appliquer une mise en cache heuristique basée sur les métadonnées de réponse, ce qui peut conduire à un comportement que vous n’aviez pas prévu.

Conclusion

La mise en cache n’est pas quelque chose que vous configurez une fois et oubliez. Définissez des en-têtes Cache-Control explicites sur chaque réponse. Associez des valeurs max-age longues avec des noms de fichiers hashés par contenu pour les ressources statiques. Utilisez no-cache avec ETag ou Last-Modified pour le contenu qui doit rester à jour, et marquez toujours le contenu personnalisé comme private. Vérifiez vos en-têtes dans les DevTools, vérifiez le comportement de votre CDN, et testez ce que les utilisateurs vivent réellement.

FAQ

no-cache indique au navigateur qu'il peut stocker la réponse mais doit revalider avec le serveur avant de l'utiliser. no-store indique au navigateur de ne pas enregistrer la réponse du tout. Utilisez no-store pour les données sensibles comme les détails bancaires, et no-cache pour le contenu qui change souvent mais bénéficie de la revalidation conditionnelle.

Ouvrez les DevTools de votre navigateur, allez dans l'onglet Réseau, et sélectionnez n'importe quelle requête. La section En-têtes de réponse affiche les valeurs Cache-Control, ETag et Last-Modified. Regardez aussi la colonne taille. Si elle indique disk cache ou memory cache, la réponse a été servie depuis le cache du navigateur plutôt que depuis le réseau.

Cela dépend des données. Les données publiques qui changent rarement, comme les catégories de produits, peuvent utiliser des valeurs max-age courtes. Les données spécifiques à l'utilisateur ou qui changent fréquemment devraient utiliser no-cache avec des en-têtes de validation ou no-store. Marquez toujours les réponses authentifiées comme private pour empêcher les CDN de servir les données d'un utilisateur à un autre.

Les hashs de contenu vous permettent de définir des durées de vie de cache très longues pour les ressources statiques tout en livrant les mises à jour instantanément. Lorsque le contenu du fichier change, le hash change, produisant une nouvelle URL qui contourne tout cache existant. Cette technique s'appelle le cache busting et est l'approche standard utilisée par des outils comme Webpack, Vite et Rollup.

Gain control over your UX

See how users are using your site as if you were sitting next to them, learn and iterate faster with OpenReplay. — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.