Que signifient no-cache et no-store dans Cache-Control ?

no-store : le navigateur ne doit pas stocker la réponse du tout (pas de cache). no-cache : le navigateur peut stocker mais doit revalider avec le serveur avant chaque réutilisation (ETag ou Last-Modified). no-cache est utile pour du contenu dynamique qu’on veut frais tout en permettant une revalidation légère ; no-store pour des données sensibles.

Quelle durée de cache (max-age) pour les CSS et JS d’un site ?

Si les fichiers ont un hash dans le nom (ex. main.a1b2c3.js), utilisez une durée longue (1 an) avec immutable : max-age=31536000, immutable. Ainsi chaque nouvelle version a un nouveau nom et est re-téléchargée. Sans hash, utilisez une durée courte (ex. 1 heure) ou no-cache avec revalidation pour éviter de servir d’anciennes versions.

Faut-il mettre en cache le HTML des pages ?

En général, courte durée ou no-cache avec revalidation (ETag/Last-Modified), car le HTML peut contenir des liens vers de nouvelles versions de CSS/JS ou du contenu dynamique. Pour des pages statiques (SSG), un court max-age (ex. 300 secondes) ou stale-while-revalidate est un compromis. Évitez un cache long sur du HTML dynamique.

Qu'est-ce que Cache navigateur (Cache-Control) ?

Contrôlé côté serveur par l’en-tête HTTP Cache-Control (max-age, no-cache, no-store, immutable, etc.) et optionnellement ETag ou Last-Modified pour la revalidation. Une bonne politique de cache réduit le nombre de requêtes et accélère les visites répétées ; une politique trop agressive sur du contenu dynamique peut afficher des données obsolètes. immutable indique que la ressource ne change pas (idéal pour les fichiers avec hash dans l’URL). no-cache permet la mise en cache mais impose une revalidation avant réutilisation ; no-store interdit tout stockage. Pour les CDN, public ou private et s-maxage peuvent être utilisés.

Comment ça marche ?

Le serveur envoie l'en-tête HTTP Cache-Control (max-age, no-cache, no-store, immutable) avec chaque réponse. Le navigateur stocke la ressource et la réutilise selon ces directives. ETag ou Last-Modified permettent une revalidation légère sans retéléchargement complet.

L'Impact Business

Un cache bien configuré diminue la charge serveur et améliore la vitesse perçue (ressources statiques servies depuis le disque). Pour les images, CSS et JS, des durées longues (ex. 1 an avec nom de fichier versionné) sont courantes. Pour le HTML des pages dynamiques, une durée courte ou no-cache avec revalidation est souvent préférable. Une mauvaise config (tout en no-store ou tout en 1 an sans versionnage) dégrade soit la performance soit la fraîcheur du contenu. Les Core Web Vitals sur visites répétées profitent directement d’un bon cache statique.

Bonnes pratiques vs Erreurs communes

✅ À faire : Cache long (ex. 1 an) + immutable pour les assets avec hash dans l'URL (CSS, JS, images). Courte durée ou no-cache avec revalidation pour le HTML. Documenter la stratégie par type de ressource et tester après déploiement.
❌ À éviter : Tout mettre en no-store (pas de cache, performance dégradée) ou tout mettre en cache long sans versionner les fichiers (anciennes versions servies après mise à jour). Cache long sur du HTML dynamique qui change souvent.

Prompt IA

Contexte : stack [Next.js / WordPress / CDN], types de ressources [HTML, CSS/JS avec hash, images, API]. Propose une stratégie Cache-Control pour chaque type : valeurs max-age, immutable, no-cache, no-store. Donne les en-têtes exacts (Cache-Control, ETag si pertinent). Explique no-cache vs no-store et quand utiliser stale-while-revalidate. Indique la config pour [Vercel / Apache / Nginx] si pertinent.