Un Object Cache de Redis compensa en las peticiones que un Page Cache no puede responder, sobre todo las de usuarios con sesión iniciada, carritos y el área de administración. Guarda en memoria los resultados de las consultas de WordPress a la base de datos, de modo que las peticiones posteriores se ahorran esas consultas. Un sitio pequeño cuyas páginas salen todas de un Page Cache gana poco.
¿Qué hace un Object Cache en WordPress?
WordPress incorpora un Object Cache que, por defecto, dura una sola petición. Las opciones, las entradas, los términos y los resultados de muchas consultas de plugins se cargan en la memoria de PHP y se descartan cuando la página termina.
Un drop-in en wp-content/object-cache.php sustituye esta caché y guarda los mismos datos en un servidor como Redis. Así, cada petición puede reutilizar lo que cargaron las anteriores, y la base de datos responde a menos consultas.
Un Page Cache actúa un nivel más arriba: guarda el HTML ya generado y responde con poco PHP o sin él. Un Object Cache deja que WordPress construya la página, pero con menos viajes a la base de datos. Un sitio puede usar ambos.
¿Cuándo compensa?
| Petición o sitio | Efecto | Motivo |
|---|---|---|
| Petición o sitio: Páginas de carrito, pago y cuenta | Efecto: Compensa | Motivo: No pueden salir de un Page Cache y leen datos de productos, sesión y usuario en cada petición |
| Petición o sitio: Usuarios con sesión iniciada y administración | Efecto: Compensa | Motivo: Editores, gestores de tienda y miembros no obtienen aciertos del Page Cache |
| Petición o sitio: Tiendas y sitios multiidioma | Efecto: Compensa | Motivo: WooCommerce, WPML y WCML repiten consultas de productos, términos, traducciones y monedas |
| Petición o sitio: Páginas con muchas consultas | Efecto: Compensa | Motivo: Menús grandes, filtros, entradas relacionadas y maquetadores ejecutan consultas que la caché puede responder |
| Petición o sitio: Sitio pequeño con visitantes anónimos | Efecto: Efecto escaso | Motivo: El Page Cache responde a casi todas las peticiones |
| Petición o sitio: Búsqueda de texto libre | Efecto: Efecto escaso | Motivo: Cada término de búsqueda es una consulta nueva, así que se reutiliza poco |
WordPress ofrece además una señal propia. Desde la versión 6.1, Site Health sugiere un Object Cache persistente cuando un sitio supera ciertos umbrales, por ejemplo 1.000 entradas, términos, usuarios, comentarios u opciones, o 500 opciones de carga automática.
¿Qué necesito?
- Un servidor Redis en el mismo host, o accesible a través de una red interna o de TLS.
- Un cliente de PHP. phpredis es una extensión compilada y Predis una biblioteca de PHP. Los plugins difieren en cuáles aceptan.
- Un plugin que instale el drop-in.
- Un límite de memoria en Redis y una política de expulsión (véase más abajo).
Tres comandos muestran lo que un servidor ya tiene. wp cache type imprime Default mientras no haya ninguna caché persistente activa.
php -m | grep -i redis
redis-cli ping
wp cache type¿Qué problemas debo conocer?
Una base de datos de Redis compartida
Algunos proveedores dan a varios sitios la misma base de datos de Redis. Sin un prefijo de claves, dos sitios WordPress se sobrescriben las opciones. Asigne a cada sitio su propio prefijo en wp-config.php; el nombre de la constante depende del plugin. La documentación de Redis desaconseja las bases de datos numeradas para aplicaciones no relacionadas.
Vaciados
WordPress y muchos plugins vacían el Object Cache tras actualizaciones e importaciones. FLUSHDB vacía toda la base de datos, incluidos los datos de todos los demás que la usan. En una base de datos compartida, un vaciado debe borrar solo sus propias claves, lo que tarda más. Una base de datos propia evita el problema.
Límite de memoria y expulsión
Por defecto, Redis en un sistema de 64 bits no tiene límite de memoria. Si se fija un límite, maxmemory-policy decide qué ocurre al alcanzarlo. Con allkeys-lru, Redis elimina las claves menos usadas recientemente y la caché sigue funcionando. Con noeviction, el valor por defecto de Redis, las lecturas continúan y las escrituras nuevas fallan.
redis-cli CONFIG GET maxmemory
redis-cli CONFIG GET maxmemory-policyCaídas
Si Redis se queda colgado, un drop-in que espera el tiempo de espera en cada llamada a la caché hace que una página con cientos de llamadas sea mucho más lenta que un sitio sin caché. Compruebe que su plugin deja de usar Redis tras la primera llamada fallida.
Redis también puede volver con valores que cambiaron en la base de datos durante la caída. La caché necesita entonces un vaciado.
¿Cómo sé que funciona?
Redis cuenta los aciertos y los fallos. La tasa de aciertos es keyspace_hits dividido entre la suma de keyspace_hits y keyspace_misses. Un valor creciente de evicted_keys indica que el límite de memoria es demasiado bajo para el sitio.
redis-cli INFO stats | grep -E "keyspace_|evicted_keys"Una tasa de aciertos alta por sí sola demuestra poco. Mida las consultas a la base de datos y el tiempo hasta el primer byte de una página sin caché, con y sin la caché. Query Monitor muestra las consultas por petición.
¿Cómo los gestiona CachePilot?
CachePilot es el plugin del que trata este sitio. Sus respuestas a los problemas anteriores:
- Bases de datos compartidas. Las claves llevan un prefijo. Si la configuración encuentra claves de otra aplicación, los vaciados se limitan a ese prefijo.
- Caídas. Tras un error de conexión, el drop-in omite Redis durante 30 segundos y vacía la caché una vez cuando Redis vuelve.
- Viajes de ida y vuelta. SMEMBERS lee la lista de claves que usa una página y MGET carga sus valores. En una tienda en producción, en noviembre de 2026, esto redujo los comandos de Redis de una página de tienda sin caché de 691 a 61. El tiempo de servidor en el front end fue entre un 10 y un 15 % menor que con Redis Object Cache 3.0.0 (método).
La página del Object Cache describe el drop-in en detalle.
Fuentes
- Referencia para desarrolladores de WordPress, WP_Object_Cache: no persistente por defecto, sustitución mediante un drop-in.
- Referencia para desarrolladores de WordPress, comprobación de Site Health para un Object Cache: umbrales de Site Health.
- WP-CLI, wp cache type.
- Documentación de Redis, expulsión de claves: maxmemory, políticas, tasa de aciertos a partir de INFO stats.
- Documentación de Redis, SELECT: bases de datos numeradas.
- phpredis y Predis.
- object-cache.php y Setup.php (src/Autopilot) del plugin: gestión de caídas, prefetch y detección de bases de datos compartidas.
