Object cache con Redis en WooCommerce: qué acelera de verdad (y qué no toca)

Hay un malentendido común sobre la caché en WooCommerce, y cuesta plata: la idea de que "instalé un plugin de caché, la tienda ya está optimizada". Funciona para un blog. Para una tienda mayorista, donde casi todos los que importan están con sesión iniciada, la caché de página —la que esos plugins venden— sirve poco. El cliente B2B no ve la versión cacheada: ve su precio, su lista, su carrito. Cada una de esas vistas pega contra la base de datos. La caché que de verdad acelera una tienda con usuarios logueados no es la de página, es la de objetos. Y casi nadie la tiene encendida.

Dos cachés distintas que se confunden

Vale la pena separar dos cosas que suenan parecidas y resuelven problemas distintos:

• Caché de página (page cache). Guarda el HTML ya armado de una página y lo sirve tal cual al siguiente visitante, sin volver a generarlo. Rapidísima, pero solo aplica a páginas iguales para todos: la home, una entrada de blog, una ficha de producto para un visitante anónimo. En cuanto el usuario inicia sesión, su página es única —su precio, su carrito, su saldo— y la caché de página se salta.
• Caché de objetos (object cache). Guarda los resultados de las consultas a la base de datos —las opciones del sitio, los transients, la metadata, las consultas que WooCommerce repite en cada carga— para no volver a pedírselos a MySQL una y otra vez. Aplica a todos, logueados o no, porque opera por debajo, en la capa de datos.

La distinción es la que decide qué optimización te sirve. Una tienda mayorista vive de usuarios con sesión. Para ellos la caché de página no hace casi nada; la caché de objetos es la que mueve la aguja.

Por qué WordPress ya cachea objetos, pero mal

Acá está el detalle que casi nadie sabe: WordPress ya tiene una caché de objetos. El problema es que, por defecto, es no persistente. Vive solo durante una carga de página: WordPress arma su caché de objetos al empezar a procesar una visita y la bota al terminar. Cada nueva carga empieza de cero, volviendo a preguntarle todo a MySQL. La caché existe, pero no recuerda nada entre una visita y la siguiente.

Hacerla persistente significa guardar esos objetos en un almacén que sobreviva entre cargas, en memoria, para que la consulta cara se haga una vez y las siguientes mil la respondan desde RAM. Ese almacén es Redis (o Memcached). Conectar WordPress a Redis convierte su caché de objetos de un cuaderno que se borra cada vez en una memoria de verdad. Para una tienda que repite las mismas miles de consultas por minuto, el alivio sobre la base de datos es enorme.

Qué es Redis y qué hace por la tienda

Redis es un almacén de datos en memoria. No reemplaza a MySQL: lo protege. La base de datos sigue siendo la fuente de verdad de productos, pedidos y clientes; Redis se sienta delante y responde, desde RAM, las consultas repetidas que de otro modo golpearían a MySQL en cada carga. El efecto en una tienda WooCommerce con catálogo grande y usuarios logueados:

Sin object cache persistente	Con Redis
Cada carga repregunta a MySQL las opciones, transients y metadata	Esas respuestas salen de RAM tras la primera vez
La base de datos es el cuello de botella en horas peak	MySQL respira; atiende solo lo que cambia
Más usuarios simultáneos = más presión directa sobre la base	Redis absorbe la repetición; la base escala mejor

En la práctica, el lugar donde más se nota no es la vitrina pública —esa la salva la caché de página y el CDN— sino el panel de administración y la experiencia del cliente logueado: el vendedor que arma pedidos, el mayorista navegando su catálogo con sus precios. Justo donde una tienda B2B se gana o se pierde la jornada.

Cómo se conecta (y el requisito que filtra hostings)

Del lado de WordPress, conectar Redis es directo: el plugin Redis Object Cache suele bastar para enlazar la caché de objetos persistente con el servidor Redis y dejarla operando. Pero ese plugin no instala Redis; asume que ya existe un servidor Redis disponible. Y ese es el requisito que separa los hostings.

Redis necesita correr como servicio en el servidor, con memoria asignada. Un hosting compartido barato no lo ofrece —no te da un proceso Redis ni la RAM para sostenerlo—. Un VPS bien configurado o un hosting administrado para WooCommerce sí. Por eso "activar Redis" muchas veces no es una tarea de plugin, es una conversación de infraestructura: o el hosting lo soporta, o hay que cambiar de hosting. Es la misma frontera que aparece cuando una tienda mayorista carga lento y se descubre que el plan no da para lo que el negocio pesa.

Lo que la caché de objetos no arregla

Para no sobre-prometer, conviene ser claro sobre los límites. Redis acelera la lectura de datos repetidos. No arregla:

• Imágenes pesadas. Eso es frontend y CDN, no base de datos.
• Un catálogo mal modelado. Si una consulta es lenta por cómo está escrita o por falta de índices, cachear su resultado esconde el problema; no lo resuelve.
• Escrituras. Crear y actualizar pedidos toca la base sí o sí. Acá lo que ayuda es HPOS y sus tablas dedicadas, no la caché de objetos.
• Plugins que hacen trabajo caro en cada carga. Si un plugin reconstruye algo pesado en cada visita, cachear datos no lo frena.

La caché de objetos es una pieza de un diagnóstico de rendimiento, no la bala de plata. Encenderla sin medir puede tapar síntomas y dejar la causa real intacta.

La caché de página acelera lo que todos ven igual. La caché de objetos acelera lo que cada cliente ve distinto. En B2B, lo segundo es casi todo.

El orden correcto

Si tu tienda mayorista va lenta para los usuarios logueados, el camino es medir antes de instalar:

1. Confirma que el problema es de base de datos, no de frontend: un TTFB alto con muchas consultas por carga apunta a la base.
2. Verifica si ya tienes object cache persistente. Muchas tiendas creen tenerla y corren con la no persistente de WordPress, repreguntándole todo a MySQL en cada carga.
3. Confirma que el hosting ofrece Redis. Si no, esa es la conversación primero; el plugin viene después.
4. Conecta Redis y vuelve a medir. La mejora debe verse en consultas a la base por carga y en el tiempo de respuesta del admin, no solo en una métrica de marketing.

Una tienda B2B bien montada casi siempre tiene Redis trabajando en silencio por debajo. No es lo que se ve, pero es parte de por qué el panel abre rápido y el cliente navega su catálogo sin esperas. Si la tuya arrastra y no sabes si la caché de objetos está siquiera encendida, partamos por medir: la optimización que sirve sale del diagnóstico, no del plugin que estaba de moda.