Forcer la mise en cache Varnish sur LWS


Sommaire

Procédure

Dans cette documentation, nous allons vous expliquer pas à pas comment obliger Varnish et les navigateurs à conserver vos ressources en cache, même quand ceux‑ci envoient des requêtes Pragma: no‑cache ou Cache‑Control: no-cache.

1. Contexte et architecture LWS

Les formules d’hébergement mutualisé et cPanel/VPS gérés de LWS reposent sur la pile :

Navigateur ⇄ NGINX (SSL + HTTP/2) ⇄ Varnish Cache ⇄ Apache/PHP-FPM

  • NGINX gère TLS et compresse les contenus.
  • Varnish (Fastest Cache) est positionné comme reverse‑proxy pour mettre en mémoire les réponses HTTP.
  • Apache ou PHP‑FPM génèrent la réponse finale lorsque Varnish n’a pas de HIT.

Lorsque tout est correctement configuré, Varnish peut livrer jusqu’à 1000 fois plus vite qu’un accès direct à PHP, tout en soulageant le CPU du serveur. 

2. Rappel : comment Varnish décide de mettre en cache ?

Élément Impact sur la cache Comment l’influencer
Méthode Seuls GET et HEAD sont éligibles Éviter les POST pour les pages publiques
En‑têtes réponse Cache-Control, Expires, Pragma Déterminent la durée et la portée Régler via .htaccess (voir §3)
Cookies / Set-Cookie Un cookie présent = pas de mise en cache par défaut Supprimer ou neutraliser les cookies inutiles
Status HTTP 200, 203, 301, 302, 404, 410 sont cachables Pas d’action, mais éviter les 500 !

[tips_truc_astuces]Varnish ignore par défaut le Cache-Control: no-cache envoyé par le navigateur pour les fichiers statiques, mais respecte le "revalidation logic" si l’objet est déjà en cache.[/tips]

3. Contrôler la durée de vie via .htaccess

Activez le module mod_headers (c’est le cas par défaut chez LWS) puis placez le snippet suivant où vous voulez :

<IfModule mod_headers.c>
  Header set Cache-Control "public, max-age=3600, s-maxage=3600, stale-while-revalidate=60, stale-if-error=86400"
  Header set Expires "Thu, 31 Dec 2037 23:55:55 GMT"
</IfModule>
  • max-age : durée (en secondes) dans le navigateur.
  • s-maxage : durée spécifique pour les caches partagés (Varnish/CDN).
  • stale-while-revalidate : permet à Varnish de servir un contenu périmé pendant qu’il le rafraîchit en arrière‑plan.
  • stale-if-error : sert la version périmée si le backend répond en erreur (fail‑safe).

3.1. Ciblage par dossier

Mettre le même fichier .htaccess dans le dossier "/images/" applique la règle uniquement au dossier "images".

3.2. Ciblage par extension

<IfModule mod_headers.c>
  <FilesMatch "\.(css|js|png|jpg|webp)$">
    Header set Cache-Control "public, max-age=2592000, s-maxage=2592000, immutable"
  </FilesMatch>
</IfModule>

immutable : indique au navigateur qu’aucune revalidation n’est nécessaire tant que l’objet n’a pas expiré ; idéal pour les fichiers versionnés (style.483bf.css).

3.3. Cache court pour HTML

<FilesMatch "\.(html?|htm)$">
  Header set Cache-Control "public, max-age=300, s-maxage=600, must-revalidate"
</FilesMatch>

Expire après 5 min côté client et 10 min côté Varnish, puis revalidation obligatoire.

4. Scénarios concrets d’utilisation

Cas réel Fragment de .htaccess Pourquoi ?
Landing page mise à jour toutes les heures max-age=600, s-maxage=1200 Les visiteurs ont une donnée « presque live » sans saturer PHP
CSS/JS versionnés max-age=31536000, immutable Trafic quasi nul sur le serveur, chargement instantané
Images produits e‑commerce max-age=604800 Réduit le TTFB, accélère le catalogue
Back‑office / wp-admin no-store, private Évite de mettre des données sensibles dans la cache partagée

5. Purger ou invalider le cache

  1. Depuis le LWS Panel : Optimisation & Performance > LWS Cache > Vider le cache.
  2. HTTP PURGE (si activé) : 
    ​​​​​​​curl -X PURGE -H "Host: exemple.com" https://exemple.com/chemin/ressource.jpg
  3. Bannir par expression (VCL avancé) : 
    ​​​​​​​ban req.http.host == "exemple.com" && req.url ~ "/images/"

     

6. Tester et déboguer

curl -I https://exemple.com/style.css

Regardez :

  • Age: 356 → Varnish a servi une réponse âgée de 356 s.
  • Cache-Control: public, max-age=2592000, s-maxage=2592000, immutable
  • X-Cache: HIT (ou MISS).

Avec Chrome/Edge : DevTools > Network > Disable cache peut simuler un premier visiteur.

7. Pièges courants

  1. Cookies inutiles : beaucoup de thèmes WordPress posent un cookie même pour les pages publiques. Supprimez‑les ou désactivez‑les via functions.php.
  2. Chaînes de requête : par défaut, ?v=123 crée une nouvelle entrée dans la cache. Versionnez plutôt dans le nom du fichier.
  3. Contenu sensible : formulaires, pages d’espace client ➡ no-store, private, max-age=0.
  4. Compression Brotli/Gzip : activez‑les avant la couche Varnish pour éviter une double mise en cache.

8. Bonnes pratiques récapitulatives

  • Utilisez s-maxage ⩾ max-age pour conserver un cache proxy plus long que celui du navigateur.
  • Mettez immutable sur tout fichier dont le nom contient un hash.
  • Ne mélangez pas Expires obsolète avec max-age sauf pour les anciens navigateurs.
  • Documentez vos TTL dans un fichier CACHE_POLICY.md pour l’équipe.

9. Ressources utiles

✅ Votre cache Varnish est maintenant sous contrôle !
 

Notez cet article

Vous avez noté 0 étoile(s)

Cet article a été lu 246 fois.

comments powered by Disqus
Top