Cache WordPress: come scegliere, configurare e verificare page cache, object cache e CDN

La cache WordPress non è un singolo strumento. Una page cache può servire HTML già pronto, Redis può conservare dati applicativi, OPcache riduce il lavoro di compilazione di PHP e una CDN può distribuire asset o, se configurata a questo scopo, anche pagine HTML dall’edge.

Attivare più sistemi senza assegnare un ruolo a ciascuno può lasciare online contenuti non aggiornati o servire in modo errato pagine dinamiche, come carrello e checkout. Il punto di partenza è identificare la richiesta da accelerare, scegliere chi gestisce l’HTML pubblico e verificare il risultato sui flussi reali del sito.

1. Scegliere la cache in base al problema

Scelta rapida

• Blog o sito vetrina: usa la page cache già fornita dall’hosting oppure un solo plugin di page cache. Aggiungi browser cache e CDN per gli asset.
• Sito WooCommerce: metti in cache catalogo e pagine pubbliche, ma escludi carrello, checkout, account e richieste di sessione. Valuta Redis solo se admin o richieste dinamiche mostrano un collo di bottiglia.
• Membership, e-learning o intranet: privilegia cache selettiva e object cache; dashboard e contenuti personalizzati devono restare dinamici.
• Hosting con cache gestita: verifica prima il suo funzionamento. Non aggiungere un secondo plugin che genera HTML senza sapere come avviene il purge.
• Pubblico internazionale: una CDN può ridurre la distanza dall’origine. La cache HTML edge va attivata solo con regole di bypass e invalidazione verificabili.

Page cache, object cache, OPcache, browser cache e CDN

I livelli possono convivere, ma risolvono problemi diversi. Redis non rende più veloce una pagina pubblica già servita interamente dalla page cache; una CDN per immagini, invece, non implica che l’HTML WordPress sia memorizzato ai nodi edge.

 
In WordPress, l’object cache standard è normalmente limitata alla singola richiesta. Per renderla persistente tra richieste servono un backend, come Redis o Memcached, e un drop-in wp-content/object-cache.php. La page cache usa spesso il drop-in wp-content/advanced-cache.php, una cache del server o un reverse proxy dell’hosting. La documentazione di WordPress sulle cache descrive i diversi meccanismi disponibili.

2. Mappare i layer attivi e configurare un flusso semplice

Prima di installare un plugin, controlla cosa offre già il provider. Molti hosting applicano cache server-side tramite Varnish, Nginx FastCGI cache o sistemi proprietari; aggiungere un secondo generatore di HTML senza comprenderne l’ordine rende più difficile invalidare la copia corretta.

Verifica nel pannello hosting, nei plugin e nella configurazione del sito:

• page cache o reverse proxy dell’hosting;
• CDN attiva e presenza di cache HTML edge, non solo di asset statici;
• Redis o Memcached inclusi nel piano;
• OPcache abilitato sul server;
• plugin di cache, CDN e ottimizzazione già attivi;
• i file wp-content/advanced-cache.php e wp-content/object-cache.php;
• quale comando o pannello esegue il purge del plugin, dell’hosting e della CDN.

La costante WP_CACHE in wp-config.php non dimostra che la page cache funzioni: abilita il caricamento anticipato di una soluzione compatibile, ma non crea una cache da sola. Il suo ruolo è documentato nella guida di WordPress su wp-config.php.

Un flusso operativo comune è questo: rileva la cache dell’hosting; scegli il solo gestore principale dell’HTML pubblico; configura le esclusioni per login, carrello, checkout e account; verifica che il purge raggiunga anche la CDN, se questa memorizza HTML; infine testa gli stessi URL come anonimo, guest con carrello e utente autenticato. Se un passaggio non è verificabile, non aggiungere un ulteriore livello di cache finché quello esistente non è chiaro.

3. Configurare page cache e CDN senza servire contenuti personali

Esclusioni: URL, cookie, query string e risposta

Una regola basata soltanto sull’URL non basta. Una pagina prodotto può essere cacheabile per un visitatore anonimo, ma la stessa richiesta non deve ricevere HTML condiviso quando contiene una sessione, un carrello o informazioni personali.

Le esclusioni devono considerare almeno:

• URL sensibili: login, carrello, checkout, account, aree riservate ed endpoint amministrativi;
• stato dell’utente: autenticato, con ruolo specifico o con autorizzazione HTTP;
• cookie di login, sessione e carrello;
• query string che cambiano il contenuto, come ricerca, filtri e parametri di personalizzazione;
• header e direttive della risposta, inclusi Cache-Control: private e Set-Cookie.

La presenza di Set-Cookie non rende automaticamente una risposta non cacheabile in ogni proxy o CDN. Tuttavia, se il cookie rappresenta uno stato individuale, la risposta richiede un bypass o regole esplicite per evitare di condividere contenuti personali. Le direttive HTTP e il comportamento della cache devono essere valutati insieme.

Browser cache e header HTTP

Gli header HTTP determinano per quanto tempo una risposta può essere riutilizzata. max-age indica la freschezza per il client; s-maxage riguarda cache condivise come proxy e CDN. public segnala che la risposta è condivisibile, mentre private la limita al browser dell’utente.

no-cache non significa “non memorizzare”: la risposta può essere conservata, ma deve essere rivalidata prima del riuso. Per vietare la memorizzazione serve no-store. La direttiva stale-while-revalidate può consentire temporaneamente l’uso di una risposta non fresca mentre avviene l’aggiornamento. Per il significato delle direttive, consulta il riferimento MDN su Cache-Control.

Evita durate identiche per tutto: asset versionati e stabili possono avere TTL lunghi; l’HTML di pagine aggiornate spesso richiede durate più prudenti oppure un purge affidabile dopo pubblicazioni, variazioni di prezzo e modifiche ai contenuti.

CDN, HTML edge e Cloudflare

Una CDN può distribuire immagini, CSS, JavaScript e font senza cacheare l’HTML. Con Cloudflare, il comportamento predefinito riguarda soprattutto le risorse statiche; per memorizzare pagine HTML servono regole dedicate o soluzioni come APO. La cacheabilità dipende da metodo della richiesta, header, cookie, risposta e regole applicate.

“Cache Everything” non è un’impostazione da attivare alla cieca: in presenza di cookie, query string o pagine personalizzate richiede bypass espliciti e test completi. Le condizioni e le regole disponibili sono descritte nella documentazione Cloudflare sul comportamento predefinito della cache e sulle Cache Rules.

4. WooCommerce e aree riservate: cosa deve restare dinamico

Un e-commerce può ottenere buoni tempi apparenti e allo stesso tempo essere configurato male. Carrello, checkout, “Il mio account”, login, recupero password, dashboard e contenuti dipendenti dal ruolo non devono essere serviti come HTML condiviso.

Oltre agli URL, controlla che la cache riconosca i cookie WooCommerce rilevanti, come woocommerce_cart_hash, woocommerce_items_in_cart e il cookie di sessione con prefisso wp_woocommerce_session_. Plugin, gateway di pagamento, strumenti di consenso e funzionalità aggiuntive possono introdurre ulteriori cookie da valutare. WooCommerce raccoglie indicazioni operative nella guida alla configurazione dei plugin di caching.

Prima della produzione esegui almeno questo test, sia in incognito sia da utente autenticato:

1. aggiungi un prodotto come guest e controlla il contatore del carrello;
2. apri il carrello, modifica la quantità e rimuovi un articolo;
3. raggiungi il checkout;
4. prova login, account e recupero password;
5. modifica prezzo, disponibilità o promozione e verifica il risultato da una finestra anonima.

Carrello vuoto dopo l’aggiunta, prezzi non aggiornati, sessioni incoerenti o login anomalo richiedono di controllare bypass ed esclusioni prima di intervenire sulle metriche prestazionali.

5. Verificare cache, HIT/MISS e invalidazione

Prima di modificare la configurazione, registra una baseline per home, articolo, archivio, prodotto, carrello, checkout e account. Per ogni URL annota lo stato del visitatore: anonimo, con cookie e autenticato. Rileva TTFB, header HTTP e comportamento funzionale; se il provider li mostra, conserva anche tempi applicativi o query.

Controllare gli header con curl e DevTools

Su una pagina pubblica, ripeti due o tre volte la stessa richiesta senza cookie:

curl -sD - -o /dev/null -H "Accept: text/html" https://www.esempio.it/pagina/

Osserva Cache-Control, Age, ETag, Last-Modified, CF-Cache-Status e gli eventuali header proprietari dell’hosting. Se l’HTML è effettivamente idoneo alla cache Cloudflare e la richiesta non varia per cookie, query string, cache key o header, un MISS iniziale seguito da HIT, con Age crescente, è un indizio coerente con una risposta servita dall’edge.

CF-Cache-Status: DYNAMIC indica che Cloudflare non ha considerato cacheabile quella risposta. BYPASS non identifica da solo un errore: va interpretato in base alle direttive della risposta e alle regole applicate. Cloudflare documenta gli stati e le cause delle risposte non memorizzate nella guida per indagare le risposte non in cache.

Per simulare una richiesta con cookie usa un cookie di test, senza copiare in script o documentazione cookie di sessione reali:

curl -sD - -o /dev/null -H "Accept: text/html" -b "nome_cookie=valore_di_test" https://www.esempio.it/pagina/

curl non riproduce la cache del browser né tutti gli header inviati dal browser. Completa quindi il controllo in DevTools, nella scheda Network: verifica la risposta HTML, eventuali redirect, header, cookie impostati e il valore di Vary. La documentazione di Chrome DevTools Network spiega come ispezionare le richieste.

Testare il purge con una modifica reale

Inserisci temporaneamente un marcatore testuale univoco in una pagina pubblica, pubblica la modifica e controlla il risultato da una finestra anonima. Se il sito usa una CDN o ha pubblico internazionale, ripeti da una seconda rete o località quando possibile.

Il test deve confermare l’invalidazione ordinaria tra WordPress, cache hosting e CDN. Non partire da “Purge Everything”: se svuotare tutto è l’unico modo per vedere una modifica, il flusso di invalidazione va corretto.

6. Quando il contenuto resta vecchio o le prestazioni non migliorano

Una pagina HTML obsoleta, un file PHP non aggiornato e un dato applicativo vecchio hanno cause diverse. Per l’HTML segui l’ordine browser, plugin di page cache, cache server o reverse proxy, quindi CDN. Se una modifica al codice PHP non appare, controlla OPcache e il deploy: opcache.validate_timestamps e opcache.revalidate_freq influenzano il rilevamento dei file modificati. Reset e riavvio dipendono dai permessi disponibili e dalla gestione dell’hosting. Consulta la documentazione PHP su OPcache prima di modificare tali impostazioni.

Se il problema riguarda transient, valori applicativi o risultati di query, l’object cache è un candidato più plausibile. Non svuotare tutti i livelli indistintamente: isola prima quello responsabile.

Redis può non produrre un miglioramento visibile in PageSpeed perché aiuta soprattutto richieste dinamiche, admin e utenti autenticati; una page cache efficace può evitare PHP e database per il traffico anonimo. Site Health può rilevare una persistent object cache, ma non dimostra hit rate, dimensionamento o beneficio reale. Misura prima e dopo sulle richieste che la usano davvero.

PageSpeed Insights combina dati di laboratorio e dati reali CrUX; questi ultimi coprono una finestra mobile di 28 giorni e possono mancare per URL con poco traffico. Un TTFB migliore non risolve automaticamente immagini pesanti, JavaScript, font, CLS, INP o script di terze parti. Prima verifica cache, header e flussi dinamici; poi usa Lighthouse o PageSpeed per individuare il collo di bottiglia successivo.

Come controllo finale, conferma che le pagine pubbliche ricevano la cache prevista, che le richieste personali siano escluse dalla cache condivisa, che una modifica pubblicata raggiunga tutte le copie e che WooCommerce o le aree autenticate funzionino correttamente. Solo dopo ha senso aggiungere object cache o cache edge come ottimizzazioni mirate.