Présentation de de cache

Ton site met trois secondes à charger ? Le cache HTTP peut t'en faire gagner deux. C'est le levier le plus rentable que tu connaisses déjà sans le maîtriser. Je ne te parle pas d'un CDN ou d'un service externe : juste des en-têtes HTTP que ton serveur envoie avec chaque réponse.

Le cache HTTP, c'est un mécanisme qui stocke les réponses du serveur quelque part — navigateur, proxy, CDN — pour ne pas avoir à les retransmettre entièrement à chaque requête. Concrètement, si tu as déjà ouvert les DevTools et vu des ressources servies avec un statut 200 (from disk cache), tu sais de quoi je parle. Ça réduit la latence, allège la charge serveur et rend l'expérience utilisateur nettement plus agréable. Et le meilleur dans tout ça ? C'est gratuit.

On va décortiquer ensemble les trois outils essentiels : Cache-Control avec sa directive max-age pour définir la durée de validité, ETag et Last-Modified pour la revalidation conditionnelle — oui, il y a une différence subtile entre les deux, et je vais te la montrer. Enfin, on verra comment bien gérer les ressources statiques avec des noms de fichiers versionnés, une pratique qui me sauve la mise en production.

Un exemple pour te mettre en appétit : imagine ton CSS. Un fichier de 50 Ko servi avec Cache-Control: max-age=31536000. Le navigateur ne le re-télécharge plus pendant un an. Mais si tu modifies ton CSS, tes utilisateurs restent bloqués avec l'ancienne version. Solution : tu renommes le fichier avec un hash, comme styles.a3f9c2.css, et tu mets à jour ta balise <link>. Le cache reste intact, le navigateur voit une nouvelle URL et recharge le fichier. Voilà le genre de chose qu'on va approfondir.

Commençons par le commencement : ce que le cache HTTP fait vraiment, et pourquoi tu perds du temps à ignorer ces en-têtes.

Qu'est-ce que le cache HTTP et pourquoi est-ce important ?

Ton serveur n'a aucune raison de renvoyer un fichier que le navigateur a déjà en mémoire. Pourtant, des milliers de sites le font. Résultat : des pages lentes, des serveurs surchargés, des utilisateurs frustrés. Le cache HTTP règle ça.

Prenons un exemple. Une feuille de style styles.css de 50 Ko. Sans cache, chaque visite relance le téléchargement complet. Avec un en-tête Cache-Control: max-age=31536000, le navigateur garde le fichier pendant un an. La différence ? Une requête qui passe de 300 ms à 10 ms. Sur une page avec 30 ressources, ça change tout.

Pourquoi c'est important ? Trois raisons :

Perf utilisateur : les pages se chargent instantanément après la première visite.
Coûts serveur : moins de requêtes traitées, moins de bande passante consommée.
Scalabilité : ton infrastructure respire, même sous pic de trafic.

Mon avis : si tu n'as qu'un seul en-tête à retenir, c'est Cache-Control. Les autres sont des outils de précision, mais celui-là, c'est le socle.

Le cache HTTP repose sur des en-têtes que ton serveur envoie avec chaque réponse. Les principaux sont Cache-Control, ETag, Last-Modified et Expires. Chacun a son rôle, et on va les décortiquer. Ce que je veux que tu retiennes ici : le cache ne sert pas qu'à éviter des téléchargements. Il permet aussi de revalider une ressource sans la transférer entièrement. Ça, c'est le boulot d'ETag et Last-Modified.

D'ailleurs, un conseil : ne te contente jamais d'envoyer Cache-Control sans penser à la revalidation. Un cache mal configuré peut servir des fichiers obsolètes ou, au contraire, re-télécharger systématiquement des ressources immuables. Le juste équilibre, c'est ce qu'on va voir.

Maîtriser l'en-tête Cache-Control et max-age

La plupart des sites servent leurs ressources statiques sans en-tête de cache ou avec des valeurs à l'arrache. Résultat : le navigateur retélécharge tout à chaque visite. Cache-Control est l'en-tête qui règle ça, et max-age sa directive la plus utile.

Prenons un cas réel. Tu serves /css/app.css. Sans en-tête, le navigateur fait une nouvelle requête à chaque visite, ou pire, décide seul. Avec Cache-Control: max-age=21600, tu fixes six heures de fraîcheur. Le navigateur garde le fichier et aucune requête ne part. Regarde le résultat dans le panneau Network : statut 200 (from disk cache). C'est exactement ça qu'on veut.

La directive max-age est en secondes. C'est une durée relative à l'instant de la réponse, pas une date fixe comme avec l'en-tête Expires de HTTP/1.0. Un max-age=31536000 signifie un an, calculé à partir de la réponse. Ça évite les problèmes de serveur avec une mauvaise horloge.

Un exemple complet de configuration ?

Le mot-clé public autorise les caches intermédiaires comme les CDN à stocker la ressource. Sans lui, certains proxies peuvent refuser. Pour une ressource statique, c'est souvent ce que tu veux. Mais vérifie toujours : max-age ne valide pas le contenu. Si tu changes le fichier, le navigateur garde l'ancien tant que la durée n'est pas écoulée. D'où l'importance de la revalidation, qu'on voit juste après.

Revalidation conditionnelle : ETag vs Last-Modified

La plupart des serveurs envoient Last-Modified par défaut. C'est une erreur que tu paies en requêtes inutiles. L'ETag fait le même boulot, mais en mieux.

Last-Modified se base sur la date de modification du fichier. ETag utilise un hash du contenu. Si ton fichier change deux fois dans la même seconde, Last-Modified ne le voit pas. L'ETag, lui, détecte la moindre variation.

Concrètement, ton navigateur envoie sa version en requête conditionnelle. Avec ETag :

Si la ressource n'a pas bougé, le serveur répond 304 Not Modified sans le corps. Avec Last-Modified, tu envoies If-Modified-Since avec une date. Moins fiable, surtout si tes serveurs ont des horloges légèrement désynchronisées.

Mon avis : utilise toujours ETag quand tu peux. C'est plus précis, ça marche avec un cluster de serveurs, et ça évite les pièges de granularité. Si tu dois aussi envoyer Last-Modified pour compatibilité, fais-le, mais sache que ETag est ta vraie garantie de revalidation.

Stratégies de cache pour les ressources statiques et bonnes pratiques en production

Le cache HTTP, c'est un accélérateur de site web. Mais mal configuré, il devient un cauchemar. La solution tient en un mot : le versioning.

Le principe ? Tu renommes chaque ressource avec un hash de son contenu. Exemple : styles.css devient styles.a3f9c2.css. Le navigateur voit une nouvelle URL et recharge le fichier. L'ancienne version reste en cache jusqu'à expiration. Tu peux donc servir des fichiers avec Cache-Control: max-age=31536000 sans aucun risque de servir une version obsolète.

Voici une config Nginx que j'utilise en production pour mes fichiers hashés :

L'option immutable indique au navigateur qu'il ne doit même pas revalider. Il utilise le cache local sans poser de question. Pour les fichiers non hashés, je préfère un max-age plus court, disons 3600, et je garde ETag actif pour la revalidation conditionnelle.

Quelques bonnes pratiques que j'ai apprises à la dure :

Ne jamais cacher les fichiers HTML sans ETag : tu bloques tes propres déploiements.
Toujours combiner hash et cache long : c'est la base du cache busting.
Vérifier avec curl -I les en-têtes réellement envoyés avant de crier victoire.

La revalidation avec ETag ou Last-Modified, c'est bien pour les ressources qui changent souvent. Mais pour tes assets statiques versionnés, tu n'en as plus besoin. La règle d'or : plus le fichier est stable, plus le cache est long.

Conclusion

Pose un Cache-Control: max-age=31536000 sur ton app.js de 200 Ko. Le premier chargement reste le même, mais tous les suivants sont instantanés. C'est le levier le plus sous-estimé du web.

Tu as maintenant toutes les cartes en main : Cache-Control pour la durée de vie, ETag et Last-Modified pour revalider sans re-télécharger, et des noms de fichiers versionnés pour éviter les caches périmés. Cette config te prend une heure, et elle te fait gagner des secondes à chaque visite.

Alors, arrête de servir des fichiers que le navigateur a déjà en mémoire. Ouvre tes DevTools, regarde tes en-têtes, et mets en place ce que tu viens d'apprendre. Ton serveur soufflera, tes utilisateurs te remercieront. Le cache HTTP, ce n'est pas magique — c'est du bon sens.