Le cache du navigateur expliqué : Cache-Control, ETag et optimisation CDN

Deux couches de cache HTTP

Le navigateur demande une ressource
      ↓
① Cache fort (sans aller-retour au serveur)
   Cache-Control: max-age=31536000
      ↓ expiré
② Cache de validation (demander au serveur si la ressource a changé)
   ETag / Last-Modified → 304 Not Modified
      ↓ ressource modifiée
③ Récupérer la nouvelle ressource depuis le serveur → 200 OK

Directives Cache-Control

Directive	Signification	Exemple d'utilisation
`max-age=N`	Utiliser le cache pendant N secondes	JS/CSS (1 an)
`s-maxage=N`	Le CDN met en cache pendant N secondes	HTML (1 jour)
`no-cache`	Revalider l'ETag à chaque fois	Réponses d'API
`no-store`	Pas de cache du tout	Données sensibles
`immutable`	Le contenu ne change jamais	Ressources nommées par hash
`stale-while-revalidate=N`	Servir le contenu périmé pendant N secondes pendant la revalidation	JSON i18n

Configuration du cache de ToolsKu

# _next/static/chunks/app-abc123.js
Cache-Control: public, max-age=31536000, immutable

# /fr/pdf/merge/index.html
Cache-Control: public, max-age=3600, s-maxage=86400

# /i18n/toolClients/fr.json
Cache-Control: public, max-age=86400, stale-while-revalidate=604800

Cache de validation ETag

# Première requête
GET /api/config HTTP/1.1
→ 200 OK
   ETag: "abc123"
   Cache-Control: no-cache

# Requête suivante
GET /api/config HTTP/1.1
   If-None-Match: "abc123"
→ 304 Not Modified (corps vide, économise la bande passante)

Les ETags sont dérivés d'un hachage du contenu. Un contenu inchangé renvoie 304 et le navigateur utilise sa copie locale.

Architecture du cache CDN

ToolsKu est déployé sur Alibaba Cloud OSS + CDN :

L'utilisateur demande https://www.toolsku.com/fr/
      ↓
Nœud de bordure CDN (Pékin / Shanghai / Guangzhou)
      ↓ cache atteint → réponse directe (TTFB ~20ms)
      ↓ cache manqué
Origine OSS (Pékin)
      ↓ retourne la ressource + remplit le cache CDN
CDN → utilisateur

Conception de la clé de cache

Les clés CDN sont généralement URL + chaîne de requête. Attention à :

?v=123 et ?v=456 sont des entrées de cache différentes
Les requêtes avec Accept-Language peuvent diviser le cache (en-tête Vary)
ToolsKu utilise des locales basées sur le chemin (/zh-CN/, /en/) pour éviter les problèmes avec Vary

Pièges courants du cache

1. JS mis à jour mais les utilisateurs voient l'ancienne version

Cause : L'ancien JS est fortement mis en cache ; le nouveau HTML référence de nouveaux noms de fichiers mais l'ancien JS reste en cache.

Solution : Noms de fichiers avec hachage de contenu (par défaut dans Next.js _next/static/chunks/app-[hash].js). Changement de contenu → changement de hash → invalidation naturelle.

2. Le cache HTML masque le contenu frais

Solution : max-age plus court + s-maxage sur le HTML, ou purge active via l'API de rafraîchissement CDN.

3. Cache du Service Worker vs cache HTTP

Le gestionnaire fetch du Service Worker peut intercepter toutes les requêtes — priorité sur le cache HTTP. Incrémentez la version du cache lors des mises à jour du SW et supprimez les anciens caches.

Outils de débogage du cache

Chrome DevTools → Network : Colonne Size ((disk cache) / (memory cache) / taille réelle)
En-têtes de réponse : Vérifier Cache-Control, ETag, Age
ToolsKu Référence des codes d'état HTTP : Comprendre 200, 304, 404, etc.

Résumé

Un bon cache est fondamental pour la performance web. Cache fort + cache de validation + nœuds de bordure CDN donnent à ToolsKu un TTFB d'environ ~50ms au premier rendu. Comprendre Cache-Control et ETag est un travail fondamental de performance frontend.