Forcer la mise en cache Varnish sur LWS

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 ?

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

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

• LWS : Accélérer la vitesse de votre site avec Fastest Cache
• Blog LWS : Comment avoir un site plus performant avec Cache Varnish

✅ Votre cache Varnish est maintenant sous contrôle !