¿Qué es la caché de objetos (object cache)? Redis y Memcached para WordPress explicados

Una caché de objetos (o object cache, como la verás en muchos plugins y tutoriales) guarda en memoria los resultados de las consultas a la base de datos, para que WordPress no tenga que ir a buscarlos ahí la próxima vez. Dicho así, no suena a gran cosa. Pero en tiendas, webs de membresía y cualquier sitio con muchos usuarios que navegan con la sesión iniciada, suele ser lo que más se nota en el tiempo de carga. WordPress trae su propia caché de objetos, aunque esa lo olvida todo en cuanto termina cada carga de página. Solo con Redis o Memcached detrás se convierte en una caché de objetos persistente, capaz de conservar los datos de una petición a otra. En este artículo verás cómo funciona exactamente, en qué se diferencian Redis y Memcached, cuándo compensa el esfuerzo y qué errores conviene evitar al configurarla.

¿Qué es la caché de objetos en WordPress?

Cada vez que alguien abre una página de tu web, WordPress la monta a partir de un montón de piezas sueltas. Carga los ajustes del sitio, los menús, los widgets, la propia entrada, los datos del autor, las categorías, las etiquetas y todo lo que tus plugins necesiten encima. Casi todo eso vive en la base de datos (MySQL o MariaDB). En una página normal se juntan fácilmente entre 50 y 150 consultas, y con WooCommerce y unos cuantos plugins grandes, bastantes más. Muchas de ellas preguntan exactamente lo mismo en cada visita: ¿cómo se llama el sitio? ¿Qué plugins están activos? ¿Qué aspecto tiene el menú principal?

La caché de objetos recuerda las respuestas a preguntas como esas. WordPress mira primero en la caché, y solo si ahí no hay nada la consulta llega a la base de datos. Después, el resultado se guarda en la caché y la próxima vez está disponible al instante. El nombre viene de que WordPress no guarda ahí páginas terminadas, sino objetos de datos sueltos: una entrada, una lista de opciones, los metadatos de un usuario.

Piensa en un pósit pegado junto al teclado. En lugar de rebuscar cada vez en el archivador, primero echas un vistazo al pósit. Para una pregunta suelta apenas ganas tiempo. Pero si la misma pregunta se repite mil veces al día, ganas muchísimo.

¿Cómo funciona la caché de objetos de WordPress?

WordPress tiene desde hace muchos años su propia clase para la caché de objetos, WP_Object_Cache. El núcleo de WordPress y muchos plugins se comunican con ella mediante funciones como wp_cache_get() y wp_cache_set(). La pega: sin software adicional, esta caché solo dura lo que dura una carga de página. En cuanto la página se ha entregado, la memoria vuelve a quedar vacía y con el siguiente visitante todo empieza de cero.

Aun así, esta caché no persistente no es inútil, porque evita consultas duplicadas dentro de una misma petición. Lo interesante de verdad llega con una caché de objetos persistente. Para eso hay un archivo llamado object-cache.php en la carpeta wp-content. WordPress lo detecta automáticamente al arrancar y, en lugar de su almacenamiento temporal, usa un servicio externo como Redis o Memcached. Los datos se quedan ahí durante muchas cargas de página, hasta que caducan, cambian o la memoria se llena. No tienes que escribir este archivo tú. Plugins como Redis Object Cache lo traen incluido y lo colocan donde corresponde al activarlos.

Hay un efecto secundario que mucha gente desconoce y que afecta a los llamados transients. Son valores cacheados con fecha de caducidad que los plugins usan a menudo, por ejemplo para guardar respuestas de API externas. Sin una caché de objetos persistente, los transients acaban en la tabla wp_options y la van hinchando con el tiempo. Con Redis o Memcached pasan a la memoria y la base de datos se mantiene más ligera.

Caché de objetos, caché de página y OPcache: ¿en qué se diferencian?

En cuanto se habla de WordPress y caché, salen enseguida tres términos que es fácil confundir. Trabajan en niveles distintos y se complementan, no se sustituyen entre sí.

• Caché de página: guarda la página completa ya terminada como HTML y la sirve sin llegar a arrancar WordPress. Así funcionan, por ejemplo, WP Rocket, LiteSpeed Cache o WP Super Cache. No hay nada más rápido, pero solo mientras todos los visitantes vean la misma página.
• Caché de objetos: guarda resultados sueltos de la base de datos. WordPress sigue ejecutándose en cada petición, pero tiene que preguntar a la base de datos muchas menos veces.
• OPcache: no tiene nada que ver con tus datos. Se encarga de que PHP no tenga que leer y compilar de nuevo los archivos de WordPress en cada petición. Hoy viene activado en casi cualquier alojamiento.

Lo más importante: la caché de página solo ayuda con páginas que se ven igual para todo el mundo. En cuanto alguien inicia sesión, añade algo al carrito o trabaja en el panel de administración, la caché de página deja de intervenir. Justo ahí entra en juego la caché de objetos. Para un blog con lectores casi siempre anónimos, una buena caché de página aporta más. En una tienda, una plataforma de cursos o un foro, la caché de objetos suele ser la palanca más grande.

Redis vs. Memcached: ¿qué caché de objetos elegir para WordPress?

Los dos sistemas guardan los datos en memoria y los almacenan como pares sencillos de clave y valor. Como caché de objetos, ambos son lo bastante rápidos. Las diferencias están en los detalles.

Redis es hoy la opción habitual para WordPress. Puede guardar más que claves y valores, por ejemplo listas, hashes y sets, y si quieres escribe su contenido en disco para que la caché sobreviva a un reinicio. A eso se suman la replicación, un control de acceso más fino y un ecosistema enorme. Para WordPress existe además Redis Object Cache, un plugin muy extendido y bien mantenido. Tras un cambio de licencia de Redis en 2024 nació también Valkey, un fork libre bajo el paraguas de la Linux Foundation que ya usan muchos proveedores de alojamiento. Para WordPress se comporta exactamente igual que Redis y, por lo general, no notarás ninguna diferencia.

Memcached es más antiguo y sencillo a propósito. Solo conoce claves y valores, no guarda nada de forma permanente y pierde todo su contenido en cada reinicio. A cambio, aprovecha varios núcleos de CPU a la vez y es muy fácil de repartir entre varios servidores. Hay un límite que de vez en cuando asoma con WordPress: por defecto, una sola entrada puede ocupar como máximo 1 MB. Con opciones muy grandes, como los ajustes inflados de algunos maquetadores, eso puede dar problemas.

Nuestra recomendación: si tu proveedor de alojamiento ofrece los dos, quédate con Redis. Si solo tienes Memcached, no hay motivo para preocuparse, porque como caché de objetos cumple de sobra. Mucho más importante que elegir entre uno u otro es que haya una caché de objetos persistente funcionando y que esté bien configurada. Por cierto, existe un tercer candidato: APCu, una caché integrada directamente en PHP. No necesita un servicio aparte, pero solo funciona en un único servidor y en la práctica tiene un papel menor.

¿Cuándo merece la pena una caché de objetos persistente?

La caché de objetos no hace milagros. Lo que aporta depende de cuántas peticiones se saltan la caché de página y llegan directamente a WordPress, y de cuánto trabajo le dan a la base de datos. El efecto se nota sobre todo en:

• Tiendas con WooCommerce, porque el carrito, la página de pago y la cuenta del cliente nunca salen de la caché de página.
• Webs de membresía, plataformas de cursos y foros en los que muchos usuarios navegan con la sesión iniciada.
• Redacciones en las que varias personas trabajan a la vez en el panel de administración.
• Webs con muchos plugins que guardan sus datos en opciones y transients.
• Sitios grandes con miles de entradas, términos o usuarios.

El propio WordPress te da una pista. Desde la versión 6.1, la pantalla Salud del sitio, dentro de Herramientas, recomienda una caché de objetos persistente cuando tu web supera ciertos tamaños, por ejemplo más de 1.000 entradas, comentarios o usuarios.

En cambio, una caché de objetos aporta poco en la web pequeña de una empresa, con diez páginas, visitantes casi siempre anónimos y una buena caché de página ya en marcha. Ahí la caché de página responde de todos modos a casi todas las peticiones antes de que WordPress llegue siquiera a arrancar.

¿Cómo configurar la caché de objetos con Redis en WordPress?

El camino exacto depende de tu alojamiento. Muchos proveedores de alojamiento gestionado ya tienen Redis disponible y te dejan activarlo con un interruptor en su panel de cliente, y algunos incluso lo configuran todo por ti. Ante la duda, pregunta un momento al soporte antes de instalar nada por tu cuenta. En un servidor propio, normalmente se hace así:

1. Instala y arranca Redis, en Debian o Ubuntu por ejemplo con el paquete redis-server.
2. Instala la extensión phpredis para PHP (paquete php-redis) para que PHP pueda hablar con Redis. El plugin incluye también Predis, una variante que no necesita ninguna extensión, pero es bastante más lenta.
3. Añade los datos de conexión en wp-config.php, por encima de la línea que te indica que dejes de editar.
4. Instala el plugin Redis Object Cache y activa la caché de objetos en sus ajustes. Al hacerlo, el plugin crea el archivo 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 );

Configura siempre el prefijo cuando varias webs compartan la misma instancia de Redis. Sin él, dos instalaciones pueden pisarse los datos entre sí, y eso provoca errores muy raros. Si prefieres la línea de comandos, el último paso se hace con wp plugin install redis-cache --activate y después wp redis enable. Para tiendas grandes existe además la solución de pago Object Cache Pro.

¿Cuáles son los errores más comunes con la caché de objetos?

La caché de objetos se configura rápido, pero hay unos cuantos tropiezos que se repiten una y otra vez.

• Sin límite de memoria: sin maxmemory, Redis crece hasta que el servidor se queda sin memoria. Con límite, pero con la política por defecto noeviction, Redis rechaza las entradas nuevas en cuanto la memoria está llena, y WordPress empieza a dar errores de repente. Para una caché, lo correcto es allkeys-lru: así Redis simplemente descarta las entradas que llevan más tiempo sin usarse.
• Redis abierto a internet: Redis solo debería ser accesible en 127.0.0.1 o en una red privada, y debería tener contraseña. Hay quien rastrea la red buscando instancias abiertas en el puerto 6379 para abusar de ellas.
• Datos desactualizados tras cambios directos: si cambias datos directamente en la base de datos, por ejemplo con phpMyAdmin o durante una importación, te saltas la caché. WordPress sigue mostrando entonces los valores antiguos. Vacía la caché después, desde los ajustes del plugin o con wp cache flush.
• Un object-cache.php olvidado tras una migración: si migras a un servidor sin Redis, a veces el archivo se queda en la carpeta wp-content. En el mejor de los casos solo ves un aviso en el área de administración; en el peor, WordPress se detiene con un error fatal. Entonces basta con borrar el archivo por FTP.
• Redis en un servidor remoto: cada acceso a la caché cuesta entonces un viaje por la red. Con cientos de accesos por carga de página, la latencia se come parte de la ventaja. Lo ideal es tener Redis en el mismo servidor o, como mínimo, en el mismo centro de datos.

maxmemory 256mb
maxmemory-policy allkeys-lru

Estas dos líneas en redis.conf bastan para la mayoría de webs. Cuánta memoria necesitas depende del tamaño del sitio. Para una tienda normal, 256 MB es un buen punto de partida.

¿Cómo comprobar si la caché de objetos funciona?

Hay varias formas de ver si la caché está haciendo su trabajo de verdad:

• En el plugin: Redis Object Cache muestra en sus ajustes si hay conexión y ofrece una pequeña estadística de aciertos y fallos.
• En la línea de comandos: wp cache type te dice qué caché de objetos está activa. Si aparece Default, no hay ninguna caché persistente funcionando.
• Con Query Monitor: este plugin gratuito muestra en cada carga de página la tasa de aciertos de la caché de objetos y el número de consultas a la base de datos. Compara los valores una vez con caché y otra sin ella: la diferencia suele ser mayor de lo que esperas.
• Directamente en Redis: redis-cli info stats devuelve, entre otras cosas, keyspace_hits y keyspace_misses. Si la tasa de aciertos sigue baja después de unas horas en marcha, casi siempre hay algo mal en la configuración, por ejemplo un límite de memoria demasiado pequeño.

Cómo te ayuda InspectWP a evaluar la caché de tu web

La caché de objetos trabaja en el servidor, así que desde fuera no se ve directamente. Su efecto, en cambio, sí. El informe de InspectWP mide, entre otras cosas, el Time to First Byte, es decir, cuánto tarda el servidor en hacer llegar el primer byte de la página. InspectWP marca como advertencia los valores por encima de 800 milisegundos, y justo ahí ayuda una caché de objetos cuando la página no sale de la caché de página. Además, InspectWP detecta qué plugins se usan para la caché, Redis Object Cache incluido, gracias al breve comentario que el plugin deja por defecto en el código fuente. Junto con los datos del proveedor de alojamiento, el servidor y la versión de PHP, enseguida te haces una idea de si la caché de un sitio todavía tiene margen de mejora.