Chaque fois qu'un visiteur ouvre une page, son navigateur télécharge des dizaines de fichiers : feuilles de style, scripts, polices, images. Si rien n'est configuré, il risque de les retélécharger à chaque page, voire à chaque visite. Le cache HTTP permet d'éviter ce gaspillage, et c'est l'une des optimisations les plus rentables pour la vitesse d'un site.
Le principe du cache http
Lorsqu'un serveur envoie un fichier, il peut l'accompagner d'en-têtes indiquant au navigateur combien de temps il peut le conserver. Pendant cette durée, le navigateur réutilise sa copie locale sans rien demander au serveur. La page suivante s'affiche alors beaucoup plus vite, et le serveur reçoit moins de requêtes.
Le cache http est donc doublement gagnant : il améliore l'expérience des visiteurs et réduit la charge de l'hébergement, ce qui compte lors des pics de trafic.
L'en-tête Cache-Control
C'est l'en-tête principal. Ses valeurs les plus utiles :
- max-age indique la durée de conservation, en secondes ;
- public autorise le stockage par le navigateur et par les intermédiaires (CDN, proxys) ;
- private réserve le stockage au navigateur de l'utilisateur, pour les contenus personnalisés ;
- no-cache oblige le navigateur à vérifier auprès du serveur que sa copie est toujours valable ;
- no-store interdit tout stockage, pour les données sensibles ;
- immutable signale qu'un fichier ne changera jamais à cette adresse.
Quelle durée pour quels fichiers ?
Ma règle de base est simple. Les fichiers statiques versionnés (CSS, JavaScript, polices, images dont le nom change quand le contenu change) peuvent être conservés un an, avec la mention immutable. Ils ne seront plus jamais redemandés tant que leur adresse ne change pas.
Les pages HTML, en revanche, doivent rester fraîches : un cache court ou une revalidation systématique garantit que les visiteurs voient toujours la dernière version de vos contenus.
Le versionnage des fichiers
Mais alors, comment faire si vous modifiez votre feuille de style alors qu'elle est en cache pour un an ? La solution est le versionnage : on ajoute au nom du fichier ou à son adresse un identifiant qui change à chaque modification, par exemple une empreinte du contenu ou une date. Le navigateur considère alors qu'il s'agit d'un nouveau fichier et le télécharge.
La plupart des outils modernes de compilation et des CMS gèrent ce versionnage automatiquement. Il suffit de vérifier qu'il est bien actif.
La revalidation avec ETag
Pour les ressources qui peuvent changer sans prévenir, le serveur peut fournir un identifiant de version, appelé ETag, ou une date de modification. Le navigateur demande alors simplement si le fichier a changé. Si ce n'est pas le cas, le serveur répond par un code 304 très léger, sans renvoyer le contenu. On économise la bande passante tout en garantissant la fraîcheur.
Vérifier votre configuration
Les outils de développement du navigateur affichent, dans l'onglet réseau, les en-têtes de chaque fichier et indiquent s'il provient du cache. Lighthouse signale aussi les ressources dont la durée de cache est trop courte. La documentation MDN sur le cache HTTP est une excellente référence pour approfondir.
Sur les serveurs que je configure avec Nginx, ces règles sont définies une fois pour toutes par type de fichier : un an pour les ressources statiques, revalidation pour les pages. C'est quelques lignes de configuration pour un gain permanent.
Mon conseil
Si votre site obtient un avertissement sur la durée de cache dans Lighthouse, ne le négligez pas : c'est souvent la correction la plus simple et la plus efficace que vous puissiez faire. Un cache http bien réglé rend la navigation quasi instantanée pour les visiteurs réguliers, sans changer une seule ligne de votre contenu.
