Cos'è l'object cache? Redis e Memcached per WordPress spiegati

L'object cache conserva in memoria i risultati delle query al database, così alla richiesta successiva WordPress non deve andarli a ripescare dal database. Detto così sembra poca cosa. Su negozi online, siti di membership e in generale ovunque ci siano molti utenti loggati, però, è spesso ciò che incide di più sul tempo di caricamento. WordPress include già una propria cache degli oggetti, che però dimentica tutto a ogni caricamento di pagina. Solo con Redis o Memcached alle spalle si ottiene l'object cache persistente, che conserva i dati da una richiesta all'altra. In questo articolo scopri nel dettaglio come funziona, in cosa si differenziano Redis e Memcached, quando ne vale la pena e quali errori evitare durante la configurazione.

Cos'è l'object cache in WordPress?

Ogni volta che qualcuno apre una pagina del tuo sito, WordPress la mette insieme a partire da tanti piccoli pezzi. Carica le impostazioni del sito, i menu, i widget, l'articolo vero e proprio, i dati dell'autore, le categorie, i tag e tutto quello che serve in più ai tuoi plugin. Quasi tutto questo sta nel database (MySQL o MariaDB). Una pagina normale richiede facilmente dalle 50 alle 150 query al database, e con WooCommerce e qualche plugin più corposo anche molte di più. Tante di queste chiedono a ogni richiesta esattamente la stessa cosa: come si chiama il sito? Quali plugin sono attivi? Com'è fatto il menu principale?

L'object cache si ricorda le risposte a domande come queste. WordPress controlla prima nella cache, e solo se lì non trova nulla la richiesta arriva al database. Il risultato finisce poi nella cache ed è subito pronto la volta successiva. Il nome deriva dal fatto che WordPress lì non salva pagine finite, ma singoli oggetti di dati: un articolo, un elenco di opzioni, i metadati di un utente.

Immagina un foglietto attaccato accanto alla tastiera. Invece di frugare ogni volta nello schedario, dai prima un'occhiata al foglietto. Per una domanda sola il risparmio è quasi nullo. Se però la stessa domanda arriva mille volte al giorno, il tempo guadagnato diventa parecchio.

Come funziona l'object cache di WordPress?

Da molti anni WordPress ha una classe dedicata all'object cache, WP_Object_Cache. Il core di WordPress e molti plugin la usano tramite funzioni come wp_cache_get() e wp_cache_set(). Il problema è che senza software aggiuntivo questa cache vive solo per la durata di un singolo caricamento di pagina. Appena la pagina è stata consegnata, la memoria si svuota, e con il visitatore successivo si riparte da zero.

Anche così questa cache temporanea ha la sua utilità, perché evita query doppie all'interno della stessa richiesta. Le cose si fanno davvero interessanti, però, solo con l'object cache persistente. Per averla serve un file chiamato object-cache.php nella cartella wp-content. WordPress lo riconosce in automatico all'avvio e, al posto della propria memoria temporanea, usa un servizio esterno come Redis o Memcached. Lì i dati restano disponibili per molti caricamenti di pagina, finché non scadono, cambiano o la memoria si riempie. Questo file non devi scriverlo tu. Plugin come Redis Object Cache lo includono e lo mettono al posto giusto quando li attivi.

Un effetto collaterale che in pochi conoscono riguarda i transient. Sono valori memorizzati temporaneamente con una data di scadenza, che i plugin usano volentieri, per esempio per le risposte di API esterne. Senza una cache degli oggetti persistente i transient finiscono nella tabella wp_options e col tempo la gonfiano. Con Redis o Memcached si spostano invece in memoria, e il database resta più snello.

Object cache, cache delle pagine e OPcache: qual è la differenza?

Appena si parla di WordPress e caching saltano fuori tre termini che si confondono facilmente. Lavorano su livelli diversi e si completano a vicenda, invece di sostituirsi.

• Cache delle pagine (page cache): salva la pagina completa e già pronta come HTML e la consegna senza nemmeno avviare WordPress. Funzionano così, per esempio, WP Rocket, LiteSpeed Cache e WP Super Cache. Più veloce di così non si può, ma solo finché tutti i visitatori vedono la stessa pagina.
• Object cache: salva singoli risultati provenienti dal database. WordPress continua a girare a ogni richiesta, ma deve interrogare il database molto meno spesso.
• OPcache: non ha niente a che fare con i tuoi dati. Fa sì che PHP non debba rileggere e compilare i file di WordPress a ogni richiesta. Su quasi tutti gli hosting oggi è già attiva.

Il punto più importante: la cache delle pagine aiuta solo con le pagine che sono uguali per tutti. Appena qualcuno è loggato, mette qualcosa nel carrello o lavora nel backend, viene scavalcata. È proprio lì che entra in gioco l'object cache. Per un blog con lettori quasi solo anonimi, quindi, una buona cache delle pagine rende di più. Per un negozio online, una piattaforma di corsi online o un forum, l'object cache è spesso la leva più grande.

Redis vs. Memcached: quale object cache scegliere per WordPress?

Entrambi i sistemi tengono i dati in memoria e li salvano come semplici coppie di chiave e valore. Come object cache sono veloci abbastanza tutti e due. Le differenze stanno nei dettagli.

Redis oggi è la scelta abituale per WordPress. Non si ferma a chiavi e valori, ma sa salvare anche liste, hash e set, e se vuoi scrive i suoi contenuti su disco, così la cache sopravvive a un riavvio. A questo si aggiungono la replica, un controllo degli accessi più granulare e un grande ecosistema. Per WordPress c'è poi Redis Object Cache, un plugin molto diffuso e curato bene. Dopo che Redis ha cambiato licenza nel 2024 è nato anche Valkey, un fork libero sotto l'ombrello della Linux Foundation, che ormai usano molti provider di hosting. Per WordPress si comporta esattamente come Redis, e di norma non noterai nessuna differenza.

Memcached è più vecchio e volutamente essenziale. Conosce solo chiavi e valori, non salva nulla in modo permanente e a ogni riavvio perde tutto il suo contenuto. In compenso sfrutta più core della CPU contemporaneamente ed è molto facile da distribuire su più server. Un limite che con WordPress ogni tanto si fa notare: per impostazione predefinita una singola voce può pesare al massimo 1 MB. Con opzioni molto grandi, come le impostazioni gonfiate di certi page builder, questo può creare problemi.

Il nostro consiglio: se il tuo hosting offre entrambi, scegli Redis. Se è disponibile solo Memcached, non c'è da preoccuparsi, come object cache basta e avanza. Molto più importante della scelta tra i due è che una cache persistente sia davvero attiva e configurata con criterio. Un terzo candidato, tra l'altro, è APCu, una cache integrata direttamente in PHP. Non richiede un servizio separato, ma funziona solo su un singolo server e nella pratica ha un ruolo minore.

Quando conviene una cache degli oggetti persistente?

L'object cache non fa miracoli. Quanto aiuta dipende da quante richieste scavalcano la cache delle pagine e arrivano direttamente a WordPress, e da quanto lavoro deve fare il database per gestirle. L'effetto si sente soprattutto con:

• Negozi WooCommerce, perché carrello, checkout e account cliente non arrivano mai dalla cache delle pagine.
• Siti di membership, piattaforme di corsi online e forum con molti utenti loggati.
• Redazioni in cui più persone lavorano contemporaneamente nel backend.
• Siti con molti plugin che salvano i propri dati in opzioni e transient.
• Siti grandi con migliaia di articoli, termini o utenti.

Lo stesso WordPress ti dà un indizio. Dalla versione 6.1 la schermata Salute del sito, sotto Strumenti, consiglia una cache degli oggetti persistente quando il sito supera certe dimensioni, per esempio più di 1.000 articoli, commenti o utenti.

Al contrario, l'object cache serve a poco per il piccolo sito aziendale di dieci pagine che ha visitatori quasi solo anonimi e usa già una buona cache delle pagine. Lì è comunque la cache delle pagine a rispondere a quasi ogni richiesta, prima ancora che WordPress parta.

Come configurare l'object cache con Redis in WordPress?

La strada esatta dipende dal tuo hosting. Molti hosting gestiti hanno già Redis a disposizione e ti permettono di attivarlo con un interruttore nel pannello cliente, alcuni configurano persino tutto al posto tuo. Nel dubbio, chiedi un attimo al supporto prima di installare qualcosa da solo. Su un server tuo, di solito si procede così:

1. Installa e avvia Redis, su Debian o Ubuntu per esempio con il pacchetto redis-server.
2. Installa l'estensione phpredis per PHP (pacchetto php-redis), così PHP può comunicare con Redis. Il plugin include anche Predis, una variante che non richiede nessuna estensione, ma è sensibilmente più lenta.
3. Aggiungi i dati di connessione nel file wp-config.php, sopra la riga che segna la fine delle modifiche.
4. Installa il plugin Redis Object Cache e attiva l'object cache nelle sue impostazioni. In questo modo viene creato il file object-cache.php.

define( 'WP_REDIS_HOST', '127.0.0.1' );
define( 'WP_REDIS_PORT', 6379 );
define( 'WP_REDIS_DATABASE', 0 );
define( 'WP_REDIS_PREFIX', 'mysite_' );
define( 'WP_REDIS_MAXTTL', 86400 );

Imposta sempre il prefisso quando più siti condividono la stessa istanza di Redis. Senza, due installazioni possono sovrascriversi i dati a vicenda, e ne nascono errori molto strani. Se preferisci la riga di comando, l'ultimo passaggio lo fai con wp plugin install redis-cache --activate seguito da wp redis enable. Per i negozi grandi esiste anche la soluzione commerciale Object Cache Pro.

Quali sono gli errori più comuni con l'object cache?

L'object cache si configura in fretta, ma alcune trappole si ripresentano di continuo.

• Nessun limite di memoria: senza maxmemory, Redis cresce finché il server non resta senza memoria. Con un limite ma con la policy predefinita noeviction, Redis rifiuta le nuove voci appena la memoria è piena, e all'improvviso WordPress inizia a dare errori. Per una cache la scelta giusta è allkeys-lru: Redis elimina semplicemente le voci che non vengono usate da più tempo.
• Redis esposto su internet: Redis dovrebbe essere raggiungibile solo su 127.0.0.1 o in una rete privata e avere una password. Le istanze aperte sulla porta 6379 vengono cercate attivamente e sfruttate.
• Dati vecchi dopo modifiche dirette: chi modifica i dati direttamente nel database, per esempio con phpMyAdmin o durante un'importazione, aggira la cache. WordPress continua così a mostrare i valori vecchi. Svuota la cache subito dopo, dalle impostazioni del plugin oppure con wp cache flush.
• Un object-cache.php dimenticato dopo un trasloco: se ti sposti su un server senza Redis, a volte il file resta nella cartella wp-content. Nel caso innocuo vedi solo un avviso nell'area di amministrazione, nel caso peggiore WordPress si blocca con un errore fatale. A quel punto basta cancellare il file via FTP.
• Redis su un server remoto: ogni accesso alla cache costa allora un viaggio attraverso la rete. Con centinaia di accessi per caricamento di pagina, la latenza si mangia una parte del vantaggio. L'ideale è tenere Redis sullo stesso server, o almeno nello stesso data center.

maxmemory 256mb
maxmemory-policy allkeys-lru

Queste due righe in redis.conf bastano per la maggior parte dei siti. Quanta memoria ti serve dipende dalle dimensioni del sito. Per un negozio tipico, 256 MB sono un buon punto di partenza.

Come verificare se l'object cache funziona?

Per capire se la cache sta davvero facendo il suo lavoro hai diverse strade:

• Nel plugin: Redis Object Cache mostra nelle sue impostazioni se la connessione è attiva e fornisce una piccola statistica di hit e miss.
• Dalla riga di comando: wp cache type ti dice quale object cache è attiva. Se compare Default, non c'è nessuna cache persistente in funzione.
• Con Query Monitor: il plugin gratuito mostra per ogni caricamento di pagina la percentuale di hit dell'object cache e il numero di query al database. Prova una volta a confrontare i valori con e senza cache, la differenza è spesso più grande di quanto pensi.
• Direttamente in Redis: redis-cli info stats restituisce tra le altre cose keyspace_hits e keyspace_misses. Se la percentuale di hit resta bassa anche dopo qualche ora di funzionamento, di solito c'è qualcosa che non va nella configurazione, per esempio un limite di memoria troppo piccolo.

Come InspectWP ti aiuta a valutare il caching del tuo sito

L'object cache lavora sul server, quindi dall'esterno non la vedi direttamente. I suoi effetti sì. Il report di InspectWP misura tra le altre cose il Time to First Byte, cioè quanto tempo impiega il server prima che arrivi il primo byte della pagina. InspectWP segnala come avviso i valori oltre gli 800 millisecondi, ed è proprio lì che l'object cache aiuta quando la pagina non arriva dalla cache delle pagine. InspectWP riconosce anche quali plugin vengono usati per il caching, compreso Redis Object Cache, grazie al breve commento che il plugin lascia di default nel codice sorgente. Insieme alle informazioni su provider di hosting, server e versione di PHP, ti fai così in fretta un'idea di quanto margine di miglioramento ci sia ancora nel caching di un sito.