Caching e pagine dinamiche: perché il carrello WooCommerce non si può (e non si deve) cachare
La page cache accelera il 90% del sito ma le pagine dinamiche — carrello, checkout, account — devono restare non cachate. Come configurare le esclusioni senza lasciare buchi che rallentano tutto il resto.
La page cache è la prima cosa che attivi su un sito WordPress lento, e nella maggior parte dei casi risolve metà del problema in un colpo solo. Le pagine statiche — home, articoli, pagine — vengono servite dal cache senza toccare PHP né database, e il TTFB passa da 1.200ms a 80ms. Poi apri il carrello e scopri che si svuota da solo, o che il cliente vede il carrello di un altro utente. La cache sta facendo esattamente quello che le hai detto di fare, solo sulla pagina sbagliata.
Il principio è semplice: si cachano le pagine uguali per tutti, non si cachano quelle che cambiano per utente. Carrello, checkout, account, ordini, wishlist sono pagine dinamiche per definizione — il loro contenuto dipende dall'utente che le visita. Cacharle significa servire a un cliente il carrello del precedente visitatore. Non è un'ottimizzazione, è un bug di sicurezza.
Le pagine che non si cachano mai
L'elenco delle pagine da escludere dalla page cache è quasi standard su ogni installazione WooCommerce seria. Lo ricordiamo perché l'ho visto dimenticare su siti in produzione più volte di quanto mi piacerebbe ammettere:
// Esclusioni dalla page cache per WooCommerce + WordPress dinamico
// Da aggiungere al plugin di caching o nel functions.php del tema child
add_action( 'template_redirect', function() {
if ( function_exists( 'WC' ) ) {
// Pag WooCommerce: carrello, checkout, account, ordini
if ( is_cart() || is_checkout() || is_account_page() || is_order_received_page() ) {
header( 'Cache-Control: no-cache, must-revalidate, max-age=0' );
header( 'Pragma: no-cache' );
return;
}
}
// Pagine utente autenticato
if ( is_user_logged_in() ) {
header( 'Cache-Control: no-cache, must-revalidate, max-age=0' );
return;
}
// WooCommerce e-commerce con coupon
if ( isset( $_COOKIE['woocommerce_recently_viewed'] ) ||
isset( $_COOKIE['woocommerce_items_in_cart'] ) ) {
header( 'Cache-Control: no-cache, must-revalidate, max-age=0' );
return;
}
} );Nginx FastCGI cache: escludere le pagine dinamiche a livello server
Su un hosting gestito con Nginx + PHP-FPM, la page cache è spesso implementata con FastCGI cache a livello di server. In quel caso l'esclusione via header PHP funziona solo se Nginx è configurato per rispettarli, e l'approccio più solido è escludere per location o cookie:
# Nginx FastCGI cache — esclude pagine dinamiche per location
# Nel server block di Nginx:
fastcgi_cache_path /var/cache/nginx levels=1:2 keys_zone=WP:100m inactive=60m;
server {
# ... configurazione base ...
# Non cacheare carrello, checkout, account, my-account
location ~* ^/(carrello|checkout|mio-account|account|my-account|dashboard) {
fastcgi_cache off;
fastcgi_pass php;
fastcgi_cache_bypass $skip_cache 1;
fastcgi_no_cache $skip_cache 1;
add_header X-Cache-Status "DYNAMIC";
}
# Non cacheare se l'utente ha il cookie del carrello o è loggato
set $skip_cache 0;
if ( $http_cookie ~* "wordpress_logged_in_|woocommerce_items_in_cart" ) {
set $skip_cache 1;
}
if ( $arg_add-to-cart ) {
set $skip_cache 1;
}
location ~ \.php$ {
fastcgi_cache WP;
fastcgi_cache_key "$scheme$request_method$host$request_uri$skip_cache";
fastcgi_cache_bypass $skip_cache;
fastcgi_no_cache $skip_cache;
fastcgi_pass php;
# ... resto della configurazione FastCGI ...
}
}L'object cache Redis: la cache che serve sulle pagine dinamiche
La page cache non si usa sulle pagine dinamiche, ma lì il database lavora comunque — ogni accesso al carrello esegue query su prodotti, stock, prezzi, sessioni. È qui che entra l'object cache Redis: non cachea la pagina intera, ma le singole query e gli oggetti PHP che si ripetono. Il risultato è che il carrello risponde in 150ms invece di 400ms, pur restando dinamico e personalizzato per utente.
// wp-config.php — abilita Redis object cache
// (richiede il plugin Redis Object Cache o Drop-in)
define( 'WP_REDIS_HOST', '127.0.0.1' );
define( 'WP_REDIS_PORT', 6379 );
define( 'WP_REDIS_DB', 0 );
// Usato da WP Planet su ogni installazione WooCommerce gestita
define( 'WP_REDIS_PREFIX', 'miosito' );
define( 'WP_REDIS_TIMEOUT', 2 );
define( 'WP_REDIS_READ_TIMEOUT', 2 );Il test che ti dice se la cache è configurata male
Il modo più rapido di capire se la page cache sta servendo il carrello sbagliato è aprire il carrello su due browser diversi o due sessioni in incognito. Se vedi gli stessi prodotti in entrambi, la cache è rotta. Un secondo test è controllare l'header X-Cache-Status della pagina carrello:
# Verifica lo stato della cache sulla pagina carrello
curl -sI https://miosito.com/carrello/ | grep -i 'x-cache\|cache-control'
# Output atteso (cache disattivata):
# X-Cache-Status: DYNAMIC
# Cache-Control: no-cache, must-revalidate, max-age=0
# Verifica che le pagine statiche siano in cache
curl -sI https://miosito.com/ | grep -i 'x-cache\|cache-control'
# Output atteso (cache attiva):
# X-Cache-Status: HIT
# Cache-Control: max-age=86400La cache ben configurata è la differenza tra un WooCommerce veloce e uno che apparentemente funziona ma perde ordini ogni tanto in modo misterioso. Le esclusioni non sono un dettaglio, sono la parte che rende sicuro tutto il resto. Un audit del checkout e della configurazione di cache è il modo più rapido di capire se la tua cache sta facendo il suo lavoro o creando problemi nascosti.
Checkout, pagamenti e cache del tuo e-commerce sotto controllo.
Verifica tecnica del tuo store WooCommerce: configurazione della cache, esclusioni del carrello, object cache e prestazioni del checkout.
Articoli correlati
Gateway di pagamento WooCommerce: Stripe, PayPal e la sicurezza del checkout
Leggi
Gateway di pagamento WooCommerce: scegliere, configurare e non perdere ordini
Leggi