Le caching web pages accélère le site, à condition de maîtriser la fraîcheur des données

Le caching web pages, ou mise en cache des pages web, consiste à conserver temporairement une réponse HTTP ou une ressource pour la réutiliser lors d’une demande ultérieure. Au lieu de solliciter systématiquement le serveur d’origine, le navigateur, un proxy, un CDN ou l’application peut servir une copie déjà disponible. Cette réutilisation réduit généralement la latence, la bande passante consommée et la charge de traitement du serveur.

Le cache réutilise une réponse au lieu de la reconstruire

Lors de la première visite d’une page, le navigateur envoie une requête au serveur. Celui-ci génère ou retrouve le HTML, les feuilles CSS, les scripts JavaScript, les images et, selon le site, des données issues d’une base de données. Si la réponse peut être mise en cache, elle est stockée avec des règles de validité. Lors d’une demande suivante, une couche intermédiaire peut répondre sans refaire l’ensemble de ce parcours.

Un cache hit signifie que la ressource demandée est présente et toujours exploitable dans le cache. Elle peut donc être servie directement. Un cache miss indique qu’elle est absente, expirée ou non réutilisable. La requête doit alors atteindre le serveur d’origine. L’objectif n’est pas d’obtenir un hit à tout prix, mais de trouver un équilibre entre vitesse et fraîcheur des informations.

Expiration, validation et revalidation : trois notions distinctes

Le TTL, pour time to live, désigne la durée pendant laquelle une ressource peut être considérée comme fraîche. Quand cette durée expire, la ressource n’est pas forcément téléchargée à nouveau dans son intégralité. Le cache peut demander au serveur si sa copie reste valable grâce à une validation conditionnelle, notamment avec ETag ou Last-Modified. Si rien n’a changé, le serveur confirme la réutilisation. Dans le cas contraire, il délivre une nouvelle version. Cette revalidation limite les transferts inutiles tout en réduisant le risque de servir un contenu obsolète.

Choisir le bon niveau de cache selon le contenu

La mise en cache ne se situe pas à un seul endroit. Une même page peut bénéficier du cache navigateur pour ses fichiers statiques, d’un CDN pour sa diffusion géographique et d’un cache applicatif pour certaines données. Chaque couche répond à un besoin différent et doit avoir une clé de cache adaptée.

Le cache client est généralement privé : il appartient au navigateur d’une personne. Le cache serveur, le proxy ou le CDN peuvent être partagés entre de nombreux visiteurs. Cette différence compte pour les espaces connectés, les paniers e-commerce, les comptes utilisateurs et toute réponse dépendant d’une session. Une copie destinée à une personne ne doit pas être réutilisée pour une autre.

La nappe de caches, un risque souvent oublié

Après une mise en ligne, une page ne change pas forcément au même moment pour tous les visiteurs. Plusieurs couches peuvent encore contenir l’ancienne réponse : navigateur, CDN, reverse proxy ou application. Pour limiter cette incohérence, identifiez la clé utilisée par chaque couche, par exemple l’URL, les paramètres, la langue, l’appareil, le cookie ou un en-tête. Une page d’accueil publique peut être partagée. Une page personnalisée doit rester liée au bon utilisateur. Cette cartographie est plus fiable qu’une purge générale répétée, souvent lente et difficile à contrôler.

Définir Cache-Control sans fragiliser les données

L’en-tête HTTP Cache-Control pilote les règles modernes de mise en cache. La directive max-age exprime en secondes la durée de fraîcheur côté navigateur. Par exemple, Cache-Control: public, max-age=2592000 autorise le stockage partagé et privé pendant 2 592 000 secondes, soit environ 30 jours, pour une ressource publique stable.

L’en-tête Expires définit une date d’expiration. Il reste utile pour la compatibilité, mais lorsque Cache-Control et Expires coexistent, Cache-Control est prioritaire. Une configuration cohérente doit donc s’appuyer d’abord sur Cache-Control et conserver Expires en complément lorsque cela est nécessaire.

• public convient à une ressource identique pour tous, comme une image de marque ou un fichier CSS versionné.
• private réserve le stockage au navigateur de l’utilisateur. Cette directive convient à une réponse personnelle qui ne doit pas rejoindre un cache partagé.
• no-cache n’interdit pas le stockage, mais impose une revalidation avant toute réutilisation.
• no-store interdit de conserver la réponse. Cette directive convient aux données réellement sensibles.
• must-revalidate demande au cache de vérifier la validité après expiration au lieu de servir librement une ancienne copie.
• s-maxage permet de définir une durée spécifique pour les caches partagés, indépendamment de max-age.

Des durées adaptées aux ressources, pas une règle unique

Les images, polices, CSS et JavaScript versionnés changent rarement à la même URL. Ils peuvent donc supporter une durée de cache longue. Ajoutez un identifiant de version au nom du fichier ou à son URL lors d’une modification, afin que la nouvelle ressource possède une adresse distincte. À l’inverse, le HTML d’une actualité, un stock produit, une disponibilité ou une réponse d’API doit avoir un TTL court, être revalidé fréquemment ou être exclu du cache selon son niveau de personnalisation.

Sur Apache, les en-têtes peuvent être définis dans la configuration ou dans un fichier .htaccess. Avec Nginx, ils se règlent dans nginx.conf. Une application PHP peut les envoyer avec header, tandis qu’une application Node.js peut utiliser res.setHeader. Le bon emplacement dépend de la personne qui connaît la nature de la réponse : serveur web pour les fichiers statiques, application ou reverse proxy pour les pages dynamiques.

Prévoir l’invalidation avant la première mise en cache

Le problème le plus fréquent n’est pas l’absence de cache, mais la persistance d’une ancienne version après une mise à jour. Une stratégie fiable associe trois mécanismes : le versionnement pour les fichiers statiques, une purge ciblée des URL modifiées sur le CDN ou le proxy, et l’invalidation des clés applicatives lorsque les données changent. Redis, Varnish et Memcached peuvent participer à cette couche applicative. Ils complètent les règles HTTP, mais ne les remplacent pas.

Évitez de placer en cache partagé une réponse contenant un cookie de session, un en-tête d’autorisation, des données de compte ou des tarifs individualisés sans analyse précise. Une clé de cache trop large peut exposer le contenu d’un utilisateur à un autre. Pour les formulaires, les paiements, les pages d’administration et les données sensibles, la priorité reste la confidentialité, pas le taux de cache hit.

Tester le cache et diagnostiquer une ressource obsolète

Après la configuration, ouvrez les outils de développement du navigateur et inspectez les en-têtes de la réponse. Vérifiez la présence de Cache-Control, ETag et Last-Modified, ainsi que, le cas échéant, des en-têtes signalant un passage par le CDN ou le proxy. Comparez une première requête, une requête répétée et une requête après expiration. Vous devez pouvoir déterminer si la réponse vient du cache, si elle est revalidée ou si elle revient du serveur d’origine.

1. Testez une URL publique en navigation normale et dans une fenêtre privée pour distinguer le cache navigateur du cache partagé.
2. Déployez une modification sur un fichier CSS ou JavaScript versionné, puis contrôlez que la nouvelle URL est bien demandée.
3. Après une mise à jour de page, déclenchez une purge ciblée si un CDN ou un reverse proxy est utilisé.
4. Comparez le temps de réponse, la taille transférée, le nombre de requêtes et le ratio de cache hit avant et après le réglage.

Un cache correctement paramétré améliore les temps de chargement et peut soutenir la performance SEO en réduisant les délais d’affichage. Il ne compense toutefois ni un code lourd ni une origine lente. Sa valeur repose sur une politique explicite : contenu public ou privé, durée réaliste, versionnement et procédure d’invalidation testée.