Estrategia de caché PrestaShop 2026: Redis, Memcached, Varnish — qué stack para qué tienda

En una tienda PrestaShop 8 o 9 no optimizada, el TTFB (Time To First Byte) supera habitualmente los 800 ms en hosting compartido y se mantiene alrededor de 400 ms en un VPS de gama media. Impacto directo: mal LCP (Core Web Vitals deficientes), presupuesto de rastreo de Googlebot reducido y mayor tasa de rebote. Todo en 2026, cuando el benchmark de Google ha pasado a 200 ms de TTFB y 2,5 s de LCP.

El caché no es un tema de nicho ni reservado a tiendas de alto volumen. Es la optimización de mayor ROI en PrestaShop, y la peor implementada: confusión entre caché PHP, caché de objetos, caché HTTP y proxy inverso; configuraciones por defecto ineficaces; pilas de módulos pisándose entre sí. Este artículo desglosa las cuatro capas de un stack de caché limpio y da la regla de decisión Redis / Memcached / Varnish según el perfil de la tienda.

Las cuatro capas de caché de una tienda PrestaShop

Una tienda sirve cada página apilando varias capas de caché. Conocer las capas significa evitar apilar más de lo necesario — cada capa añade complejidad y puntos de purga a gestionar.

1. Caché opcode PHP

OPcache almacena el bytecode de los archivos .php interpretados. Esencial: sin OPcache, cada petición a PrestaShop reinterpreta miles de archivos. Ganancia típica: 30 a 50% de TTFB. Gratuito, nativo de PHP, y lo primero a validar mediante php -i | grep opcache en un entorno de producción. Dimensión: 256 MB mínimo para PrestaShop 8/9, opcache.validate_timestamps=0 en producción con reciclado manual en cada despliegue.

2. Caché de objetos (in-memory key-value)

PrestaShop cachea ciertos resultados a nivel de aplicación: sesiones de usuario, metadatos de Smarty (rutas de plantillas, configuración de hooks), resultados de consultas repetitivas. Por defecto, estos cachés pasan por el sistema de archivos — lento. En producción seria, se mueven a un almacén in-memory: Redis o Memcached.

3. Caché HTTP y proxy inverso

Por encima de PrestaShop, un proxy inverso (Varnish, NGINX cache o edge cache de CDN) intercepta las peticiones HTTP y sirve respuestas pre-renderizadas sin llamar a PHP. La optimización de mayor apalancamiento — ganancia típica del 90% del tiempo de servidor en páginas anónimas con cache hit.

4. Caché de navegador y CDN

Los recursos estáticos (imágenes, CSS, JS, fuentes) deben llevar cabeceras Cache-Control: public, max-age=31536000, immutable y ser servidos por un CDN. Evidente en 2026, pero mal hecho en el 40% de las tiendas auditadas: max-age demasiado corto, recursos sin versionar, variaciones de caché mal configuradas.

Redis vs Memcached: la decisión en la práctica

Para el caché de objetos, dominan dos opciones: Redis y Memcached. El debate « cuál es más rápido » está zanjado — ambos superan ampliamente las necesidades de una tienda PrestaShop. La verdadera diferencia está en otra parte.

Memcached

• Más simple, menos funcionalidades, por tanto menos superficie de ataque y menos trampas de configuración.
• Excelente para caché efímero key-value puro.
• Sin persistencia en disco: un reinicio borra todo, produciendo un thundering herd transitorio en PHP-FPM.
• Sin estructuras avanzadas (listas, sorted sets, pub-sub) — uso limitado al caché estricto.

Redis

• Más rico: estructuras de datos (lists, sets, sorted sets), pub-sub, scripting Lua.
• Persistencia opcional (RDB o AOF): sobrevive a reinicios.
• Usado mucho más allá del caché PrestaShop: sesiones multi-servidor, cola Symfony Messenger, rate limiting.
• Configuración de memoria a vigilar (maxmemory, eviction policy) — si no, consume más de lo previsto.

Regla práctica 2026: Redis es la elección por defecto. Memcached sigue siendo relevante solo si la tienda es deliberadamente minimalista en su stack y las únicas necesidades son caché de objetos puro. Cualquier tienda que pueda eventualmente necesitar una cola de trabajos, rate limiting de API o sesiones compartidas multi-servidor se beneficia empezando directamente con Redis.

Cuándo Varnish tiene sentido (y cuándo no)

Varnish (o NGINX full-page cache) es la optimización de mayor apalancamiento en PrestaShop: sirve páginas anónimas en milisegundos en lugar de 400-800 ms. Pero Varnish no es un game-changer en todas las configuraciones.

Casos donde Varnish lo cambia todo

• Tráfico mayoritariamente anónimo: visitantes no conectados, sin precios personalizados por cliente, sin A/B testing del lado servidor. Catálogo B2C de público general.
• Volumen alto concentrado en pocas URLs: una home, 50 categorías, 500 fichas de producto representan el 80% del tráfico. El caché hace la mayor parte del trabajo.
• Pico estacional previsible: Black Friday, rebajas. Varnish absorbe el tráfico sin saturar PHP-FPM.

Casos donde Varnish es una trampa

• Tienda B2B con login obligatorio: cada página está personalizada (precios de grupo cliente, multi-usuario, presupuestos en curso). Varnish solo sirve las pocas páginas públicas y la complejidad de configuración supera la ganancia.
• Personalización del lado servidor: recomendaciones IA por usuario, A/B testing del lado servidor, precios dinámicos. El caché full-page invalida toda personalización.
• Tráfico anónimo disperso en miles de URLs long-tail: si cada URL se visita una vez al día, el hit ratio se mantiene bajo y Varnish no aporta nada.

La alternativa edge cache CDN

En 2026, Cloudflare Cache Rules, BunnyCDN Permacache, Fastly y otros edge caches hacen el trabajo de Varnish a nivel del CDN, sin servidor adicional. Ventaja: ninguna capa que mantener, distribución geográfica, integración WAF nativa. Inconveniente: la purga fina es menos flexible que Varnish, y el coste puede subir en volúmenes altos. Para el 80% de las tiendas mid-market, el edge cache CDN se ha convertido en una alternativa superior al Varnish auto-hospedado.

Coste real y ROI de un stack de caché limpio

Coste

• OPcache: 0 €. Activar y dimensionar correctamente.
• Redis: 0 € en local (mismo servidor que PHP-FPM) a 15-30 €/mes en un VPS dedicado (Hetzner CX11) o Redis gestionado (Upstash, Redis Cloud) desde 10 €/mes.
• Varnish: 0 € open source, pero 1 a 3 días de instalación y tuning por un sysadmin competente. Presupuesto en tiempo, no en licencia.
• CDN edge cache: Cloudflare Pro 25 $/mes, BunnyCDN alrededor de 1 $/GB transferido, Fastly desde 50 $/mes usage-based.
• Implementación inicial: 2 a 5 días de dev para una tienda estándar (configuración, pruebas, purga automática vía webhook PrestaShop).

ROI medido

De auditorías de tiendas PrestaShop 8 mid-market tras el despliegue de un stack de caché limpio:

• TTFB pasa de 600-800 ms a 80-150 ms en cache hit.
• LCP cae de 3,2 s a 1,4 s en ficha de producto anónima.
• Tasa de rebote móvil disminuye un 12 a 18% de media.
• Conversión móvil sube un 6 a 12%.
• Presupuesto de rastreo de Google se duplica, lo que se traduce en 4-8 semanas en +15% de URLs indexadas.

El coste de oportunidad de no desplegar un caché limpio supera frecuentemente el 1% del CA anual. Una tienda a 1 M€/año pierde típicamente 10-20 K€/año por rendimiento degradado.

Trampas a evitar

1. Apilar módulos de caché sin coherencia

Muchas tiendas acumulan: módulo oficial PrestaShop cache, módulo Redis de terceros, módulo Varnish separado, plugin CDN. Sin una jerarquía clara, los cachés no se invalidan entre sí y algunos hits anulan otros. Se necesita una única política de caché documentada con un esquema claro de purga en cascada.

2. Mala gestión de la purga por evento

Cuando un precio cambia, el stock se actualiza o un atributo de producto se modifica, la página afectada debe purgarse. PrestaShop no tiene un hook unificado — hay que cablear actionProductUpdate, actionObjectStockMvtAddAfter, actionObjectCategoryUpdateAfter y disparar la purga correcta (Varnish PURGE, Redis DEL, CDN API). Sin esto, el visitante ve precios obsoletos, lo que puede caer bajo la directiva Omnibus.

3. Cachear páginas personalizadas

El carrito, la cuenta de cliente, el checkout y cualquier página con datos de usuario nunca deben entrar en caché full-page. La regla Varnish o CDN debe excluir explícitamente estas rutas (/cart, /mi-cuenta, /pedido, /identidad). Error común: una tienda que cachea todo por defecto muestra el carrito de un cliente a otro. Incidente grave y difícil de diagnosticar a posteriori.

4. No hacer pruebas de carga

Un caché limpio se valida bajo carga. Una herramienta como k6 o Locust simula 500-1000 visitantes simultáneos y mide hit ratio, TTFB bajo carga, estabilidad PHP-FPM. Sin esta prueba, los problemas se descubren en producción un día pico — el peor momento para corregirlos.

5. Olvidar multishop y multi-divisa

Un caché demasiado agresivo en una tienda multishop puede servir el mismo HTML a todas las tiendas, o servir el precio EUR a un visitante en GBP. La clave de caché debe incluir id_shop, id_lang, id_currency como mínimo. Verificar explícitamente la clave de caché generada — es el error silencioso más caro en pérdida de conversión.

El stack recomendado por defecto en 2026

Para el 80% de las tiendas PrestaShop 8/9 mid-market (CA 200 K€ a 5 M€/año):

1. OPcache activado con 256 MB y opcache.validate_timestamps=0 en producción.
2. Redis como backend de caché de objetos PrestaShop (sesiones, Smarty, metadatos). Una instancia basta en la mayoría de los casos.
3. Edge cache CDN (Cloudflare o BunnyCDN) en páginas catálogo y CMS públicas, con exclusión explícita de rutas de usuario.
4. Caché de navegador agresivo en recursos estáticos (1 año), versionados por hash mediante el sistema de assets PrestaShop.
5. Sin Varnish salvo caso específico de tráfico alto homogéneo donde el tuning y mantenimiento se justifiquen.

Este stack se despliega en 2 a 5 días, cuesta 10-30 € al mes en cuotas recurrentes, y aporta una ganancia de rendimiento muy superior a lo que se puede obtener optimizando el código aplicativo. Antes de cualquier optimización backend (refactorización de módulos, consultas SQL), revisar estos cinco puntos sigue siendo el primer paso rentable.