Cache per WooCommerce: quali usare e come configurarle

Su un sito vetrina la cache la accendi e via, tanto le pagine sono uguali per tutti. Su WooCommerce è un altro mestiere: appena arrivano carrello, sessioni e prezzi che cambiano da utente a utente, la stessa cache che ti fa volare la home ti può servire il carrello di un altro cliente al malcapitato di turno. Ho visto shop mostrare “3 articoli nel carrello” a chi era appena arrivato, e indovina il motivo: checkout messo in cache. Quindi sì, la cache su WooCommerce serve eccome, ma va capita prima di accenderla.

In questa guida vediamo quali tipi di cache per WooCommerce esistono davvero, quali strumenti usare nel 2026 e come configurarli senza rompere il carrello. Niente formule magiche, solo l’ordine giusto in cui mettere le cose.

I livelli di cache (che tutti confondono)

Quando qualcuno dice “ho messo la cache” di solito intende un plugin. In realtà la cache è fatta a strati, e ognuno lavora in un punto diverso della catena:

• Browser cache: il browser dell’utente tiene CSS, JS e immagini in locale, così alla seconda visita non riscarica tutto.
• CDN / edge cache: una rete (tipo Cloudflare) serve i file statici da un server vicino al visitatore. Occhio: di default non mette in cache l’HTML di WordPress.
• Page cache: qui si salva l’HTML già pronto della pagina, così PHP e database non lavorano a ogni visita. È la leva più potente e anche la più pericolosa su Woo.
• Object cache: Redis o Memcached tengono in RAM i risultati delle query più frequenti. Su uno shop con tanti prodotti e utenti loggati è oro.
• OPcache: la cache del codice PHP compilato, lato server. Si attiva e si dimentica, ma fa la sua parte.

Non sono alternativi, lavorano insieme. Un WooCommerce fatto bene li usa quasi tutti, ognuno al suo posto.

La regola d’oro: cosa non cachare MAI

Se ti porti a casa una cosa sola da questo articolo, che sia questa. Su WooCommerce ci sono pagine che devono restare dinamiche, sempre, per ogni utente:

• le pagine /carrello/, /checkout/ e /mio-account/;
• le chiamate AJAX di WooCommerce (wc-ajax=), tipo l’aggiornamento del mini-carrello;
• tutto ciò che gira attorno ai cookie di sessione: woocommerce_items_in_cart, woocommerce_cart_hash, wp_woocommerce_session_*.

Se una di queste finisce in cache, servi a un cliente il carrello o la sessione di un altro. Non è un bug estetico, è un problema di privacy e di ordini sballati. La buona notizia è che i plugin seri queste esclusioni le fanno già da soli, come vedremo tra poco. Se vuoi il quadro completo su come tenere veloce lo shop senza toccare il checkout, ne ho parlato a fondo nella guida su come velocizzare WooCommerce.

Quali cache usare nel 2026

Partiamo dalla page cache, che è quella che fa la differenza. La regola vale sopra ogni cosa: una sola page cache. Due plugin che cachano l’HTML in contemporanea significano pagine rotte, prezzi vecchi e checkout ballerino. Detto questo, ecco cosa userei a seconda del caso.

• WP Rocket: su hosting normale (Nginx o Apache) è la scelta più sicura. Si installa, funziona, e soprattutto riconosce WooCommerce ed esclude carrello, checkout e account da solo, senza che tu debba toccare niente. A pagamento, ma per uno shop vale i soldi.
• LiteSpeed Cache: se il tuo host gira su server LiteSpeed o OpenLiteSpeed, è gratis ed è il più veloce, perché la cache vive nel web server e non in PHP. Fuori da LiteSpeed, però, perde quasi tutto il vantaggio.
• FlyingPress: la scelta di chi campa sui Core Web Vitals, ottimo sul lato frontend.
• W3 Total Cache e WP Super Cache: gratis, ma il primo è complesso e il secondo basilare; su Woo richiedono esclusioni configurate a mano con attenzione.

Poi c’è l’object cache: qui parliamo di Redis (o Memcached), che non arriva dal plugin di cache ma dal server. Lo attivi lato host e lo colleghi con Redis Object Cache. Su uno shop con parecchi ordini al mese abbassa il tempo di risposta in modo netto. Se hai un tuo VPS e vuoi capirci qualcosa, ho scritto come installare Redis su un server passo passo.

Sopra tutto, Cloudflare davanti al sito: fa da edge cache per i file statici e regge bene i picchi. Nel suo pannello imposti una regola di “bypass” per carrello, checkout e mio-account, e sei a posto. Se invece hai il controllo del server, la page cache la puoi fare direttamente a livello di Nginx o con Varnish come reverse proxy: più veloce ancora, ma la devi configurare con criterio.

Come configurarle, in ordine

L’ordine con cui accendo le cose su uno shop è sempre questo:

• Page cache con le esclusioni giuste: attivo il plugin e verifico che carrello, checkout, account e wc-ajax siano fuori. Con WP Rocket è automatico, con gli altri controllo a mano.
• Preload: faccio precaricare la cache delle pagine pubbliche così il primo visitatore non becca la pagina “fredda”. Su WP Rocket si automatizza, e ho spiegato come svuotarla e ricaricarla in automatico.
• Object cache Redis: se il server ce l’ha, la attivo e controllo dal backend che stia davvero rispondendo.
• OPcache: verifico che sia attivo lato PHP, di solito lo è già.
• Browser cache e CDN: header di scadenza sui file statici e Cloudflare davanti per servirli dall’edge.
• Test con un ordine vero: aggiungo un prodotto, vado al checkout, pago in modalità test. Se il carrello si aggiorna e il totale è giusto, la cache è configurata bene.

Quest’ultimo passo non saltarlo mai. Il modo più veloce per accorgersi che la cache è rotta è un cliente che ti scrive incazzato, e non è il momento migliore per scoprirlo.

Le esclusioni a livello Nginx (per chi ha il server)

Se gestisci il tuo VPS e usi la FastCGI cache di Nginx, queste sono le righe che uso per non cachare mai la roba dinamica di WooCommerce. Copia-incolla, adattando gli slug se il tuo sito è in inglese:

Chi invece usa WP Rocket o LiteSpeed queste esclusioni ce le ha già pronte: è proprio uno dei motivi per cui, su uno shop, un plugin fatto bene ti risparmia un sacco di grane.

Gli errori che vedo più spesso

• Due page cache insieme: plugin di cache più cache dell’host che si pestano i piedi. Una sola, punto.
• Checkout in cache: il classico dei classici, con prezzi e carrelli sbagliati serviti ai clienti.
• Object cache dimenticata: si mette la page cache e si lascia il database a sudare su ogni query dinamica.
• CDN che caches le pagine loggate: regole di edge cache troppo aggressive che servono pagine utente a tutti.
• Nessun test reale: si guarda solo il punteggio di velocità e non si prova un ordine vero. Il numero può essere bello anche con il checkout rotto: conta l’esperienza reale, come ho raccontato parlando di PageSpeed contro le prestazioni reali.

Domande frequenti

Devo cachare il carrello e il checkout di WooCommerce ?

No, mai. Carrello, checkout e “mio account” cambiano per ogni utente e devono restare dinamici. Se li metti in cache rischi di mostrare il carrello o la sessione di un cliente a un altro, con ordini e prezzi sbagliati. I plugin seri li escludono in automatico.

Meglio WP Rocket o LiteSpeed Cache ?

Dipende dal server. Se il tuo host gira su LiteSpeed o OpenLiteSpeed, LiteSpeed Cache è gratis e più veloce perché lavora dentro il web server. Su qualsiasi altro host (Nginx, Apache) WP Rocket è la scelta più sicura e comoda, anche perché esclude WooCommerce da solo.

Serve davvero Redis su WooCommerce ?

Su uno shop piccolo puoi anche farne a meno, ma appena cresci — tanti prodotti, filtri, utenti loggati, parecchi ordini al mese — l’object cache Redis fa una differenza netta sui tempi di risposta. Va attivata lato server e collegata con un plugin come Redis Object Cache.

Cloudflare basta come cache per WooCommerce ?

No, Cloudflare da solo non basta: di default serve i file statici dall’edge ma non mette in cache l’HTML di WordPress. Ti serve comunque una page cache (plugin o server) e le regole di bypass per carrello, checkout e account. Cloudflare è un ottimo complemento, non un sostituto.

Se hai uno shop lento e non hai voglia di litigare con esclusioni, cookie e VCL, posso configurarti la cache come si deve: page cache, Redis e test end-to-end, senza rompere il checkout.