# Mise en cache HTTP

> Mécanisme piloté par les en-têtes de réponse (Cache-Control, Expires, ETag) qui autorise un navigateur ou un intermédiaire à réutiliser une ressource déjà téléchargée sans la redemander.

- Auteur : Clément Hadrot
- Publié le : 2026-09-25
- Mis à jour le : 2026-09-25
- URL : https://wpmoderne.dev.wordpress-developpement.fr/lexique/mise-en-cache-http/

Recharger une image ou un fichier CSS qui n'a pas changé depuis la dernière visite gaspille de la bande passante des deux côtés. La mise en cache HTTP formalise, via des en-têtes précis dans la réponse, combien de temps une ressource peut être réutilisée telle quelle, et comment vérifier si elle a changé sans forcément la retélécharger en entier.

## Comment ça s'applique à WordPress

Les fichiers statiques d'un thème (CSS, JS, images) peuvent recevoir un `Cache-Control` long via la configuration du serveur web (Apache, Nginx) puisqu'ils changent rarement une fois publiés. Le HTML généré dynamiquement par WordPress, lui, est en général mis en cache différemment via une extension de cache de page (WP Super Cache, W3 Total Cache...), qui stocke une version pré-générée du HTML pour éviter de repasser par PHP et MySQL à chaque visite.

## Exemple

```
Cache-Control: public, max-age=31536000, immutable
ETag: "5d8c72a5"
```

`max-age=31536000` autorise une réutilisation pendant un an ; l'`ETag` permet ensuite au navigateur de vérifier en une requête légère si le fichier a changé.

## Pièges fréquents

- Mettre en cache trop longtemps une page dynamique personnalisée (panier, contenu selon l'utilisateur connecté), ce qui affiche à tort le même contenu à des visiteurs différents.
- Oublier de purger le cache HTTP après une mise à jour de thème : les visiteurs continuent de voir l'ancienne version du CSS pendant la durée du `max-age`.
- Confondre ce cache navigateur/CDN avec le cache d'objets interne de WordPress (basé sur `wp_cache_*`), qui répond à un besoin différent, côté serveur.