Caché de página completa en PrestaShop: cuándo sirve y qué hay que dejar fuera

Cada vez que alguien abre una ficha de producto, PrestaShop arranca, consulta la base de datos decenas o cientos de veces, monta la plantilla y devuelve el HTML. Para el siguiente visitante que abre la misma ficha, repite exactamente el mismo trabajo. La caché de página completa guarda ese HTML la primera vez y lo sirve directamente las siguientes, sin ejecutar PrestaShop.

La diferencia en tiempo de respuesta del servidor puede ser enorme. Pero una tienda no es un blog: tiene carrito, sesión, precios por cliente y un banner de cookies. Cachear lo que no se debe es la forma más rápida de enseñarle a un cliente el carrito de otro.

Las cachés que ya tiene PrestaShop (y en qué se diferencia)

• Caché de plantillas Smarty: guarda las plantillas compiladas. Acelera el montaje, pero PrestaShop sigue ejecutándose en cada visita.
• Caché de objetos o consultas (Memcached, Redis, APCu): guarda resultados de consultas. Menos carga a la base de datos, pero sigue ejecutándose PHP.
• OPcache: guarda el PHP compilado. Imprescindible, y no tiene nada que ver con el HTML.
• Caché de página completa: guarda el resultado final. Es la única que evita ejecutar PrestaShop.

No compiten: se suman. Una tienda bien montada tiene OPcache siempre, y caché de consultas y de página según su tráfico y su catálogo.

Qué páginas se pueden cachear

La regla práctica: se cachea para el visitante anónimo y sin carrito. En cuanto hay sesión de cliente o productos en el carrito, la página se genera normal.

Lo que hay que resolver antes de activarla

Partes dinámicas dentro de una página cacheable

La ficha de producto es igual para todos, pero el contador del carrito en la cabecera no. Tampoco el «Hola, Marta» ni los precios si tienes grupos de clientes con tarifas distintas. Hay dos formas de resolverlo: no cachear para quien tiene sesión o carrito, o cargar esas partes después por AJAX. La primera es la más segura.

Precios por grupo, país o moneda

Si un cliente B2B ve otros precios, nunca debe recibir la versión cacheada del anónimo, ni al revés. Lo mismo con monedas y países que cambian impuestos: o se guarda una versión por combinación, o esas visitas no se cachean.

Móvil y escritorio

Si tu tema genera HTML distinto para móvil, necesitas versiones separadas por dispositivo. Si es un tema responsive puro, una sola versión vale.

Cookies y consentimiento

Este es el que más se pasa por alto. Si tu banner de cookies decide en el servidor qué scripts se imprimen, la primera página cacheada «congela» la decisión de quien la generó. Un visitante que aceptó todo genera la página con los píxeles activos, y el siguiente, que aún no ha decidido, los recibe igual.

Las soluciones habituales: que el banner aplique el bloqueo en el navegador, sobre una página igual para todos, o que la caché guarde versiones separadas según el estado del consentimiento.

Invalidar: el problema de verdad

Cachear es fácil. Lo difícil es saber cuándo una página guardada ha dejado de ser cierta. En una tienda pasa a todas horas:

• Cambias un precio o una descripción.
• Activas una regla de carrito o un precio específico.
• Se agota un producto con un pedido.
• Editas una categoría, un fabricante o una página CMS.

Si la caché no se entera, los clientes ven el precio viejo o un producto «disponible» que ya no lo está. Hay dos estrategias: caducidad por tiempo (la página vale una hora y luego se regenera) y purga por evento (al guardar un producto se vacía lo que le afecta). Lo correcto es combinarlas: purga cuando cambias algo y caducidad como red de seguridad.

Y una cosa que hay que saber: los cambios que no pasan por el back-office —una importación por SQL directo, un ERP que escribe en la base de datos sin usar la API— no disparan ningún evento. Si tu stock entra así, necesitas vaciar la caché al final de cada sincronización.

Cuándo no compensa

• Tiendas con casi todo el tráfico identificado, como un B2B donde todos inician sesión: el porcentaje de aciertos será bajo.
• Catálogos que cambian cada pocos minutos por sincronización con proveedores: la caché se purga antes de servir nada.
• Un servidor lento por otra causa: una consulta mal indexada o un módulo que llama a una API externa en cada página. La caché lo tapa para el anónimo, pero el cliente que compra sigue sufriéndolo en el checkout, que es donde importa.

Primero, una base actualizada

Una caché de página sobre PHP 7.x y PrestaShop 1.6 sigue sirviendo rápido a los anónimos, pero el carrito y el pago, que nunca se cachean, siguen igual de lentos. Con PHP 8 y OPcache bien configurado, y PrestaShop al día, la parte que no se puede cachear ya es mucho más rápida. Por eso, en una tienda muy atrasada, actualizar suele ser el primer paso de rendimiento y la caché el segundo.

Checklist antes de activarla

• OPcache activo y con memoria suficiente.
• Carrito, pedido, pago, cuenta y controladores de módulos excluidos.
• Sin caché para visitantes con sesión o carrito, o con partes dinámicas por AJAX.
• Prueba de consentimiento en dos ventanas privadas.
• Prueba de precio: cambia uno y comprueba que la ficha lo refleja.
• Prueba de stock: haz un pedido del último que queda y mira la ficha.
• Vaciado al final de cada sincronización externa.

Cómo resolverlo en PrestaShop

All In One Cache gestiona tres cachés desde un panel: página completa en disco, consultas SQL en Redis (PrestaShop 8 o superior, con las tablas de pedidos, carritos, sesiones y stock bloqueadas de serie) y OPcache. En la de página decides qué queda fuera, incluidas URL por expresión regular, puedes separar versiones por dispositivo y la purga va enganchada a PrestaShop: al guardar un producto, una categoría, un precio específico, una regla de carrito o una página CMS se vacía, y al validar un pedido o cambiar el stock se purga la de stock. También puedes vaciar una URL concreta o todo desde el panel, y ves aciertos y fallos. Si prefieres que te la dejemos configurada y probada en tu tienda, está el servicio de All In One Cache.