Forzare la cache di Varnish su LWS

Procédure

In questa documentazione spiegheremo passo dopo passo come forzare Varnish e i browser a mantenere le risorse nella cache, anche quando inviano richieste Pragma: no-cache o Cache-Control: no-cache.

1. Contesto e architettura LWS

I pacchetti di hosting condiviso e di cPanel/VPS gestiti di LWS si basano sull'architettura :

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

• NGINX gestisce il TLS e comprime il contenuto.
• Varnish (Fastest Cache) è utilizzato come reverse proxy per memorizzare le risposte HTTP.
• Apache o PHP-FPM generano la risposta finale quando Varnish non ha HIT.

Quando tutto è configurato correttamente, Varnish può fornire una velocità fino a 1000 volte superiore rispetto all'accesso diretto a PHP, alleggerendo al contempo la CPU del server.

2. Promemoria: come fa Varnish a decidere la cache?

[tips]Varnish ignora per impostazione predefinita il Cache-Control: no-cache inviato dal browser per i file statici, ma rispetta la "logica di riconvalida" se l'oggetto è già nella cache[/tips].

3. Controllare il tempo di vita tramite .htaccess

Attivate il modulo mod_headers (è quello predefinito in LWS) e inserite il seguente snippet dove volete:

  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: durata (in secondi) nel browser.
• s-maxage: durata specifica per le cache condivise (Varnish/CDN).
• stale-while-revalidate: consente a Varnish di servire contenuti obsoleti mentre li aggiorna in background.
• stale-if-error: serve la versione non aggiornata se il backend risponde con un errore (fail-safe).

3.1 Targeting per cartella

Mettendo lo stesso file .htaccess nella cartella "/images/" si applica la regola solo alla cartella "images".

3.2 Individuazione del bersaglio per estensione

  
    L'intestazione imposta Cache-Control "public, max-age=2592000, s-maxage=2592000, immutable".  

immutable: indica al browser che non è necessaria una riconvalida fino alla scadenza dell'oggetto; ideale per i file con versione (style.483bf.css).

3.3 Cache breve per l'HTML

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

Scade dopo 5 minuti lato client e 10 minuti lato Varnish, poi deve essere riconvalidata.

4. Scenari di utilizzo reali

5. Eliminare o invalidare la cache

1. Dal pannello LWS: Ottimizzazione e prestazioni > Cache LWS > Svuota cache.
2. HTTP PURGE (se abilitato):

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

3. Divieto per espressione (VCL avanzato):

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

6. Test e debug

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

Guardare :

• Età: 356 → Varnish ha servito una risposta di 356 secondi.
• Cache-Control: public, max-age=2592000, s-maxage=2592000, immutable
• X-Cache: HIT (o MISS).

Con Chrome/Edge: DevTools > Network > Disable cache può simulare un primo visitatore.

7. Insidie comuni

1. Cookie non necessari: molti temi di WordPress impostano un cookie anche per le pagine pubbliche. Eliminarli o disabilitarli tramite functions.php.
2. Stringhe di query: per impostazione predefinita, ?v=123 crea una nuova voce nella cache. La versione nel nome del file, invece, è da considerarsi un'opzione.
3. Contenuti sensibili: moduli, pagine dell'area clienti ➡ no-store, private, max-age=0.
4. Compressione Brotli/Gzip: attivarli prima del livello Varnish per evitare una doppia cache.

8. Riassunto delle migliori pratiche

• Utilizzare s-maxage ⩾ max-age per mantenere una cache proxy più lunga di quella del browser.
• Mettere immutable su qualsiasi file il cui nome contenga un hash.
• Non mischiare Obsolete Expires con max-age, tranne che per i browser più vecchi.
• Documentare i TTL in un file CACHE_POLICY.md per il team.

9. Risorse utili

• LWS: Velocizza il tuo sito con Fastest Cache
• Blog LWS: Come ottenere un sito più performante con Varnish Cache

La vostra cache Varnish è ora sotto controllo!