Varnish Cache è un reverse proxy con cache HTTP che si posiziona davanti al server su cui gira WordPress. Quando una pagina può essere memorizzata, Varnish può restituirla direttamente senza costringere PHP, WordPress e il database a ricostruirla a ogni visita.
È proprio questo il suo vantaggio: invece di cercare di rendere più veloce ogni singola elaborazione di WordPress, evita che molte elaborazioni debbano avvenire.
Non significa però che basti installare Varnish per velocizzare qualsiasi sito. Un blog prevalentemente pubblico è relativamente semplice da gestire; un ecommerce WooCommerce, un’area riservata o un sito con contenuti personalizzati richiedono invece regole precise per distinguere ciò che può essere condiviso dalla cache da ciò che deve arrivare sempre da WordPress.
Prima di intervenire a livello server conviene quindi avere chiaro come funziona la cache in WordPress e quale livello dello stack stai cercando di ottimizzare.
In questa guida vediamo come funziona Varnish, quando ha senso usarlo con WordPress, come impostare le regole fondamentali e soprattutto come evitare di mettere in cache login, sessioni, carrello e altre risposte che devono restare dinamiche.
Cos’è Varnish Cache e cosa fa davanti a WordPress
Varnish Cache è un software che opera come caching reverse proxy. Riceve le richieste HTTP prima del web server che ospita WordPress e decide, attraverso una serie di regole, se restituire una risposta già presente in cache oppure inoltrare la richiesta al backend. La documentazione corrente lo descrive proprio come un proxy di cache collocato davanti al web server per ridurre il carico sui sistemi di origine.
Il modello semplificato è questo:
Browser → Varnish → Apache/Nginx → PHP → WordPress → database
Se Varnish possiede già una risposta valida per quella richiesta, il percorso può fermarsi molto prima:
Browser → Varnish → risposta dalla cache
Questa differenza diventa particolarmente importante quando un sito deve gestire molte richieste contemporanee o quando la generazione delle pagine WordPress è relativamente costosa.
Per una strategia più ampia sulle performance puoi approfondire anche come velocizzare un sito WordPress.
Reverse proxy, cache hit e cache miss
Un reverse proxy lavora dal lato del server: il visitatore non deve configurare nulla e normalmente non sa neppure che Varnish sia presente.
Quando arriva una richiesta possono verificarsi due situazioni principali.
Un cache hit si verifica quando Varnish trova una copia ancora valida della risposta e può servirla senza interrogare nuovamente WordPress.
Un cache miss si verifica invece quando la risposta non è disponibile, è scaduta oppure la richiesta non può essere messa in cache. Varnish inoltra quindi la richiesta al backend e WordPress genera normalmente la pagina.
Il punto importante è che un MISS non indica necessariamente un problema. Alcune richieste devono raggiungere WordPress: una pagina amministrativa, una sessione autenticata, un checkout o una richiesta POST non dovrebbero essere trattati come una normale pagina pubblica anonima.
La qualità della configurazione non si misura quindi dal tentativo di ottenere il 100% di hit, ma dalla capacità di mettere in cache ciò che è sicuro condividere e bypassare ciò che è personale o dinamico.
Varnish, Varnish Cache e Vinyl Cache: perché oggi trovi nomi diversi
La terminologia può creare confusione soprattutto se confronti documentazione recente e vecchi tutorial.
Varnish è il nome generalmente utilizzato per l’ecosistema e la tecnologia. Varnish Cache indica oggi una distribuzione open source mantenuta da Varnish Software, basata sul progetto upstream Vinyl Cache. Il progetto open source storico ha infatti iniziato il passaggio dal nome Varnish Cache a Vinyl Cache dopo la release 8.0.
Per chi amministra WordPress il modello operativo rimane comunque riconoscibile: reverse proxy, cache HTTP, VCL, backend, invalidazione e bypass continuano a essere i concetti fondamentali.
Questa distinzione diventa importante soprattutto quando cerchi pacchetti, documentazione o release correnti. Prima di copiare una configurazione trovata anni fa, controlla quindi per quale progetto e versione è stata scritta.
Quando Varnish conviene davvero su un sito WordPress
Varnish ha più senso quando vuoi ridurre il lavoro del backend su contenuti che vengono richiesti molte volte ma cambiano relativamente poco tra un visitatore e l’altro.
Un sito editoriale, una testata, un portale con molto traffico anonimo o un catalogo consultato frequentemente sono scenari naturali. Un’applicazione quasi interamente personalizzata o un sito in cui la maggior parte degli utenti è autenticata può ottenere invece meno beneficio dalla full-page cache.
Prima di aggiungere un altro livello allo stack conviene inoltre capire quali sistemi di cache sono già presenti.
| Sistema | Dove lavora | Funzione principale | Attenzione |
|---|---|---|---|
| Varnish Cache | Davanti al web server | Cache delle risposte HTTP | Deve distinguere contenuti pubblici e dinamici |
| Page cache WordPress | Applicazione/server | Evita parte della generazione WordPress | Dipende dal plugin o dall’hosting |
| Object cache | WordPress/database | Riutilizza dati e risultati di query | Non sostituisce la page cache |
| CDN | Rete distribuita/edge | Porta contenuti più vicino agli utenti | Può aggiungere un ulteriore livello di cache |
| NGINX FastCGI Cache | Web server | Cache delle risposte generate da PHP | Può svolgere un ruolo simile alla page cache server-side |
Questi livelli non sono automaticamente alternativi e non vanno nemmeno sommati alla cieca.
Un sito può avere, per esempio, object cache per alleggerire WordPress e una cache HTTP davanti all’applicazione. Ma utilizzare contemporaneamente diversi sistemi di full-page cache senza capire quale debba essere la fonte di verità può complicare invalidazione e troubleshooting.
Varnish rispetto alla cache di un plugin, object cache e CDN
Un plugin WordPress opera dall’interno dell’ecosistema WordPress e può conoscere direttamente eventi come pubblicazione, modifica di un post o aggiornamento di determinate impostazioni.
Varnish lavora invece prima dell’applicazione. È proprio questa distanza da WordPress a renderlo estremamente efficace, ma rende necessaria una buona integrazione per sapere quando eliminare una risposta che non è più valida.
L’object cache risolve un problema ancora diverso: riduce il costo del recupero di dati utilizzati da WordPress, ma la richiesta continua comunque ad arrivare a PHP e all’applicazione.
Anche una CDN può sovrapporsi parzialmente alla funzione di Varnish se effettua full-page caching all’edge. Prima di costruire uno stack molto complesso conviene quindi stabilire quale componente è responsabile di ogni livello.
In pratica:
- se il tuo hosting fornisce già una cache server-side ben integrata con WordPress, aggiungere Varnish potrebbe essere inutile;
- se gestisci direttamente l’infrastruttura e vuoi un controllo molto preciso delle policy HTTP, Varnish diventa molto più interessante;
- se il problema principale riguarda query ripetitive o dati applicativi, la soluzione potrebbe essere una object cache anziché un altro reverse proxy.
Serve un VPS oppure può occuparsene l’hosting?
Per installare e amministrare direttamente Varnish devi poter intervenire sull’infrastruttura: porte, servizi, configurazione del backend, VCL e spesso systemd o container.
Questo rende naturali ambienti come VPS, server dedicati, cloud e piattaforme containerizzate. La documentazione corrente prevede installazioni per Debian/Ubuntu, distribuzioni compatibili con RHEL, Docker e Kubernetes.
Guida ufficiale all’installazione di Varnish Cache
Non significa però che Varnish sia incompatibile per definizione con qualsiasi hosting condiviso. Potresti non poterlo installare personalmente, ma il provider può averlo già implementato come servizio gestito.
Prima di cambiare configurazioni controlla quindi il pannello e la documentazione dell’hosting. Potresti scoprire che la cache server-side viene già gestita automaticamente e che aggiungere un secondo sistema produrrebbe soltanto complessità.
Come funziona l’architettura Varnish + WordPress
Nella configurazione classica Varnish riceve il traffico pubblico e comunica con un backend rappresentato da Apache, NGINX o un altro web server.
Se i due servizi girano sulla stessa macchina, un’impostazione comune consiste nel far ascoltare Varnish sulla porta pubblica e spostare il web server su una porta interna, per esempio 8080.
La definizione VCL del backend può quindi partire da qualcosa di simile:
vcl 4.1;
backend default {
.host = "127.0.0.1";
.port = "8080";
}
Questo frammento dice soltanto dove trovare l’origin. Non costituisce una configurazione WordPress completa.
La VCL reale deve occuparsi anche di metodi HTTP, cookie, autenticazione, URL da bypassare, invalidazione, risposte non cacheabili e altre caratteristiche del tuo stack.
VCL significa Varnish Configuration Language: è il linguaggio utilizzato per descrivere come Varnish deve trattare richieste e risposte. La vecchia sigla “VLC” che si trova in alcuni tutorial è semplicemente errata.
Se il backend è NGINX e vuoi approfondire il suo ruolo indipendentemente da Varnish, trovi una guida dedicata a NGINX e al suo funzionamento come web server e reverse proxy.
HTTPS: Varnish supporta TLS nativamente?
Sì, a partire dalla versione 9 Varnish supporta TLS nativo, sia per le connessioni in ingresso sia per la comunicazione HTTPS con i backend. La documentazione corrente permette quindi di configurare direttamente l’ascolto HTTPS senza richiedere obbligatoriamente un proxy TLS separato.
Documentazione ufficiale per configurare TLS in Varnish
È una differenza importante rispetto a molte guide storiche, secondo cui la versione open source non poteva gestire TLS e doveva necessariamente essere affiancata da Hitch, NGINX o HAProxy.
Gli stack precedenti restano comunque perfettamente possibili. Potresti avere, per esempio:
Browser → CDN/NGINX/HAProxy → Varnish → WordPress
Se TLS viene terminato prima di Varnish, devi assicurarti che il protocollo originario venga comunicato correttamente lungo la catena. Un valore errato di X-Forwarded-Proto può portare WordPress a credere di essere stato raggiunto tramite HTTP quando il visitatore utilizzava HTTPS, con conseguenze come mixed content e redirect loop. La documentazione Varnish mantiene una guida specifica proprio per questi scenari legacy o proxy-based.
Come configurare Varnish Cache con WordPress
La configurazione dovrebbe partire dall’infrastruttura e arrivare soltanto dopo a WordPress.
Prima di intervenire su un sito di produzione, fai un backup e, quando possibile, prova le regole in staging. Un errore nella cache HTTP può essere subdolo: il sito può sembrare perfettamente funzionante mentre alcuni utenti ricevono contenuti destinati ad altre sessioni.
1. Installa Varnish e configura il backend
Usa i pacchetti e le istruzioni della distribuzione corrente invece di recuperare comandi da tutorial molto vecchi.
Install guide ufficiale Varnish Cache
Una volta installato il servizio devi definire il backend, cioè il server al quale Varnish deve rivolgersi quando non può soddisfare una richiesta dalla cache.
In un’installazione sulla stessa macchina può essere qualcosa come:
backend default {
.host = "127.0.0.1";
.port = "8080";
}
La porta deve naturalmente corrispondere a quella effettivamente utilizzata dal tuo web server.
Non copiare 8080 come se fosse un requisito di Varnish: è soltanto una convenzione frequente.
2. Configura il file VCL per WordPress
Il vero lavoro avviene nel file VCL.
Per WordPress devi innanzitutto evitare la cache per richieste che non sono semplici pagine pubbliche anonime. Un punto di partenza concettuale può essere:
sub vcl_recv {
# Solo GET e HEAD sono candidati alla normale page cache
if (req.method != "GET" && req.method != "HEAD") {
return (pass);
}
# Richieste autenticate
if (req.http.Authorization) {
return (pass);
}
# Backend e login WordPress
if (
req.url ~ "^/wp-admin" ||
req.url ~ "^/wp-login\.php" ||
req.url ~ "^/wp-cron\.php"
) {
return (pass);
}
# Utenti autenticati o contenuti protetti
if (
req.http.Cookie ~ "wordpress_logged_in_" ||
req.http.Cookie ~ "wordpress_sec_" ||
req.http.Cookie ~ "wp-postpass"
) {
return (pass);
}
}
Questo esempio serve a mostrare il meccanismo, non è un default.vcl completo pronto per qualunque sito.
Una configurazione production-ready deve considerare almeno:
- invalidazione della cache;
- query string;
- file statici;
- header
Cache-Control; - risposte con
Set-Cookie; - richieste AJAX/API quando necessario;
- plugin che utilizzano sessioni;
- eventuale ecommerce;
- protocollo HTTP/HTTPS;
- caratteristiche specifiche del sito.
Varnish Software mantiene un template WordPress molto più completo che include normalizzazione delle richieste, gestione delle purge, cookie e intestazioni di debugging.
Configurazione Varnish ufficiale per WordPress
Partirei da quel template e lo adatterei al sito, invece di assemblare decine di snippet trovati in articoli scritti per versioni differenti.
3. Escludi wp-admin, login e utenti autenticati
wp-admin e wp-login.php non devono essere trattati come normali pagine pubbliche.
Lo stesso vale per le richieste degli utenti autenticati. Una cache condivisa deve riconoscere i cookie di login e passare quelle richieste al backend.
Questa distinzione è fondamentale: servire accidentalmente una risposta personalizzata dalla cache condivisa non è semplicemente un problema di performance, ma può diventare un problema di privacy o funzionamento.
Quando testi la configurazione, non limitarti quindi alla homepage da una finestra anonima. Prova almeno:
- visitatore anonimo;
- amministratore autenticato;
- preview di un contenuto;
- pubblicazione e modifica di un post;
- eventuali form o aree personali.
4. Collega WordPress all’invalidazione della cache
Una cache veloce che restituisce contenuti vecchi non è una buona cache.
Quando modifichi un articolo WordPress, Varnish non può conoscere automaticamente il significato editoriale di quell’evento. Serve quindi un meccanismo che comunichi al proxy quali risposte non sono più valide.
Un’opzione ancora disponibile è Proxy Cache Purge.
Proxy Cache Purge su WordPress.org
Il plugin non installa né configura Varnish. Funziona come interfaccia con un reverse proxy già esistente e, quando WordPress aggiorna determinati contenuti, invia le richieste necessarie per invalidare le relative copie in cache.
La distinzione è importante perché elimina un errore frequente:
installare Proxy Cache Purge non significa aver configurato Varnish.
La VCL deve essere predisposta per ricevere e gestire correttamente le richieste di invalidazione.
5. Proteggi le richieste PURGE
Non dovresti consentire a chiunque su Internet di svuotare la cache.
Una normale configurazione definisce un’ACL con gli host o gli indirizzi autorizzati:
acl purge {
"localhost";
"127.0.0.1";
"::1";
}
Se WordPress e Varnish sono su macchine differenti, dovrai adattare l’ACL al tuo ambiente.
La configurazione ufficiale usa proprio questo meccanismo per evitare che richieste PURGE non autorizzate possano eliminare oggetti dalla cache.
Non rimuovere questa protezione solo perché durante il test il purge “non funziona”: prima verifica da quale IP arriva realmente la richiesta di WordPress.
Varnish e WooCommerce: cosa non deve finire nella cache
WooCommerce rende la configurazione più delicata perché alcune pagine e alcuni cookie rappresentano uno stato specifico del singolo cliente.
Il principio è semplice: le pagine pubbliche del catalogo possono essere ottime candidate alla cache, mentre il percorso transazionale deve rimanere dinamico.
WooCommerce indica esplicitamente che Cart, Checkout e My Account devono essere escluse dalla cache perché contengono informazioni specifiche del cliente.
Raccomandazioni ufficiali WooCommerce sulla cache
Carrello, checkout e account
In una configurazione con gli slug predefiniti potresti trovare una regola di questo tipo:
if (
req.url ~ "^/(cart|checkout|my-account)(/|$)" ||
req.url ~ "[?&]add-to-cart="
) {
return (pass);
}
Attenzione però: gli URL reali del tuo negozio possono essere diversi.
Un WooCommerce italiano può usare slug personalizzati o pagine tradotte. Non copiare quindi /cart e /checkout senza verificare quali URL sono effettivamente configurati nel negozio.
La regola corretta è quella che rappresenta la struttura reale del sito.
Cookie e sessioni WooCommerce
Anche i cookie permettono di riconoscere richieste che non devono ricevere una pagina generica dalla cache.
WooCommerce documenta, tra gli altri:
woocommerce_cart_hash;woocommerce_items_in_cart;wp_woocommerce_session_.
Questi cookie servono a mantenere informazioni legate al carrello e alla sessione del cliente.
Una regola VCL può quindi bypassare la cache quando sono presenti:
if (
req.http.Cookie ~ "woocommerce_cart_hash" ||
req.http.Cookie ~ "woocommerce_items_in_cart" ||
req.http.Cookie ~ "wp_woocommerce_session_"
) {
return (pass);
}
Non è però sufficiente copiare tre nomi e considerare risolto l’ecommerce. Estensioni per membership, wishlist, prezzi personalizzati, multivaluta, affiliate tracking o contenuti riservati possono introdurre altre condizioni che richiedono bypass.
Su WooCommerce la domanda da farti è sempre:
questa risposta può essere condivisa in sicurezza tra due visitatori diversi?
Se la risposta è no o non ne sei sicuro, quella richiesta non dovrebbe entrare nella full-page cache senza un test specifico.
Come verificare se Varnish sta realmente funzionando
Il fatto che il servizio sia attivo non dimostra che le pagine WordPress stiano ottenendo cache hit.
Una configurazione errata può far passare praticamente tutto al backend, lasciandoti con Varnish perfettamente acceso ma quasi inutile.
Controlla gli header HTTP
Un primo test può essere eseguito con:
curl -I https://example.com/
Ripeti la stessa richiesta come utente anonimo.
A seconda della configurazione puoi osservare header come Age, Via, X-Varnish oppure un header di debug personalizzato.
Il template WordPress ufficiale aggiunge, per esempio, X-Cacheable per rendere più semplice capire se una richiesta è stata considerata cacheabile.
Non lasciare necessariamente header di debug dettagliati esposti per sempre: sono utili soprattutto durante configurazione e troubleshooting.
Controlla cosa raggiunge il backend
Quando vuoi capire cosa sta realmente accadendo, gli strumenti server-side sono molto più informativi del solo browser.
varnishstat permette di osservare le statistiche del servizio, mentre varnishlog mostra il flusso delle richieste attraverso Varnish.
La documentazione consiglia inoltre varnishtop per individuare quali URL stanno raggiungendo più frequentemente il backend.
Se una homepage pubblica viene sempre rigenerata, indaga per prima cosa:
- cookie presenti sulla richiesta;
Set-Cookienella risposta;Cache-Control;- query string;
- regole VCL che restituiscono
pass; - plugin che creano una sessione anche per utenti anonimi.
Verifica l’invalidazione
Fai un test semplice:
- apri una pagina pubblica come utente anonimo;
- verifica che venga memorizzata;
- modifica il contenuto in WordPress;
- salva;
- ricarica la pagina da una sessione anonima.
La nuova versione deve essere visibile senza attendere arbitrariamente la scadenza del TTL.
Se continui a vedere il contenuto precedente, il problema non è necessariamente “Varnish che non si aggiorna”: potrebbe essere il plugin di purge, l’ACL, una cache CDN sovrapposta o la regola VCL utilizzata per individuare gli oggetti da invalidare.
Problemi comuni con Varnish su WordPress
Quando qualcosa non funziona, evita di svuotare indiscriminatamente tutte le cache e cambiare più configurazioni contemporaneamente. Prima identifica quale livello sta restituendo la risposta sbagliata.
Le modifiche a WordPress non compaiono
Se una pagina continua a mostrare contenuti vecchi dopo la modifica, verifica innanzitutto che l’invalidazione raggiunga Varnish.
Proxy Cache Purge può eliminare automaticamente le copie interessate quando WordPress modifica contenuti, ma il proxy deve essere configurato per accettare e interpretare correttamente quelle richieste.
Se esiste anche una CDN o un’altra page cache davanti o dietro Varnish, potresti invece aver aggiornato correttamente un livello e continuare a vedere la risposta di un altro.
Per problemi generici di contenuto non aggiornato è utile distinguere questa situazione dalla normale cache del browser o del dispositivo.
Varnish restituisce sempre MISS
Un sito WordPress può impostare cookie anche per visitatori anonimi. Inoltre alcune risposte possono contenere header che indicano a Varnish di non memorizzarle.
Prima di aumentare TTL o eliminare indiscriminatamente cookie, scopri perché quella risposta viene rifiutata dalla cache.
Forzare la cache eliminando ogni cookie può trasformare un problema di performance in un problema funzionale molto più grave.
Loop di redirect e problemi HTTPS
Se TLS viene terminato da un componente davanti a Varnish, WordPress deve sapere che la richiesta originale era HTTPS.
Una gestione incoerente di X-Forwarded-Proto può causare URL HTTP generati all’interno di pagine HTTPS oppure ERR_TOO_MANY_REDIRECTS.
La soluzione corrente, quando l’infrastruttura lo consente, è valutare il TLS nativo di Varnish. Negli stack che continuano a terminare TLS attraverso un proxy separato devi invece mantenere correttamente l’informazione sul protocollo lungo tutta la catena.
Login o area amministrativa si comportano in modo anomalo
Controlla subito che:
/wp-admin/bypassi la cache;/wp-login.phpbypassi la cache;- i cookie degli utenti autenticati causino un
pass; - eventuali pagine riservate siano escluse.
Questi controlli vengono prima di qualsiasi ricerca del “TTL ideale”.
Carrello WooCommerce che si svuota o mostra dati sbagliati
Qui il sospetto principale deve ricadere sulle regole di cache delle sessioni.
Controlla URL del carrello, checkout e account, cookie WooCommerce e plugin che modificano il comportamento delle sessioni.
WooCommerce considera espressamente queste pagine dinamiche e raccomanda di escluderle dalla cache.
Varnish può migliorare il TTFB di WordPress?
Può ridurre sensibilmente il tempo necessario a ricevere una risposta quando la richiesta viene soddisfatta direttamente dalla cache, perché PHP e WordPress non devono generare nuovamente la pagina.
Non significa però che qualsiasi TTFB alto richieda Varnish.
Se le richieste non sono cacheabili, il collo di bottiglia può rimanere nel backend. In quel caso devi analizzare hosting, PHP, database, query, plugin, chiamate esterne e architettura prima di aggiungere un ulteriore proxy.
Puoi approfondire questa parte nella guida al TTFB e alle cause che influenzano il tempo di risposta del server.
La metrica utile non è quindi soltanto “quanto è veloce Varnish”, ma anche quale percentuale del traffico che dovrebbe essere cacheabile sta effettivamente ottenendo hit.
Conclusione
Varnish Cache può essere un ottimo strumento per WordPress quando hai molto traffico pubblico, controllo dell’infrastruttura e una strategia di cache ben definita.
Il vantaggio reale non deriva dal semplice fatto di avere un altro software davanti al sito. Deriva dal togliere lavoro a WordPress quando una risposta può essere riutilizzata in sicurezza e dal lasciare invece al backend tutte le richieste che dipendono da utente, sessione o stato dell’applicazione.
Per un blog o un sito editoriale, la configurazione può essere relativamente lineare. Su WooCommerce devi invece considerare carrello, checkout, account e cookie di sessione. Se il tuo hosting offre già una page cache server-side gestita, prima di installare Varnish verifica cosa sta già facendo: due sistemi che risolvono lo stesso problema non sono necessariamente meglio di uno configurato bene.
La sequenza che seguirei è questa: capire lo stack esistente, definire cosa può essere messo in cache, configurare VCL e invalidazione, quindi verificare HIT/MISS e comportamento degli utenti autenticati. Solo dopo ha senso intervenire su TTL e ottimizzazioni più aggressive.
Se non hai accesso o esperienza sufficiente per modificare reverse proxy, VCL e configurazione server, è preferibile non sperimentare direttamente sul sito di produzione. In questi casi una revisione dell’infrastruttura può rientrare naturalmente in un intervento di assistenza e manutenzione WordPress, soprattutto quando cache, hosting e configurazione applicativa devono essere analizzati insieme.