Caché de página completa, Redis y CDN en PrestaShop

Qué haríamos

Mediríamos el recorrido de las solicitudes en producción antes de elegir otra caché. Conserva una caché que funcione si mantiene los datos correctos y reduce la carga medida. Utiliza caché de página completa para las visitas públicas repetidas que sean aptas y corrige también las operaciones costosas sin caché, especialmente en el carrito y el proceso de compra. Redis es una opción cuando un adaptador implementado puede reutilizar los datos que causan la demora.

La opción depende de tus versiones actuales de PrestaShop y PHP, módulos, integraciones, tema, datos del catálogo, grupos de clientes, mercados y tráfico. Ten en cuenta la capacidad de tu equipo para supervisar, purgar y recuperar cada servicio añadido. Una importación de stock desde el ERP, precios según el país o una cabecera personalizada pueden cambiar la política segura aunque dos tiendas utilicen el mismo módulo de caché.

Realiza el cambio en una copia privada de staging con datos representativos y los mismos módulos, integraciones y tema pertinentes. Aísla su espacio de nombres de caché y almacenamiento de sesiones de los de producción, e impide que los pedidos de prueba, correos y exportaciones lleguen a sistemas reales. Cambia una capa cada vez, ensaya la navegación, las actualizaciones y la recuperación ante fallos y planifica después el cambio en producción con la configuración anterior disponible y una persona encargada de comprobar los pedidos y la vigencia de los datos.

Si quieres evaluar el cuello de botella antes de elegir una caché, PrestaShop Speed & Core Web Vitals Audit proporciona un plan de mejoras medido y priorizado; la implementación se delimita por separado.

¿Qué opción encaja con tus mediciones?

Identifica la capa de caché que vas a cambiar

Una caché solo ayuda cuando la aplicación lee de ella. Instalar Redis no traslada automáticamente todas las cachés de PrestaShop a la memoria.

Smarty normalmente reutiliza plantillas compiladas. No compila todas las plantillas en cada solicitud. PrestaShop inicia Smarty con la caché global de salida desactivada y gestiona la caché de forma selectiva. Utiliza los ajustes compatibles del back office en lugar de cambiar indiscriminadamente la caché global de salida.

Los formularios de Rendimiento de PrestaShop 1.7.8 y 9 incluyen los backends Memcache, Memcached, APC/APCu y XCache, según las extensiones instaladas. No ofrecen Redis ni un backend de sistema de archivos en ese selector. El antiguo CacheFs es una implementación separada. Redis requiere un adaptador o módulo que implemente la capa que quieres utilizar.

Cache::store() utiliza un array local de la solicitud, mientras que Configuration tiene cachés estáticas. Los resultados aptos de la base de datos pueden utilizar el backend persistente Cache. Cambiar ese backend no redirige todas las consultas de categorías, hooks, configuración o plantillas.

Elige una política segura de caché de página completa

La caché de página completa almacena una respuesta renderizada apta para visitantes posteriores. Si no hay un acierto, se realiza el renderizado normal. Una caché de páginas en PHP puede reducir el trabajo posterior de controladores y plantillas, manteniendo el coste de inicialización. Un acierto en un proxy o una CDN puede evitar por completo el origen.

Empieza por páginas públicas para visitantes anónimos. Excluye de la caché el carrito, el pago, la autenticación, las páginas de cuenta, las rutas del back office, los endpoints privados de módulos, los servicios web, los callbacks y las solicitudes que modifican el estado. Ten en cuenta también AJAX, los parámetros de consulta, los enlaces de vista previa, las cookies de sesión y las respuestas que establecen cookies.

Una clave de caché debe distinguir todos los contextos que cambian la respuesta pública. Según tu tienda, pueden incluir el nombre de host, la tienda, el idioma, la moneda, el país, el contexto fiscal, el renderizado por dispositivo y los parámetros de consulta admitidos. Los precios por grupo de clientes y las promociones personalizadas requieren especial atención.

No sirvas el contenido privado de un cliente a otro. Si un contexto no puede representarse de forma segura en una clave, exclúyelo de la caché. Evita eliminar cookies solo para forzar un acierto. Prueba tanto la consulta de caché como la decisión de almacenar una respuesta recién renderizada.

Los fragmentos dinámicos, la hidratación AJAX, las inclusiones en el borde y la exclusión de solicitudes personalizadas son diseños distintos. La hidratación y el parpadeo no son propiedades inevitables de la caché de página completa. Si tu implementación sustituye fragmentos de la cabecera o el carrito tras la carga, reserva espacio y prueba dispositivos lentos. Que se vea un contador del carrito a cero no demuestra por sí solo que el carrito esté vacío en el servidor.

Performance Revolution ejecuta su caché de páginas de origen dentro de PHP tras la inicialización, y su política de elegibilidad comprueba el contexto del cliente, del carrito y de otras partes de la solicitud. Su página de ayuda cubre los procesos compatibles de caché de páginas, CSS crítico, precarga y CDN.

La invalidación forma parte del diseño

• Purga o actualiza las entradas afectadas tras cambios en productos, categorías, stock, precios, promociones, traducciones y configuración.
• Ten en cuenta la activación y la caducidad programadas de las reglas de precios.
• Exige que las importaciones e integraciones activen la invalidación adecuada. Las escrituras directas en la base de datos pueden omitir los hooks de la aplicación.
• Utiliza el TTL como límite de vigencia, no como prueba de que los cambios se harán visibles de inmediato.
• Precarga solo páginas públicas aptas y evita saturar el origen con fallos de caché simultáneos.

Prueba una modificación de precio y un cambio de stock mediante cada vía de actualización que utilices. Una purga manual puede resolver una incidencia, pero los datos obsoletos recurrentes requieren corregir la invalidación.

Ejemplo práctico: precios públicos e importación de stock del ERP

Tu tienda vende a particulares de distintos países y ofrece precios diferentes a los clientes profesionales que inician sesión. Precarga una página de producto y otra de categoría en cada contexto de precios compatible e inicia después sesión como cliente profesional. Comprueba el precio mostrado, la visualización de impuestos y el total del carrito frente a una referencia sin caché; la visita profesional debe seguir la política acordada de omisión de caché.

En staging, precarga las variantes públicas de producto y listado y confirma los aciertos en cada capa de caché HTML activada. Cambia solo el precio en el back office y compara después cada variante con una referencia sin caché antes de cualquier purga manual. Precarga de nuevo, confirma los aciertos y cambia después solo el stock mediante la importación real del ERP; repite las comprobaciones, incluidos los mensajes de disponibilidad y las copias de los nodos de la CDN. Prueba cada vía de actualización por separado: si alguna conserva datos antiguos, omite la caché de páginas afectada hasta que esa vía la invalide de forma fiable.

Conecta Redis a una integración implementada

Redis es un servicio de clave-valor en memoria que se ejecuta en tu servidor o te proporciona tu proveedor de alojamiento. Puede almacenar valores de caché, entradas de caché de páginas o sesiones PHP cuando una integración correspondiente lo utiliza. Identifica primero el adaptador, las versiones compatibles de PrestaShop/PHP, el formato de las claves, la política de TTL, la invalidación y el comportamiento ante fallos.

1. Confirma que tu proveedor ofrece un servicio Redis accesible. Un servicio gestionado por el proveedor no requiere que tengas SSH.
2. Comprueba el cliente PHP requerido en el entorno PHP web, no solo en PHP de CLI. PHP-FPM y CLI pueden cargar configuraciones diferentes.
3. Configura host, puerto, autenticación, TLS cuando sea necesario, base de datos y espacio de nombres en la integración elegida. En contenedores, utiliza la dirección de servicio correcta; localhost se refiere al contenedor actual.
4. Asigna un espacio de nombres explícito a cada instalación y a cada ámbito necesario de tienda/grupo. Un prefijo predeterminado compartido como ps_ no aísla las tiendas.
5. Visita páginas representativas y verifica las claves específicas del adaptador, los TTL y las lecturas/escrituras.
6. Prueba la invalidación, los fallos de conexión y la recuperación en un entorno de pruebas.

Ejemplos de diagnóstico local, suponiendo que Redis sea accesible deliberadamente en el mismo host en el puerto 6379:

redis-cli -h 127.0.0.1 -p 6379 PING
redis-cli -h 127.0.0.1 -p 6379 INFO stats
redis-cli -h 127.0.0.1 -p 6379 INFO memory
redis-cli -h 127.0.0.1 -p 6379 -n 0 DBSIZE

Aplica los requisitos de autenticación y transporte de tu servicio. PONG confirma la accesibilidad, no que PrestaShop utilice Redis. Un recuento de claves distinto de cero puede pertenecer a otra aplicación. Examina el espacio de nombres y la actividad de la integración elegida. Los aciertos y fallos de toda la instancia no permiten identificar el beneficio de una tienda.

Utiliza SCAN con un prefijo conocido para una inspección controlada. MONITOR puede exponer datos de comandos y añadir carga; resérvalo para diagnósticos breves en un entorno controlado.

Redis Cache Manager & Monitor proporciona pruebas administrativas de conexión, supervisión y gestión de espacios de nombres y claves; su página de ayuda cubre los procesos del módulo.

Los adaptadores de caché de aplicaciones, la configuración de sesiones PHP y la caché de página completa siguen siendo trabajos de integración independientes. Un interruptor guardado o una conexión correcta desde el panel no demuestran que haya cambiado una caché de la aplicación. Si el espacio de nombres esperado sigue vacío, comprueba la base de datos seleccionada, el prefijo y la elegibilidad de las páginas antes de cambiar la capacidad. Revisa los errores de conexión del entorno web y la configuración del adaptador; instalar una extensión PHP por sí solo no añade una opción Redis al selector nativo.

Memcached es otra opción de caché en memoria, con funciones diferentes. Tanto Redis como Memcached pueden tener gestores de sesiones PHP configurados por separado. Elige según los adaptadores compatibles, las necesidades operativas y las mediciones, en lugar de suponer que uno siempre es más rápido.

Separa las sesiones, la expulsión y la durabilidad

Los carritos de PrestaShop son registros de la base de datos. La identidad del cliente también implica cookies de PrestaShop y registros respaldados por la base de datos. Las sesiones PHP/Symfony son otra capa. Trasladar las sesiones PHP a Redis no traslada los registros del carrito ni garantiza la continuidad del inicio de sesión del cliente.

Si cambias el gestor de sesiones PHP, sigue las indicaciones de configuración de phpredis de tu versión instalada y aplícalas al pool de PHP-FPM correcto. Verifica dónde espera el framework de tu aplicación que se configuren las sesiones.

Define los TTL de las sesiones, los bloqueos, la autenticación, la capacidad, la persistencia y el comportamiento ante fallos. Las sesiones almacenadas en Redis pueden seguir necesitando bloqueos para impedir que solicitudes simultáneas sobrescriban el estado. Prueba solicitudes paralelas de una misma sesión y de sesiones diferentes.

Los números de base de datos Redis separados pueden ayudar a distinguir claves, pero comparten la memoria de la instancia, la política de expulsión y la exposición a fallos. Un vaciado de caché puede afectar a las sesiones si el ámbito es incorrecto. Prefiere un servicio de sesiones aprovisionado por separado cuando estas necesiten una política distinta de durabilidad y expulsión.

Las políticas de expulsión de Redis se aplican a la instancia. volatile-lru expulsa claves con TTL, que pueden incluir sesiones. No las protege. Elige deliberadamente la política de expulsión de la caché y supervisa los fallos de escritura si utilizas una política sin expulsión.

Para las sesiones, elige explícitamente la persistencia RDB/AOF, la replicación y los objetivos de recuperación. La persistencia reduce algunos escenarios de pérdida, pero no garantiza una pérdida nula ni inicios de sesión sin interrupciones.

En una tienda con equilibrio de carga, verifica que todos los nodos web utilizan el backend compartido previsto y un espacio de nombres compatible. Ensaya un recorrido que pase por distintos nodos. El almacenamiento compartido de sesiones PHP por sí solo no corrige una configuración de aplicación, un ámbito de cookies o unos secretos incoherentes, ni sustituye a la base de datos que almacena los carritos.

Dimensiona Redis con mediciones del número de claves, el tamaño de los datos, las variantes, los TTL y el uso máximo. Vigila used_memory, used_memory_peak, maxmemory, evicted_keys, las escrituras rechazadas y las conexiones. La expulsión puede ser normal en una caché desechable con capacidad limitada; interprétala junto con la latencia y los patrones de aciertos. No existe una fórmula de memoria por tamaño del catálogo ni un objetivo universal del 90% de aciertos.

Calcula la tasa de aciertos de un periodo de observación dividiendo el incremento de keyspace_hits entre la suma de los incrementos de keyspace_hits y keyspace_misses, excluyendo periodos con reinicio de contadores o sin consultas. Estos contadores abarcan toda la instancia de Redis, además de la tienda. Una tasa baja de reutilización puede reflejar muchas variantes de país/moneda o URL que rara vez se vuelven a visitar. Relaciónala con las caducidades, importaciones, purgas y presión de memoria antes de aumentar maxmemory. Supervisa connected_clients en relación con el tráfico y los errores de conexión; un crecimiento por sí solo no demuestra una fuga.

Configura Cloudflare o Varnish en torno a la aplicación

El comportamiento predeterminado de caché de Cloudflare se centra principalmente en recursos estáticos aptos; almacenar HTML en caché requiere una configuración deliberada. Empieza por la entrega de contenido estático y confirma que las solicitudes dinámicas siguen siendo privadas. Utiliza Full (Strict) TLS con un certificado válido en el origen y un nombre de host coincidente. El modo Flexible utiliza HTTP hasta el origen y puede entrar en conflicto con las redirecciones HTTPS.

• Mantén el carrito, el pago, la cuenta, la administración, la API, AJAX y los callbacks de pago fuera de la caché HTML compartida.
• Respeta las directivas private/no-store y el comportamiento de Set-Cookie. Prueba las reglas efectivas en el borde, no solo las cabeceras del origen.
• Mantén sin proxy los registros DNS relacionados con el correo cuando lo exija el servicio de correo.
• Restaura las direcciones reales de los visitantes solo desde proxies de Cloudflare de confianza. No confíes en una cabecera de reenvío arbitraria proporcionada por el cliente.
• Prueba las reglas de WAF y bots con los callbacks de pago, la realización de pedidos y las integraciones.
• Desactiva Rocket Loader o excluye explícitamente los scripts del pago si modifica el orden de scripts necesario; prueba todo el proceso.

Una integración HTML controlada con la CDN puede marcar para caché solo las respuestas GET/HEAD anónimas aptas y enviar cabeceras de exclusión para otros contextos. Configura mecanismos de purga compatibles y verifica las capacidades actuales de tu cuenta. Las cabeceras por sí solas no demuestran que el borde haya almacenado una respuesta en caché o la haya excluido.

Varnish es un proxy inverso HTTP. Cuando hay un acierto, puede responder antes de que se ejecute PHP. Necesita reglas para métodos, cookies, claves de caché, respuestas privadas, invalidación y comportamiento ante fallos. Muchos despliegues terminan TLS en un componente separado. Los fragmentos dinámicos son un trabajo de implementación opcional.

Añade un proxy inverso cuando el tráfico anónimo medido o la saturación de los procesos PHP justifiquen su operación. No puede eliminar el trabajo sin caché del proceso de pago. Proporciona suficiente capacidad en el origen para fallos de caché, purgas e interrupciones, y protege los endpoints de invalidación.

Vacía y diagnostica la caché correcta

Empieza por Parámetros avanzados > Rendimiento > Borrar caché. Registra el síntoma que investigas. Una actualización del navegador no vacía las cachés del origen, OPcache ni las del borde.

1. Utiliza un entorno de pruebas cuando sea posible. Cambia o evita una capa cada vez.
2. Vacía las cachés compatibles de la aplicación y verifica la página directamente en el origen mediante tu vía de diagnóstico autorizada.
3. Invalida la caché de cualquier módulo o espacio de nombres Redis independiente que esté implicado.
4. Reinicia OPcache web solo si el despliegue lo requiere. Un opcache_reset() desde CLI normalmente no reinicia el pool web de PHP-FPM.
5. Purga las entradas afectadas del proxy/CDN cuando el origen ya sea correcto.
6. Vuelve a comprobar una solicitud anónima nueva y una personalizada, y después restaura los ajustes previstos.

var/cache/prod y var/cache/dev siguen activos para las cachés del framework y Smarty tras instalar un adaptador Redis separado. Las estructuras antiguas de 1.6 utilizan cache/smarty; el antiguo CacheFs utiliza cache/cachefs. Confirma tu versión exacta y la raíz antes de limpiar el sistema de archivos.

Prefiere la operación de vaciado de caché compatible. Si la recuperación exige una limpieza manual, aísla el sitio, conserva la estructura de directorios y los controles de acceso, ejecútala como el usuario de la aplicación y verifica la propiedad y la reconstrucción de la caché. No apliques un borrado recursivo sin ámbito definido desde un directorio de trabajo incierto.

Utiliza una invalidación del espacio de nombres que tenga en cuenta la integración. FLUSHDB borra todas las claves de la base de datos seleccionada; FLUSHALL borra todas las bases de datos de la instancia. Ninguno sustituye de forma segura a una purga limitada a una tienda en infraestructura compartida.

Si la caché devuelve precios, información personal o estados del pago incorrectos, evita la capa afectada hasta corregirla y verificarla. La configuración de caché en producción debe basarse en que los datos sean correctos y en la carga medida, en lugar de una regla incondicional de mantener todas las cachés activadas.

Mide el rendimiento y corrige el trabajo sin caché

Registra respuestas con caché vacía y poblada para las mismas URL, datos, idioma, moneda, dispositivo y estado de sesión. Incluye la concurrencia, la carga del origen y el estado de caché. Compara la navegación normal con las solicitudes del carrito y del pago. Mide pruebas repetidas en lugar de una sola solicitud.

TTFB mide la espera hasta que comienza la respuesta. Ayuda a diagnosticar la carga, pero no es una Core Web Vital. Las Core Web Vitals son LCP, INP y CLS. Expresa LCP e INP como tiempo, CLS como valor sin unidad y la puntuación de rendimiento de Lighthouse por separado. Mejores puntuaciones no garantizan posiciones en los buscadores.

Utiliza el perfilador clásico de PrestaShop para solicitudes normales del front office clásico, en un entorno de pruebas protegido. Utiliza el perfilado de Symfony para las solicitudes gestionadas a través de Symfony. El APM de producción, los registros de consultas lentas y las métricas del servidor web pueden ayudar sin exponer una página de depuración.

• Perfila hooks costosos, consultas repetidas y llamadas externas en directo. Guarda en caché solo datos cuya vigencia y ámbito puedas definir.
• Corrige los índices ausentes y las consultas costosas. Aplica una política de retención antes de limpiar registros, registros de correo o datos de conexiones.
• Utiliza ajustes compatibles de compilación de Smarty y borra las plantillas compiladas tras el despliegue cuando sea necesario.
• Activa y dimensiona OPcache para el entorno web. JIT es independiente y necesita una prueba de rendimiento de la aplicación. Si desactivas la validación de marcas de tiempo, reinicia OPcache de forma fiable durante el despliegue.
• Elige PHP según la matriz de compatibilidad de la versión exacta. PrestaShop 1.7.8 no admite oficialmente PHP 8.
• Ajusta MySQL según tu carga de trabajo y el presupuesto total de memoria. MySQL 8.0.30+ utiliza innodb_redo_log_capacity; MariaDB y versiones anteriores de MySQL son diferentes.
• Prueba la optimización de CSS/JavaScript, el CSS crítico, las imágenes adaptables y los scripts de terceros. Reserva las dimensiones de las imágenes y el espacio de la interfaz dinámica para limitar los desplazamientos del diseño.

Si la misma solicitud sigue siendo lenta tras activar una caché, analiza también el rendimiento de sus mecanismos: la construcción de claves, la serialización, los bloqueos y el cálculo repetido de hashes de recursos pueden añadir trabajo al recorrido de la solicitud. Compara ese coste con el trabajo ahorrado, también cuando no hay acierto.

Una caché puede reducir el trabajo repetido mientras los fallos de caché siguen siendo lentos. Consérvala cuando mejore de forma segura el rendimiento medido; elimínala o sustitúyela solo después de probar la carga y la experiencia del cliente resultantes.

Ensaya el cambio y documenta la recuperación

1. Registra los ajustes actuales, los tiempos de solicitud y el estado de caché de páginas representativas de inicio, categoría y producto, además de un carrito y un proceso de compra. Conserva los contextos exactos de prueba para poder repetir la comparación.
2. En staging, precarga las variantes públicas previstas. Utiliza perfiles de navegador separados para visitantes anónimos y clientes de distintos grupos o monedas. Comprueba el comportamiento del carrito, del inicio de sesión y de la cabecera personalizada, además del cuerpo de la página.
3. Ejecuta actualizaciones mediante el back office, promociones programadas y cada importación o integración que utilices. Contrasta la caché de la aplicación y cualquier copia de proxy/CDN con los datos actuales esperados.
4. Ensaya una purga y la navegación con caché fría con una concurrencia representativa. Después, deja Redis o el servicio de caché de páginas fuera de servicio en el entorno controlado y verifica los errores, la carga al recurrir a la alternativa y la recuperación por separado para cada capa activada.
5. Acuerda la ventana de producción, el criterio para revertir y la persona responsable. Aplica la configuración probada, invalida o precarga solo el ámbito previsto y comprueba la navegación real, las compras y la siguiente importación tras el cambio.

Revertir una caché de HTML descartable puede consistir en omitir esa capa y purgar sus copias. Revertir un gestor de sesiones requiere su propio procedimiento: el almacén anterior puede no contener las sesiones creadas después del cambio. Acuerda las expectativas de continuidad antes de cambiar de gestor y ensaya ambos sentidos. No sustituyas la base de datos de producción por la de staging para aplicar una configuración de caché.

Qué preguntar a tu desarrollador o agencia

• ¿Qué capa cambia, dónde detiene el procesamiento un acierto y qué sigue ejecutándose?
• ¿Qué contextos de solicitud se incluyen en las claves o se excluyen de la caché y dónde están las pruebas de que el contenido privado no puede entrar en el almacenamiento compartido?
• ¿Qué actualizaciones invalidan cada copia y quién se encarga de la invalidación de las importaciones del ERP y de las promociones programadas?
• ¿Qué ocurre durante una purga, una caída de caché o la reversión del gestor de sesiones, y puede el origen soportar la carga resultante?
• ¿Dónde se documentan para el personal los ajustes probados, el mapa de espacios de nombres, la supervisión, las instrucciones de purga delimitada y el procedimiento de recuperación?

Preguntas de los propietarios de tiendas

¿Qué caché debería comprar primero?

Elige en función de la solicitud lenta y del trabajo que repite. Pide una medición de referencia y una prueba reversible antes de comprar infraestructura u otro módulo. Si el diagnóstico no está claro, utiliza la guía de rendimiento para organizar las mediciones.

¿Redis sustituye a OPcache o a la base de datos?

No. OPcache reutiliza código PHP compilado; una integración de Redis reutiliza valores seleccionados o almacena sesiones. La base de datos sigue guardando los registros de tu tienda y las solicitudes sin caché siguen necesitando capacidad suficiente.

¿Por qué una visita repetida es rápida mientras un visitante nuevo sigue esperando?

La visita repetida puede encontrar datos en la caché del navegador, de páginas o de datos que la nueva solicitud no encuentra. Comprueba el estado real de la caché y el contexto del visitante, y compara después los resultados con caché fría y precargada. Tu propio navegador con caché precargada no demuestra cómo es la primera visita.

¿Debo dejar todas las cachés activadas durante una incidencia?

Omite la capa que sirve contenido incorrecto o privado e investígala después con una referencia sin caché. Comprueba la carga del origen mientras atiende más solicitudes y restablece la política probada cuando se resuelva la incidencia.

¿Puedo quitar la caché de página completa después de optimizar la tienda?

Prueba primero a omitirla en staging con una carga representativa. Consérvala o elimínala según la corrección de los datos, la capacidad en picos y la experiencia del cliente; una página sin caché más rápida por sí sola no demuestra que se pueda atender el tráfico máximo.