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

> TTFB de 800 ms, LCP de 3,2 s, presupuesto de rastreo Google saturado: en una tienda PrestaShop no optimizada, el caché es la optimización de mayor ROI en 2026 — y la peor implementada. Las cuatro capas de un stack limpio, la regla de decisión Redis / Memcached / Varnish, y el stack por defecto recomendado para el 80% de las tiendas mid-market.

- Página: <https://www.datafirefly.com/es/2026/08/14/estrategia-cache-prestashop-redis-memcached-varnish-2026/>
- Idioma: es
- Publicado el: 2026-08-14
- Actualizado el: 2026-06-13
- Otros idiomas: [fr](https://www.datafirefly.com/2026/08/14/strategie-cache-prestashop-redis-memcached-varnish-2026/index.md), [en](https://www.datafirefly.com/en/2026/08/14/prestashop-cache-strategy-redis-memcached-varnish-2026/index.md), [it](https://www.datafirefly.com/it/2026/08/14/strategia-cache-prestashop-redis-memcached-varnish-2026/index.md), [de](https://www.datafirefly.com/de/2026/08/14/cache-strategie-prestashop-redis-memcached-varnish-2026/index.md), [pl](https://www.datafirefly.com/pl/2026/08/14/strategia-cache-prestashop-redis-memcached-varnish-2026/index.md), [nl](https://www.datafirefly.com/nl/2026/08/14/cachestrategie-prestashop-redis-memcached-varnish-2026/index.md), [pt](https://www.datafirefly.com/pt/2026/08/14/estrategia-cache-prestashop-redis-memcached-varnish-que-stack-2026/index.md)
- Índice: <https://www.datafirefly.com/es/2026/llms.txt>

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.