Cache HTTP côté serveur: maîtriser Cache-Control, ETag et Expires pour WordPress

Tu veux améliorer la performance WordPress sans changer de thème ni d’hébergement ? Commence par le cache HTTP. Bien configurés côté serveur, les en-têtes Cache-Control, ETag et Expires peuvent réduire drastiquement le nombre de requêtes, la bande passante et la charge CPU. Avec Nginx ou Apache, et éventuellement un CDN, tu peux servir instantanément les assets statiques tout en gardant un contrôle précis sur la fraîcheur des contenus. Dans ce guide, on décortique les headers, on te donne des configurations prêtes à l’emploi, et on t’aide à éviter les pièges classiques (admin, pages dynamiques, cookies). Objectif: un site plus fluide, des Core Web Vitals stables, et une expérience utilisateur qui convertit. On va parler d’Expires, d’ETag, de TTL, d’immutable, de must-revalidate, de s-maxage pour le CDN, et des réglages malins pour ne pas casser l’édition de contenus. C’est précisément ce que nous optimisons au quotidien chez WP Builders lorsque nous prenons en main la maintenance et la performance WordPress de nos clients.

Comprendre le cache HTTP: les bases utiles pour WordPress

Le cache HTTP permet au navigateur (et aux intermédiaires comme un CDN ou un reverse proxy) de réutiliser une ressource déjà téléchargée plutôt que de la recharger. Sur WordPress, cela s’applique surtout aux ressources statiques (images, CSS, JS, polices) et plus rarement au HTML (souvent dynamique). Trois headers jouent un rôle central:

• Cache-Control: la règle moderne qui dicte qui peut cacher (public/private), combien de temps (max-age, s-maxage), et comment revalider (must-revalidate, no-cache).
• ETag: une empreinte (hash ou signature) de la ressource. Si elle n’a pas changé, le serveur peut répondre 304 Not Modified, sans renvoyer le fichier.
• Expires: l’ancienne méthode qui fixe une date de péremption absolue. Elle reste utile pour compatibilité, mais Cache-Control domine.

À retenir: le header Cache-Control prime sur Expires si les deux existent. L’ETag (ou Last-Modified) n’empêche pas le cache, il gère la revalidation si la ressource a expiré.

Cache-Control: les directives qui font la différence

Voici les directives les plus utiles pour un site WordPress:

• public: autorise le cache côté navigateur et intermédiaires (CDN, proxy).
• private: limite le cache au navigateur (à éviter sur statiques partagées, utile pour pages personnelles).
• max-age=N: durée en secondes avant expiration (ex: 30 jours = 2592000).
• s-maxage=N: TTL côté CDN/proxy (ignore max-age pour les partages). Idéal quand tu veux un TTL différent pour l’edge.
• no-cache: la ressource peut être mise en cache, mais chaque utilisation déclenche une revalidation (If-None-Match/If-Modified-Since). Parfait pour HTML dynamique léger.
• no-store: interdit tout stockage (souvent pour données sensibles; généralement inutile pour WordPress public).
• immutable: indique qu’un fichier versionné ne changera jamais. Le navigateur n’ira pas vérifier pendant max-age.
• must-revalidate: impose une revalidation stricte à l’expiration.

Exemple conseillé pour les fichiers statiques versionnés: Cache-Control: public, max-age=2592000, immutable. Pour les pages HTML WordPress publiques (non versionnées et dynamiques), on préfère: Cache-Control: no-cache, must-revalidate (ou private, no-cache selon contexte) pour forcer une revalidation sans empêcher le navigateur ou un CDN d’optimiser le trafic.

Pour approfondir, la documentation MDN sur Cache-Control est une référence claire et à jour.

ETag et Last-Modified: quand les utiliser (et quand les désactiver)

ETag compare une signature de la ressource; Last-Modified compare la date de modification. Les deux favorisent des réponses 304 ultra légères après expiration. Toutefois:

• En cluster (plusieurs serveurs), l’ETag par défaut d’Apache peut inclure l’inode du fichier, créer des signatures différentes entre nœuds et nuire au cache. Solution: le désactiver ou uniformiser.
• Avec des CDN, ETag reste utile mais n’est pas indispensable si tu relies proprement Last-Modified et des TTL bien pensés.

Bon compromis courant sur WordPress:

• Désactiver ETag en multi-serveurs ou le forcer à MTime Size.
• Laisser Last-Modified actif sur les statiques, en complément de Cache-Control robuste.

Configurer sous Apache (.htaccess): Expires et Cache-Control

Si ton WordPress est derrière Apache, voici une base solide dans le .htaccess du virtualhost ou du site:

<IfModule mod_expires.c>  ExpiresActive On  # Par défaut: 1 mois pour les statiques  ExpiresDefault "access plus 1 month"  ExpiresByType text/css "access plus 1 month"  ExpiresByType application/javascript "access plus 1 month"  ExpiresByType application/x-javascript "access plus 1 month"  ExpiresByType image/webp "access plus 1 month"  ExpiresByType image/svg+xml "access plus 1 month"  ExpiresByType image/jpeg "access plus 1 month"  ExpiresByType image/png "access plus 1 month"  ExpiresByType image/gif "access plus 1 month"  ExpiresByType font/woff2 "access plus 1 month"</IfModule><IfModule mod_headers.c>  # Statiques versionnées: longue durée + immutable  <FilesMatch "\.(?:css|js|png|jpg|jpeg|gif|svg|webp|ico|woff2?)$">    Header set Cache-Control "public, max-age=2592000, immutable"  </FilesMatch>  # HTML: revalidation forte (évite le cache CDN des pages dynamiques)  <FilesMatch "\.(?:html|htm|php)$">    Header set Cache-Control "no-cache, must-revalidate"  </FilesMatch>  # Vary utile pour compression & origines  Header append Vary "Accept-Encoding"</IfModule># ETag: safe pour mono-serveur, sinon désactiverFileETag MTime Size

Teste ensuite avec curl -I pour vérifier les en-têtes renvoyés. N’oublie pas que certains plugins ou l’hébergeur peuvent écraser ces réglages: un audit de la pile s’impose avant de conclure.

Configurer sous Nginx: expires, add_header et contrôle fin

Sur Nginx, on maîtrise le cache HTTP avec expires et add_header. Exemple:

server {  server_name exemple.com;  root /var/www/html;  # Statiques: 30 jours + immutable  location ~* \.(?:css|js|png|jpg|jpeg|gif|svg|webp|ico|woff2?)$ {    expires 30d;    add_header Cache-Control "public, max-age=2592000, immutable";    add_header Vary "Accept-Encoding";    try_files $uri $uri/ @wordpress;  }  # HTML/PHP: revalidation stricte  location / {    add_header Cache-Control "no-cache, must-revalidate";    try_files $uri $uri/ @wordpress;  }  location @wordpress {    # vers PHP-FPM    fastcgi_pass unix:/run/php/php8.3-fpm.sock;    include fastcgi_params;    fastcgi_param SCRIPT_FILENAME $document_root/index.php;  }}

Adapte selon ta version de PHP et ton chemin fastcgi_pass. Selon l’hébergeur, une couche de reverse proxy peut s’intercaler (varnish/NGINX proxy) et imposer ses propres en-têtes. Là aussi, vérifie la pile.

Avec ou sans CDN: s-maxage, stale-while-revalidate et purge

Un CDN accélère la distribution d’assets en rapprochant le contenu des utilisateurs. Pour tirer le meilleur parti des headers, ajoute des règles dédiées aux intermédiaires:

# Exemple d'en-tête côté HTML quand on veut revalider au CDN mais éviter un cache trop long navigateurCache-Control: public, max-age=0, s-maxage=86400, must-revalidate

Ici, le navigateur revalide à chaque fois (max-age=0), mais le CDN peut garder la page jusqu’à 24h (s-maxage=86400) et la rafraîchir quand nécessaire. Avec des CDN modernes, pense aussi à stale-while-revalidate et stale-if-error pour servir une version «parfaite» quasi instantanément pendant qu’une mise à jour se fait en arrière-plan.

Le plus important: pouvoir purger. Quand tu publies, mets à jour une image ou un CSS, il faut invalider les objets au CDN. Beaucoup d’extensions de cache WordPress intègrent des purges automatiques; les équipes WP Builders automatisent ces purges et surveillent les headers de près.

Quel TTL choisir ? Stratégies par type de contenu

Tu dois doser entre fraîcheur et performance. Quelques repères pragmatiques:

• Images, polices, CSS/JS versionnés: 1 à 12 mois, immutable.
• CSS/JS non versionnés: 1 à 7 jours (mieux: passe à un système de versionnement de fichiers).
• HTML public: no-cache, must-revalidate. Avec CDN: s-maxage de 5 min à 24 h selon la fréquence de mise à jour et la criticité.
• API JSON publiques: TTL courts (60–300 s) + revalidation stricte.
• Fichiers téléchargés (PDF): 30 jours à 1 an si versionnés.

Si tu ne sais pas par où commencer, vise une stratégie sûre: assets longs + immutable, HTML no-cache, CDN avec s-maxage court et purge automatique. C’est simple, robuste, et ça couvre 80% des cas.

Versionner tes assets WordPress: la clé d’un cache agressif

Le secret pour utiliser immutable sans risques: changer le nom du fichier quand il évolue (cache-busting). Sur WordPress, utilise le paramètre $ver de wp_enqueue_* ou, mieux, injecte un hash dans le nom de fichier via ton build (Webpack, Vite, Gulp).

// functions.php — versionner par hash de fichier (simple)$css_path = get_stylesheet_directory() . '/assets/css/app.css';$css_ver  = file_exists($css_path) ? filemtime($css_path) : time();wp_enqueue_style(  'theme-css',  get_stylesheet_directory_uri() . '/assets/css/app.css',  [],  $css_ver);

Avec un nom qui change (ou au moins un ver unique), tu peux pousser Cache-Control: public, max-age=31536000, immutable sans craindre que les utilisateurs voient une ancienne version.

Pages dynamiques, WooCommerce et cookies: ne casse pas l’expérience

Les pages qui dépendent de l’utilisateur (panier, compte, wishlist) ne doivent pas être servies depuis un cache partagé. WooCommerce et d’autres plugins posent des cookies (ex: woocommerce_items_in_cart) qui indiquent que la page doit être personnalisée. Dans ce cas, il faut bypass le cache pour l’HTML tout en conservant un cache agressif pour les images/CSS/JS.

Exemple Nginx: désactiver le cache HTML quand certains cookies sont présents:

map $http_cookie $bypass_html_cache {  default 0;  ~*(woocommerce_items_in_cart|wp_woocommerce_session_|wordpress_logged_in_) 1;}server {  # ...  location / {    if ($bypass_html_cache) { add_header Cache-Control "private, no-cache, must-revalidate"; }    try_files $uri $uri/ @wordpress;  }}

N’oublie pas que Vary: Cookie détruit l’efficacité d’un CDN (chaque valeur de cookie produit une variante). Il vaut souvent mieux ne pas mettre en cache l’HTML dès qu’un cookie sensible est détecté, et laisser le CDN n’accélérer que les ressources partagées.

Éviter les conflits: plugin de cache, serveur, et CDN

WordPress sait empiler plusieurs couches de cache: plugin (page cache), reverse proxy (varnish/Nginx), CDN, navigateur. Mal maîtrisé, cela crée des comportements incohérents (pages périmées, headers contradictoires). Pour éviter le chaos:

• Choisis une source de vérité pour les headers. Par exemple: serveur pour les statiques, plugin pour l’HTML, CDN pour les TTL edge.
• Évite les directives contradictoires (ex: no-store d’un plugin + max-age sur le serveur).
• Documente les priorités et la purge (qui purge quoi, quand?).
• Teste toujours en navigation privée ET après purge du CDN pour valider la config réelle.

Chez WP Builders, on commence par un audit des en-têtes renvoyés par chaque couche, puis on définit une politique simple et mesurable. Cela supprime 90% des effets de bord.

Booste la vitesse de ton WordPress en continu

Confie la configuration Cache-Control, ETag, Expires, Nginx/Apache et CDN à nos experts WP Builders. Intervention sous 2h et monitoring 24/7.

Voir nos offres de maintenance

Mesurer l’impact: DevTools, curl, et Core Web Vitals

Pas d’optimisation sans mesures. Pour vérifier tes headers:

• Chrome DevTools → Network → onglet Headers: cherche Cache-Control, ETag, Expires, Age (si CDN) et Vary.
• curl -I https://tonsite.com/style.css pour voir l’entête de réponse sans télécharger le fichier.
• Lighthouse et PageSpeed Insights pour identifier les ressources non mises en cache.

L’impact se verra principalement sur les visites récurrentes (moins de transferts), mais aussi dès la première visite via le CDN (latence plus courte). Des headers propres aident souvent à améliorer le LCP (grâce au CSS/JS/images servis depuis le cache) et la stabilité du site lors des pics de trafic.

Bonnes pratiques avancées pour WordPress

• Preload & preconnect: indique au navigateur les ressources prioritaires (<link rel="preload" as="style" href="...">) et les origines tierces (fonts, CDN).
• Compression: fais cohabiter cache et gzip/br (Brotli). Ajoute toujours Vary: Accept-Encoding.
• Images modernes: image/webp ou avif avec un TTL long. Combine avec responsive images (srcset, sizes).
• HTTP/2 / HTTP/3: combine-les avec un CDN pour des multiplexages efficaces.
• Cache buster côté build: fingerprintage des assets (hash dans le nom) pour tirer parti de immutable.
• Admin / prévisualisation: applique private, no-cache et évite de laisser un CDN mettre en cache l’admin ou les aperçus de brouillons.

Dépanner les problèmes de cache: check-list express

Tu constates un contenu obsolète ou l’absence de cache ? Suis cette check-list:

1. Headers contradictoires: scanne la réponse et isole la couche qui injecte no-store ou un max-age non souhaité.
2. Cookies imprévus: certaines extensions ajoutent des cookies qui déclenchent un bypass; désactive/ajuste si non essentiel.
3. Versions non synchronisées: si tu ne versionnes pas tes assets, le navigateur peut garder une ressource périmée. Mets en place le cache-busting.
4. CDN mal configuré: vérifie l’ordre de priorité (headers d’origine vs règles CDN). Purge sélective puis purge globale si besoin.
5. ETag en cluster: désactive-le ou homogénéise le format (évite l’inode).

Quand un incident te bloque (erreurs 304/200 incohérentes, ressource jamais rafraîchie, pages dynamiques en cache), notre équipe peut intervenir en moins de 2h pour diagnostiquer et stabiliser rapidement la politique de cache.

Étude rapide: gains typiques après réglages

Sur des sites clients, une stratégie simple «assets immuables + HTML revalidé + CDN avec s-maxage» apporte souvent:

• -30 à -70% de requêtes réseau sur les visites récurrentes.
• -20 à -50% de bande passante consommée.
• LCP plus stable (surtout sur mobile) et serveur plus serein pendant les pics.

Ces gains ne remplacent pas un bon hébergement ni un code propre, mais ils forment une base technique saine. WP Builders intègre ces réglages à ses contrats de maintenance, en les adaptant à ton thème, tes plugins et ton hébergeur.

Ressources pour aller plus loin

• Guide pratique sur l’HTTP caching sur web.dev pour consolider tes connaissances.
• Spécifications et nuances sur Cache-Control via la doc MDN.

Conclusion: une politique claire, des sites plus rapides

Le cache HTTP n’est pas un gadget: c’est une fondation. En définissant proprement Cache-Control, ETag et Expires sur Nginx ou Apache, et en orchestrant correctement ton CDN, tu améliores concrètement la performance WordPress et la fiabilité du site. Commence par les assets statiques (long TTL + immutable), sécurise l’HTML avec une revalidation stricte, puis ajuste les TTL au CDN. Mesure, teste, et mets en place des purges automatiques. Et si tu préfères te concentrer sur ton cœur de métier, on s’occupe de tout: audit, configuration, monitoring et dépannage rapide en cas d’alerte.