Le cache HTTP expliqué : ETag, Cache-Control et CDN

Pourquoi votre site semble lent (et comment le cache y remédie)

Vous avez optimisé vos images, minifié votre CSS et même mis à niveau votre serveur. Pourtant, les visiteurs réguliers subissent encore des temps de chargement lents, et votre serveur d'origine consomme de la bande passante. Le coupable ? Un cache HTTP inefficace. Sans en-têtes de cache appropriés, les navigateurs retéléchargent les mêmes ressources à chaque visite, et les CDN ne peuvent pas faire leur travail efficacement.

Le cache HTTP est l'une des optimisations de performance les plus rentables. Il réduit la latence, diminue les coûts de bande passante et allège la charge sur vos serveurs d'origine. Dans ce guide, nous détaillerons les mécanismes clés : ETag, Cache-Control, et comment les CDN s'intègrent. Vous apprendrez des stratégies pratiques pour les mettre en œuvre correctement.

Comment fonctionne le cache HTTP : vue d'ensemble

Lorsqu'un navigateur demande une ressource, il peut soit la récupérer depuis le serveur d'origine, soit servir une copie stockée localement. Le cache HTTP définit les règles pour déterminer quand une copie stockée est considérée comme fraîche et quand elle doit être revalidée.

Il existe deux principaux types de cache :

• Cache navigateur (privé) : Le navigateur de l'utilisateur stocke les ressources localement. Cela profite à un seul utilisateur sur plusieurs pages ou visites.
• Cache partagé (CDN, proxy) : Des serveurs intermédiaires mettent en cache les ressources pour plusieurs utilisateurs. Cela réduit la charge sur votre origine et accélère la livraison à l'échelle mondiale.

Les deux reposent sur des en-têtes HTTP pour décider de la fraîcheur et de la revalidation. Les deux en-têtes les plus importants sont Cache-Control et ETag.

Cache-Control : les règles de fraîcheur

Cache-Control est l'en-tête principal pour définir les politiques de cache. C'est un en-tête basé sur des directives qui indique aux caches comment traiter une réponse.

Directives clés

• max-age : Le nombre de secondes pendant lesquelles une réponse est considérée comme fraîche. Par exemple, Cache-Control: max-age=3600 signifie que la réponse est fraîche pendant 1 heure.
• s-maxage : Comme max-age mais spécifiquement pour les caches partagés (CDN). Remplace max-age pour les caches partagés.
• public : La réponse peut être mise en cache par n'importe quel cache, y compris les caches partagés.
• private : La réponse est destinée à un seul utilisateur et ne doit pas être stockée par les caches partagés.
• no-cache : La réponse peut être stockée, mais doit être revalidée avec l'origine avant chaque utilisation.
• no-store : La réponse ne doit être stockée dans aucun cache. À utiliser pour les données sensibles.
• must-revalidate : Une fois périmé, le cache ne doit pas utiliser la réponse sans revalidation.
• immutable : La réponse ne changera pas pendant sa durée de fraîcheur. Utile pour les ressources versionnées.

Exemple : Cache-Control: public, max-age=31536000, immutable est idéal pour les ressources statiques avec des noms de fichiers hachés.

ETag et requêtes conditionnelles

Un ETag (Entity Tag) est un identifiant pour une version spécifique d'une ressource. Lorsqu'une ressource change, l'ETag change. Les navigateurs utilisent les ETags pour effectuer des requêtes conditionnelles : ils envoient l'ETag stocké dans un en-tête If-None-Match. Si la ressource n'a pas changé, le serveur répond avec 304 Not Modified et sans corps, économisant de la bande passante.

De même, Last-Modified fonctionne avec If-Modified-Since, mais les ETags sont plus précis (ils peuvent détecter des changements dans la même seconde).

Comment générer des ETags

La plupart des serveurs web et frameworks génèrent des ETags automatiquement. Par exemple, dans Express.js, vous pouvez l'activer avec app.set('etag', 'strong'). Dans Nginx, les ETags sont activés par défaut pour les fichiers statiques.

Les ETags forts (par exemple, "abc123") garantissent une identité octet par octet. Les ETags faibles (par exemple, W/"abc123") indiquent une équivalence sémantique, pas des octets exacts.

Cache CDN : cache partagé à grande échelle

Les CDN (Content Delivery Networks) agissent comme des caches partagés distribués mondialement. Ils mettent en cache votre contenu aux emplacements périphériques, le servant aux utilisateurs depuis un point de présence proche. Cela réduit la latence et décharge votre origine.

Les CDN respectent les en-têtes Cache-Control mais ont souvent leur propre configuration. Concepts clés :

• Cache edge : Le cache local du CDN. Il stocke les réponses en fonction des clés de cache (généralement l'URL + des en-têtes comme Accept-Encoding).
• Origin shield : Une couche de cache supplémentaire qui réduit les requêtes vers votre origine.
• Invalidation de cache : Les CDN fournissent des API pour purger le contenu mis en cache lorsque vous mettez à jour des ressources.

Lorsque vous utilisez un CDN, définissez Cache-Control avec s-maxage pour contrôler la fraîcheur du cache partagé séparément du cache navigateur. Par exemple : Cache-Control: public, max-age=600, s-maxage=3600 signifie que les navigateurs mettent en cache pendant 10 minutes, mais le CDN met en cache pendant 1 heure.

Comparaison des en-têtes de cache

Remarque : Expires est remplacé par Cache-Control mais est encore utilisé par les clients plus anciens.

Stratégie de cache pratique pour les applications web

Suivez ces étapes pour mettre en œuvre un cache efficace :

1. Empreinte digitale des ressources statiques : Utilisez des noms de fichiers hachés (par exemple, app.a1b2c3.js) et définissez un max-age long avec immutable. Lorsque le fichier change, le hachage change, invalidant le cache.
2. Définissez un Cache-Control approprié pour le HTML : Le HTML doit généralement être no-cache ou avoir un max-age court pour que les utilisateurs obtiennent rapidement les mises à jour. Utilisez ETag pour la revalidation.
3. Utilisez Vary: Accept-Encoding : Si vous servez des versions compressées et non compressées, cela garantit que les caches les stockent séparément.
4. Tirez parti du CDN avec s-maxage : Définissez un s-maxage plus long pour les caches partagés afin de réduire la charge sur l'origine, tout en gardant le cache navigateur plus court si nécessaire.
5. Invalidez judicieusement : Utilisez les API de purge du CDN lors du déploiement de mises à jour critiques. Pour les ressources statiques, l'empreinte digitale évite le besoin de purge.
6. Surveillez le taux de succès du cache : Utilisez les analyses du CDN pour vous assurer que votre cache est efficace. Un faible taux de succès signifie des en-têtes mal configurés.

Pièges courants et comment les éviter

• Sur-cache du HTML : Les utilisateurs voient du contenu obsolète. Utilisez no-cache ou un max-age court.
• Sous-cache des ressources statiques : Définissez un max-age long (par exemple, 1 an) avec empreinte digitale.
• Ignorer Vary : Les caches peuvent servir un contenu incorrect (par exemple, gzip vs. plain). Définissez toujours Vary: Accept-Encoding.
• Oublier private pour les données spécifiques à l'utilisateur : Les caches partagés pourraient divulguer des données. Utilisez Cache-Control: private pour les réponses authentifiées.
• Mauvaise utilisation de no-store : Cela empêche tout cache, ce qui peut nuire aux performances. À utiliser uniquement pour les données sensibles.

Tester votre configuration de cache

Utilisez les DevTools du navigateur (onglet Réseau) pour inspecter les en-têtes de réponse et voir si les ressources sont servies depuis le cache (recherchez « (from disk cache) » ou « (from memory cache) »). Pour le comportement du CDN, utilisez curl -I pour vérifier les en-têtes comme X-Cache ou CF-Cache-Status. Des outils comme WebPageTest peuvent visualiser la mise en cache entre les visites.

FAQ

Quelle est la différence entre ETag et Last-Modified ?

ETag est un identifiant opaque qui change lorsque la ressource change, tandis que Last-Modified est un horodatage. Les ETags sont plus précis car ils peuvent détecter des changements dans la même seconde et ne dépendent pas de la synchronisation des horloges.

Quand dois-je utiliser no-cache vs no-store ?

Utilisez no-cache lorsque vous voulez que le cache stocke la réponse mais la revalide avec l'origine avant chaque utilisation. Utilisez no-store pour les données sensibles qui ne doivent jamais être écrites sur disque ou en mémoire par un cache.

Comment les CDN gèrent-ils l'invalidation du cache ?

Les CDN fournissent des API de purge qui vous permettent de supprimer des URL spécifiques ou des répertoires entiers de leurs caches edge. Certains prennent également en charge les purges douces qui marquent le contenu comme obsolète et le revalident à la prochaine requête. L'empreinte digitale des ressources est souvent plus efficace que la purge.

Conclusion

Maîtriser le cache HTTP avec ETag, Cache-Control et les CDN est essentiel pour créer des applications web rapides et évolutives. Commencez par définir des en-têtes appropriés pour vos ressources statiques et votre HTML, tirez parti des caches partagés des CDN avec s-maxage, et testez toujours votre configuration. De petits changements dans les en-têtes de cache peuvent entraîner des gains de performance significatifs.

Besoin d'analyser rapidement vos journaux serveur pour voir les taux de succès du cache ? Essayez notre Analyseur de journaux Nginx pour parser et visualiser vos journaux d'accès.