Éviter les requêtes réseau inutiles avec le cache HTTP

Récupérer des ressources sur le réseau est à la fois lent et coûteux. Les réponses volumineuses multiplient les allers-retours, votre page ne s’affiche pas tant que ses ressources essentielles ne sont pas téléchargées, et chaque requête superflue gaspille le forfait de données de l’internaute. Le cache HTTP du navigateur est votre première ligne de défense : il n’est ni le plus puissant ni le plus flexible des mécanismes, mais il est efficace, compatible avec tous les navigateurs et demande peu d’efforts. Pour le SEO, réduire les requêtes réseau accélère les visites répétées, un levier que l’on retrouve dès qu’on cherche à optimiser le cache pour les visites répétées, ce qui améliore les Core Web Vitals et l’expérience perçue par vos visiteurs comme par les moteurs.

Concrètement, chaque requête du navigateur passe d’abord par le cache : s’il existe une réponse valide, elle est réutilisée, ce qui supprime la latence réseau et le coût de transfert. Ce comportement se pilote par des en-têtes de réponse que vous configurez sur votre serveur.

L’en-tête Cache-Control accepte une liste de directives séparées par des virgules qui définissent comment et combien de temps une réponse peut être stockée. Omettre cet en-tête ne désactive pas le cache, qui reste une étape clé de le chemin critique de rendu : le navigateur devine alors un comportement, souvent au détriment du contrôle. Mieux vaut donc être explicite.

Voici quelques combinaisons d’en-têtes types et leur signification concrète.

Quand une réponse mise en cache expire, le navigateur n’a pas forcément besoin de la retélécharger. L’en-tête ETag porte un petit jeton, généralement un hachage du contenu, que le navigateur renvoie ensuite via If-None-Match. L’en-tête Last-Modified joue le même rôle, mais sur une base temporelle plutôt que sur le contenu, et déclenche l’en-tête If-Modified-Since.

À la requête suivante, le serveur compare le jeton ou la date reçue avec sa version courante. S’ils correspondent, il renvoie une réponse 304 Not Modified, très légère, qui dit au navigateur de réutiliser sa copie. C’est bien plus rapide que de renvoyer la ressource entière. ETag est généralement préférable, car plus précis que la stratégie temporelle de Last-Modified.

La décision repose sur deux scénarios. Pour les URL versionnées, dont le nom inclut une empreinte comme style.x234dff.css, vous pouvez adopter la mise en cache de longue durée en fixant max-age=31536000 : changer le contenu change le nom, donc l’invalidation est propre. Pour les URL non versionnées comme le HTML, laissez le serveur revalider via ETag ou Last-Modified afin de toujours servir la bonne version.