Facciamo chiarezza su una confusione che sento di continuo: la page cache e l’object cache non sono la stessa cosa. La prima salva l’HTML già pronto di una pagina, l’altra tiene in memoria i risultati delle query al database. Su un sito con tanti utenti loggati o su un WooCommerce pieno di prodotti e filtri, è proprio la seconda a fare la differenza sulle pagine che non puoi mettere in page cache. E lo strumento con cui la si fa, nel 99% dei casi, si chiama Redis.
In questa guida vediamo cos’è davvero l’object cache, perché su WordPress conviene usare Redis, come attivarlo e come metterlo a punto senza spararsi nei piedi.
Object cache: cos’è (e cosa non è)
Ogni volta che WordPress genera una pagina fa decine, a volte centinaia di query al database: opzioni, post, meta, utenti, transient. Molte di queste sono identiche a ogni caricamento. L’object cache le tiene in RAM così la seconda volta non tocca il database, risponde dalla memoria. Il risultato tipico è un TTFB più basso e pagine dinamiche — carrello, area utente, ricerche — sensibilmente più reattive.
La differenza con la page cache è netta: la page cache serve l’HTML pronto e salta PHP del tutto, ma non può farlo sulle pagine personalizzate per utente. Lì l’object cache lavora dove la page cache non arriva. Non sono alternative, vanno insieme: ne ho parlato anche nella guida per velocizzare WooCommerce senza rompere il checkout.
Perché Redis
Redis (o in alternativa Memcached) è un archivio chiave-valore in memoria, velocissimo. Su WordPress lo si usa come backend dell’object cache persistente: “persistente” vuol dire che la cache sopravvive tra una richiesta e l’altra, a differenza di quella di default che vive solo per il singolo caricamento. Su uno shop con parecchi ordini al mese, o su un sito con molti utenti loggati, la differenza si sente eccome.
Cosa ti serve
- Redis installato sul server: se hai un VPS lo installi tu, se sei su hosting gestito spesso c’è già (chiedi o attivalo dal pannello). Ho scritto come installare Redis su un server passo passo.
- L’estensione PHP redis (
phpredis), quella che fa parlare PHP con Redis. - Il plugin Redis Object Cache, che collega WordPress a Redis con un drop-in.
Come attivarlo
Prima dico a WordPress dove trovare Redis, nel wp-config.php:
|
1 2 3 4 5 6 7 8 9 10 |
// dico a WordPress a quale Redis collegarsi define( 'WP_REDIS_HOST', '127.0.0.1' ); define( 'WP_REDIS_PORT', 6379 ); // prefisso e database dedicati: così non mescolo la cache di siti diversi define( 'WP_REDIS_PREFIX', 'aa_' ); define( 'WP_REDIS_DATABASE', 0 ); // tetto di durata di sicurezza per le chiavi (in secondi) define( 'WP_REDIS_MAXTTL', 86400 ); |
Poi installo il plugin e abilito l’object cache. Da WP-CLI è un secondo:
|
1 2 3 4 5 6 |
# installo e attivo il plugin, poi accendo l'object cache wp plugin install redis-cache --activate wp redis enable # controllo che stia davvero rispondendo wp redis status |
Se wp redis status risponde “Connected”, ci sei. Da qui in poi WordPress smette di ri-chiedere al database le stesse cose mille volte.
Il tuning che conta davvero
Redis appena installato va già bene, ma due impostazioni lato server evitano guai quando la memoria si riempie. Nel redis.conf:
|
1 2 3 4 5 |
# limito la RAM che Redis può usare (adatta al tuo server) maxmemory 256mb # quando è pieno, butto le chiavi usate meno di recente invece di dare errore maxmemory-policy allkeys-lru |
Il punto chiave è la policy allkeys-lru: senza, Redis pieno inizia a rifiutare scritture e la cache smette di funzionare in silenzio. Con l’LRU invece scarta da solo le chiavi vecchie e continua a girare.
Come verifico che stia lavorando
Non fidarti del “l’ho attivato”: guarda i numeri. Dal backend del plugin, o con wp redis status, controlli l’hit ratio — la percentuale di richieste servite dalla cache. Se dopo un po’ di traffico sta sopra il 90% stai andando bene; se è bassa o piena di miss, qualcosa non gira (spesso un plugin che invalida la cache troppo spesso).
Gli errori che vedo più spesso
- Object cache senza page cache (o viceversa): sono due leve diverse, servono entrambe.
- Redis senza limite di memoria e senza LRU: si riempie e la cache muore zitta zitta.
- Flush a raffica: plugin che svuotano tutta la cache a ogni salvataggio azzerano il vantaggio.
- Nessun prefisso su server condivisi: due siti che scrivono sullo stesso Redis senza prefisso si pestano i piedi.
Domande frequenti
Object cache o page cache: quale mi serve ?
Tutte e due, perché fanno cose diverse. La page cache serve l’HTML pronto delle pagine pubbliche; l’object cache (Redis) velocizza le query del database, soprattutto sulle pagine dinamiche che la page cache non può toccare. Su WooCommerce si usano insieme.
Meglio Redis o Memcached ?
Per WordPress, Redis. Fa le stesse cose di Memcached ma è più ricco, gestisce meglio la persistenza e le policy di eviction, ed è supportato da tutti i plugin di object cache. Memcached resta una scelta valida se il tuo host offre solo quello.
Serve anche su un blog piccolo ?
Su un blog statico con poco traffico il guadagno è modesto: lì la page cache fa quasi tutto. Redis dà il meglio dove ci sono utenti loggati, carrelli, ricerche e cataloghi grossi — cioè su WooCommerce e sui siti dinamici.
Come faccio a sapere se Redis sta davvero lavorando ?
Controlla lo stato con wp redis status o dal pannello del plugin, e guarda l’hit ratio. Connesso e con una buona percentuale di hit significa che la cache sta servendo; se è scollegato o pieno di miss, va indagato.
Se invece parti da uno shop che arranca, tieni d’occhio anche gli altri colli di bottiglia di WooCommerce.
