Force Varnish caching on LWS

Procédure

In this documentation, we will explain step-by-step how to force Varnish and browsers to keep your resources cached, even when they send Pragma: no-cache or Cache-Control: no-cache requests.

1. Context and LWS architecture

LWS shared hosting and managed cPanel/VPS packages are based on the :

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

• NGINX manages TLS and compresses content.
• Varnish (Fastest Cache) is used as a reverse proxy to store HTTP responses.
• Apache or PHP-FPM generate the final response when Varnish has no HIT.

When everything is correctly configured, Varnish can deliver up to 1000 times faster than direct access to PHP, while relieving the server's CPU.

2. Reminder: how does Varnish decide to cache?

[tips]Varnish ignores by default the Cache-Control: no-cache sent by the browser for static files, but respects the "revalidation logic" if the object is already cached[/tips].

3. Control the lifetime via .htaccess

Activate the mod_headers module (this is the default at LWS) then place the following snippet wherever you want:

  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"

• max-age: duration (in seconds) in the browser.
• s-maxage: specific duration for shared caches (Varnish/CDN).
• stale-while-revalidate: allows Varnish to serve stale content while it refreshes it in the background.
• stale-if-error: serves the out-of-date version if the backend responds in error (fail-safe).

3.1 Targeting by folder

Putting the same .htaccess file in the "/images/" folder applies the rule only to the "images" folder.

3.2 Targeting by extension

  
    Header set Cache-Control "public, max-age=2592000, s-maxage=2592000, immutable".  

immutable: tells the browser that no revalidation is required until the object has expired; ideal for versioned files (style.483bf.css).

3.3 Short cache for HTML

  Header set Cache-Control "public, max-age=300, s-maxage=600, must-revalidate".

Expires after 5 min client-side and 10 min Varnish-side, then must-revalidate.

4. Real-life usage scenarios

5. Purge or invalidate the cache

1. From the LWS Panel: Optimisation & Performance > LWS Cache > Empty cache.
2. HTTP PURGE (if enabled):

   curl -X PURGE -H "Host: example.com" https://exemple.com/chemin/ressource.jpg

3. Ban by expression (advanced VCL):

   ban req.http.host == "example.com" && req.url ~ "/images/"

6. Testing and debugging

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

Look at :

• Age: 356 → Varnish served a response aged 356 s.
• Cache-Control: public, max-age=2592000, s-maxage=2592000, immutable
• X-Cache: HIT (or MISS).

With Chrome/Edge: DevTools > Network > Disable cache can simulate a first visitor.

7. Common pitfalls

1. Unnecessary cookies: many WordPress themes set a cookie even for public pages. Delete them or disable them via functions.php.
2. Query strings: by default, ?v=123 creates a new entry in the cache. Version in the file name instead.
3. Sensitive content: forms, customer area pages ➡ no-store, private, max-age=0.
4. Brotli/Gzip compression: activate them before the Varnish layer to avoid double caching.

8. Summary of best practices

• Use s-maxage ⩾ max-age to keep a proxy cache that is longer than the browser cache.
• Put immutable on any file whose name contains a hash.
• Do not mix Obsolete Expires with max-age except for older browsers.
• Document your TTLs in a CACHE_POLICY.md file for the team.

9. Useful resources

• LWS: Speed up your site with Fastest Cache
• LWS blog: How to get a better-performing site with Varnish Cache

✅ Your Varnish cache is now under control!