Caching avanzata WordPress: livelli, configurazione e quando il caching sbagliato rompe il checkout

Il caching è la prima risposta a qualsiasi problema di lentezza WordPress, ma è anche la prima causa di comportamenti strani quando è configurato male. Il problema è che quasi tutti parlano di "la cache" come fosse una cosa sola. Non lo è. Su un sito WordPress serio ci sono almeno tre livelli di cache che lavorano in cascade, e ognuno ha un lavoro diverso.

Capire quale livello sta facendo cosa è quello che separa un sito veloce da un sito veloce ma rotto. Lo vediamo spesso: un cliente si lamenta che il checkout non aggiorna i prezzi dopo uno sconto, o che il carrello mostra prodotti vecchi. Nove volte su dieci è la page cache che sta servendo una versione HTML statica di una pagina che dovrebbe essere dinamica.

I tre livelli: page cache, object cache, CDN cache

La page cache è la più conosciuta: salva l'HTML completo di una pagina già renderizzata e lo serve senza far girare PHP o interrogare il database. È il livello che dà il salto di velocità più visibile, perché elimina quasi tutto il lavoro del server. Plugin come WP Rocket o la cache integrata del hosting gestito fanno questo.

L'object cache è un livello sotto: salva i risultati delle singole query al database (oggetti, opzioni, post) in memoria veloce, tipicamente Redis o Memcached. Non sostituisce la page cache, la completa. Quando la page cache non può servire una pagina (perché è dinamica, o perché l'utente è loggato), l'object cache riduce il costo delle query che WordPress deve comunque fare.

La CDN cache è il livello più esterno: copia asset statici (CSS, JS, immagini) su server distribuiti geograficamente, più vicini all'utente. Cloudflare, o la CDN del tuo hosting, fanno questo. Riduce il TTFB per gli utenti lontani dal server originario e alleggerisce il carico sull'origine.

La regola che quasi tutti sbagliano: non cachare il checkout

Qui è dove vediamo i disastri più costosi. La page cache è fantastica per le pagine statiche — articoli, landing, pagine vetrina. Ma su un e-commerce WooCommerce, alcune pagine devono essere sempre dinamiche: il carrello, il checkout, l'area account, le pagine con prezzi personalizzati per ruolo utente. Cachare queste pagine significa servire a un cliente il carrello di un altro utente, o un prezzo sbagliato, o un ordine che non si finalizza mai.

La regola operativa è semplice: escludi sempre dalla page cache le pagine dinamiche. Su un hosting gestito con cache a livello server (come facciamo noi), queste esclusioni sono configurate di default. Se usi un plugin di cache, devi impostarle manualmente. Ecco le esclusioni minime per WooCommerce:

// Esclusioni page cache per WooCommerce (functions.php o MU plugin)
add_filter( 'rocket_cache_reject_uri', function( $uri ) {
    $uri[] = '/carrello/';
    $uri[] = '/checkout/';
    $uri[] = '/checkout/(.*)';
    $uri[] = '/il-mio-account/';
    $uri[] = '/il-mio-account/(.*)';
    return $uri;
});

// Non cachare mai le risposte AJAX di WooCommerce
add_filter( 'rocket_cache_reject_ajax', function( $reject ) {
    $reject[] = 'wc-ajax';
    return $reject;
});

Quando l'object cache (Redis) fa davvero la differenza

L'object cache non è per tutti. Su un blog con 500 visite al giorno, la page cache risolve già il 90% dei problemi di velocità e Redis è sovrainvestimento. Ma su un WooCommerce con migliaia di prodotti, o un sito editoriale con query complesse, l'object cache cambia le carte. Riduce il tempo di ogni query non cachabile dal database, che è il collo di bottiglia tipico di WordPress quando il traffico sale.

Il punto è che l'object cache va configurata, non solo attivata. Un plugin di object cache mal scritto può serializzare oggetti grandi e peggiorare le prestazioni. La configurazione corretta su Redis:

// wp-config.php — abilita Redis come object cache
define( 'WP_REDIS_HOST', '127.0.0.1' );
define( 'WP_REDIS_PORT', 6379 );
define( 'WP_REDIS_DATABASE', 0 );

// TTL predefinito degli oggetti in cache (secondi)
define( 'WP_REDIS_MAXTTL', 3600 );

// Non cachare in modalità debug (evita risultati stale in sviluppo)
define( 'WP_REDIS_DISABLE_BANNERS', true );

I segnali che la cache è configurata male

Tre sintomi ricorrenti. Primo: i prezzi o gli sconti non si aggiornano nel carrello — la page cache sta servendo HTML vecchio del checkout. Secondo: l'admin è lentissimo ma il frontend vola — la page cache nasconde il problema ma il backend, non cachato, rivela query pesanti o plugin gonfi. Terzo: dopo un aggiornamento il sito mostra contenuti vecchi per ore — la CDN o la page cache non si svuotano correttamente al salvataggio.

Il caching è una leva potente, ma è una leva che va calibrata. Troppa cache su pagine dinamiche rompe il business; troppo poca su pagine statiche lascia performance sul tavolo. La configurazione corretta non è un'opzione del plugin: è una decisione architetturale che dipende dal tipo di sito.