Cache Smarty vs OPcache vs Cache del Navegador en PrestaShop

Comprender las tres capas de cache en PrestaShop

PrestaShop utiliza multiples mecanismos de cache para entregar paginas rapidamente. Cada capa opera en un nivel diferente de la pila tecnologica, y comprender que hace cada una, cuando interviene y cuando necesitas limpiarla es esencial tanto para la optimizacion del rendimiento como para la resolucion de problemas. Las tres capas de cache mas importantes son la cache de plantillas Smarty, PHP OPcache y la cache del navegador. Trabajan juntas, pero resuelven problemas diferentes y requieren enfoques de gestion distintos.

Cuando un cliente visita tu tienda, la solicitud pasa por las tres capas en orden inverso. El navegador comprueba primero su cache local. Si tiene una copia actualizada del recurso, no contacta en absoluto con tu servidor. Si el navegador envia una solicitud, PHP la procesa. OPcache asegura que los archivos PHP se compilan una sola vez y se reutilizan desde la memoria en lugar de ser analizados de nuevo en cada solicitud. Finalmente, la cache Smarty asegura que el renderizado de plantillas, que implica el analisis de la sintaxis de plantillas y la ejecucion de la logica de plantillas, ocurra solo cuando es necesario en lugar de en cada carga de pagina.

Los problemas surgen cuando estas capas sirven contenido obsoleto. Modificas un archivo de plantilla, pero la pagina se ve igual. Actualizas un archivo PHP, pero el comportamiento anterior persiste. Modificas el CSS, pero el navegador sigue mostrando los estilos antiguos. Cada uno de estos sintomas apunta a una capa de cache diferente, y limpiar la incorrecta desperdicia tiempo sin resolver el problema.

Cache de plantillas Smarty - como funciona

Smarty es el motor de plantillas que PrestaShop utiliza para generar HTML. Cada archivo .tpl en tu tema y modulos pasa por Smarty antes de convertirse en HTML enviado al navegador. El cache de Smarty opera en dos fases distintas: compilacion y cache de salida.

Compilacion de plantillas

Cuando Smarty encuentra un archivo .tpl por primera vez, lo compila en un archivo PHP. Este archivo compilado se almacena en el directorio /var/cache/prod/smarty/compile/ (o /var/cache/dev/smarty/compile/ en modo debug). El archivo compilado contiene la logica de la plantilla traducida a PHP puro, que se ejecuta mucho mas rapido que analizar la sintaxis Smarty en cada solicitud.

Smarty verifica si la version compilada esta actualizada comparando marcas de tiempo. Si el archivo fuente .tpl es mas reciente que la version compilada, Smarty lo recompila automaticamente. Esto se controla mediante la configuracion compile_check. En produccion, puedes desactivar la verificacion de compilacion para el maximo rendimiento, lo que significa que Smarty asume que las plantillas compiladas siempre estan actualizadas y nunca verifica los archivos fuente.

Cache de salida de plantillas

Mas alla de la compilacion, Smarty tambien puede almacenar en cache la salida renderizada de las plantillas. Cuando el cache de salida esta activado, Smarty almacena la salida HTML final de una plantilla y la sirve directamente en solicitudes posteriores sin ejecutar ninguna logica de plantilla. Esto es mas agresivo que el cache de compilacion porque omite no solo el paso de analisis sino tambien el procesamiento de datos y la ejecucion de logica dentro de la plantilla.

El cache de salida en PrestaShop se gestiona por hook de modulo. Cada modulo puede declarar si su salida de hook es cacheable, y PrestaShop asigna claves de cache basadas en factores como el idioma actual, la tienda, la moneda y el grupo de clientes. Esto significa que un cliente frances y un cliente ingles obtienen versiones en cache separadas.

Configuracion del cache Smarty en PrestaShop

Configuras el cache Smarty en el back office en Parametros avanzados > Rendimiento. Las configuraciones relevantes son:

Compilacion de plantillas: Esto controla como Smarty maneja la compilacion de plantillas. Las opciones son tipicamente "Nunca recompilar" (mas rapido, siempre usa la version compilada), "Recompilar si se modifico" (verifica marcas de tiempo de archivos, buen equilibrio) y "Forzar compilacion" (recompila en cada solicitud, solo para desarrollo). En produccion, usa "Recompilar si se modifico" a menos que estes seguro de que tus plantillas nunca cambian entre despliegues, en cuyo caso "Nunca recompilar" proporciona una pequena ganancia adicional de rendimiento.

Cache: Esto activa o desactiva el cache de salida de Smarty. Cuando esta activado, Smarty almacena la salida HTML renderizada y la sirve sin volver a ejecutar la logica de la plantilla. Esto proporciona beneficios significativos de rendimiento para tiendas con plantillas complejas o muchos hooks de modulos. El tipo de cache puede configurarse como sistema de archivos (predeterminado) o un manejador de cache personalizado.

Optimizaciones multi-front: Esto habilita el cache a traves de multiples servidores front-end. Solo relevante para configuraciones en cluster.

Limpiar cache: Las opciones incluyen "Nunca limpiar archivos de cache", "Limpiar cache cada vez que algo se modifique" y estrategias de limpieza especificas. Para la mayoria de las tiendas, limpiar al modificar es la opcion correcta porque asegura que las actualizaciones sean visibles inmediatamente mientras se beneficia del cache entre cambios.

Limpiar el cache Smarty

Para limpiar el cache Smarty manualmente, puedes usar el boton "Limpiar cache" en la pagina de Rendimiento del back office. Esto elimina las plantillas compiladas y la salida en cache del directorio /var/cache/. Tambien puedes limpiarlo eliminando archivos directamente del servidor:

Eliminar plantillas compiladas: eliminar el contenido de var/cache/prod/smarty/compile/

Eliminar salida en cache: eliminar el contenido de var/cache/prod/smarty/cache/

Necesitas limpiar el cache Smarty cuando modificas archivos de plantilla .tpl (si la verificacion de compilacion esta desactivada), cuando instalas o actualizas un modulo que modifica plantillas, cuando cambias de tema o cuando modificas la configuracion relacionada con plantillas. Si modificas un archivo .tpl y el cambio no aparece en el front-end, el cache de compilacion Smarty es casi siempre la causa.

PHP OPcache - como funciona

PHP OPcache es un cache de bytecode integrado en PHP. Cuando PHP ejecuta un script, pasa por tres etapas: lexing (descomposicion del codigo fuente en tokens), parsing (construccion de un arbol sintactico abstracto) y compilacion (generacion de bytecode que el motor PHP ejecuta). OPcache almacena el bytecode compilado en memoria compartida para que las solicitudes posteriores del mismo script omitan completamente las etapas de lexing, parsing y compilacion.

Esto es diferente del cache Smarty. Smarty almacena en cache la salida del renderizado de plantillas (HTML). OPcache almacena en cache la salida de la compilacion PHP (bytecode). Operan en niveles completamente diferentes. Una plantilla Smarty que ha sido compilada en un archivo PHP por Smarty aun se beneficia de OPcache porque ese archivo PHP compilado se almacena como bytecode por OPcache.

Configuracion de OPcache para PrestaShop

OPcache se configura en tu archivo php.ini. Las configuraciones mas importantes para PrestaShop son:

opcache.enable=1 activa OPcache. Esto siempre deberia estar activado en produccion. La diferencia de rendimiento es significativa: la ejecucion de PHP se vuelve de 2 a 5 veces mas rapida con OPcache activado.

opcache.memory_consumption=256 establece la cantidad de memoria compartida (en megabytes) disponible para almacenar bytecode compilado. PrestaShop con varios modulos puede consumir facilmente 128 MB o mas. Si este valor es demasiado bajo, OPcache desaloja entradas antiguas para hacer espacio a las nuevas, lo que anula el proposito. Configuralo a 256 MB o mas para tiendas con muchos modulos. Puedes verificar el uso con opcache_get_status() para ver cuanta memoria se consume realmente.

opcache.max_accelerated_files=20000 establece el numero maximo de archivos PHP que pueden almacenarse en cache. El nucleo de PrestaShop mas los modulos pueden tener facilmente 10.000 o mas archivos PHP. El valor real utilizado por OPcache se redondea al siguiente numero primo de un conjunto predefinido, por lo que configurar 20000 resulta en un limite real de 20479. Verifica con opcache_get_status() que no estes alcanzando este limite.

opcache.validate_timestamps=1 indica a OPcache que verifique si los archivos fuente han cambiado. Cuando esta activado, OPcache verifica el tiempo de modificacion del archivo a intervalos definidos por revalidate_freq. En produccion, puedes configurar esto a 0 (desactivado) para el maximo rendimiento, pero entonces debes reiniciar PHP-FPM o llamar a opcache_reset() cada vez que despliegues codigo nuevo.

opcache.revalidate_freq=60 define con que frecuencia (en segundos) OPcache verifica los cambios en archivos cuando validate_timestamps esta activado. Un valor de 60 significa que OPcache verifica cada archivo como maximo una vez por minuto. Valores mas altos significan mejor rendimiento pero mayores retrasos antes de que los cambios de codigo tengan efecto. Para desarrollo activo, configuralo a 0 o 2. Para produccion, 60 es un buen equilibrio.

opcache.interned_strings_buffer=16 asigna memoria para cadenas internadas, que PHP utiliza para deduplicar cadenas identicas entre diferentes scripts. PrestaShop se beneficia de esto porque muchos modulos comparten los mismos nombres de clases, nombres de funciones y literales de cadena. Configuralo a 16 MB o mas.

opcache.save_comments=1 debe estar activado para PrestaShop. PrestaShop y algunas de sus dependencias utilizan anotaciones PHP DocBlock que se leen en tiempo de ejecucion. Si lo desactivas, ciertas funcionalidades dejan de funcionar.

OPcache y la separacion CLI vs Web

Un detalle importante sobre OPcache es que los entornos CLI (linea de comandos) y web (PHP-FPM o mod_php) mantienen pools de OPcache separados. Limpiar OPcache desde la linea de comandos (por ejemplo, ejecutando un script PHP que llama a opcache_reset() via CLI) no limpia el OPcache web. Para limpiar el OPcache web, debes reiniciar el servicio PHP-FPM o ejecutar opcache_reset() a traves de una solicitud web.

Esta distincion importa en los flujos de trabajo de despliegue. Si despliegas codigo nuevo y limpias OPcache mediante un comando CLI, tu sitio web continua sirviendo el bytecode antiguo hasta que el OPcache web tambien se limpie. Muchas herramientas de despliegue manejan esto llamando a un endpoint URL especial que dispara opcache_reset(), o reiniciando PHP-FPM como parte del proceso de despliegue.

Cuando limpiar OPcache

Necesitas limpiar OPcache cada vez que modificas, subes o reemplazas archivos PHP en tu servidor. Esto incluye desplegar una nueva version de PrestaShop, instalar o actualizar modulos, editar archivos PHP directamente en el servidor y actualizar dependencias de Composer. Si modificas un archivo PHP y el comportamiento anterior persiste a pesar de que el archivo esta claramente modificado en el disco, OPcache esta sirviendo el bytecode antiguo. Reiniciar PHP-FPM es la forma mas confiable de limpiarlo.

Cache del navegador - como funciona

La cache del navegador es la capa final, y opera completamente en el lado del cliente. Cuando un navegador descarga un recurso (archivo CSS, archivo JavaScript, imagen, fuente o incluso una pagina HTML), puede almacenar una copia local y reutilizarla para solicitudes posteriores. Esto elimina completamente los viajes de ida y vuelta por la red para los recursos en cache, lo cual es la mayor mejora de rendimiento posible porque ninguna optimizacion del lado del servidor puede superar una latencia de red cero.

La cache del navegador se controla mediante los encabezados de respuesta HTTP que tu servidor envia con cada recurso. Los encabezados mas importantes son Cache-Control, Expires, ETag y Last-Modified.

Encabezado Cache-Control

El encabezado Cache-Control es el mecanismo principal para controlar la cache del navegador. Soporta varias directivas:

max-age=31536000 indica al navegador que almacene el recurso en cache durante un maximo de 31.536.000 segundos (un ano). Durante este periodo, el navegador usa su copia local sin contactar al servidor. Esto es ideal para recursos estaticos como CSS, JavaScript e imagenes que incluyen un identificador de version en su URL (como un hash o una cadena de consulta).

no-cache no significa "no almacenar en cache". Significa que el navegador puede almacenar el recurso en cache pero debe validarlo con el servidor antes de usar la copia en cache. El servidor responde con un estado 304 (Not Modified), indicando que la version en cache sigue siendo valida, o un 200 con el nuevo contenido.

no-store realmente previene el almacenamiento en cache. El navegador debe descargar el recurso nuevo cada vez. Usa esto para contenido sensible que nunca deberia almacenarse localmente.

public indica que la respuesta puede ser almacenada en cache por cualquier cache, incluyendo CDNs y servidores proxy. Usa esto para recursos estaticos.

private indica que la respuesta es especifica para un solo usuario y no deberia ser almacenada en cache por caches compartidos como CDNs. Usa esto para paginas que contienen contenido especifico del usuario, como la pagina de cuenta del cliente o el carrito.

Encabezado ETag

Un ETag (Entity Tag) es un identificador unico para una version especifica de un recurso. El servidor lo genera (tipicamente un hash del contenido del archivo) y lo envia con la respuesta. Cuando el navegador necesita validar su copia en cache, envia el ETag de vuelta al servidor en un encabezado If-None-Match. El servidor compara los ETags y devuelve 304 (usa tu version en cache) o 200 (aqui esta la nueva version).

Los ETags son utiles cuando quieres cache del navegador con validacion. El navegador aun hace una solicitud al servidor, pero si el contenido no ha cambiado, el servidor envia una pequena respuesta 304 en lugar del recurso completo. Esto ahorra ancho de banda mientras asegura la frescura.

Last-Modified e If-Modified-Since

Estos encabezados funcionan de manera similar a los ETags pero usan marcas de tiempo en lugar de hashes de contenido. El servidor envia la marca de tiempo Last-Modified con el recurso, y el navegador la envia de vuelta como If-Modified-Since durante la validacion. El servidor verifica si el archivo ha sido modificado desde ese momento y devuelve 304 o 200 segun corresponda.

Los ETags son generalmente preferidos sobre Last-Modified porque se basan en el contenido en lugar del tiempo, lo que evita problemas de sincronizacion de relojes y es mas preciso. Sin embargo, la mayoria de los servidores envian ambos, y los navegadores usan el que este disponible.

Configuracion de cache del navegador para PrestaShop

Los recursos estaticos de PrestaShop (CSS, JavaScript, imagenes) deberian ser almacenados en cache agresivamente por los navegadores. El enfoque estandar es configurar tu servidor web para agregar encabezados Cache-Control apropiados a las respuestas de archivos estaticos.

Para Apache, usas los modulos mod_expires y mod_headers en tu archivo .htaccess. El archivo .htaccess predeterminado de PrestaShop incluye algunas reglas de cache, pero puedes querer extenderlas. Una configuracion tipica establece max-age=31536000 para imagenes, fuentes, CSS y archivos JavaScript, mientras que las respuestas HTML reciben no-cache para asegurar contenido fresco.

Para Nginx, agregas directivas expires en tus bloques location para archivos estaticos. Por ejemplo: location ~* \\.(css|js|jpg|png|gif|ico|woff2)$ { expires 1y; add_header Cache-Control "public, immutable"; } almacena recursos estaticos en cache por un ano y los marca como inmutables (indicando al navegador que ni siquiera los valide).

Cache busting en PrestaShop

Si configuras tiempos de cache largos para archivos CSS y JavaScript, como obtienen los navegadores versiones actualizadas cuando despliegas cambios? Aqui es donde entra el cache busting. PrestaShop maneja esto de manera diferente dependiendo de si CCC (Combine, Compress, Cache) esta activado.

Con CCC activado, PrestaShop combina archivos CSS y JavaScript en paquetes y genera nombres de archivo que incluyen un hash del contenido. Cuando el contenido cambia, el nombre del archivo cambia, y los navegadores descargan el nuevo archivo porque nunca han visto esa URL antes. Este es el enfoque de cache busting mas confiable.

Sin CCC, PrestaShop sirve archivos CSS y JavaScript individuales en sus URLs originales. Algunos temas y modulos agregan una cadena de consulta de version (como ?v=1.2.3) a estas URLs, que cambia cuando el modulo se actualiza. Los navegadores tratan la URL con una cadena de consulta diferente como un recurso diferente y lo descargan nuevo.

Las imagenes son mas complicadas porque sus URLs tipicamente no cambian a menos que la imagen misma sea reemplazada. Si reemplazas una imagen con una nueva en la misma URL, los navegadores que tienen la version antigua en cache continuaran mostrandola hasta que el cache expire. En este caso, necesitas cambiar el nombre del archivo de imagen o limpiar las caches de los navegadores (lo cual no puedes hacer para tus visitantes). La solucion practica es usar URLs de imagenes con version o esperar a que el cache expire naturalmente.

Como interactuan las tres capas

Comprender como interactuan estas tres capas de cache es crucial para una resolucion de problemas efectiva. Aqui esta el ciclo de vida de una solicitud tipica:

Un cliente visita una pagina de producto. El navegador comprueba su cache para el HTML de esa pagina. Como el HTML tipicamente se sirve con no-cache, el navegador envia una solicitud al servidor (posiblemente con un encabezado If-Modified-Since o If-None-Match para validacion).

El servidor web recibe la solicitud y la pasa a PHP. El OPcache de PHP-FPM tiene el bytecode para index.php de PrestaShop, el dispatcher, los controladores y todos los archivos de modulos almacenados en cache en memoria compartida. PHP ejecuta el bytecode sin recompilar ningun archivo fuente.

El controlador de PrestaShop llama a Smarty para renderizar la plantilla. Smarty comprueba su cache para una version compilada de la plantilla. Si el cache de salida esta activado y existe una salida en cache valida para esta combinacion de idioma, grupo de clientes y otras claves de cache, Smarty devuelve el HTML en cache directamente. Si no, Smarty ejecuta la plantilla compilada (que OPcache tambien ha almacenado en cache como bytecode ya que las plantillas Smarty compiladas son archivos PHP), genera el HTML, lo almacena en el cache de salida y lo devuelve.

PHP envia la respuesta HTML al navegador, junto con encabezados HTTP que controlan la cache del navegador. El navegador renderiza el HTML y solicita todos los archivos CSS, JavaScript e imagenes referenciados en el. Para cada uno de estos recursos, el navegador comprueba su cache local. Si tiene una copia fresca (basada en el max-age de Cache-Control), usa la copia local sin contactar al servidor. Si la copia en cache necesita validacion, envia una solicitud condicional con encabezados ETag o If-Modified-Since.

Resolucion de problemas con contenido obsoleto

Cuando los cambios que realizas no aparecen en el front-end, necesitas identificar que capa de cache es responsable. Aqui hay un enfoque sistematico:

Paso 1: Verificar el navegador

Abre la pagina en una ventana de navegacion privada o de incognito, o realiza una actualizacion forzada (Ctrl+Shift+R en la mayoria de los navegadores). Si el cambio aparece en incognito pero no en una ventana normal, la cache del navegador es la causa. Limpia la cache del navegador o espera a que expire.

Para cambios de CSS y JavaScript especificamente, verifica la pestana de red en los DevTools del navegador. Mira los encabezados de respuesta del archivo que modificaste. Si la respuesta muestra un 304 (Not Modified) y el contenido es antiguo, el archivo del lado del servidor puede no haber cambiado realmente (verifica OPcache). Si el navegador ni siquiera esta haciendo una solicitud para el archivo (muestra "from disk cache" o "from memory cache"), el max-age de Cache-Control no ha expirado.

Paso 2: Verificar el cache Smarty

Si el cambio no aparece ni siquiera en incognito, el problema es del lado del servidor. Para cambios de plantillas, limpia el cache Smarty desde el back office (Parametros avanzados > Rendimiento > Limpiar cache) o elimina el contenido de var/cache/prod/smarty/. Recarga la pagina y verifica si el cambio aparece.

Paso 3: Verificar OPcache

Si limpiar el cache Smarty no ayuda y el cambio involucra un archivo PHP (no una plantilla), OPcache probablemente esta sirviendo bytecode antiguo. Reinicia PHP-FPM o llama a opcache_reset() a traves de una solicitud web. En alojamiento compartido donde no puedes reiniciar PHP-FPM, tu panel de control de hosting puede tener una opcion para limpiar OPcache, o puedes crear un pequeno archivo PHP que llame a opcache_reset() y acceder a el a traves de tu navegador.

Paso 4: Verificar otros caches

PrestaShop tiene mecanismos de cache adicionales mas alla de estas tres capas. El cache de Symfony (en PrestaShop 1.7 y 8.x) almacena contenedores de servicios Symfony compilados, definiciones de rutas y otros datos del framework. Limpialo eliminando los directorios var/cache/prod/ y var/cache/dev/. Si usas un proxy inverso como Varnish o un CDN como Cloudflare, estos agregan otra capa de cache que debe limpiarse por separado.

Configuracion optima para produccion

Para una tienda PrestaShop en produccion, la configuracion optima de cache equilibra rendimiento y mantenibilidad:

Smarty: Configura la compilacion de plantillas en "Recompilar si se modifico". Activa el cache de salida. Configura la limpieza de cache en "Limpiar al modificar". Esto da un fuerte rendimiento de cache mientras asegura que los cambios del back office (como editar paginas CMS o cambiar la configuracion de modulos) tengan efecto inmediatamente.

OPcache: Activa con al menos 256 MB de memoria, 20000 max accelerated files, validate_timestamps activado con revalidate_freq de 60 segundos. Esta configuracion significa que los cambios de codigo tardan hasta 60 segundos en tener efecto, lo cual es aceptable para produccion. Si despliegas cambios de codigo con poca frecuencia y quieres el maximo rendimiento, desactiva validate_timestamps y reinicia PHP-FPM despues de cada despliegue.

Cache del navegador: Configura Cache-Control con valores max-age largos (al menos un mes, idealmente un ano) para recursos estaticos (CSS, JavaScript, imagenes, fuentes). Usa no-cache para respuestas HTML para que las paginas siempre sean validadas. Activa CCC en PrestaShop para obtener nombres de archivo con hash de contenido para archivos CSS y JavaScript combinados, lo cual proporciona cache busting automatico cuando los recursos cambian.

Con esta configuracion, tu tienda se beneficia de las tres capas de cache trabajando juntas. Los recursos estaticos se sirven desde la cache del navegador sin ningun contacto con el servidor. Los archivos PHP se ejecutan desde bytecode en cache sin recompilacion. Y el renderizado de plantillas se almacena en cache para que la logica Smarty se ejecute solo cuando el contenido cambia. El resultado es una tienda que carga rapidamente para visitantes recurrentes y maneja alto trafico eficientemente del lado del servidor.

Cuando limpiar cada capa de cache

Para evitar tanto contenido obsoleto como limpieza innecesaria de cache, sigue estas directrices:

Limpia el cache Smarty cuando edites archivos .tpl, cambies posiciones o hooks de modulos, instales o actualices modulos que modifican plantillas, o cambies configuraciones relacionadas con el tema. No necesitas limpiar el cache Smarty cuando cambias archivos PHP o cuando actualizas archivos CSS o JavaScript.

Limpia OPcache cuando edites archivos PHP, instales o actualices modulos, actualices el nucleo de PrestaShop, o ejecutes Composer para actualizar dependencias. No necesitas limpiar OPcache para cambios de plantillas o CSS.

Limpia la cache del navegador cuando necesites ver cambios de CSS, JavaScript o imagenes inmediatamente durante el desarrollo. Para produccion, depende del cache busting (URLs con version, nombres de archivo con hash CCC) en lugar de pedir a los usuarios que limpien sus caches. No puedes controlar las caches de los navegadores de tus visitantes, por lo que tu proceso de despliegue debe tener esto en cuenta usando tecnicas adecuadas de cache busting.

Una secuencia completa de limpieza de cache despues de un despliegue importante seria: limpiar los directorios de compilacion y cache Smarty, reiniciar PHP-FPM para limpiar OPcache, purgar la cache de tu CDN o proxy inverso si aplica, y verificar en una ventana de navegacion privada. Para cambios menores (como editar una sola plantilla), limpiar solo la capa relevante es suficiente y mas rapido.