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.