Configurar mal Redis o Memcached rompe tu carrito

Lanzas una campaña, suben los usuarios logueados y la portada sigue cargando rápido. Sin embargo, el carrito tarda, el checkout responde a trompicones y algunos precios o cantidades parecen no actualizarse como deberían. La caché de página no toca esas zonas dinámicas: una caché de objetos mal configurada puede convertir una mejora esperada en un riesgo directo para las ventas.

Redis vs Memcached para WooCommerce: ¿cuál elegir? Para la mayoría de tiendas WooCommerce, Redis es la opción más segura: aporta caché de objetos persistente, estructuras de datos flexibles y mayor control con sesiones, precios dinámicos o picos de tráfico. Memcached encaja en instalaciones sencillas sin necesidad de persistencia. Antes de activarlos, mide el TTFB con usuarios logueados y valida qué datos de WooCommerce deben quedar fuera de caché.

Redis encaja en tiendas WooCommerce complejas

Redis suele ser la elección segura para una tienda WooCommerce con sesiones, reglas de precio o picos de compra. Guarda datos en memoria, como una mesa de trabajo mucho más rápida que buscar cada documento en un archivador MySQL, y puede conservarlos tras un reinicio mediante persistencia RDB o AOF, según la configuración del servidor.

Memcached también guarda datos en memoria, pero está pensado para información temporal. Si el proceso se reinicia, su contenido desaparece. Eso no rompe WooCommerce por sí mismo, porque la base de datos sigue siendo la fuente real, pero puede devolver carga a MySQL justo durante una campaña.

Cuándo Redis aporta ventas y estabilidad

Redis compensa cuando el servidor repite muchas consultas internas para cada comprador. Es habitual en tiendas con filtros, membresías, precios por rol, WPML, conversión de moneda o una conexión con ERP mediante API.

La práctica demuestra que una portada rápida no basta si la ficha, la cuenta y el carrito siguen esperando a PHP y MySQL. En una campaña de rebajas de enero para una tienda de Madrid, veinte clientes concurrentes pueden importar más que miles de visitas anónimas repartidas durante todo el día.

Redis fue creado por Salvatore Sanfilippo y hoy Redis Ltd. mantiene el proyecto. Su valor en WordPress no nace de instalar un plugin, sino de tener un servicio Redis accesible desde PHP y una caché persistente bien conectada.

Cuándo Memcached sigue siendo suficiente

Memcached puede bastar para un catálogo de menos de 500 productos, pocos clientes identificados y ausencia de reglas de precio personales. Brad Fitzpatrick lo creó para repartir objetos temporales en memoria con un diseño deliberadamente simple.

Su software puede desplegarse por 0 € en un servidor propio, igual que Redis, pero la RAM, la administración y las copias siguen teniendo coste. En hosting compartido español, la diferencia práctica suele ser otra: muchos planes solo exponen uno de los dos servicios y no permiten ajustar memoria ni políticas de borrado.

Elige esto si: tu tienda es sencilla, el hosting mantiene Memcached y puedes probar el área privada antes de publicar. Con esta base clara, conviene medir la capa que está lenta de verdad.

El TTFB logueado revela la carga que importa

El TTFB de usuarios logueados revela si Redis o Memcached reducen trabajo real en WooCommerce. El TTFB es el tiempo que tarda el servidor en empezar a responder; en una tienda, compara al menos el percentil 50 y el 95, es decir, el caso normal y los casos lentos de cada 100 peticiones.

La caché de página guarda una página ya preparada, como una fotocopia lista para entregar. Por eso Cloudflare, LiteSpeed Cache u otro plugin pueden bajar mucho el TTFB de la portada pública, pero suelen excluir carrito, cuenta y checkout.

La portada no representa el checkout

El checkout calcula impuestos, envío, descuentos, stock y métodos de pago para una cesta concreta. También usa nonces, códigos temporales que WordPress crea para comprobar que la petición viene de una sesión válida.

Una mejora creíble baja el TTFB p95 del área privada y reduce consultas SQL con la misma cesta, cupón y método de pago. Un rango razonable para detectar un cambio es repetir entre 20 y 50 recorridos controlados, no comparar una sola carga aislada.

MySQL recibe lo que no cacheas

La caché de objetos guarda resultados internos de WordPress, como opciones de wp_options o datos obtenidos repetidamente. No arregla una consulta SQL mal diseñada, un índice ausente ni un plugin que consulta una API externa en cada carga.

El error más frecuente que se detecta aquí es celebrar un PageSpeed alto mientras el checkout sigue haciendo decenas de consultas lentas. Query Monitor permite revisar el diagnóstico en pruebas, y New Relic sirve para observar trazas de producción sin adivinar.

Elige esto si: necesitas saber si el cuello está en la caché, PHP-FPM o MySQL. La siguiente matriz convierte esa medición en una elección concreta.

La matriz decide por carga y funciones

Redis es preferible si la tienda reúne dos o más factores de complejidad: clientes logueados, multimoneda, membresías, precios por rol, API o picos de campaña. Memcached sigue siendo razonable si casi todo el tráfico es anónimo y el proveedor lo gestiona mejor que Redis.

Catálogo y concurrencia cambian la elección

Un catálogo grande no obliga por sí solo a instalar Redis. Lo que cambia la decisión es la concurrencia, es decir, cuántos compradores piden cálculos a la vez durante una promoción.

Una tienda con 8.000 referencias y visitas repartidas puede necesitar menos caché que una con 800 productos y 30 compradores simultáneos. Las búsquedas filtradas, los filtros AJAX y las consultas a stock elevan el trabajo en cada petición.

Multimoneda y B2B elevan el riesgo

Los precios por rol, país o moneda exigen comprobar el contexto de cada clave guardada. Piensa en ello como etiquetar cajas en un almacén: si una caja no indica para quién es, alguien puede recibir el precio equivocado.

Un caso habitual: una tienda B2B activa Redis, prueba como administrador y da el cambio por bueno; después un cliente profesional ve una promoción minorista. La causa no es Redis como motor, sino una extensión que genera o reutiliza datos sin separar rol, moneda o sesión.

Elige esto si: tienes reglas comerciales distintas por comprador y puedes probarlas con cuentas reales de prueba. El punto siguiente evita que una mejora de velocidad se convierta en un error de venta.

En WooCommerce headless, Redis no debe confundirse con una caché pública de respuestas de API. Un frontend basado en React, Next.js o una aplicación móvil puede consultar la REST API o la Store API para catálogo, carrito y checkout WooCommerce; cada endpoint tiene un nivel de personalización distinto. Las fichas públicas y categorías pueden beneficiarse de una caché de página o CDN con invalidación al actualizar productos, pero las respuestas que contienen sesión, nonce, moneda, impuestos, disponibilidad o precios dinámicos WooCommerce deben variar por cliente o quedar fuera de una caché compartida.

Redis puede reducir trabajo interno de WordPress y contribuir a la optimización de MySQL, pero no autoriza a reutilizar la respuesta de un carrito entre tokens, cookies o compradores distintos.

Carrito y checkout exigen reglas distintas

Carrito, checkout, cuenta, nonces, stock y precios personalizados no deben servirse como contenido compartido entre compradores. Redis y Memcached pueden acelerar el trabajo interno de WordPress, pero no convierten esos datos en páginas públicas reutilizables.

La recomendación extendida de “excluir carrito y checkout” es incompleta. Esa exclusión pertenece a la caché de página; el object cache funciona en otra capa y exige revisar plugins, sesiones de WooCommerce y claves que puedan depender del usuario.

Una caché rápida es segura solo si una cesta, un precio y un cupón siguen perteneciendo al mismo comprador en cada prueba.

Datos que cambian por comprador

No cachees como página compartida el carrito de compra, los fragmentos de carrito, sesiones de WooCommerce, cupones, impuestos, envío, stock ni un precio condicionado. Las reglas de geolocalización y membresía merecen el mismo trato.

Prueba siempre añadir producto, variar cantidad, aplicar cupón, cambiar moneda, iniciar sesión, elegir transporte, pagar y verificar la reducción de stock. Hazlo con dos usuarios distintos y dos navegadores separados.

El fallo que surge en campaña

Las señales de alerta son un total incorrecto, cupón ajeno, nonce inválido, bucle de checkout o stock que no cambia. Si aparecen, desactiva primero la caché de objetos o vuelve al estado previo, antes de tocar diez ajustes a la vez.

Las obligaciones del RGPD y la LOPDGDD también importan: no debe guardarse información identificable en claves compartidas ni enviar datos de sesión a servicios externos sin una base legal clara. La LSSI-CE añade obligaciones de información cuando intervienen servicios y comunicaciones comerciales.

Elige esto si: puedes separar claramente caché de página y caché de objetos. Antes de activar nada, queda una revisión técnica que no admite atajos.

Redis solo sirve si hosting y PHP encajan

Redis o Memcached solo mejoran WooCommerce cuando el servicio, PHP, el plugin y WordPress usan la misma configuración. Instalar Redis Object Cache sin extensión phpredis, o dejar dos archivos object-cache.php activos, es como enchufar dos mandos al mismo cuadro eléctrico.

El consenso en la documentación de WordPress es que los drop-ins sustituyen partes del comportamiento normal de carga. Revisa la documentación oficial de WordPress sobre drop-ins antes de borrar o reemplazar object-cache.php.

Un solo object-cache.php activo

Comprueba que existe un único plugin de caché de objetos y un solo object-cache.php. El panel del hosting, LiteSpeed Cache y un plugin antiguo pueden dejar configuraciones que compiten sin mostrar un error claro.

Valida también que PHP-FPM puede conectar por socket Unix o red, con contraseña y TLS cuando el proveedor lo requiera. WP-CLI ayuda a verificar cambios, pero nunca debe ejecutarse un vaciado de caché sin saber qué servicio y qué entorno se está tocando.

Prefijos separan producción y pruebas

Producción, staging y cada sitio de un multisite necesitan prefijos de clave distintos. Compartir el mismo espacio sin aislamiento puede mezclar datos de pruebas con pedidos reales.

Elige esto si: el proveedor confirma el servicio y puedes crear una copia de configuración antes del cambio. La decisión final solo se gana con métricas y un regreso rápido preparado.

Cambiar de Memcached a Redis no requiere migrar pedidos, productos ni clientes: ambos almacenan una capa derivada y temporal, mientras WooCommerce mantiene la información definitiva en MySQL o MariaDB. Aun así, conviene hacerlo en una ventana de tráfico bajo y conservar una copia del archivo wp-config.php, de la configuración del plugin y del object-cache.php previo. Primero activa Redis en staging con un prefijo de claves propio, vacía únicamente la caché de ese entorno y prueba altas de carrito, cupones, impuestos, pagos, reducción de stock y correos transaccionales.

En producción, activa un único drop-in, verifica los registros de PHP y deja Memcached disponible hasta completar una compra real de prueba. Si aparecen totales incorrectos, errores AJAX o aumento de 5xx, desactiva el plugin de Redis, restaura la configuración anterior y purga la caché afectada antes de seguir investigando.

Antes de habilitar una caché persistente WordPress, confirma cinco puntos en el mismo entorno:

• que el hosting ofrece Redis o Memcached con memoria asignada y acceso desde PHP-FPM
• que está instalada la extensión PHP adecuada, como phpredis o memcached
• que el plugin elegido reconoce ese servicio y crea un único object-cache.php
• que LiteSpeed Cache, Cloudflare u otra caché de página excluyen carrito WooCommerce, cuenta y checkout WooCommerce
• y que staging usa una base, credenciales y prefijo de claves separados de producción

También conviene comprobar si el proveedor impone TLS, contraseña, socket Unix o límite de conexiones. Esta revisión evita el error de activar Memcached WordPress o Redis desde el panel sin que el proceso PHP pueda conectarse realmente al servicio.

Las métricas separan ahorro de riesgo

Mantén Redis o Memcached en producción solo si bajan el TTFB y las consultas a MySQL sin elevar evicciones, errores PHP ni fallos de compra. Un hit ratio mide cuántas veces se encuentra un dato en caché, pero por sí solo no prueba que el checkout venda mejor.

Mide antes y después el TTFB p50 y p95 para anónimos y logueados, consultas y tiempo de MySQL o MariaDB, latencia de PHP-FPM, memoria usada y errores 5xx. Registra también pedidos fallidos, pagos rechazados y errores AJAX durante un periodo comparable de 7 a 14 días si el volumen de pedidos lo permite.

El hit ratio no aprueba la caché

Un hit ratio del 90% puede coexistir con un checkout lento. Puede estar acertando objetos pequeños mientras la consulta costosa, una llamada de transporte o el cálculo de impuestos sigue tardando demasiado.

Lo que se ve en la práctica es que cruzar TTFB logueado, consultas SQL y errores de pago encuentra problemas que PageSpeed no muestra. Query Monitor sirve para diagnóstico puntual; New Relic y la CLI de Redis permiten seguir comportamiento bajo carga.

Memoria para picos, no para valle

Dimensiona la memoria con campañas, no con un martes tranquilo. Redis puede expulsar claves al llenarse, una evicción, usando reglas como LRU o LFU, que deciden qué dato sale antes de que entre otro.

Configura alertas antes de alcanzar el límite y observa evictions por minuto durante promociones. Si el consumo pasa del rango habitual de 60% a 80% de la memoria asignada, investiga antes de que el sistema empiece a expulsar claves útiles.

Elige esto si: tus mediciones muestran mejora en compradores reales y tienes un plan de vuelta atrás. Si ninguna opción supera estas pruebas, primero corrige la causa fuera de la caché.

Lo que más preguntan

¿Qué caché es mejor, Memcached o Redis?

Redis suele ser mejor para WooCommerce complejo porque ofrece persistencia, TTL y más herramientas de control. Memcached basta con tráfico mayormente anónimo, pocas áreas privadas y un hosting que lo gestione de forma fiable.

¿Memcached sigue utilizándose en WordPress?

Sí, Memcached sigue siendo útil para objetos temporales en WordPress. Funciona si el servicio, la extensión PHP y el plugin son compatibles, pero no conserva datos tras un reinicio.

¿Redis puede ralentizar mi tienda WooCommerce?

Sí, Redis puede ralentizar una tienda si agota memoria, sufre evicciones o tiene latencia de conexión. Revisa TTFB p95, memoria, errores PHP-FPM y conexiones antes de culpar a WooCommerce.

¿Redis sustituye a Cloudflare o caché de página?

No, Redis no sustituye Cloudflare ni la caché de página. Redis acelera objetos internos; Cloudflare y la caché de página sirven páginas públicas, mientras carrito y checkout requieren reglas propias.

¿Qué debo medir antes de activar Redis?

Mide TTFB p50 y p95, consultas SQL, tiempo PHP, uso de memoria y errores de checkout. Repite entre 20 y 50 recorridos con la misma cesta, cupón y forma de pago.

¿Cómo vuelvo de Redis a Memcached sin perder datos?

Vuelve mediante una ventana de bajo tráfico y una configuración anterior ya guardada. Desactiva el plugin Redis, verifica el único object-cache.php, activa Memcached y prueba compra, cupón y stock con dos sesiones.

• Optimización Redis/Memcached para velocidad y estabilidad
• Tu hosting WooCommerce B2B rompe el carrito con caché

Josu Barrios

Somos especialistas en mantenimiento WordPress para empresas, profesionales y tiendas online. Contamos con experiencia en seguridad web, optimización de rendimiento, actualizaciones, copias de seguridad y resolución de incidencias técnicas, ayudando a que cada sitio funcione de forma rápida, estable y protegida. Nuestro enfoque combina soporte técnico profesional, buenas prácticas de seguridad y seguimiento continuo para ofrecer un servicio fiable, transparente y orientado a resultados reales.