Consejos PrestaShop FAQ

Por qué las migraciones son peligrosas para el SEO

Migrar una tienda PrestaShop es una de las operaciones de mayor riesgo que puedes realizar desde la perspectiva del SEO. Ya sea que estés trasladándote a un nuevo servidor, cambiando de dominio, actualizando de PrestaShop 1.6 a 1.7 u 8.x, o reestructurando tus patrones de URL, cada migración conlleva el potencial de destruir meses o años de posicionamiento acumulado en los motores de búsqueda.

La razón es sencilla. Google y otros motores de búsqueda han indexado tus URLs actuales, les han asignado autoridad y han construido un mapa de cómo está estructurado tu sitio. Cuando cambias cualquier aspecto de esas URLs, su estructura o su accesibilidad, los motores de búsqueda deben reevaluar todo. Si la transición se maneja de forma deficiente, Google interpreta el cambio como si tu contenido antiguo hubiera desaparecido y apareciera contenido nuevo sin historial. El resultado es una caída en el posicionamiento que puede tardar meses en recuperarse, si es que la recuperación completa llega a producirse.

La buena noticia es que las migraciones pueden realizarse de forma segura. Con una planificación adecuada, una implementación correcta de redirecciones y un monitoreo cuidadoso, puedes preservar la gran mayoría de tu posicionamiento durante una migración. Esta guía recorre cada paso del proceso, desde la auditoría SEO inicial hasta el monitoreo posterior a la migración.

Auditoría SEO previa a la migración

Antes de tocar un solo archivo de configuración, necesitas tener una imagen completa de tu estado SEO actual. Esta auditoría cumple dos propósitos: te ofrece una línea base con la cual comparar después de la migración, e identifica las páginas más valiosas que deben manejarse con absoluto cuidado.

Rastrea tu sitio actual

Utiliza una herramienta de rastreo como Screaming Frog, Sitebulb o la versión gratuita de Screaming Frog (limitada a 500 URLs) para rastrear tu sitio completo. Exporta la lista completa de URLs, sus códigos de estado HTTP, títulos de página, meta descripciones, etiquetas canónicas y estructura de enlaces internos. Guarda estos datos. Los necesitarás después de la migración para verificar que nada se haya perdido.

Exporta los datos de Google Search Console

Google Search Console es tu fuente más fiable de información sobre qué páginas realmente reciben tráfico orgánico. Ve a Rendimiento > Resultados de búsqueda y exporta los datos de los últimos 16 meses (el máximo disponible). Presta especial atención a:

Páginas con más clics e impresiones. Estas son tus páginas de mayor valor. Un fallo en la redirección de cualquiera de estas páginas tendrá un impacto inmediato y visible en el tráfico.

Consultas que generan más tráfico. Después de la migración, monitorearás estas consultas para verificar que el posicionamiento sea estable.

Páginas con muchas impresiones pero pocos clics. Estas páginas están a punto de posicionarse bien y son especialmente sensibles a las interrupciones.

Documenta tu estructura de URLs

PrestaShop genera URLs basándose en la configuración de URLs amigables, la estructura de categorías y las configuraciones de productos. Documenta los patrones. Por ejemplo, ¿tus URLs de productos están estructuradas como /categoria/nombre-producto.html o simplemente /nombre-producto.html? ¿Tus URLs de categorías incluyen IDs como /3-nombre-categoria? ¿Las páginas CMS están en /content/5-nombre-pagina?

Comprender estos patrones es esencial porque tu nueva instalación puede generar estructuras de URL diferentes por defecto, y cada URL modificada necesita una redirección.

Verifica los backlinks existentes

Utiliza una herramienta de verificación de backlinks como Ahrefs, Moz o el informe de Enlaces de Google Search Console para identificar qué sitios externos enlazan a tu tienda y a qué páginas específicas enlazan. Estas páginas con backlinks son las que tienen mayor autoridad, y perderlas significa perder el valor SEO de cada enlace externo que apunta hacia ellas.

Creación del mapeo de URLs

El mapeo de URLs es el documento más crítico de toda tu migración. Es una hoja de cálculo que asocia cada URL antigua con su correspondiente URL nueva. Cada URL que haya recibido tráfico, tenga backlinks o aparezca en tu sitemap debe tener un mapeo.

Generación de la lista de URLs

Combina las URLs de tu rastreo del sitio, la exportación de Google Search Console, el informe de backlinks y el sitemap XML. Elimina duplicados y ordena por importancia (tráfico y valor de backlinks). Tu lista final debe incluir:

Todas las URLs de productos. En PrestaShop, estas se generan a partir del nombre del producto y tu configuración de URLs amigables. Si estás cambiando la estructura de URLs (por ejemplo, eliminando las extensiones .html o cambiando el formato de la ruta de categorías), cada URL de producto cambia.

Todas las URLs de categorías. Las URLs de categorías en PrestaShop a menudo incluyen el ID de la categoría, y este ID puede ser diferente en la nueva instalación si reimportas las categorías.

Todas las URLs de páginas CMS. Estas incluyen tu página "Sobre nosotros", términos y condiciones, política de privacidad y cualquier otra página de contenido.

Todas las URLs de fabricantes y proveedores, si utilizas estas funcionalidades.

URLs paginadas para categorías con muchos productos.

Creación del mapeo

Para cada URL antigua, determina cuál será la URL nueva correspondiente. Si la estructura de URLs no cambia (mismo dominio, misma configuración de URLs amigables, mismos IDs), muchas URLs se mapearán a sí mismas y no será necesaria ninguna redirección. Pero verifica esto. Incluso cambios pequeños como una profundidad diferente en el árbol de categorías o una diferencia en la barra diagonal final crean nuevas URLs que necesitan redirecciones.

Si estás cambiando patrones de URL de forma sistemática (por ejemplo, eliminando todas las extensiones .html), puedes usar redirecciones basadas en expresiones regulares en lugar de mapear cada URL individualmente. Pero siempre verifica la expresión regular contra tu lista real de URLs antes de publicar los cambios.

Implementación de redirecciones 301

Una redirección 301 indica a los motores de búsqueda que una página se ha trasladado permanentemente a una nueva ubicación. Transfiere la gran mayoría del valor SEO (link equity) de la URL antigua a la nueva. Este es el mecanismo que preserva tu posicionamiento durante una migración.

Dónde colocar las redirecciones

Para PrestaShop en Apache, las redirecciones van en el archivo .htaccess en tu directorio raíz. Coloca tus reglas de redirección antes de las reglas de reescritura de PrestaShop (antes de la sección que comienza con # Dispatcher).

Para PrestaShop en Nginx, las redirecciones van en la configuración del bloque de servidor. Es posible que necesites recargar Nginx después de los cambios: sudo nginx -t && sudo systemctl reload nginx.

Sintaxis de las reglas de redirección

Para Apache .htaccess, las redirecciones individuales usan este formato:

Redirect 301 /ruta-antigua/producto-antiguo.html https://www.nuevodominio.com/nueva-ruta/nuevo-producto

Para redirecciones basadas en patrones usando mod_rewrite:

RewriteEngine On RewriteRule ^categoria-antigua/(.*)$ /nueva-categoria/$1 [R=301,L]

Para Nginx, redirecciones individuales:

location = /ruta-antigua/producto-antiguo.html { return 301 https://www.nuevodominio.com/nueva-ruta/nuevo-producto; }

Manejo de grandes cantidades de redirecciones

Las tiendas PrestaShop con miles de productos necesitan un enfoque más escalable que escribir reglas de redirección individuales. Las opciones incluyen usar un RewriteMap en Apache (que lee desde un archivo de texto o base de datos), usar un módulo de PrestaShop diseñado para gestionar redirecciones, o implementar redirecciones a nivel de aplicación mediante un módulo personalizado que intercepte errores 404 y consulte una tabla de redirecciones.

El enfoque a nivel de aplicación tiene la ventaja de ser gestionable desde el back office, pero añade una pequeña sobrecarga de rendimiento a cada solicitud 404. El enfoque mediante .htaccess es más rápido pero más difícil de gestionar a gran escala.

Actualización del sitemap XML

Tu sitemap XML indica a los motores de búsqueda qué URLs existen en tu sitio y deben ser rastreadas. Después de una migración, el sitemap debe reflejar la nueva estructura de URLs de forma inmediata.

Generación de un nuevo sitemap

PrestaShop incluye generación de sitemap integrada, pero muchos propietarios de tiendas utilizan un módulo como Google Sitemap o un módulo SEO de terceros para tener más control. Después de la migración, genera un sitemap nuevo que incluya todas las URLs nuevas. Verifica que el sitemap no contenga URLs antiguas que ahora redirigen.

Envío del sitemap actualizado

Ve a Google Search Console, navega a Sitemaps y envía la URL de tu nuevo sitemap (normalmente https://www.tudominio.com/1_index_sitemap.xml para PrestaShop). Si la URL del sitemap en sí ha cambiado, elimina la entrada del sitemap antiguo y añade la nueva.

Un envío de sitemap nuevo indica a Google que la estructura de tu sitio ha cambiado y fomenta un rastreo más rápido de las nuevas URLs. Combinado con redirecciones 301 correctas desde las URLs antiguas, esto proporciona a Google una imagen clara de lo que ha ocurrido.

Pasos de migración en Google Search Console

Migración con el mismo dominio (cambio de servidor o actualización)

Si tu dominio no cambia, no se requiere ninguna acción especial en Search Console más allá de enviar el sitemap actualizado y monitorear. Google descubrirá los cambios mediante el rastreo normal.

Migración con cambio de dominio

Si estás cambiando de dominio, utiliza la herramienta de Cambio de dirección en Google Search Console. Esto requiere que tanto el dominio antiguo como el nuevo estén verificados en Search Console. Los pasos son:

Primero, configura y verifica el nuevo dominio en Google Search Console. Segundo, asegúrate de que todas las redirecciones 301 estén implementadas desde el dominio antiguo al nuevo. Tercero, ve a la propiedad del dominio antiguo en Search Console y usa Configuración > Cambio de dirección. Cuarto, sigue las instrucciones para especificar el nuevo dominio.

Esto indica explícitamente a Google que tu sitio se ha trasladado, lo que acelera significativamente la transición. Sin este paso, Google finalmente lo descubre a través de las redirecciones 301, pero tarda más tiempo.

Consideraciones sobre la propagación DNS

Si tu migración implica cambiar registros DNS (apuntar tu dominio a un nuevo servidor), ten en cuenta que la propagación DNS no es instantánea. Los diferentes resolutores DNS alrededor del mundo se actualizan en momentos diferentes, y la propagación completa puede tardar de 24 a 72 horas.

Minimización del tiempo de inactividad

Antes de la migración, reduce el TTL (Time To Live) de tu DNS a un valor bajo como 300 segundos (5 minutos). Haz esto al menos 48 horas antes de la migración real para que el TTL alto anterior expire en todos los servidores. Cuando cambies los registros DNS, los resolutores verificarán actualizaciones cada 5 minutos en lugar de cada varias horas.

Una vez que la migración esté completa y verificada, aumenta el TTL de nuevo a un valor normal como 3600 (1 hora) o superior para reducir la carga de consultas DNS.

Ejecución de ambos servidores en paralelo

Durante la ventana de propagación, algunos visitantes llegarán al servidor antiguo y otros al nuevo. Mantén el servidor antiguo funcionando con una copia del sitio (o al menos con las reglas de redirección implementadas) hasta que la propagación se complete. Apagar el servidor antiguo de inmediato causa tiempo de inactividad para los visitantes cuyo DNS aún no se ha actualizado.

Monitoreo de posicionamiento después de la migración

El trabajo no termina cuando la migración se pone en producción. El monitoreo posterior a la migración es esencial para detectar problemas antes de que causen daños duraderos.

Verificaciones inmediatas (Día 1)

Verifica que todas las páginas críticas se carguen correctamente en el nuevo sitio. Prueba cada redirección de tu mapeo de URLs para confirmar que funciona. Revisa Google Search Console en busca de nuevos errores de rastreo. Ejecuta un nuevo rastreo del sitio y compáralo con los datos de rastreo previos a la migración.

Monitoreo de la primera semana

Revisa Google Search Console diariamente en busca de errores de rastreo, problemas de indexación y cualquier caída de tráfico. Examina el informe de Cobertura en busca de páginas que ya no están indexadas o que devolvieron errores. Monitorea el posicionamiento de tus palabras clave principales utilizando una herramienta de seguimiento de rankings. Cierta fluctuación es normal durante la primera semana, pero caídas importantes en palabras clave relevantes indican un problema de redirección.

Monitoreo del primer mes

Compara el tráfico orgánico en Google Analytics o tu plataforma de analítica con el mismo período antes de la migración. Verifica que todas las páginas importantes estén siendo reindexadas buscando site:tudominio.com/pagina-especifica en Google. Comprueba que las URLs antiguas estén siendo eliminadas del índice (deberían redirigir a las nuevas URLs, y Google debería eventualmente reemplazarlas en su índice).

Evaluación a los tres meses

A los tres meses de la migración, tu tráfico orgánico debería haberse estabilizado en niveles cercanos o iguales a los previos a la migración. Si no es así, investiga qué páginas o consultas específicas han perdido posicionamiento y verifica sus cadenas de redirección, la calidad del contenido y la salud técnica.

Errores comunes en la migración

Usar redirecciones 302 en lugar de 301

Una redirección 302 indica a los motores de búsqueda que el traslado es temporal. Los motores de búsqueda no transfieren el link equity completo a través de redirecciones 302. Utiliza siempre 301 para migraciones permanentes. Este es el error más común y más dañino.

Olvidar redirigir de non-www a www (o viceversa)

Si tu sitio antiguo usaba www.ejemplo.com y tu nuevo sitio usa ejemplo.com (o al revés), necesitas redirecciones tanto para el cambio de estructura de URL como para el cambio www/non-www. Olvidar uno de estos crea una situación en la que algunas URLs antiguas devuelven errores 404.

No actualizar los enlaces internos

Después de la migración, tus enlaces internos deben apuntar directamente a las nuevas URLs, no a las URLs antiguas que redirigen. Aunque las redirecciones preservan el valor SEO para los enlaces externos, los enlaces internos que redirigen crean cadenas de redirección innecesarias y ralentizan el rastreo.

Perder el HTTPS

Si tu sitio antiguo usaba HTTPS y tu nuevo sitio no (o viceversa), Google los trata como URLs diferentes. Asegúrate de que tu certificado SSL esté correctamente configurado en el nuevo servidor antes de publicar, y que todas las redirecciones usen el protocolo correcto.

Cambiar múltiples cosas a la vez

Si cambias tu dominio, tu estructura de URLs, tu contenido y el diseño de tu sitio todo al mismo tiempo, se vuelve imposible diagnosticar qué causó cualquier caída en el posicionamiento. Cambia la menor cantidad de cosas posible durante la migración en sí. Las actualizaciones de contenido y diseño pueden realizarse después de que el posicionamiento se haya estabilizado.

Cronograma de migración

Una migración de PrestaShop bien planificada sigue este cronograma:

4 semanas antes: Completa la auditoría SEO, exporta todos los datos, comienza el mapeo de URLs. Reduce el TTL de DNS si vas a cambiar de servidor.

2 semanas antes: Finaliza el mapeo de URLs, escribe todas las reglas de redirección, configura el nuevo sitio en un entorno de staging y prueba exhaustivamente.

1 semana antes: Prueba todas las redirecciones en staging. Verifica que el nuevo sitemap XML sea correcto. Ejecuta un rastreo completo del sitio en staging y compáralo con los datos de rastreo del sitio antiguo.

Día de la migración: Despliega el nuevo sitio, activa las redirecciones, actualiza el DNS si es necesario, envía el nuevo sitemap a Search Console, usa el Cambio de dirección si cambias de dominio.

Semana 1: Monitorea Search Console diariamente, corrige cualquier error de rastreo de inmediato, verifica el funcionamiento de las redirecciones.

Mes 1: Revisiones semanales de Search Console, compara el tráfico con la línea base, verifica el progreso de la indexación.

Mes 3: Evaluación completa contra la línea base previa a la migración. Aborda cualquier problema pendiente.

Resumen

Una migración exitosa de PrestaShop que preserve el posicionamiento en Google requiere tres cosas: preparación exhaustiva, implementación correcta de redirecciones y monitoreo diligente posterior a la migración. La auditoría previa te proporciona una línea base e identifica tus páginas más valiosas. El mapeo de URLs y las redirecciones 301 aseguran que el valor SEO de cada página se transfiera a la nueva ubicación. La actualización del sitemap y la configuración de Search Console ayudan a Google a descubrir y procesar los cambios rápidamente. Y el monitoreo posterior a la migración detecta problemas antes de que se conviertan en permanentes. Omite cualquiera de estos pasos y arriesgas perder posicionamiento que tardó meses o años en construir. Sigue todos ellos y tu migración se convertirá en una transición controlada en lugar de un desastre para el SEO.

Leer respuesta completa

Entendiendo las redirecciones y por qué la 301 es la única opción correcta

Cuando migras una tienda PrestaShop, las URLs cambian. Los productos que vivían en una dirección ahora viven en otra. Las categorías que tenían un slug ahora tienen uno diferente. Sin redirecciones, cada URL antigua se convierte en un callejón sin salida que devuelve un error 404 tanto a los visitantes como a los motores de búsqueda. El efecto acumulativo es devastador: tráfico perdido, posicionamiento perdido y ventas perdidas.

Una redirección es una instrucción de tu servidor que indica a los navegadores y rastreadores de motores de búsqueda que una página se ha trasladado. Cuando un visitante o Googlebot solicita la URL antigua, el servidor responde con la nueva ubicación y el cliente la sigue automáticamente. Pero no todas las redirecciones son iguales, y usar el tipo incorrecto puede socavar toda tu migración.

301 vs 302: Una distinción crítica

Una redirección 301 señala un traslado permanente. Indica a los motores de búsqueda que transfieran el link equity acumulado (el valor SEO construido a través de backlinks, calidad del contenido e interacción de los usuarios) de la URL antigua a la nueva. Con el tiempo, Google reemplaza la URL antigua en su índice por la nueva. Esto es lo que deseas después de una migración.

Una redirección 302 señala un traslado temporal. Indica a los motores de búsqueda que la URL antigua volverá eventualmente, por lo que deben mantener la URL antigua en el índice y no transferir link equity. Usar redirecciones 302 después de una migración permanente significa que Google sigue intentando indexar tus URLs antiguas, tus nuevas URLs tienen dificultades para ganar autoridad y pierdes posicionamiento innecesariamente.

También existe la redirección 307, que es el equivalente HTTP/1.1 de la 302, y la redirección 308, que es el equivalente HTTP/1.1 de la 301. Para propósitos de SEO en PrestaShop, la 301 es la opción estándar y universalmente soportada.

La regla es sencilla: si la página se ha trasladado permanentemente, usa 301. Después de una migración, la página se ha trasladado permanentemente. Siempre usa 301.

Configuración de redirecciones en .htaccess (Apache)

La mayoría de las instalaciones de PrestaShop funcionan con Apache, y el archivo .htaccess es donde configuras las redirecciones. Este archivo se encuentra en el directorio raíz de tu PrestaShop junto a index.php.

La ubicación importa

El archivo .htaccess de PrestaShop contiene reglas de reescritura que gestionan las URLs amigables, fuerzan HTTPS y dirigen las solicitudes a los controladores correctos. Tus reglas de redirección deben colocarse antes de las reglas de reescritura de PrestaShop. Si las colocas después, las reglas de PrestaShop pueden interceptar la solicitud primero y tus redirecciones nunca se ejecutarán.

Busca la línea de comentario que dice # Dispatcher o el bloque que comienza con RewriteRule ^api. Tus redirecciones personalizadas van por encima de esta sección pero después de RewriteEngine On.

Redirecciones de páginas individuales

La forma más sencilla de redirección mapea una URL antigua específica a una URL nueva específica:

Redirect 301 /categoria-antigua/producto-antiguo.html https://www.ejemplo.com/nueva-categoria/nuevo-producto

La directiva Redirect es parte del módulo mod_alias de Apache. El primer argumento es el código de estado HTTP (301), el segundo es la ruta antigua (relativa a la raíz del documento) y el tercero es la URL nueva completa.

Detalles importantes: la ruta antigua debe comenzar con una barra diagonal y no debe incluir el nombre de dominio. La URL nueva debe ser una URL completa que incluya el protocolo y el dominio. La ruta antigua se compara de forma exacta, incluyendo barras diagonales finales y extensiones de archivo.

Redirecciones basadas en patrones con RewriteRule

Cuando muchas URLs siguen un cambio de patrón predecible, las redirecciones individuales se vuelven poco prácticas. El módulo mod_rewrite de Apache te permite escribir reglas basadas en patrones usando expresiones regulares:

RewriteEngine On RewriteRule ^categoria-antigua/(.*)$ /nueva-categoria/$1 [R=301,L]

Esta regla captura todo lo que hay después de categoria-antigua/ y lo añade a nueva-categoria/. El $1 es una referencia inversa al primer grupo capturado (la parte entre paréntesis). Los indicadores [R=301,L] especifican una redirección 301 y que esta es la última regla a procesar si coincide.

Escenarios comunes de redirección basada en patrones para migraciones de PrestaShop:

Eliminar extensiones .html:

RewriteRule ^(.+)\.html$ /$1 [R=301,L]

Cambiar de URLs de categorías basadas en ID a basadas en nombre:

RewriteRule ^3-nombre-categoria-antigua(.*)$ /nuevo-nombre-categoria$1 [R=301,L]

Redirigir un subdirectorio completo:

RewriteRule ^tienda/(.*)$ /$1 [R=301,L]

Redirecciones condicionales

A veces necesitas redirecciones que solo se apliquen bajo ciertas condiciones. RewriteCond proporciona esta capacidad:

RewriteCond %{HTTP_HOST} ^dominioantiguo\.com$ [NC] RewriteRule ^(.*)$ https://www.nuevodominio.com/$1 [R=301,L]

Esto redirige todas las solicitudes de dominioantiguo.com a nuevodominio.com, preservando la ruta. El indicador [NC] hace que la condición no distinga entre mayúsculas y minúsculas.

Para redirigir solo si el archivo solicitado no existe en el nuevo servidor (útil durante una migración gradual):

RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule ^ruta-antigua/(.*)$ /nueva-ruta/$1 [R=301,L]

Configuración de redirecciones en Nginx

Si tu PrestaShop funciona con Nginx, las redirecciones se configuran en el archivo de configuración del bloque de servidor, normalmente ubicado en /etc/nginx/sites-available/tudominio.conf o /etc/nginx/conf.d/tudominio.conf.

Redirecciones individuales

location = /categoria-antigua/producto-antiguo.html { return 301 https://www.ejemplo.com/nueva-categoria/nuevo-producto; }

El modificador = especifica una coincidencia exacta. Sin él, Nginx trata la ubicación como una coincidencia de prefijo, lo que podría redirigir más URLs de las previstas.

Redirecciones basadas en patrones

location ~ ^/categoria-antigua/(.*)$ { return 301 /nueva-categoria/$1; }

El modificador ~ habilita la coincidencia con expresiones regulares. El grupo capturado $1 funciona de la misma manera que en Apache.

Redirecciones basadas en map para listas grandes

La directiva map de Nginx es ideal para gestionar cientos o miles de redirecciones individuales sin saturar el bloque de servidor:

map $request_uri $redirect_target { /producto-antiguo-1.html /nuevo-producto-1; /producto-antiguo-2.html /nuevo-producto-2; /producto-antiguo-3.html /nuevo-producto-3; }

server { if ($redirect_target) { return 301 $redirect_target; } }

El bloque map se evalúa solo una vez por solicitud y es altamente eficiente incluso con miles de entradas. Incluso puedes cargar el map desde un archivo externo usando la directiva include.

Recuerda probar tu configuración con nginx -t y recargar con systemctl reload nginx después de cualquier cambio.

Redirecciones masivas con CSV

Para migraciones que involucran miles de productos, escribir reglas de redirección manualmente no es viable. Un enfoque basado en CSV agiliza el proceso.

Creación del CSV

Exporta tus URLs antiguas desde los datos de rastreo previos a la migración o desde la base de datos. Exporta tus URLs nuevas desde la nueva instalación. Emparéjalas en una hoja de cálculo con dos columnas: ruta de URL antigua y ruta de URL nueva. Guarda como CSV.

Tu CSV podría verse así:

/3-categoria-antigua,/nueva-categoria /categoria-antigua/producto-antiguo-1.html,/nueva-categoria/nuevo-producto-1 /categoria-antigua/producto-antiguo-2.html,/nueva-categoria/nuevo-producto-2 /content/5-sobre-nosotros,/content/sobre-nosotros

Conversión del CSV a reglas .htaccess

Un enfoque sencillo es convertir cada línea del CSV en una directiva Redirect. Usando un editor de texto con buscar y reemplazar o una herramienta sencilla de línea de comandos:

awk -F',' '{print "Redirect 301 " $1 " https://www.ejemplo.com" $2}' redirects.csv >> .htaccess

Esto lee el archivo CSV, divide cada línea por la coma y genera una directiva Redirect para cada línea.

Uso de una tabla de base de datos

Para listas de redirecciones muy grandes (más de 10.000 entradas), considera almacenar las redirecciones en una tabla de base de datos y gestionarlas a nivel de aplicación. Crea una tabla con columnas para la ruta antigua y la ruta nueva, y escribe un pequeño módulo de PrestaShop o un override que intercepte los errores 404, consulte la tabla y devuelva una redirección 301 si encuentra una coincidencia. Este enfoque es más fácil de gestionar a través de una interfaz de administración pero añade una pequeña consulta de base de datos a cada respuesta 404.

Soluciones de redirección basadas en módulos

Varios módulos de PrestaShop proporcionan gestión de redirecciones a través del back office, eliminando la necesidad de editar archivos de configuración del servidor directamente.

Beneficios de las redirecciones basadas en módulos

Un módulo de redirección ofrece una interfaz amigable para añadir, editar y eliminar redirecciones. Normalmente incluye funcionalidad de importación/exportación para operaciones masivas, registro para rastrear qué redirecciones se están utilizando y la posibilidad de que miembros del equipo no técnicos gestionen las redirecciones sin acceso al servidor.

Cómo funcionan las redirecciones basadas en módulos

La mayoría de los módulos de redirección funcionan enganchándose al proceso de manejo de solicitudes de PrestaShop. Cuando llega una solicitud que normalmente resultaría en un error 404, el módulo la intercepta, consulta su base de datos de redirecciones en busca de una URL antigua coincidente y, si la encuentra, envía una respuesta de redirección 301 a la nueva URL.

Algunos módulos van más allá creando automáticamente redirecciones cuando cambias la URL amigable de un producto en el back office. Esto previene el problema común de romper enlaces antiguos cuando optimizas los slugs de tus URLs.

Consideraciones de rendimiento

Las redirecciones basadas en módulos añaden una pequeña sobrecarga a cada solicitud 404 porque deben consultar la base de datos. Para la mayoría de las tiendas esto es insignificante, pero si tienes miles de redirecciones y un tráfico de bots significativo que accede a URLs antiguas, las consultas de base de datos pueden acumularse. Considera usar una capa de caché o mover las redirecciones más utilizadas al .htaccess para un rendimiento óptimo.

Redirecciones Regex: Poder y peligro

Las redirecciones con expresiones regulares son herramientas poderosas que pueden manejar transformaciones complejas de URLs con una sola regla. También son la fuente más común de errores de redirección y bucles infinitos.

Cuándo usar redirecciones Regex

Usa redirecciones regex cuando el cambio de URL sigue un patrón consistente y predecible. Buenos candidatos incluyen: eliminar o añadir extensiones de archivo en todas las URLs, cambiar un prefijo de URL para una sección completa del sitio, eliminar o añadir prefijos de idioma y eliminar parámetros de consulta.

Patrones Regex comunes para PrestaShop

Eliminar el prefijo de ID de categoría que PrestaShop 1.6 añade a las URLs de categorías:

RewriteRule ^([0-9]+)-(.+)$ /$2 [R=301,L]

Esto coincide con URLs como /3-zapatos y redirige a /zapatos.

Añadir un prefijo de idioma:

RewriteCond %{REQUEST_URI} !^/(en|de|fr)/ RewriteRule ^(.+)$ /en/$1 [R=301,L]

Eliminar barras diagonales duplicadas:

RewriteRule ^(.*)//(.*)$ /$1/$2 [R=301,L]

Prueba segura de reglas Regex

Antes de desplegar redirecciones regex en producción, pruébalas exhaustivamente. Usa un probador de regex en línea (como regex101.com) para verificar que tu patrón coincida con las URLs que pretendes y no coincida con las que no debería.

Comienza con una redirección 302 durante las pruebas. Esto evita que los motores de búsqueda almacenen en caché redirecciones incorrectas. Una vez que hayas verificado que la regla funciona correctamente, cámbiala a 301.

Prueba casos extremos: URLs con parámetros de consulta, URLs con caracteres especiales, URLs con múltiples patrones coincidentes. Cada uno de estos puede revelar problemas que no son evidentes con URLs de prueba sencillas.

Prueba de redirecciones

Desplegar redirecciones sin pruebas exhaustivas es una receta para el desastre. Estos son los métodos que debes usar para verificar tus redirecciones antes y después de ponerlas en producción.

Pruebas por línea de comandos con curl

El comando curl es la forma más fiable de probar redirecciones porque te muestra exactamente lo que el servidor devuelve:

curl -I https://www.ejemplo.com/producto-antiguo.html

El indicador -I solicita solo las cabeceras. En la respuesta, busca:

HTTP/1.1 301 Moved Permanently Location: https://www.ejemplo.com/nuevo-producto

Verifica que el código de estado sea 301 (no 302) y que la cabecera Location apunte a la nueva URL correcta.

Para seguir la cadena de redirecciones y ver cada salto:

curl -IL https://www.ejemplo.com/producto-antiguo.html

El indicador -L le dice a curl que siga las redirecciones, mostrándote las cabeceras en cada paso.

Pruebas masivas

Para listas grandes de redirecciones, automatiza las pruebas con un bucle:

while IFS=, read -r old new; do status=$(curl -s -o /dev/null -w "%{http_code}" "https://www.ejemplo.com$old") echo "$old -> $status" done < redirects.csv

Esto lee tu archivo CSV, prueba cada URL antigua e imprime el código de estado HTTP. Cualquier URL que no devuelva 301 necesita atención.

Pruebas en el navegador

Abre las herramientas de desarrollo de tu navegador (F12), ve a la pestaña Red y navega a una URL antigua. La pestaña Red muestra la cadena de solicitudes, incluyendo todas las redirecciones. Verifica el código de estado, el destino de la redirección y la página final que se carga.

Inspección en Google Search Console

Después del despliegue, usa la herramienta de Inspección de URLs en Google Search Console para verificar cómo Google ve tus URLs redirigidas. Introduce una URL antigua y observa si Google reconoce la redirección y ha descubierto la nueva URL.

Cadenas de redirección y cómo evitarlas

Una cadena de redirección ocurre cuando una redirección lleva a otra redirección, que a su vez puede llevar a otra más. Por ejemplo: la URL A redirige a la URL B, que redirige a la URL C, que finalmente sirve el contenido. Cada salto añade latencia y diluye el link equity.

Por qué las cadenas de redirección son perjudiciales

Google ha declarado que seguirá las cadenas de redirección, pero con límites. Después de un cierto número de saltos (normalmente de 5 a 10), Googlebot se rinde y trata la URL como un error. Incluso para cadenas más cortas, cada salto retrasa la entrega de la página y pierde una pequeña cantidad de link equity.

Para los visitantes, cada redirección añade de 50 a 200 milisegundos de latencia, dependiendo de las condiciones de la red y el tiempo de respuesta del servidor. Una cadena de 3 redirecciones puede añadir medio segundo o más al tiempo de carga percibido.

Causas comunes de cadenas de redirección en PrestaShop

La cadena más común ocurre cuando una migración añade redirecciones sobre redirecciones existentes. Por ejemplo, podrías tener redirecciones antiguas de un cambio previo en la estructura de URLs, y la nueva migración añade otra capa. La URL A redirige a la URL B (de la primera migración), y la URL B redirige a la URL C (de la segunda migración).

Otra causa común es la interacción entre la redirección canónica integrada de PrestaShop y tus redirecciones personalizadas. PrestaShop puede redirigir desde una URL no canónica a la versión canónica, y si tu redirección personalizada también coincide, obtienes una cadena.

La aplicación de HTTPS añade otro salto potencial. Si tu redirección apunta a una URL HTTP, y el servidor luego redirige a HTTPS, eso es una cadena de dos pasos.

Corrección de cadenas de redirección

Audita tus redirecciones regularmente usando una herramienta de rastreo que detecte cadenas. Cuando encuentres una cadena, actualiza la primera redirección para que apunte directamente al destino final. La URL A debe redirigir directamente a la URL C, saltándose la URL B por completo.

Al añadir nuevas redirecciones durante una migración, verifica siempre si la URL de destino es ella misma una redirección. Si lo es, configura la nueva redirección para que apunte al destino final en su lugar.

Errores comunes y cómo evitarlos

Bucles de redirección infinitos

Un bucle infinito ocurre cuando la URL A redirige a la URL B, y la URL B redirige de vuelta a la URL A. El navegador detecta esto y muestra un error ERR_TOO_MANY_REDIRECTS. Las causas comunes incluyen reglas conflictivas en .htaccess (una regla redirige www a non-www mientras otra redirige non-www a www), redirecciones conflictivas entre .htaccess y un módulo de redirección, y reglas regex demasiado amplias que coinciden con sus propias URLs de destino.

Para corregir un bucle, comienza deshabilitando todas las redirecciones personalizadas y vuelve a habilitarlas una por una hasta que el bucle reaparezca. Esto identifica la regla conflictiva.

Olvidar los parámetros de consulta

De forma predeterminada, la directiva Redirect de Apache pasa los parámetros de consulta a la nueva URL. Sin embargo, RewriteRule no pasa los parámetros de consulta a menos que añadas el indicador [QSA] (Query String Append). Si tus URLs antiguas incluyen parámetros de consulta importantes (como ?id_product=123), asegúrate de que se manejen correctamente.

Sensibilidad a mayúsculas y minúsculas

En servidores Linux, las URLs distinguen entre mayúsculas y minúsculas. /Producto.html y /producto.html son URLs diferentes. Si tu sitio antiguo tenía URLs con mayúsculas mixtas y tu nuevo sitio normaliza todo a minúsculas, necesitas redirecciones que manejen ambos casos. Usa el indicador [NC] en RewriteRule para coincidencias sin distinción de mayúsculas.

No redirigir todas las variaciones de URL

Una sola página de producto puede ser accesible a través de múltiples URLs: con y sin barra diagonal final, con y sin extensión .html, con y sin el prefijo de ruta de categoría, con y sin www. Cada variación que fue indexada necesita su propia redirección a la nueva URL canónica.

Dejar las redirecciones en su lugar para siempre

Si bien las redirecciones deben permanecer en su lugar durante al menos 12 meses después de una migración (Google recomienda al menos un año), no deberían permanecer indefinidamente. Después de un año o más, las URLs antiguas ya no deberían aparecer en los resultados de búsqueda ni recibir tráfico significativo. Audita tus registros de redirección, elimina las reglas que ya no se activan y mantén tu configuración limpia.

Resumen

Configurar correctamente las redirecciones 301 es la tarea técnica más importante en una migración de PrestaShop. Cada URL antigua que tenía tráfico, backlinks o visibilidad en motores de búsqueda debe redirigir a su nueva contraparte con un código de estado 301. El método de implementación depende de tu servidor (Apache .htaccess o configuración de Nginx), la cantidad de URLs (reglas individuales, patrones regex o módulos respaldados por base de datos) y las capacidades técnicas de tu equipo. Prueba cada redirección antes de ponerla en producción usando curl o las herramientas de desarrollo del navegador. Vigila las cadenas de redirección, los bucles infinitos y los problemas de sensibilidad a mayúsculas y minúsculas. Monitorea Google Search Console después del despliegue para verificar que Google está procesando correctamente tus redirecciones. Y recuerda que una 302 donde debería haber una 301 nunca es inofensiva. Siempre es la opción equivocada para una migración permanente.

Leer respuesta completa

Por qué la calidad del tema importa más que la apariencia

Elegir un tema de PrestaShop es una de las decisiones más trascendentales que toma un propietario de tienda. Un tema controla no solo cómo se ve tu tienda, sino cómo rinde, qué tan accesible es para los clientes con discapacidades, qué tan bien pueden rastrearla los motores de búsqueda y con qué facilidad puedes extenderla con módulos. Un tema mal construido crea problemas que se acumulan con el tiempo. Lo que parece una pequeña molestia durante la configuración se convierte en un cuello de botella de rendimiento bajo carga, una pesadilla de mantenimiento durante las actualizaciones o un fallo en la experiencia del cliente que mata silenciosamente las conversiones.

El problema es que los marketplaces de temas están inundados de temas que se ven impresionantes en sus capturas de demostración pero están construidos con mínima atención a los estándares de codificación, el rendimiento o la compatibilidad. Muchos desarrolladores de temas optimizan para el atractivo visual en la vista previa, sabiendo que la mayoría de los compradores evalúan los temas basándose en cómo se ven en lugar de cómo están construidos. Esta guía te enseña a mirar más allá de la superficie e identificar las señales de alerta que separan un tema de PrestaShop bien construido de uno que te causará problemas.

Solicitudes HTTP excesivas

Uno de los indicadores más fiables de un tema mal construido es un número excesivo de solicitudes HTTP. Cada archivo CSS, archivo JavaScript, imagen, fuente y recurso externo que carga una página requiere una solicitud separada al servidor. Aunque los navegadores modernos pueden manejar múltiples solicitudes en paralelo a través de HTTP/2, cada solicitud sigue añadiendo latencia, especialmente en conexiones móviles.

Un tema de PrestaShop bien construido debería cargarse con no más de 30 a 50 solicitudes en una página típica de producto o categoría, asumiendo que no hay módulos adicionales instalados. Los temas mal construidos rutinariamente superan las 80 o incluso 100 solicitudes. Las causas más comunes son cargar múltiples archivos CSS en lugar de combinarlos, incluir bibliotecas JavaScript que no se usan en todas las páginas, cargar fuentes web de múltiples proveedores e incrustar widgets externos o píxeles de seguimiento directamente en el tema en lugar de a través de módulos.

Para verificar esto antes de comprar un tema, abre la demostración del tema en Chrome, abre las Herramientas para desarrolladores (F12), ve a la pestaña Red y recarga la página. Observa el número total de solicitudes que se muestra en la parte inferior del panel. Luego examina qué se está cargando. ¿Hay docenas de archivos CSS individuales? ¿Hay múltiples versiones de jQuery? ¿Hay solicitudes a dominios de terceros que no reconoces? Estas son señales de alerta.

Presta especial atención a las solicitudes que bloquean el renderizado. El CSS y el JavaScript síncrono en el encabezado del documento impiden que el navegador muestre cualquier contenido hasta que terminen de cargarse. Un tema bien construido aplaza el CSS y JavaScript no críticos para que la página comience a renderizarse rápidamente. Un tema mal construido carga todo de entrada, creando una pantalla en blanco que dura segundos.

Estilos en línea y diseño hardcodeado

Los desarrolladores profesionales de temas usan clases CSS y hojas de estilo para controlar la apariencia visual de un tema. Este enfoque es mantenible, se puede sobreescribir y es eficiente porque los navegadores almacenan en caché las hojas de estilo externas. Los temas mal construidos, por el contrario, dispersan estilos en línea a lo largo de sus plantillas Smarty y archivos PHP. Encontrarás cosas como style="color: #333; font-size: 14px; margin-top: 20px;" directamente en elementos HTML.

Los estilos en línea son problemáticos por varias razones. No pueden almacenarse en caché por separado del HTML. Son extremadamente difíciles de sobreescribir con CSS, requiriendo la declaración !important en todas partes. Hacen que el tema sea casi imposible de personalizar sin editar archivos de plantilla directamente, lo que significa que tus personalizaciones se pierden cada vez que el tema se actualiza. Y aumentan el tamaño del documento HTML, lo que afecta al rendimiento en cada carga de página.

Una señal de alerta relacionada es encontrar valores de diseño hardcodeados en archivos PHP. Si ves códigos de color, tamaños de fuente o dimensiones de maquetación definidos en PHP en lugar de en CSS o un panel de configuración, el desarrollador del tema tomó atajos. Cualquier cambio de diseño requerirá editar código PHP, lo cual es propenso a errores y hace que las actualizaciones sean peligrosas.

Para verificar los estilos en línea, haz clic derecho en varios elementos de la demostración del tema y elige Inspeccionar elemento. Observa el panel de Estilos en las Herramientas para desarrolladores. Si ves un gran número de estilos listados bajo element.style en lugar de provenientes de clases CSS, el tema depende en gran medida de los estilos en línea. Algunos estilos en línea son normales y aceptables (por ejemplo, imágenes de fondo dinámicas establecidas por el CMS), pero si la mayoría de los estilos son en línea, eso es una clara señal de alerta.

Diseño responsive ausente

En 2026, más del 60 por ciento del tráfico de comercio electrónico proviene de dispositivos móviles. Un tema que no funciona bien en móvil no es solo inconveniente. Te cuesta directamente ventas y posicionamiento en buscadores, porque Google utiliza la indexación mobile-first, lo que significa que evalúa tu sitio basándose en la versión móvil.

Pero el diseño responsive no se trata solo de si el tema tiene una vista móvil. Muchos temas afirman ser responsive pero lo implementan de forma deficiente. Las señales de alerta de un mal diseño responsive incluyen texto que se desborda de su contenedor en pantallas pequeñas, botones y enlaces demasiado pequeños para pulsar de forma fiable, desplazamiento horizontal en móvil, imágenes que no se redimensionan y obligan al usuario a desplazarse horizontalmente, menús de navegación difíciles o imposibles de usar en dispositivos táctiles, y formularios de pago inutilizables en teléfonos.

Prueba la demostración del tema en un teléfono real, no solo redimensionando la ventana de tu navegador. Redimensionar el navegador no replica las interacciones táctiles, las condiciones reales de la red ni el comportamiento de renderizado de los navegadores móviles. Intenta todo el flujo de compra en tu teléfono: navega por categorías, abre un producto, añade al carrito y pasa por el proceso de pago. Si algún paso es frustrante o está roto, el tema falla la prueba más básica de preparación para móviles.

También verifica si el tema usa imágenes responsive adecuadas. Un tema bien construido sirve diferentes tamaños de imagen para diferentes tamaños de pantalla usando el atributo srcset o el elemento <picture>. Un tema mal construido sirve la misma imagen grande de escritorio a los dispositivos móviles y se basa en CSS para reducirla visualmente, desperdiciando ancho de banda y ralentizando las cargas de página móviles.

Texto hardcodeado sin traducciones

PrestaShop tiene un sistema de traducción robusto que permite que cada cadena mostrada al usuario se traduzca a cualquier idioma. Un tema correctamente construido utiliza este sistema para cada pieza de texto visible, desde etiquetas de botones hasta mensajes de error y texto de encabezados. La sintaxis de Smarty se ve como {l s='Add to cart' d='Shop.Theme.Actions'}, lo que hace que la cadena esté disponible en la interfaz de traducción del back office.

Los temas mal construidos hardcodean el texto directamente en sus plantillas. En lugar de usar la función de traducción, escriben HTML plano como <button>Add to cart</button>. Esto significa que el texto no se puede traducir, lo que hace que el tema sea inútil para tiendas multilingües y problemático incluso para tiendas de un solo idioma que quieran personalizar las etiquetas de los botones o los mensajes.

Para verificar esto, observa la demostración del tema y anota cadenas de texto específicas como etiquetas de botones, encabezados de secciones y texto de marcadores de posición. Luego intenta encontrar los archivos de traducción del tema. Un tema bien construido incluye catálogos de traducción o usa los dominios de traducción de PrestaShop de forma consistente. Si la documentación del tema no menciona traducciones o soporte multilingüe, eso es una preocupación. Si puedes acceder a alguno de los archivos de plantilla del tema (algunos marketplaces proporcionan vistas previas de archivos), busca cadenas de texto plano que deberían ser traducibles. Cada cadena visible para el usuario debería estar envuelta en una llamada a la función de traducción.

Conflictos de jQuery y problemas de JavaScript

PrestaShop incluye jQuery como parte de su framework front-end principal. Un tema bien construido trabaja con la versión de jQuery que PrestaShop proporciona. Un tema mal construido o bien incluye su propia versión de jQuery (creando conflictos), carga bibliotecas JavaScript adicionales que duplican funcionalidad ya disponible en el núcleo, o usa técnicas de JavaScript que son incompatibles con otros módulos.

Los conflictos de jQuery son uno de los problemas más comunes con los temas de terceros. Cuando un tema carga su propia versión de jQuery, puede romper módulos que dependen de la versión del núcleo. Los síntomas incluyen módulos que fallan silenciosamente (botones que no responden a los clics, formularios que no se envían, funciones AJAX que no funcionan), errores de JavaScript en la consola del navegador y funciones que funcionan en la demostración del tema (donde no hay otros módulos instalados) pero se rompen en tu tienda real.

Para verificar conflictos de jQuery antes de comprar, abre la demostración del tema, abre la consola del navegador (F12, pestaña Consola) y escribe jQuery.fn.jquery para ver qué versión está cargada. Luego mira en la pestaña Red si se cargan múltiples archivos jQuery. Si ves más de un archivo jQuery, o si la versión no coincide con la que PrestaShop incluye (jQuery 3.x para PrestaShop 1.7 y 8.x), es probable que el tema cause conflictos.

También busca errores de JavaScript en la consola mientras navegas por la demostración. Errores en el sitio de demostración, donde las condiciones están controladas y solo hay módulos por defecto instalados, son una señal de alerta muy fuerte. Si el tema no puede ejecutarse limpiamente en su propio entorno de demostración, definitivamente tendrá problemas en una tienda real con módulos adicionales.

Falta de soporte de hooks

El sistema de hooks de PrestaShop es el mecanismo principal para que los módulos se integren con tu tienda. Los hooks son puntos predefinidos en las plantillas del tema donde los módulos pueden insertar su contenido. Los hooks estándar de PrestaShop incluyen displayHeader, displayTop, displayHome, displayFooter, displayLeftColumn, displayRightColumn, displayProductAdditionalInfo y muchos más.

Un tema bien construido soporta todos los hooks estándar de PrestaShop, asegurando que cualquier módulo diseñado para PrestaShop funcione correctamente. Un tema mal construido elimina hooks para simplificar su maquetación, reemplaza hooks estándar con hooks propietarios personalizados o posiciona hooks en ubicaciones que rompen la maquetación esperada.

La falta de hooks significa que los módulos que instales no tendrán dónde mostrar su contenido. Un módulo de pago que depende de displayPaymentReturn no mostrará su mensaje de confirmación. Un módulo de personalización de productos que usa displayProductAdditionalInfo será invisible en las páginas de productos. Terminas o bien modificando las plantillas del tema manualmente para añadir los hooks faltantes (lo que se rompe con las actualizaciones del tema) o eligiendo módulos específicamente diseñados para ese tema (lo que limita tus opciones y crea dependencia del proveedor).

Para verificar el soporte de hooks, busca en la documentación del tema una lista de hooks soportados. Si tal lista no existe, eso en sí mismo es una preocupación. En la demostración, instala o imagina instalar un módulo que use un hook estándar y verifica si la maquetación del tema lo acomoda. También puedes examinar los archivos de plantilla del tema si están accesibles, buscando {hook h='displayHome'} y otros nombres de hooks estándar.

Sin soporte para temas hijo

PrestaShop 1.7 y versiones posteriores soportan temas hijo, que te permiten personalizar un tema sin modificar sus archivos originales. Un tema hijo hereda todo del tema padre y solo contiene los archivos que quieres sobreescribir. Cuando el tema padre se actualiza, tus personalizaciones permanecen intactas porque viven en archivos separados.

Un tema que no soporta temas hijo te obliga a hacer todas las personalizaciones directamente en los archivos del tema. Cada vez que el desarrollador del tema lanza una actualización, te enfrentas a una disyuntiva: saltarte la actualización y perderte correcciones de errores y nuevas funciones, o aplicar la actualización y perder todas tus personalizaciones. Ninguna opción es aceptable para una tienda en producción.

Verifica la documentación del tema y su archivo theme.yml para comprobar el soporte de temas hijo. El archivo theme.yml es el archivo de configuración central de un tema de PrestaShop, y debería incluir un campo parent o documentación explicando cómo crear un tema hijo. Si el desarrollador del tema no menciona los temas hijo en su documentación, pregúntale directamente antes de comprar. Un desarrollador que no soporta temas hijo o bien no entiende el desarrollo moderno de PrestaShop o no se preocupa por la mantenibilidad a largo plazo de su producto.

Accesibilidad deficiente

La accesibilidad web significa que las personas con discapacidades pueden usar tu tienda. Esto incluye personas que usan lectores de pantalla, personas que navegan con el teclado en lugar del ratón, personas con baja visión que usan ampliación de pantalla y personas con daltonismo. La accesibilidad no es solo éticamente importante. En muchos países, incluyendo los de la Unión Europea y Estados Unidos, los sitios de comercio electrónico están obligados por ley a cumplir estándares de accesibilidad (WCAG 2.1 Nivel AA).

Un tema mal construido ignora la accesibilidad por completo. Los fallos de accesibilidad comunes incluyen imágenes sin atributos alt (los lectores de pantalla no pueden describirlas), campos de formulario sin etiquetas asociadas (los lectores de pantalla no pueden decirle al usuario qué escribir), contraste de color insuficiente entre texto y fondo (las personas con baja visión no pueden leer el texto), elementos interactivos que no pueden alcanzarse o activarse con el teclado, indicadores de foco eliminados por razones estéticas (los usuarios de teclado no pueden ver dónde están en la página) y atributos ARIA usados incorrectamente o no usados en absoluto.

Para realizar una verificación básica de accesibilidad en una demostración de tema, intenta navegar por el sitio usando solo el teclado (Tab para moverte entre elementos, Enter para activar botones y enlaces). Si no puedes alcanzar todos los elementos interactivos o si no hay un indicador de foco visible que muestre qué elemento está actualmente seleccionado, el tema falla en accesibilidad básica. También ejecuta la página a través de una herramienta gratuita como WAVE Web Accessibility Evaluation Tool o usa la auditoría de Accesibilidad de Lighthouse en Chrome DevTools (ve a la pestaña Lighthouse, marca solo Accesibilidad y ejecuta la auditoría). Un tema bien construido debería obtener al menos 80 de 100 puntos en la auditoría de accesibilidad de Lighthouse.

Tamaños de archivo inflados

El tamaño de los archivos de un tema afecta directamente la rapidez con que carga tu tienda. Los temas inflados incluyen recursos innecesarios, imágenes sin optimizar, CSS y JavaScript sin minificar, y bibliotecas enteras usadas para una sola función. Es común encontrar temas que incluyen varios megabytes de CSS (cuando el CSS realmente utilizado es una fracción de eso), múltiples fuentes de iconos cargadas completas cuando solo se usan un puñado de iconos, imágenes de demostración sin comprimir dejadas en el directorio del tema y bibliotecas JavaScript como Moment.js o Lodash incluidas en su totalidad cuando solo se necesitan una o dos funciones.

Para evaluar los tamaños de archivo, verifica el tamaño total de transferencia en la pestaña Red de Chrome DevTools al cargar la demostración del tema. Un tema bien optimizado debería cargar menos de 1 MB de recursos totales en una página típica (excluyendo imágenes de productos, que varían). Si la demostración del tema carga de 2 a 3 MB o más de CSS, JavaScript y fuentes, el tema está inflado. Presta especial atención a los tamaños de archivos CSS. Los temas de PrestaShop que usan Bootstrap o un framework similar deberían incluir solo los componentes de Bootstrap que realmente usan, no la biblioteca completa. Un archivo CSS de 500 KB en una sola página está casi seguramente inflado.

También verifica si el tema minifica su CSS y JavaScript de producción. La minificación elimina espacios en blanco, comentarios y caracteres innecesarios, reduciendo típicamente los tamaños de archivo entre un 20 y un 40 por ciento. Visualiza el código fuente de los archivos CSS en la demostración. Si contienen código legible y formateado con comentarios, no están minificados, lo que sugiere que el desarrollador no implementó un proceso de compilación adecuado.

Cómo evaluar un tema antes de comprarlo

Verificar theme.yml

El archivo theme.yml es el corazón de la configuración de un tema de PrestaShop. Define el nombre del tema, la versión, la compatibilidad, los hooks soportados, la configuración de maquetación y la gestión de recursos. Busca una declaración clara de compatibilidad con versiones de PrestaShop, una lista de hooks registrados y sus módulos asignados, definiciones de maquetación para diferentes tipos de página (producto, categoría, CMS, checkout), y declaraciones de recursos que especifiquen qué archivos se cargan globalmente frente a en páginas específicas. Si el archivo theme.yml es mínimo o le faltan secciones clave, el tema fue construido sin seguir las directrices de desarrollo de temas de PrestaShop.

Pruebas con el modo debug

Si puedes instalar el tema en un entorno de pruebas, habilita el modo debug de PrestaShop inmediatamente configurando _PS_MODE_DEV_ a true en config/defines.inc.php. Esto revela errores PHP, advertencias y avisos ocultos en modo producción. Un tema bien construido debería generar cero errores y advertencias mínimas. Si el modo debug produce una avalancha de errores, el tema tiene problemas de calidad de código que causarán problemas en producción.

Verificar el historial del desarrollador

Investiga al desarrollador antes de comprar. Verifica cuántos temas han publicado, cuán recientemente se actualizaron sus temas y qué dicen las reseñas. Presta atención a las reseñas negativas que mencionen errores, funciones rotas después de actualizaciones o soporte que no responde. Un historial de cambios detallado documentando correcciones de errores y actualizaciones de compatibilidad indica mantenimiento activo. Un historial de cambios ausente sugiere que el tema puede estar abandonado después de la venta inicial.

Verificación de compatibilidad

Siempre verifica que el tema declare explícitamente compatibilidad con tu versión exacta de PrestaShop. Frases como "compatible con PrestaShop 1.7 y superior" son demasiado vagas. Quieres números de versión específicos listados como probados. Verifica comprobando cuándo se actualizó el tema por última vez. Si el tema afirma compatibilidad con PrestaShop 8.1 pero fue actualizado por última vez antes de que esa versión fuera lanzada, la afirmación no está verificada en el mejor de los casos.

El coste real de un tema malo

Un tema mal construido tiene costes concretos y medibles. Los problemas de rendimiento reducen tu puntuación en PageSpeed, afectando al posicionamiento y las conversiones (cada segundo adicional de tiempo de carga reduce las conversiones entre un 7 y un 10 por ciento). La falta de soporte de hooks obliga a pagar trabajo de desarrollador por cada nuevo módulo. Una accesibilidad deficiente crea responsabilidad legal. La ausencia de soporte de temas hijo convierte cada actualización en una fusión manual. Los conflictos de jQuery rompen módulos, causando ventas perdidas por botones de "añadir al carrito" rotos y formularios de pago que fallan.

Al evaluar temas, considera el coste total de propiedad. Un tema barato que requiere cientos de euros en tiempo de desarrollador es mucho más caro que un tema más costoso que funciona correctamente desde el principio.

Lista de verificación resumida

Antes de comprar cualquier tema de PrestaShop, pasa por esta lista de verificación. Abre la demostración y verifica la pestaña Red en busca de solicitudes HTTP excesivas (más de 50 es preocupante, más de 80 es señal de alerta). Inspecciona elementos en busca de estilos en línea que deberían estar en clases CSS. Prueba todo el flujo de compra en un dispositivo móvil real. Busca texto hardcodeado que no pueda traducirse. Verifica la consola del navegador en busca de errores de JavaScript y múltiples versiones de jQuery. Comprueba que los hooks estándar de PrestaShop estén presentes en las plantillas. Confirma que la creación de temas hijo está documentada y soportada. Ejecuta una auditoría de accesibilidad de Lighthouse y verifica la navegabilidad por teclado. Revisa los tamaños totales de transferencia para CSS, JavaScript y fuentes. Lee el archivo theme.yml para verificar la estructura de configuración apropiada. Revisa el historial de actualizaciones del desarrollador y la capacidad de respuesta del soporte. Verifica la compatibilidad explícita con tu versión de PrestaShop.

Un tema que pasa todas estas verificaciones no está garantizado de ser perfecto, pero ha superado el estándar básico de calidad que separa el trabajo profesional del desarrollo amateur. Un tema que falla múltiples verificaciones te causará problemas. El tiempo invertido en evaluar antes de la compra ahorra mucho más tiempo, dinero y frustración que lidiar con las consecuencias de un tema mal construido después de que ya está ejecutando tu tienda.

Leer respuesta completa

El coste oculto del exceso de fuentes en los temas de PrestaShop

Abre las DevTools de tu navegador, cambia a la pestaña Red, filtra por "Font" y recarga tu tienda PrestaShop. Si ves más de tres o cuatro archivos de fuentes descargándose, tienes un problema que está costándote clientes silenciosamente. La mayoría de los temas de PrestaShop incluyen una cantidad asombrosa de recursos de fuentes que la tienda promedio nunca utiliza, y cada uno de ellos retrasa el momento en que tus visitantes pueden realmente leer tu contenido.

El exceso de fuentes es uno de los problemas de rendimiento más ignorados en PrestaShop. Los propietarios de tiendas dedican horas a optimizar imágenes, habilitar CCC (Combinar, Comprimir, Cachear) y ajustar configuraciones del servidor, pero ignoran el hecho de que su tema está cargando 800KB o más de archivos de fuentes en cada carga de página. Este artículo explica exactamente por qué esto ocurre, cómo auditar la carga de fuentes y qué hacer al respecto.

Cómo los temas de PrestaShop empaquetan las fuentes

Los temas de PrestaShop se distribuyen como paquetes autocontenidos. Cuando un desarrollador de temas construye un tema, quiere que funcione de inmediato para la mayor cantidad posible de tiendas. Esto significa que incluyen cada variante de fuente y biblioteca de iconos que podrían llegar a necesitar. El resultado es un tema que incluye muchos más recursos de fuentes de los que cualquier tienda individual llegará a utilizar.

Un tema típico de PrestaShop incluye tres categorías de fuentes. Primero, están las fuentes de visualización usadas para encabezados, texto del cuerpo y elementos de interfaz. Estas suelen ser fuentes de Google Fonts como Roboto, Open Sans, Lato o Montserrat. Segundo, están las fuentes de iconos como FontAwesome, Material Icons o conjuntos de iconos específicos del tema. Tercero, están las fuentes de respaldo o decorativas que el tema usa para componentes específicos como banners, insignias o secciones promocionales.

El problema se multiplica porque cada familia de fuentes típicamente incluye múltiples pesos y estilos. Una sola fuente como Roboto puede incluir Regular (400), Medium (500), Bold (700) y sus variantes en cursiva, cada una como un archivo WOFF2 separado. Multiplica eso por dos o tres familias de fuentes más una biblioteca de iconos, y rápidamente llegas a 12 o 15 archivos de fuentes individuales cargándose en cada página.

El problema de FontAwesome

FontAwesome merece su propia sección porque es el mayor infractor de rendimiento relacionado con fuentes en los temas de PrestaShop. La biblioteca completa de FontAwesome 5 pesa aproximadamente 150KB solo para el archivo de fuente web, más otros 60-80KB para su CSS. FontAwesome 6 es aún más grande. La biblioteca contiene más de 1.600 iconos, pero la tienda PrestaShop promedio usa quizás entre 20 y 30 de ellos.

Eso significa que estás obligando a cada visitante a descargar más de 200KB de datos de fuentes y CSS solo para mostrar un icono de carrito de compras, una lupa de búsqueda y algunos logotipos de redes sociales. Este es un compromiso absurdo, y ocurre porque a los desarrolladores de temas les resulta más fácil incluir toda la biblioteca que crear un subconjunto para las necesidades específicas de cada tienda.

El tema Classic en PrestaShop 1.7 y 8.x incluye FontAwesome 4.7, que es ligeramente más pequeño pero sigue conteniendo cientos de iconos que nunca usarás. El tema Hummingbird en PrestaShop 8.x se alejó de FontAwesome en favor de iconos SVG, lo cual es una mejora significativa, pero muchos temas y módulos de terceros siguen dependiendo de FontAwesome y cargan su propia copia además de lo que el tema proporciona.

Google Fonts y el impuesto al rendimiento

Google Fonts es el servicio de fuentes web más popular, y los temas de PrestaShop hacen un uso intensivo de él. Sin embargo, cargar Google Fonts de la manera predeterminada crea una cadena de solicitudes que perjudican el rendimiento.

Cuando tu tema carga Google Fonts mediante la etiqueta link estándar, el navegador primero debe conectarse a fonts.googleapis.com para descargar el archivo CSS. Ese archivo CSS luego indica al navegador que descargue los archivos de fuentes reales desde fonts.gstatic.com. Cada una de estas conexiones requiere resolución DNS, negociación TCP y negociación TLS. En conexiones móviles, esta cadena puede añadir de 300 a 500ms de retraso antes de que un solo carácter de texto se renderice en pantalla.

Aún peor, el CSS de Google Fonts usa el descriptor font-display establecido en "swap" por defecto desde 2019, pero muchos temas antiguos todavía hacen referencia a URLs de CSS de Google Fonts que son anteriores a este cambio. Sin font-display: swap, el navegador puede ocultar todo el texto de la página hasta que la fuente se descargue, creando el temido Flash de Texto Invisible (FOIT) donde los visitantes ven una página en blanco durante uno a tres segundos.

También existe una preocupación de privacidad. Cargar fuentes desde el CDN de Google significa que Google recibe información sobre cada visitante de tu tienda, incluyendo su dirección IP y las páginas que visita. Bajo el RGPD, esto requiere consentimiento explícito, y un tribunal alemán dictaminó en enero de 2022 que usar Google Fonts sin consentimiento viola el RGPD, resultando en multas.

Cómo auditar la carga de fuentes

Antes de poder solucionar el problema, necesitas entender exactamente qué fuentes está cargando tu tema y cuáles realmente necesitas. Aquí tienes un enfoque sistemático.

Abre Chrome DevTools (F12), ve a la pestaña Red y marca la casilla "Deshabilitar caché". Recarga tu página y filtra por "Font" en la barra de filtros. Verás cada archivo de fuente que el navegador descarga. Anota los nombres de archivo, tamaños y la columna de iniciador que te indica qué archivo CSS solicitó cada fuente.

A continuación, usa la pestaña Cobertura (Coverage) en DevTools (Ctrl+Shift+P, luego escribe "Coverage"). Inicia una grabación de cobertura y navega por tu tienda. La pestaña de Cobertura te muestra exactamente cuánto de cada archivo CSS se usa realmente. Para el CSS de FontAwesome, normalmente verás un 90% o más marcado como no utilizado.

También puedes usar la auditoría de Lighthouse en DevTools. Ejecuta una auditoría de rendimiento y busca las oportunidades "Reducir CSS no utilizado" y "Asegurar que el texto permanezca visible durante la carga de fuentes web". Lighthouse señalará específicamente los problemas de rendimiento relacionados con fuentes.

Para un análisis más exhaustivo, usa WebPageTest (webpagetest.org) para ejecutar una prueba desde una conexión móvil. Observa el gráfico de cascada y encuentra las solicitudes de fuentes. Nota cuándo comienzan a cargarse en relación con otros recursos y cuánto tiempo tardan. En una conexión 3G, los retrasos en la carga de fuentes se vuelven dolorosamente evidentes.

Eliminación de fuentes no utilizadas paso a paso

Una vez que sepas qué fuentes carga tu tema y cuáles realmente necesitas, es momento de eliminar el exceso. El enfoque varía dependiendo de la arquitectura de tu tema.

Para temas que cargan Google Fonts mediante una etiqueta link en la plantilla del encabezado, encuentra el archivo de plantilla que contiene la referencia a Google Fonts. En la mayoría de los temas, esto está en templates/layout/head.tpl o un archivo similar. Si estás usando un tema hijo, copia esta plantilla a tu directorio de tema hijo antes de editarla. Elimina o modifica el enlace de Google Fonts para incluir solo los pesos y familias que realmente usas.

Para FontAwesome, verifica si tu tema lo carga mediante un archivo CSS en el directorio assets/css o mediante un enlace CDN. Si es un archivo local, tienes dos opciones. Puedes reemplazar el paquete completo de FontAwesome con un subconjunto que contenga solo los iconos que usas, o puedes reemplazar el uso de fuentes de iconos con SVGs en línea completamente.

Para crear un subconjunto de FontAwesome, usa una herramienta como IcoMoon (icomoon.io) o Fontello (fontello.com). Estas herramientas te permiten seleccionar solo los iconos específicos que necesitas y generar un archivo de fuente personalizado que podría ser de 5-10KB en lugar de 150KB. Necesitarás actualizar los nombres de clases CSS si la herramienta genera nombres diferentes, pero la mayoría permite mantener los nombres de clase originales de FontAwesome.

Para Google Fonts, verifica cada archivo CSS de tu tema en busca de declaraciones @font-face. Los desarrolladores de temas a veces importan fuentes directamente en CSS en lugar de a través de la plantilla del encabezado. Usa la búsqueda de DevTools (Ctrl+Shift+F) para buscar en todos los recursos cargados "@font-face" y "fonts.googleapis.com".

Implementación de font-display: swap

Si conservas alguna fuente web, asegúrate absolutamente de que use el descriptor font-display: swap. Esto indica al navegador que muestre el texto inmediatamente usando una fuente del sistema como respaldo mientras la fuente web se descarga en segundo plano. Una vez que la fuente web está lista, el navegador la intercambia. Esto elimina el FOIT y asegura que tu contenido sea legible instantáneamente.

Para Google Fonts cargadas vía CDN, añade el parámetro display=swap a la URL. Por ejemplo, cambia fonts.googleapis.com/css2?family=Roboto:wght@400;700 a fonts.googleapis.com/css2?family=Roboto:wght@400;700&display=swap. Ten en cuenta que Google añadió este parámetro por defecto en 2019, pero muchos temas de PrestaShop todavía usan formatos de URL más antiguos.

Para fuentes alojadas localmente con declaraciones @font-face en tu CSS, añade font-display: swap a cada bloque @font-face. Abre el archivo CSS de tu tema que contiene las reglas @font-face y añade la propiedad. Va dentro del bloque @font-face junto a font-family, src y font-weight.

Ten en cuenta que font-display: swap puede causar un Flash de Texto Sin Estilo (FOUT) donde el texto aparece brevemente en la fuente de respaldo antes de cambiar a la fuente web. Esta es una experiencia mucho mejor que el texto invisible, pero puedes minimizar el impacto visual eligiendo fuentes de respaldo que coincidan estrechamente con las métricas de tu fuente web. Las propiedades CSS size-adjust, ascent-override y descent-override ayudan con esto.

Alojamiento propio de fuentes vs carga desde CDN

Alojar tus fuentes localmente en lugar de cargarlas desde el CDN de Google ofrece varias ventajas significativas para las tiendas PrestaShop.

El rendimiento mejora porque eliminas la búsqueda DNS adicional y la conexión a los servidores de Google. Tus fuentes se cargan desde el mismo dominio que tus otros recursos, lo que significa que el navegador puede reutilizar conexiones existentes. Con HTTP/2 o HTTP/3, todos tus archivos de fuentes pueden descargarse simultáneamente a través de una sola conexión.

El cumplimiento de la privacidad se simplifica porque los datos de los visitantes ya no se envían a Google. Esto elimina por completo una preocupación del RGPD, y no necesitas añadir Google Fonts al banner de consentimiento de cookies.

La fiabilidad mejora porque no dependes de un servicio externo. Si el CDN de Google tiene un problema (raro pero posible), tus fuentes siguen cargándose.

Para alojar Google Fonts localmente, usa la herramienta google-webfonts-helper (gwfh.mranftl.com/fonts) que proporciona una interfaz sencilla para descargar cualquier fuente de Google en formato WOFF2 con el CSS @font-face correcto. Descarga solo los pesos y estilos que necesitas, coloca los archivos en el directorio assets/fonts de tu tema y añade el CSS @font-face a la hoja de estilos de tu tema.

La única desventaja potencial del alojamiento propio es que pierdes la posibilidad de un acierto de caché si el visitante ya ha cargado la misma fuente desde el CDN de Google en otro sitio. Sin embargo, los navegadores han eliminado en gran medida esta caché entre sitios por razones de privacidad desde 2020, por lo que esta ventaja ya no existe en la práctica.

Subsetting de fuentes: La opción radical

El subsetting de fuentes significa eliminar caracteres que no necesitas de un archivo de fuente. Una fuente web latina típica incluye caracteres para docenas de idiomas, muchos de los cuales tu tienda no usa. Al crear un subconjunto con solo los caracteres que tu tienda necesita, puedes reducir el tamaño de los archivos de fuentes entre un 50 y un 70%.

La herramienta pyftsubset de la biblioteca Python fonttools es la forma más fiable de crear subconjuntos de fuentes. Puedes especificar exactamente qué rangos Unicode incluir. Para una tienda que opera solo en español, podrías crear un subconjunto de Latín Básico (U+0020-007F) más Suplemento Latín-1 (U+00A0-00FF) para símbolos de moneda y caracteres acentuados.

Para tiendas que operan en múltiples idiomas, necesitas ser más cuidadoso. Incluye los rangos Unicode para todos los idiomas que tu tienda soporta. El CSS de Google Fonts realmente hace esto automáticamente con descriptores unicode-range, cargando subconjuntos de caracteres bajo demanda, pero las fuentes alojadas localmente necesitan subsetting manual.

Un enfoque más sencillo es usar el formato WOFF2 exclusivamente y eliminar el soporte para formatos más antiguos. WOFF2 usa compresión Brotli y produce archivos un 30% más pequeños que WOFF. Todos los navegadores modernos soportan WOFF2, así que a menos que necesites soportar Internet Explorer 11, no hay razón para incluir formatos WOFF, TTF o EOT. Muchos temas de PrestaShop todavía incluyen los cuatro formatos por compatibilidad con versiones anteriores que ya no es necesaria.

Pilas de fuentes del sistema: La alternativa sin coste

La solución más radical al rendimiento de fuentes es no usar fuentes web en absoluto. Los sistemas operativos modernos incluyen fuentes de alta calidad que se ven excelentes en pantalla. Una pila de fuentes del sistema usa cualquier fuente que el sistema operativo proporcione, lo que significa cero archivos de fuentes que descargar y renderizado de texto instantáneo.

La pila moderna de fuentes del sistema se ve así: font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, "Helvetica Neue", Arial, sans-serif. Esto te da San Francisco en dispositivos Apple, Segoe UI en Windows y Roboto en Android. Todas estas son fuentes sans-serif limpias, modernas y altamente legibles.

GitHub, Bootstrap 5 y muchos sitios web de alto rendimiento usan pilas de fuentes del sistema. La diferencia visual entre una fuente del sistema y una fuente de Google como Open Sans o Roboto es mínima, especialmente para el texto del cuerpo. La mayoría de tus clientes no notarán ni les importará si tu tienda usa Roboto cargada desde un servidor o Roboto ya instalada en su teléfono Android.

Para implementar una pila de fuentes del sistema en PrestaShop, necesitas modificar el CSS de tu tema para reemplazar las declaraciones font-family existentes, eliminar las reglas @font-face y las etiquetas link de Google Fonts, y eliminar los archivos de fuentes del directorio de recursos de tu tema. Si estás usando un tema hijo, puedes sobreescribir las declaraciones de fuente del tema padre sin modificar los archivos del tema padre.

¿Y las fuentes de iconos?

Si eliminas FontAwesome u otra fuente de iconos, necesitas una alternativa para mostrar iconos. El mejor enfoque moderno es SVG en línea. Los iconos SVG se renderizan de forma nítida a cualquier tamaño, pueden estilizarse con CSS y solo añaden peso por los iconos específicos que usas en lugar de cargar una biblioteca de iconos completa.

El tema Hummingbird de PrestaShop usa iconos SVG de forma nativa, que es una de las razones por las que rinde mejor que Classic. Si tu tema usa FontAwesome, puedes reemplazar iconos individuales con SVGs de fuentes como Heroicons, Feather Icons o incluso los propios archivos SVG de FontAwesome (que están disponibles por separado de la versión de fuente).

Para una tienda PrestaShop, normalmente necesitas menos de 30 iconos únicos: carrito, búsqueda, cuenta de usuario, corazón/lista de deseos, flechas, logotipos de redes sociales y algunos iconos específicos de categorías. Como SVGs en línea, estos podrían sumar entre 10 y 15KB, comparado con los 150-200KB de la fuente y CSS completos de FontAwesome.

Medición del impacto

Después de eliminar las fuentes no utilizadas, mide la mejora. Ejecuta Lighthouse antes y después, comparando la puntuación de Rendimiento, First Contentful Paint (FCP) y Largest Contentful Paint (LCP). La optimización de fuentes típicamente mejora el FCP entre 200 y 500ms en conexiones móviles.

Verifica el tamaño total de transferencia en la pestaña Red de DevTools. Una tienda PrestaShop bien optimizada debería transferir menos de 50KB de datos de fuentes en total. Si cambias a fuentes del sistema, esa cifra baja a cero.

También verifica que tu tienda siga viéndose correcta. Revisa todos los tipos de página: inicio, categoría, producto, carrito y checkout. Algunos temas usan fuentes específicas para elementos específicos, y eliminar una fuente podría causar un renderizado de respaldo inesperado. Siempre prueba exhaustivamente antes de desplegar cambios de fuentes en producción.

Resumen: Lista de verificación de carga de fuentes

Audita tu carga de fuentes actual con la pestaña Red de DevTools filtrada por fuentes. Identifica qué fuentes se usan realmente verificando la cobertura de CSS. Elimina cualquier familia o peso de Google Fonts que no uses. Reemplaza las fuentes de iconos completas con versiones de subconjunto o SVGs en línea. Añade font-display: swap a todas las declaraciones @font-face restantes. Aloja tus fuentes localmente en lugar de cargarlas desde el CDN de Google. Considera usar solo WOFF2 para eliminar formatos más antiguos y pesados. Evalúa si las fuentes del sistema podrían reemplazar tus fuentes web completamente. Mide antes y después con Lighthouse y WebPageTest. El objetivo es sencillo: carga solo lo que necesitas, cárgalo de forma eficiente y nunca hagas esperar a tus visitantes por fuentes que no pueden ver.

Leer respuesta completa

Dos temas oficiales, dos filosofías diferentes

PrestaShop incluye dos temas oficiales: Classic y Hummingbird. Classic ha sido el tema predeterminado desde que PrestaShop 1.7 se lanzó en 2016. Hummingbird llegó con PrestaShop 8.x como una alternativa moderna diseñada para el rendimiento y la preparación hacia el futuro. Elegir entre ellos no es simplemente cuestión de cuál se ve mejor. Los dos temas representan enfoques fundamentalmente diferentes de la arquitectura front-end, y tu elección afecta al rendimiento, la compatibilidad con módulos, el esfuerzo de personalización y la mantenibilidad a largo plazo.

Este artículo ofrece una comparación exhaustiva basada en la arquitectura, datos reales de rendimiento, consideraciones prácticas y las situaciones específicas en las que cada tema tiene sentido. Ya sea que estés iniciando una nueva tienda o considerando una migración, esto te ayudará a tomar una decisión informada.

Arquitectura: Qué cambió y por qué

Classic fue construido sobre Bootstrap 4, jQuery y plantillas Smarty. Sigue un enfoque tradicional de renderizado en el servidor donde el servidor genera páginas HTML completas y las envía al navegador. JavaScript se usa principalmente para elementos interactivos como el carrito, la página de producto y el checkout. El CSS se compila desde archivos Sass y se entrega como una sola hoja de estilos grande.

Hummingbird fue construido como una reimaginación desde cero. Usa Bootstrap 5, abandona jQuery en favor de JavaScript vanilla e introduce una arquitectura basada en componentes. El CSS es más modular, el JavaScript es más ligero y el peso total de los recursos es significativamente menor.

La eliminación de jQuery es el cambio arquitectónico más trascendental. jQuery añadía aproximadamente 87KB (30KB comprimidos con gzip) a cada carga de página y fomentaba un estilo de codificación donde los módulos manipulaban libremente el DOM sin coordinación. Hummingbird reemplaza jQuery con APIs modernas del navegador como fetch, querySelector, classList y delegación de eventos. Esto significa que el tema en sí es más rápido, pero los módulos que dependen de jQuery necesitan actualizaciones.

Bootstrap 5 trae sus propios cambios. Elimina jQuery como dependencia (alineándose con el enfoque de Hummingbird), usa propiedades CSS personalizadas (variables) para una tematización más fácil, mejora el sistema de rejilla con mejores utilidades responsive y actualiza los patrones de marcado de componentes. Pasar de Bootstrap 4 a 5 afecta cualquier CSS personalizado o sobreescrituras de plantillas que referencien clases específicas de Bootstrap.

Comparación de rendimiento: Números reales

El rendimiento es la razón principal por la que PrestaShop creó Hummingbird, y los números respaldan la decisión. Probar ambos temas en una instalación idéntica de PrestaShop 8.1 con los mismos productos, módulos y configuración de servidor revela diferencias significativas.

En una página de producto típica medida con Lighthouse en una conexión móvil simulada, Classic obtiene puntuaciones en el rango de 45-55 para Rendimiento, mientras que Hummingbird obtiene entre 65-75. Las métricas específicas cuentan una historia más clara.

First Contentful Paint (FCP) mejora aproximadamente entre 0,5 y 1,0 segundos con Hummingbird. Esto se debe principalmente al menor peso del CSS y a la ausencia de jQuery bloqueando el renderizado. Largest Contentful Paint (LCP) mejora en un margen similar porque la ruta crítica de renderizado es más corta.

Total Blocking Time (TBT) experimenta la mejora más dramática. El JavaScript basado en jQuery de Classic crea un bloqueo significativo del hilo principal mientras el navegador analiza y ejecuta la biblioteca más todos los scripts de módulos dependientes de jQuery. El enfoque de JavaScript vanilla de Hummingbird reduce el TBT entre un 40 y un 60% en configuraciones típicas.

Cumulative Layout Shift (CLS) es aproximadamente equivalente entre ambos temas cuando están correctamente configurados, ya que la estabilidad del diseño depende más de las dimensiones de las imágenes y la implementación de la carga diferida que de la elección del framework.

El tamaño total de transferencia cuenta otra parte de la historia. Una instalación predeterminada de Classic transfiere aproximadamente entre 350 y 450KB de CSS y JavaScript en la primera carga de página. Hummingbird reduce esto a 200-300KB. La diferencia se acumula a lo largo de toda la sesión de navegación mientras los visitantes navegan por tu tienda.

Estos números asumen una instalación limpia. En la práctica, los módulos de terceros a menudo añaden su propio CSS y JavaScript, lo que puede reducir o ampliar la brecha dependiendo de qué tan bien estén optimizados esos módulos para cada tema.

Compatibilidad de módulos: El gran inconveniente

Aquí es donde las ventajas de Hummingbird vienen con una advertencia significativa. Muchos módulos de PrestaShop fueron construidos pensando en la arquitectura de Classic. Dependen de jQuery, usan patrones de marcado de Bootstrap 4 y asumen estructuras de plantilla específicas que Classic proporciona.

Cuando instalas estos módulos en Hummingbird, varias cosas pueden romperse. La funcionalidad JavaScript que depende de jQuery fallará silenciosamente o lanzará errores. Los diálogos modales, menús desplegables y otros componentes de Bootstrap 4 pueden no renderizarse correctamente con el marcado y nombres de clases modificados de Bootstrap 5. Las sobreescrituras de plantillas que asumen la estructura de plantilla de Classic no funcionarán con las plantillas reorganizadas de Hummingbird.

La gravedad de este problema depende de tu conjunto de módulos. Los módulos principales de PrestaShop son compatibles con ambos temas. Los módulos de terceros bien mantenidos de desarrolladores activos normalmente soportan Hummingbird. Sin embargo, los módulos más antiguos, los módulos de nicho o los módulos de desarrolladores que han dejado de actualizar sus productos pueden funcionar solo con Classic.

Antes de elegir Hummingbird, debes probar cada módulo que planees usar. Instálalos en un entorno de staging con Hummingbird activo y prueba exhaustivamente cada funcionalidad. Presta especial atención a la funcionalidad dependiente de JavaScript como carritos AJAX, campos de personalización de productos, vistas rápidas y pasos del checkout.

Algunos desarrolladores de módulos incluyen archivos de plantilla separados para Classic y Hummingbird. Cuando ves directorios como views/templates/hook/classic/ y views/templates/hook/hummingbird/ en un módulo, ese módulo soporta explícitamente ambos temas. Este es el estándar de oro para la compatibilidad.

Smarty vs Twig: Consideraciones de futuro

PrestaShop ha anunciado su intención de hacer la transición de Smarty a Twig como motor de plantillas para el front office. Esta transición se ha discutido durante años y está parcialmente implementada en el back office. Hummingbird está diseñado teniendo en cuenta esta transición, aunque a partir de PrestaShop 8.x y 9.x, ambos temas todavía usan Smarty para las plantillas del front office.

La relevancia para tu elección de tema es indirecta pero importante. La estructura de plantillas de Hummingbird está organizada de manera que hará la eventual migración de Smarty a Twig más fluida. Si construyes personalizaciones extensas sobre la estructura de plantillas de Classic, podrías enfrentar un esfuerzo de migración mayor cuando (no si) PrestaShop complete la transición a Twig.

Dicho esto, esta transición ha estado "llegando pronto" durante varios años. Tomar una decisión hoy basándose únicamente en un futuro cambio de motor de plantillas es prematuro. Elige basándote en necesidades actuales y concretas y acepta que cierto esfuerzo de migración será necesario independientemente del tema que elijas cuando la transición a Twig suceda.

Enfoque de personalización

Personalizar Classic está bien documentado y es ampliamente conocido. Existen cientos de tutoriales, miles de publicaciones en foros y años de conocimiento comunitario sobre cómo modificar Classic. El tema usa Sass directo para los estilos, jQuery tradicional para la interactividad y plantillas Smarty que son fáciles de leer y modificar.

Personalizar Hummingbird requiere habilidades actualizadas. Necesitas sentirte cómodo con CSS moderno (propiedades personalizadas, selectores modernos, container queries), JavaScript vanilla (sin la muleta de jQuery) y el enfoque utility-first de Bootstrap 5. La curva de aprendizaje es más pronunciada si tu equipo está acostumbrado al desarrollo basado en jQuery.

Sin embargo, las propiedades CSS personalizadas de Hummingbird hacen que ciertos tipos de personalización sean mucho más fáciles de lo que eran con Classic. ¿Quieres cambiar el color primario en todo el tema? Modifica una sola propiedad CSS personalizada. Con Classic, necesitabas rastrear cada variable Sass, recompilar y lidiar con conflictos de especificidad.

Hummingbird también usa una estructura HTML más semántica, lo que facilita apuntar a elementos con selectores CSS y mejora la accesibilidad. Los archivos de plantilla están mejor organizados con una separación de responsabilidades más clara.

Soporte de temas hijo

Ambos temas soportan temas hijo, que es la forma recomendada de personalizar un tema de PrestaShop sin modificar directamente los archivos del tema padre. Los temas hijo te permiten sobreescribir plantillas específicas, añadir CSS y JavaScript personalizados, y mantener tus personalizaciones a lo largo de las actualizaciones del tema.

El mecanismo de tema hijo de Classic es maduro y está bien probado. Creas un directorio de tema hijo, defines un theme.yml que referencia a Classic como padre y sobreescribes selectivamente los archivos que necesitas cambiar. Este flujo de trabajo ha sido estable desde PrestaShop 1.7.

El soporte de temas hijo de Hummingbird funciona de la misma manera a nivel de framework pero tiene algunas diferencias prácticas. Debido a que las plantillas de Hummingbird están estructuradas de forma diferente, las sobreescrituras de un tema hijo basado en Classic no pueden reutilizarse. Necesitas crear nuevas sobreescrituras basadas en la estructura de plantillas de Hummingbird.

PrestaShop 8.x mejoró el manejo de temas hijo en general, facilitando la sobreescritura de recursos (CSS y JavaScript) y plantillas parciales. Estas mejoras benefician por igual a los temas hijo tanto de Classic como de Hummingbird.

Si estás encargando un tema personalizado a un desarrollador, comenzar con Hummingbird como padre es la mejor opción a largo plazo. La arquitectura más limpia significa menos deuda técnica, y el enfoque moderno de CSS significa que se necesitan menos sobreescrituras para las personalizaciones comunes.

Ruta de migración: De Classic a Hummingbird

Si actualmente estás usando Classic y considerando un cambio a Hummingbird, esto es lo que la migración realmente implica.

Las sobreescrituras de plantillas necesitan reconstruirse desde cero. No puedes simplemente copiar tus sobreescrituras de Classic a un tema hijo de Hummingbird. La estructura de archivos de plantilla, los nombres de variables y los nombres de bloques son diferentes. Necesitas examinar cada sobreescritura, entender qué logra y recrearla usando la estructura de plantillas de Hummingbird.

El CSS personalizado necesita revisión y probablemente una revisión significativa. Si tu CSS apunta a clases de Bootstrap 4, esos nombres de clase pueden haber cambiado en Bootstrap 5. Si tu CSS usa patrones dependientes de jQuery (como estilizar elementos basándose en clases añadidas por jQuery), estos se romperán. Si tu CSS usa nombres de clase específicos del tema Classic, estos pueden no existir en Hummingbird.

El JavaScript personalizado necesita reescribirse. Cualquier código jQuery debe convertirse a JavaScript vanilla. Esta es a menudo la parte más laboriosa de la migración porque el código jQuery tiende a estar profundamente entrelazado con patrones de manipulación del DOM que necesitan ser repensados.

La compatibilidad de módulos necesita verificarse para cada módulo instalado. Como se discutió anteriormente, los módulos que dependen de jQuery o Bootstrap 4 pueden necesitar actualizaciones o reemplazos.

Un cronograma realista para migrar una tienda Classic moderadamente personalizada a Hummingbird es de 40 a 80 horas de trabajo de desarrollador. Este no es un proyecto de fin de semana. Planifícalo como un esfuerzo de desarrollo formal con un entorno de staging, pruebas exhaustivas y un plan de reversión.

Cuándo elegir Classic

Elige Classic cuando tu tienda depende de módulos de terceros más antiguos que no han sido actualizados para compatibilidad con Hummingbird. Elígelo cuando tu equipo de desarrollo se sienta más cómodo con jQuery y Bootstrap 4 y no tengas presupuesto para capacitación o contratación. Elígelo cuando estés construyendo con un plazo ajustado y necesites la selección más amplia posible de temas y módulos compatibles del marketplace de PrestaShop.

Classic también es la opción más segura para tiendas que ejecutan PrestaShop 1.7.x o versiones tempranas de 8.0.x. Hummingbird fue introducido más tarde en el ciclo 8.x y puede no estar completamente disponible o estable en versiones más antiguas de PrestaShop.

Si tu tienda ya está funcionando con Classic con personalizaciones extensas y rindiendo adecuadamente, puede que no haya una razón convincente para migrar. Las ganancias de rendimiento de Hummingbird son reales pero pueden no justificar el esfuerzo de migración si tu tienda ya carga rápidamente y convierte bien.

Cuándo elegir Hummingbird

Elige Hummingbird cuando estés iniciando una nueva tienda PrestaShop 8.x o 9.x desde cero. Las ventajas de rendimiento son gratuitas cuando no tienes personalizaciones heredadas que migrar. Elígelo cuando el rendimiento sea una prioridad máxima para tu negocio, particularmente si tu audiencia es principalmente de usuarios móviles en conexiones lentas donde cada kilobyte importa.

Elige Hummingbird cuando quieras preparar tu tienda para el futuro. A medida que PrestaShop continúa evolucionando hacia prácticas modernas de front-end, Hummingbird recibirá la mayor atención de desarrollo y será el primero en beneficiarse de las nuevas funcionalidades.

Elígelo cuando tengas desarrolladores cómodos con JavaScript y CSS modernos. La arquitectura de Hummingbird es más limpia y más mantenible para equipos con habilidades actuales de front-end.

Y elígelo cuando te importe la accesibilidad. El HTML semántico, los atributos ARIA y el soporte de navegación por teclado de Hummingbird son notablemente mejores que los de Classic. Si tu tienda necesita cumplir los estándares de accesibilidad WCAG, Hummingbird te da un mejor punto de partida.

La cuestión de los temas de terceros

Muchos propietarios de tiendas se saltan ambos temas oficiales por completo y compran un tema de terceros del marketplace PrestaShop Addons o de vendedores independientes. Estos temas están casi siempre basados en la arquitectura de Classic porque Classic ha estado disponible durante mucho más tiempo y representa la base instalada más grande.

Si estás usando un tema de terceros, la cuestión Classic vs Hummingbird es en gran medida académica para tu tienda actual. El desarrollador de tu tema tomó las decisiones arquitectónicas por ti. Sin embargo, al evaluar nuevos temas de terceros, verifica si están construidos sobre las bases de Classic o Hummingbird. Los temas construidos sobre Hummingbird rendirán mejor y mantendrán la compatibilidad por más tiempo.

Ten cuidado con los temas de terceros que afirman estar "basados en Hummingbird" pero en realidad solo toman prestado su estilo visual mientras mantienen la arquitectura dependiente de jQuery de Classic por debajo. Verifica las dependencias de JavaScript del tema y el framework CSS para confirmarlo.

Veredicto: No hay respuesta incorrecta, pero hay una mejor

Para nuevas tiendas en PrestaShop 8.x o posterior, Hummingbird es la recomendación clara. Es más rápido, más moderno, está mejor mantenido y está más preparado para el futuro. La preocupación por la compatibilidad de módulos está disminuyendo a medida que el ecosistema se pone al día, y comenzar desde cero significa que no tienes costes de migración heredados.

Para tiendas existentes que ejecutan Classic con personalizaciones significativas, la decisión requiere un análisis de coste-beneficio. Calcula el esfuerzo de migración honestamente, mide tu rendimiento actual para entender la ganancia potencial, y decide si la mejora justifica la inversión. A veces la respuesta es sí, a veces no, y a veces la respuesta correcta es esperar a tu próximo rediseño importante para hacer el cambio.

Independientemente del tema que elijas, los principios de buen rendimiento front-end se aplican por igual: minimiza el tamaño de los recursos, carga diferida del contenido debajo del pliegue, optimiza las imágenes y audita regularmente la velocidad de tu página. Una tienda Classic bien optimizada superará a una tienda Hummingbird mal configurada en todo momento. El tema proporciona los cimientos, pero la ejecución determina el resultado.

Leer respuesta completa

Tu tema probablemente es más lento de lo que crees

Todo propietario de una tienda PrestaShop tiene una opinión sobre la velocidad de su tema, pero muy pocos tienen datos reales. Decir "mi tienda se siente rápida" no tiene sentido cuando Google está midiendo tus Core Web Vitals al milisegundo y usando esos números para determinar tu posicionamiento en búsquedas. Para entender el impacto real del rendimiento de tu tema, necesitas un enfoque de medición sistemático que aísle la contribución del tema del rendimiento del servidor, la sobrecarga de los módulos y las condiciones de la red.

Este artículo recorre una metodología completa de medición del rendimiento. Aprenderás a usar Lighthouse, WebPageTest, Chrome DevTools y monitoreo de usuarios reales para cuantificar exactamente cuánto te cuesta tu tema en tiempo de carga, interactividad y estabilidad visual. Más importante aún, aprenderás a separar el rendimiento del tema de todo lo demás para que puedas tomar decisiones informadas sobre optimización o reemplazo.

Por qué el rendimiento del tema importa más de lo que piensas

Tu tema controla toda la experiencia front-end. Determina qué archivos CSS se cargan, cuánto JavaScript se ejecuta, cómo se renderizan las imágenes, cómo se cargan las fuentes y cómo se construye la maquetación. Un tema mal construido puede añadir de 2 a 5 segundos a tu tiempo de carga de página independientemente de lo rápido que sea tu servidor o lo bien codificados que estén tus módulos.

Los Core Web Vitals de Google miden directamente aspectos de la experiencia del usuario que tu tema controla. Largest Contentful Paint (LCP) mide qué tan rápido se hace visible el contenido principal. First Input Delay (FID) y su sucesor Interaction to Next Paint (INP) miden qué tan rápido responde la página a la interacción del usuario. Cumulative Layout Shift (CLS) mide la estabilidad visual mientras la página carga. Las tres métricas están fuertemente influenciadas por la arquitectura del tema.

El impacto empresarial es concreto. Las investigaciones muestran consistentemente que cada segundo adicional de tiempo de carga reduce las tasas de conversión entre un 7 y un 10%. Un tema que añade 2 segundos de tiempo de carga innecesario podría estar costándote entre un 15 y un 20% de tus ventas potenciales. Eso convierte la medición del rendimiento del tema no en un ejercicio técnico sino en un análisis crítico para el negocio.

Configuración de tu entorno de pruebas

Antes de comenzar a medir, necesitas un entorno de pruebas controlado. Medir el rendimiento en tu tienda en producción mientras los clientes navegan y la carga del servidor fluctúa producirá resultados inconsistentes. Necesitas minimizar las variables.

Idealmente, configura una copia de staging de tu tienda PrestaShop. Esta debe ser una copia idéntica de tu tienda de producción ejecutándose en el mismo hardware de servidor o una configuración similar. Instala los mismos módulos, importa los mismos productos y usa la misma configuración del tema. La única diferencia debería ser que ningún cliente real esté accediendo a ella.

Si no es posible un entorno de staging completo, ejecuta tus pruebas durante las horas de menor tráfico cuando la carga del servidor es mínima. Ejecuta cada prueba al menos tres veces y promedia los resultados para tener en cuenta la variabilidad de la red y del servidor.

Deshabilita cualquier proxy de caché (como Cloudflare) para tus pruebas, o usa la URL de staging que evite el CDN. El caché del CDN oculta el verdadero rendimiento de tu tema al servir contenido almacenado en caché. Quieres medir lo que sucede cuando un visitante llega a tu servidor de origen con una caché de navegador vacía.

Documenta tu configuración base. Anota la versión de PHP, la versión de PrestaShop, los módulos activos, la configuración CCC (Combinar, Comprimir, Cachear) y las especificaciones del servidor. Necesitarás esta información para reproducir resultados y comparar mediciones a lo largo del tiempo.

Lighthouse: Tu punto de partida

Google Lighthouse está integrado en Chrome DevTools y proporciona la auditoría de rendimiento más accesible disponible. Simula un dispositivo móvil en una conexión con throttling y mide las métricas clave que Google usa para el posicionamiento en búsquedas.

Para ejecutar una auditoría de Lighthouse, abre Chrome DevTools (F12), navega a la pestaña Lighthouse, selecciona "Rendimiento" como categoría, elige "Móvil" como dispositivo y haz clic en "Analizar carga de página". Lighthouse recargará la página en un entorno simulado y generará un informe detallado.

La puntuación de Rendimiento (0-100) es un compuesto ponderado de seis métricas: First Contentful Paint (10%), Speed Index (10%), Largest Contentful Paint (25%), Total Blocking Time (30%), Cumulative Layout Shift (25%). Ten en cuenta que Total Blocking Time y Largest Contentful Paint juntos representan el 55% de la puntuación, por lo que estas son las métricas más susceptibles de verse afectadas por la calidad del tema.

Ejecuta la auditoría en al menos cuatro tipos de página: tu página de inicio, una página de categoría, una página de producto y la página del carrito o checkout. Cada tipo de página tiene diferente complejidad de DOM y requisitos de recursos, y tu tema puede rendir de forma muy diferente en cada uno.

Advertencia importante: Lighthouse se ejecuta en un entorno simulado con throttling de CPU y red. Los números absolutos que produce no coinciden con el rendimiento del mundo real. Son útiles para comparaciones (antes vs después, tema A vs tema B) pero no deben tomarse como la experiencia real que tienen tus clientes. Para números del mundo real, necesitas el Monitoreo de Usuarios Reales, cubierto más adelante en este artículo.

Registra cada resultado de Lighthouse en una hoja de cálculo. Incluye la URL probada, la fecha y hora, la puntuación general de Rendimiento y el valor de cada métrica individual. Esto crea una línea base a la que puedes referirte mientras realizas cambios.

WebPageTest: Análisis en profundidad

WebPageTest (webpagetest.org) es una herramienta gratuita que proporciona mucho más detalle que Lighthouse. Ejecuta navegadores reales en hardware real desde ubicaciones de todo el mundo, dándote una imagen más precisa de lo que experimentan tus clientes.

Inicia una prueba introduciendo la URL de tu tienda, seleccionando una ubicación de prueba cercana a tu audiencia principal y eligiendo una velocidad de conexión. Para tiendas europeas, usa una ubicación de prueba en Frankfurt o Londres con un perfil de conexión Cable o 4G. Ejecuta al menos tres pruebas para obtener resultados medianos.

El gráfico de cascada es el resultado más valioso de WebPageTest. Muestra cada recurso individual que carga tu página, en orden cronológico, con el tiempo que cada recurso tarda en descargarse. Esta visualización hace inmediatamente obvio qué recursos bloquean el renderizado y cuáles se cargan innecesariamente.

Busca estos patrones en la cascada. CSS y JavaScript que bloquean el renderizado aparecen como barras largas en la parte superior del gráfico antes de que se renderice cualquier contenido. Archivos de fuentes grandes que se descargan antes del contenido crítico indican una estrategia deficiente de carga de fuentes. Solicitudes de terceros (analítica, widgets sociales, plugins de chat) que bloquean o retrasan los recursos de tu tema.

WebPageTest también proporciona una vista de tira de película que muestra capturas de pantalla de tu página a intervalos de 100ms durante la carga. Esto es increíblemente útil para entender la experiencia visual de carga. Puedes ver exactamente cuándo aparece el texto, cuándo se renderizan las imágenes y cuándo ocurren los cambios de diseño.

La vista "Desglose de Contenido" muestra el peso total de tu página desglosado por tipo de contenido: HTML, CSS, JavaScript, imágenes, fuentes y otros recursos. Para un tema bien optimizado, el CSS debería estar por debajo de 100KB comprimido, el JavaScript por debajo de 150KB comprimido y las fuentes por debajo de 50KB. Si tus números son significativamente superiores, tu tema lleva peso excesivo.

Pestaña Performance de Chrome DevTools: Análisis fotograma a fotograma

La pestaña Performance de Chrome DevTools proporciona el análisis más granular disponible. Registra una línea temporal detallada de todo lo que el navegador hace durante la carga de la página, incluyendo ejecución de JavaScript, cálculos de diseño, operaciones de pintado y composición.

Para usarla, abre DevTools (F12), ve a la pestaña Performance, marca "Capturas de pantalla" y "Web Vitals", selecciona el throttle de red "Slow 3G" y la ralentización de CPU "4x slowdown", luego haz clic en el botón de grabación y recarga la página. Detén la grabación una vez que la página haya cargado completamente.

La línea temporal resultante muestra varios carriles de información. El carril Network muestra las solicitudes de recursos. El carril Frames muestra capturas de pantalla en momentos clave. El carril Main muestra la ejecución de JavaScript en el hilo principal. Los marcadores de Web Vitals muestran exactamente cuándo ocurren los eventos de FCP, LCP y CLS.

Concéntrate en el carril del hilo principal (Main). Los bloques amarillos largos son ejecución de JavaScript. Busca tareas de JavaScript que tarden más de 50ms, ya que estas son "tareas largas" que bloquean la interacción del usuario y contribuyen al Total Blocking Time. Identifica qué ficheros causan estas tareas largas haciendo clic en ellas para ver la pila de llamadas. Si las tareas largas provienen de los archivos JavaScript de tu tema, ese es un problema de rendimiento del tema.

Los bloques rojos en el carril Main indican layout thrashing, donde el navegador se ve obligado a recalcular el diseño múltiples veces en rápida sucesión. Esto ocurre frecuentemente cuando el JavaScript lee propiedades de diseño (offsetHeight, getBoundingClientRect) y luego modifica el DOM en un bucle. El código del tema que causa layout thrashing es una fuente común de puntuaciones INP deficientes.

Las pestañas "Bottom-Up" y "Call Tree" debajo de la línea temporal te permiten ordenar la ejecución de JavaScript por tiempo total o tiempo propio. Esto muestra qué funciones específicas consumen más tiempo de CPU durante la carga de la página. Si las funciones del tema dominan esta lista, tu tema es el cuello de botella del rendimiento.

Análisis de cascada de red para recursos del tema

La pestaña Red en DevTools proporciona una vista diferente de la carga de recursos. Filtra por tipo de recurso (CSS, JS, Font, Img) para aislar los recursos específicos del tema y entender su impacto.

Comienza identificando todos los recursos que pertenecen a tu tema. Estos normalmente se cargan desde rutas como /themes/tu-tema/assets/ o similar. Anota el número total y el tamaño combinado. Luego identifica los recursos cargados por módulos (desde rutas /modules/) para entender la contribución de los módulos por separado.

Activa la casilla "Deshabilitar caché" y recarga. Esto simula un visitante nuevo. Anota el tamaño total de transferencia y el tiempo hasta DOMContentLoaded y los eventos Load. Luego recarga sin la casilla para ver la experiencia con caché (visitante recurrente). La diferencia te indica cuánto se beneficia tu tema de la caché del navegador.

Observa la columna "Iniciador" para entender la cadena de dependencias. Un archivo CSS cargado por la plantilla head de tu tema es un recurso crítico que bloquea el renderizado. Un archivo JavaScript cargado con el atributo async o defer es no bloqueante. Entender estas dependencias te ayuda a identificar qué recursos del tema están en la ruta crítica y cuáles podrían diferirse.

Usa la columna "Prioridad" (habilítala mediante el menú contextual del encabezado de columna) para ver cómo el navegador prioriza cada recurso. Los recursos con prioridad "Highest" o "High" son los que el navegador considera más importantes. Si tu tema carga recursos no críticos con alta prioridad, esa es una oportunidad de optimización.

La comparación con y sin tema

Para aislar verdaderamente el impacto del rendimiento de tu tema, necesitas una comparación. El enfoque más riguroso es probar tu tienda con tu tema actual y luego cambiar al tema mínimo predeterminado de PrestaShop y probar de nuevo.

En tu entorno de staging, ejecuta un conjunto completo de mediciones con tu tema actual activo. Registra todas las métricas. Luego cambia el tema a Classic de PrestaShop (o Hummingbird si estás en PrestaShop 8.x+) y ejecuta las mismas mediciones. La diferencia representa el impacto incremental de tu tema respecto al predeterminado.

Esta comparación no es perfecta porque el tema predeterminado no tiene tus personalizaciones y la salida visual es diferente. Pero te da un techo para cuánta mejora de rendimiento es posible mediante la optimización del tema. Si tu tema actual puntúa 30 puntos menos que el predeterminado en Lighthouse, sabes que hay un margen significativo para la mejora.

Una comparación más controlada implica deshabilitar progresivamente las funcionalidades del tema. Comienza con todas las funcionalidades habilitadas, mide, luego deshabilita las fuentes personalizadas y mide de nuevo. Deshabilita los efectos JavaScript del tema y mide. Elimina la fuente de iconos del tema. Cada paso te muestra el coste incremental de esa funcionalidad específica.

Core Web Vitals: Lo que Google realmente mide

Los Core Web Vitals son las tres métricas que Google usa con fines de posicionamiento. Se miden en usuarios reales a través del Chrome User Experience Report (CrUX), no mediante herramientas de laboratorio como Lighthouse. Entender la diferencia entre mediciones de laboratorio y de campo es fundamental.

Las mediciones de laboratorio (Lighthouse, WebPageTest) usan condiciones simuladas. Las mediciones de campo (CrUX, Monitoreo de Usuarios Reales) capturan experiencias reales de usuarios en diferentes dispositivos, redes y ubicaciones. Tu puntuación de Lighthouse podría ser 75, pero si la mayoría de tus clientes están en teléfonos más antiguos con conexiones lentas, tus datos de campo podrían contar una historia muy diferente.

Para ver tus datos de campo, usa el informe de Core Web Vitals de Google Search Console o PageSpeed Insights (pagespeed.web.dev). PageSpeed Insights muestra tanto datos de laboratorio como de campo cuando están disponibles. Si tu sitio tiene suficiente tráfico, verás datos de usuarios reales junto a la simulación de Lighthouse.

Los umbrales para buenos Core Web Vitals son: LCP por debajo de 2,5 segundos, INP por debajo de 200 milisegundos y CLS por debajo de 0,1. Google evalúa el percentil 75 de tus usuarios, lo que significa que el 75% de tus usuarios necesitan tener una buena experiencia para que una métrica se clasifique como "buena". Este es un listón alto porque tus visitantes con peor rendimiento (teléfonos antiguos, redes lentas) influyen fuertemente en el percentil 75.

Tu tema impacta directamente en las tres métricas. El LCP se ve afectado por el tamaño del archivo CSS (que bloquea el renderizado), la estrategia de carga de fuentes y la implementación de la imagen principal. El INP se ve afectado por la ejecución de JavaScript, la eficiencia de los event handlers y cómo el tema responde a los clics y desplazamientos. El CLS se ve afectado por los marcadores de posición de imágenes, la inserción dinámica de contenido y la carga de fuentes.

Monitoreo de Usuarios Reales: La verdad de los datos

El Monitoreo de Usuarios Reales (RUM) captura datos de rendimiento de tus visitantes reales mientras navegan por tu tienda. Esta es la medida más precisa del impacto real del rendimiento de tu tema porque refleja los dispositivos, redes y patrones de uso reales de tu audiencia.

Google Analytics 4 captura los Core Web Vitals automáticamente si tienes el fragmento de código gtag.js en tu sitio. Puedes ver estos datos en GA4 en Informes, Experiencia del usuario, o creando una exploración personalizada.

Para un RUM más detallado, servicios dedicados como SpeedCurve, Datadog o la biblioteca JavaScript gratuita web-vitals proporcionan datos granulares. La biblioteca web-vitals (disponible en npm) es particularmente útil porque puedes añadirla a tu tema y enviar datos de rendimiento a cualquier endpoint de analítica.

Con datos RUM, puedes segmentar el rendimiento por tipo de dispositivo (móvil vs escritorio), navegador (Chrome vs Safari vs Firefox), país y tipo de página. Esta segmentación a menudo revela que tu tema rinde de forma muy diferente para diferentes segmentos de audiencia. Un tema podría puntuar bien para usuarios de Chrome en escritorio pero mal para usuarios de Safari en móvil debido a diferencias en el rendimiento del motor JavaScript o el renderizado CSS.

Rastrea los datos RUM a lo largo del tiempo para correlacionar cambios de rendimiento con actualizaciones del tema, instalaciones de módulos o cambios de configuración. Si tu LCP aumenta repentinamente 500ms, verifica qué cambió en tu tema o conjunto de módulos en esa fecha.

Perfilado del lado del servidor: Separando backend de frontend

A veces la velocidad deficiente de una página se atribuye al tema cuando el problema real es el tiempo de procesamiento del lado del servidor. Antes de optimizar tu tema, verifica que el servidor esté generando HTML rápidamente.

PrestaShop incluye un perfilador integrado que puedes habilitar en el back office en Parámetros Avanzados, Rendimiento, Modo Debug. El perfilador añade una barra de depuración en la parte inferior de cada página mostrando el conteo de consultas SQL, el tiempo de ejecución SQL, el tiempo de generación de la página y el uso de memoria.

Una instalación de PrestaShop bien configurada debería generar la mayoría de las páginas en menos de 500ms del lado del servidor. Si la generación del servidor tarda más de un segundo, el problema no es tu tema sino tu servidor, las consultas a la base de datos o los hooks de módulos. Arreglar el tema no ayudará si el servidor tarda 3 segundos solo en generar el HTML.

También puedes medir el tiempo de respuesta del servidor (Time to First Byte, TTFB) desde la pestaña Red en DevTools. Haz clic en la solicitud del documento HTML y observa la sección Timing. El valor "Waiting (TTFB)" muestra cuánto tiempo esperó el navegador a que el servidor respondiera. Resta la latencia de red (que puedes estimar del valor "Connection") para obtener el tiempo de procesamiento aproximado del servidor.

Si tu TTFB es alto pero los recursos de tu tema son rápidos, concéntrate en la optimización del servidor (PHP OPcache, caché de consultas MySQL, Redis/Memcached, caché de objetos de PrestaShop) en lugar de la optimización del tema. Si tu TTFB es rápido pero la página sigue cargando lentamente, el tema es probablemente el cuello de botella.

El framework de benchmarking antes/después

Al hacer cambios de rendimiento en el tema, necesitas una comparación rigurosa antes/después para verificar que el cambio realmente ayudó. Aquí tienes un framework que produce resultados fiables.

Antes de hacer cualquier cambio, ejecuta cinco auditorías de Lighthouse en cada página objetivo y registra la puntuación mediana y las métricas individuales. También ejecuta tres pruebas de WebPageTest y registra los valores medianos. Guarda los informes completos, no solo las puntuaciones, porque podrías necesitar examinar los detalles más tarde.

Realiza tu cambio. Limpia todas las cachés, incluyendo la caché Smarty de PrestaShop, OPcache y cualquier caché CDN. Espera al menos 60 segundos para que OPcache se reinicie completamente si cambiaste archivos PHP.

Ejecuta las mismas cinco auditorías de Lighthouse y tres pruebas de WebPageTest en las mismas páginas. Compara los resultados medianos. Un cambio es significativo si produce una mejora consistente en todas las ejecuciones de prueba. Si algunas ejecuciones muestran mejora y otras muestran regresión, el impacto del cambio está dentro del margen de error de medición.

Sé escéptico con las mejoras pequeñas. Las puntuaciones de Lighthouse pueden variar en más o menos 5 puntos entre ejecuciones idénticas debido a la variabilidad del throttle simulado de red y CPU. Un cambio que mejora tu puntuación de 62 a 65 podría no ser una mejora real. Un cambio de 62 a 75 casi con certeza lo es.

Para la comparación más rigurosa, usa la función de comparación visual de WebPageTest. Introduce tu URL de staging (antes del cambio) y la URL de producción (después del cambio), o ejecuta la misma URL en momentos diferentes y compara las pruebas guardadas. WebPageTest genera una tira de película lado a lado y resalta las diferencias.

Problemas comunes de rendimiento del tema y cómo detectarlos

A través de la medición, identificarás problemas de rendimiento específicos. Estos son los problemas más comunes relacionados con el tema y las métricas que los revelan.

El CSS que bloquea el renderizado aparece como un FCP y LCP alto con una brecha larga entre el TTFB y el FCP en la cascada. La solución es incluir CSS crítico en línea y aplazar las hojas de estilo no críticas. El JavaScript excesivo se manifiesta como TBT alto y puntuaciones INP deficientes. Las tareas largas en la línea temporal de la pestaña Performance confirman esto. La carga de fuentes no optimizada se manifiesta como FOIT (texto invisible) en la tira de película o una brecha entre el FCP y el momento en que el texto realmente aparece. El cambio de diseño por imágenes sin dimensiones o contenido inyectado dinámicamente aparece como puntuaciones CLS altas.

Cada problema tiene una firma de medición específica. Aprender a leer estas firmas es lo que transforma el trabajo de rendimiento de adivinación en ingeniería. Mide primero, diagnostica basándote en datos, corrige el problema específico y luego mide de nuevo para verificar que la corrección funcionó.

Creación de una rutina de monitoreo de rendimiento

La medición del rendimiento no debería ser una actividad puntual. Construye una rutina que detecte regresiones antes de que afecten a tus clientes y al posicionamiento en búsquedas.

Semanalmente, ejecuta Lighthouse en tus cuatro tipos de página clave y registra los resultados. Mensualmente, ejecuta un análisis completo con WebPageTest y compáralo con el mes anterior. Después de cada actualización del tema o instalación de módulos, ejecuta una comparación antes/después. Configura el monitoreo de Core Web Vitals en Google Search Console y revísalo mensualmente.

Considera automatizar esto con herramientas como Lighthouse CI (para ejecuciones automatizadas de Lighthouse en tu pipeline de despliegue) o SpeedCurve (para monitoreo continuo con alertas). Estas herramientas te notifican inmediatamente cuando el rendimiento se degrada, permitiéndote identificar y corregir la causa antes de que afecte a tu posicionamiento en búsquedas.

El objetivo no es una puntuación perfecta en Lighthouse. El objetivo es entender exactamente dónde van tu tiempo y tus recursos en cada carga de página, y tomar decisiones deliberadas y basadas en datos sobre qué optimizar, qué conservar y qué eliminar.

Leer respuesta completa

El verdadero debate detrás del precio de los temas

Todo propietario de una tienda PrestaShop se enfrenta a esta pregunta en algún momento: ¿debería usar un tema gratuito o invertir en uno premium? La respuesta parece obvia a primera vista. Lo gratuito ahorra dinero, lo premium cuesta dinero. Pero el coste real de un tema va mucho más allá de su precio de compra. Un tema gratuito que requiere cientos de euros en trabajo de personalización, causa problemas de rendimiento o carece de funcionalidades críticas puede terminar costando mucho más que un tema premium que funciona correctamente desde el primer momento.

Esta guía desglosa las diferencias reales entre los temas gratuitos y premium de PrestaShop, examina los costes ocultos en ambos casos y te ayuda a tomar una decisión informada basándote en lo que realmente necesitas en lugar de lo que indica la etiqueta del precio.

Lo que realmente ofrecen los temas gratuitos

PrestaShop incluye un tema predeterminado. En PrestaShop 1.7 y 8.x, este es el tema Classic. PrestaShop 9 introduce Hummingbird como nuevo tema por defecto. Estos temas oficiales están genuinamente bien construidos. Siguen los estándares de codificación de PrestaShop, soportan todos los hooks estándar, funcionan correctamente con el sistema de traducciones y reciben actualizaciones junto con la plataforma principal. Para un propietario de tienda que necesita un diseño limpio y funcional y está dispuesto a personalizarlo con CSS, el tema predeterminado es un punto de partida legítimo.

Más allá de los temas oficiales, el panorama de temas gratuitos es mucho más variado en calidad. Los temas gratuitos de desarrolladores de terceros se dividen en varias categorías. Algunos son versiones reducidas de temas premium, diseñados para darte una muestra del trabajo del desarrollador y animarte a actualizar. Estos son típicamente funcionales pero limitados, careciendo de funcionalidades como diseños avanzados de páginas de producto, menús mega o esquemas de colores configurables. Otros son proyectos personales o piezas de portfolio creados por desarrolladores individuales. Estos varían enormemente en calidad, desde sorprendentemente buenos hasta apenas funcionales. Y luego están los temas que son gratuitos porque sirven un propósito distinto al de ser un buen tema, como temas que incluyen adware, temas con enlaces ocultos al sitio del desarrollador, o temas que recopilan datos de uso sin informar al usuario.

El marketplace oficial de PrestaShop Addons ofrece algunos temas gratuitos, y estos deben pasar un proceso básico de revisión. Los temas gratuitos de fuentes desconocidas fuera del marketplace oficial conllevan un riesgo significativamente mayor y deben evaluarse con especial precaución.

Lo que proporcionan los temas premium

Los temas premium de PrestaShop suelen oscilar entre 60 y 300 euros, y la mayoría se sitúa en el rango de 80 a 150 euros. Por este precio, generalmente recibes un tema con un diseño visual pulido que incluye múltiples diseños de página preconstruidos y esquemas de colores, un panel de configuración en el back office que te permite personalizar colores, tipografías, disposiciones y otros elementos visuales sin editar código, una colección de módulos complementarios (menú mega, páginas de producto personalizadas, sliders de imágenes, funcionalidad de blog) diseñados para funcionar perfectamente con el tema, documentación que explica la instalación, configuración y personalización, un período de soporte técnico (típicamente de 3 a 12 meses según el marketplace y el vendedor), y actualizaciones de compatibilidad para nuevas versiones de PrestaShop.

La propuesta de valor de un tema premium no es solo el diseño. Es el tiempo de desarrollo ahorrado. Construir un módulo de menú mega personalizado, un sistema configurable de diseño de páginas de producto y un configurador de tema en el back office desde cero costaría miles de euros en tiempo de desarrollo. Un tema premium agrupa todo esto por una fracción del coste.

Diferencias de calidad en el código

La diferencia más significativa entre los temas gratuitos y premium suele ser invisible para el comprador: la calidad del código. Los desarrolladores de temas premium que venden temas como su negocio principal tienen un incentivo financiero para escribir código limpio y mantenible. Las malas reseñas y las solicitudes de soporte les cuestan tiempo y dinero, por lo que invierten en calidad desde el inicio. Los desarrolladores de temas gratuitos no tienen una relación financiera continua con sus usuarios, ningún coste de soporte por código deficiente ni riesgo reputacional por abandonar el proyecto. Los temas oficiales de PrestaShop tienen una excelente calidad de código, pero la calidad media de los temas gratuitos de terceros es significativamente inferior.

Las diferencias específicas incluyen la organización de plantillas (los temas premium usan jerarquías lógicas con parciales; los temas gratuitos a menudo usan plantillas monolíticas), la arquitectura CSS (los temas premium usan BEM o metodologías similares con propiedades personalizadas adecuadas; los temas gratuitos tienen CSS desestructurado con conflictos de especificidad), y la calidad del JavaScript (los temas premium usan prácticas modernas y funcionan con la gestión de activos de PrestaShop; los temas gratuitos cargan bibliotecas de forma redundante y crean conflictos con módulos).

Soporte y actualizaciones

Cuando algo se rompe en tu tema, ya sea por una actualización de PrestaShop, un conflicto con un módulo o una personalización que salió mal, necesitas ayuda. Aquí es donde la diferencia entre gratuito y premium se vuelve más tangible.

Los temas premium comprados a través de marketplaces oficiales incluyen un período de soporte definido. Durante este período, puedes contactar al desarrollador con preguntas técnicas, informes de errores y problemas de compatibilidad. La calidad del soporte varía entre desarrolladores, pero la obligación contractual existe. Pagaste por un producto y el vendedor tiene la responsabilidad de asegurar que funcione como se describe.

Los temas gratuitos no incluyen ninguna obligación de soporte. Si encuentras un error, tus opciones son arreglarlo tú mismo, contratar a un desarrollador para que lo arregle, o abandonar el tema. El desarrollador original no tiene ningún incentivo para responder a tu informe de error, investigar tu problema o publicar una corrección. Algunos desarrolladores de temas gratuitos ofrecen soporte comunitario a través de foros o issues de GitHub, pero esto es voluntario y poco fiable.

Las actualizaciones siguen el mismo patrón. Los desarrolladores de temas premium publican actualizaciones cuando salen nuevas versiones de PrestaShop, cuando se descubren errores y cuando se añaden nuevas funcionalidades. Estas actualizaciones se distribuyen a través del marketplace y pueden aplicarse desde el back office. Los temas gratuitos pueden no recibir nunca una actualización tras su lanzamiento inicial. Cuando PrestaShop 8 introdujo cambios en el sistema de plantillas, los temas premium se actualizaron. Muchos temas gratuitos desarrollados para PrestaShop 1.7 simplemente fueron abandonados, dejando a sus usuarios atrapados en una versión antigua de PrestaShop o buscando desesperadamente un nuevo tema.

Riesgos de seguridad de los temas gratuitos

La seguridad es un área donde los temas gratuitos conllevan un riesgo genuinamente elevado. Un tema tiene acceso a todo tu front office. Controla qué HTML, CSS y JavaScript se envía a los navegadores de tus clientes. Un tema malicioso o comprometido puede inyectar código de minería de criptomonedas, redirigir a los clientes a sitios de phishing, robar datos de formularios incluyendo información de pago, crear cuentas de administrador ocultas o instalar puertas traseras que persisten incluso después de eliminar el tema.

Los temas premium de marketplaces establecidos pasan por un proceso de revisión que verifica problemas de seguridad conocidos. El marketplace de PrestaShop Addons, ThemeForest y otras plataformas reputadas escanean los temas enviados en busca de código malicioso, vulnerabilidades conocidas y cumplimiento de estándares básicos de seguridad. Esta revisión no es perfecta y pueden seguir existiendo vulnerabilidades, pero proporciona un nivel base de protección.

Los temas gratuitos descargados de sitios web aleatorios no tienen dicha protección. Estás confiando a un desarrollador desconocido el acceso al front end de tu tienda. Incluso si el desarrollador tiene buenas intenciones, su código puede contener vulnerabilidades de seguridad no intencionadas como agujeros de cross-site scripting (XSS), puntos de inyección SQL en manejadores AJAX específicos del tema, o manejo inseguro de subida de archivos en los paneles de configuración del tema.

El tema gratuito más seguro es el tema oficial predeterminado de PrestaShop, porque es mantenido por el equipo principal de PrestaShop y recibe actualizaciones de seguridad junto con la propia plataforma.

El peligro de los temas nulled

Los temas nulled son temas premium que han sido pirateados y distribuidos gratuitamente. Son la categoría más peligrosa de temas de PrestaShop. Usar un tema nulled no es solo una violación de la propiedad intelectual. Es una amenaza directa de seguridad para tu negocio y tus clientes.

Los temas nulled son modificados antes de su distribución. El código de verificación de licencia se elimina (eso es lo que los hace nulled), pero otras modificaciones se añaden frecuentemente al mismo tiempo. Las modificaciones comunes incluyen acceso por puerta trasera que permite al distribuidor acceder al panel de administración de tu tienda en cualquier momento, recolección de datos que envía la información personal de tus clientes y datos de pedidos a servidores externos, inyección de spam SEO que añade enlaces ocultos a sitios de apuestas, farmacéuticos o contenido para adultos en el HTML de tu tienda (dañando tu posicionamiento en buscadores y potencialmente violando regulaciones publicitarias), JavaScript de criptominería que utiliza los dispositivos de tus clientes para minar criptomonedas mientras navegan por tu tienda, y cadenas de redirección que envían un porcentaje de tu tráfico a sitios competidores o páginas fraudulentas.

Estas modificaciones están diseñadas para ser invisibles. Están ofuscadas, se activan solo bajo ciertas condiciones (por ejemplo, solo para visitantes de países específicos o solo después de que la tienda haya estado funcionando durante un cierto período) y están ocultas en archivos que los propietarios de tiendas raramente inspeccionan. Puedes ejecutar un tema nulled durante meses antes de descubrir que ha estado enviando los datos de tus clientes a un servidor en otro país.

No existe ninguna razón legítima para usar un tema nulled. Si no puedes permitirte un tema premium, utiliza el tema gratuito oficial. Es mejor en todos los aspectos medibles que un tema premium nulled.

Comparación de rendimiento

El rendimiento del tema afecta directamente la tasa de conversión de tu tienda y el posicionamiento en buscadores. Google utiliza los Core Web Vitals como factor de posicionamiento, y estas métricas están fuertemente influenciadas por la calidad del tema.

Los temas oficiales Classic y Hummingbird de PrestaShop están optimizados para el rendimiento. Cargan un mínimo de CSS y JavaScript, utilizan estructuras de plantilla eficientes y soportan las funciones de rendimiento integradas de PrestaShop como CCC (Combinar, Comprimir, Cachear) para archivos CSS y JavaScript. Una tienda que ejecuta el tema predeterminado con una configuración de servidor adecuada suele alcanzar buenas puntuaciones en Core Web Vitals sin trabajo de optimización adicional.

Los temas premium varían en rendimiento. Los mejores temas premium igualan o superan el rendimiento del tema predeterminado mientras ofrecen significativamente más funcionalidades. Lo logran mediante técnicas como la carga diferida de imágenes y contenido por debajo del pliegue, la carga condicional de JavaScript (solo cargando el código del carrusel en páginas que tienen carruseles, por ejemplo), CSS optimizado que evita reglas no utilizadas, y uso eficiente de fuentes web con configuraciones adecuadas de font-display. Los peores temas premium, sin embargo, sacrifican rendimiento por complejidad visual, cargando múltiples sliders, bibliotecas de animación y fuentes de iconos en cada página sin importar si son necesarios.

Los temas gratuitos de terceros (excluyendo el predeterminado oficial) tienden a rendir mal. Sin el incentivo comercial para optimizar, los desarrolladores de temas gratuitos a menudo incluyen todas las funcionalidades en todas las páginas, usan imágenes no optimizadas del contenido de demostración que se trasladan a producción, cargan compilaciones completas de bibliotecas en lugar de seleccionar solo los componentes necesarios, y omiten la minificación y concatenación de recursos.

Antes de elegir cualquier tema, prueba su demo con Google PageSpeed Insights y comprueba las puntuaciones de Core Web Vitals. Un tema que puntúa por debajo de 50 en móvil en su propio entorno de demo optimizado rendirá aún peor en tu tienda real con módulos adicionales, más productos y condiciones de alojamiento reales.

Opciones de personalización

La personalización determina cuánto puedes cambiar la apariencia de tu tienda sin escribir código. El tema oficial de PrestaShop ofrece una personalización integrada mínima: logo, favicon y algunos ajustes básicos. Cualquier cambio visual más allá de estos básicos requiere editar archivos CSS o plantillas Smarty.

Los temas premium típicamente incluyen un módulo configurador de tema que proporciona una interfaz gráfica para colores, tipografía, opciones de diseño, configuración de cabecera y pie de página, diseño de la página de producto y visualización de la página de categoría. Estas opciones permiten a un propietario de tienda sin conocimientos técnicos crear una tienda visualmente diferenciada sin tocar código. Los temas gratuitos a veces incluyen opciones básicas de personalización, pero suelen estar limitadas a unas pocas opciones de color y la subida de un logo. La diferencia es sustancial.

Marketplace vs vendedores independientes

Dónde compras un tema premium importa tanto como si lo compras o no. Los tres canales principales para temas de PrestaShop son el marketplace oficial de PrestaShop Addons, los marketplaces de temas de propósito general como ThemeForest, y los desarrolladores de temas independientes que venden a través de sus propios sitios web.

El marketplace de PrestaShop Addons proporciona el mayor nivel de protección al comprador. Los temas se revisan en cuanto a compatibilidad con PrestaShop, calidad del código y seguridad. El marketplace gestiona los pagos, proporciona un proceso de resolución de disputas y hace cumplir las obligaciones de soporte. La desventaja es una selección más pequeña en comparación con los marketplaces generales y a veces precios más elevados.

ThemeForest y marketplaces similares ofrecen una selección mucho mayor a precios competitivos. Sin embargo, el proceso de revisión para la calidad específica de PrestaShop es menos riguroso. Un tema puede pasar la revisión general de ThemeForest y aún tener problemas específicos de PrestaShop como hooks faltantes, estructuras de plantilla incompatibles o conflictos con módulos comunes. El soporte es proporcionado por el desarrollador del tema, no por el marketplace, y la calidad varía significativamente entre vendedores.

Los vendedores independientes ofrecen temas a través de sus propios sitios web. Esta puede ser la mejor o la peor opción dependiendo del desarrollador específico. Desarrolladores de temas PrestaShop establecidos con un portfolio de temas bien evaluados, blogs o tutoriales activos y una participación comunitaria visible suelen ser la mejor fuente de temas de alta calidad. Entienden PrestaShop en profundidad y construyen temas específicamente para la plataforma. Sin embargo, desarrolladores desconocidos que venden un único tema a través de un sitio web poco conocido representan la categoría de mayor riesgo para temas premium.

Independientemente de dónde compres, siempre verifica si el vendedor ofrece una política de devolución, cuáles son los términos de soporte (duración, tiempo de respuesta, qué está cubierto) y si las actualizaciones están incluidas en el precio de compra o requieren una suscripción adicional.

Qué buscar en la documentación del tema

La calidad de la documentación es uno de los indicadores más fiables de la calidad general del tema. Un desarrollador que invierte tiempo en crear documentación exhaustiva también invierte tiempo en escribir código limpio, probar minuciosamente y mantener el producto a lo largo del tiempo.

Una buena documentación de tema incluye una guía de instalación que cubre los requisitos del servidor, instrucciones de instalación paso a paso y solución de problemas para los problemas de instalación más comunes. Incluye una guía de configuración que explica cada opción del panel de configuración del tema, con capturas de pantalla que muestran lo que cambia cada ajuste. Incluye una guía de personalización que explica cómo crear un tema hijo, qué archivos de plantilla controlan qué partes de la tienda y cómo sobrescribir elementos específicos de forma segura. Incluye una referencia de hooks que lista todos los hooks soportados y dónde aparecen en el diseño. Incluye un registro de cambios que documenta cada actualización con fechas, números de versión y descripciones de lo que cambió. Y también incluye información de compatibilidad que especifica qué versiones de PrestaShop han sido probadas.

Una documentación deficiente es un único PDF con unas pocas capturas de pantalla mostrando el asistente de instalación. Si el desarrollador no se molesta en documentar su propio producto, también recorta en otros aspectos.

Coste total de propiedad

El verdadero coste de un tema no es su precio de compra. Es la cantidad total de dinero que gastas en el tema durante toda la vida de tu tienda, incluyendo el precio de compra, los costes de personalización, el tiempo del desarrollador para correcciones y soluciones alternativas, el trabajo de optimización de rendimiento y el coste de oportunidad de las ventas perdidas debido a problemas relacionados con el tema.

Considera dos escenarios. En el escenario uno, eliges un tema gratuito. Gastas cero en el tema en sí, pero necesitas un desarrollador para personalizar el diseño (500 euros), corregir problemas de diseño móvil (200 euros), añadir hooks faltantes para dos módulos (300 euros) y solucionar un conflicto de jQuery (150 euros). Después de que una actualización de PrestaShop rompa el tema (porque ya no se mantiene), gastas 400 euros migrando a un nuevo tema. Coste total: 1.550 euros más tiempo de inactividad y ventas perdidas durante la migración.

En el escenario dos, eliges un tema premium por 120 euros. El configurador integrado maneja tu personalización de diseño (cero coste adicional). El tema soporta todos los hooks estándar (cero coste adicional). El desarrollador publica una actualización para la nueva versión de PrestaShop (cero coste adicional, incluido en tu compra). Contactas al soporte para resolver una pregunta menor de configuración (cero coste adicional, cubierto por tu período de soporte). Coste total: 120 euros.

Estos números son ilustrativos, no universales. Algunos temas gratuitos no requieren ninguna inversión adicional, y algunos temas premium requieren una personalización extensiva a pesar de su precio. Pero el patrón se mantiene. La opción más barata inicialmente es a menudo la opción más cara con el tiempo.

Ejemplos reales de costes ocultos

Los costes ocultos aparecen en áreas invisibles durante la evaluación inicial. La incompatibilidad con módulos es común: un tema gratuito que elimina el hook displayProductExtraContent hace imposible usar módulos que añaden pestañas a las páginas de producto. Descubres esto solo después de comprar el módulo, y entonces te enfrentas a modificaciones de tema de pago, alternativas limitadas de módulos o cambiar de tema por completo.

El daño SEO por una estructura HTML deficiente es otro coste oculto. Los temas que usan etiquetas de encabezado incorrectamente (múltiples etiquetas H1, niveles de encabezado omitidos) perjudican el posicionamiento de formas difíciles de diagnosticar y costosas de corregir mediante reescrituras de plantillas.

Los costes de rendimiento son significativos. Un aumento de un segundo en el tiempo de carga de página en una tienda que factura 100.000 euros al año cuesta aproximadamente entre 7.000 y 10.000 euros anuales en conversiones perdidas. Si un tema gratuito carga más lento que un tema premium optimizado, la opción gratuita cuesta miles al año en ingresos perdidos invisibles.

Tomar la decisión correcta

El tema predeterminado oficial de PrestaShop es la elección correcta si tienes habilidades de desarrollo, quieres máximo control y planeas invertir en desarrollo personalizado. Un tema premium es la elección correcta si necesitas una tienda pulida rápidamente, careces de habilidades técnicas y quieres módulos incluidos con soporte. Un tema gratuito de terceros rara vez es la elección correcta. El único caso de uso válido es una tienda de prueba temporal o un prototipo donde el tema será reemplazado antes de la producción.

Nunca uses un tema nulled bajo ninguna circunstancia. Los riesgos de seguridad son reales, los riesgos legales son reales y el daño financiero de una tienda comprometida supera con creces el coste de cualquier tema premium legítimo.

Recomendaciones finales

Comienza con el tema oficial de PrestaShop si no estás seguro. Es gratuito, bien mantenido, seguro y compatible con todo. Siempre puedes cambiar a un tema premium más adelante cuando tengas una imagen más clara de tus necesidades. Si decides comprar un tema premium, prioriza los temas del marketplace oficial de PrestaShop Addons o de desarrolladores establecidos con una trayectoria demostrada. Lee las reseñas cuidadosamente, centrándote en las menciones sobre calidad del soporte, frecuencia de actualizaciones y problemas de compatibilidad. Prueba la demo a fondo en dispositivos móviles y verifica el rendimiento con PageSpeed Insights antes de comprar.

Sea cual sea el tema que elijas, conserva tu recibo de compra e información de licencia, crea un tema hijo para tus personalizaciones en lugar de editar el tema directamente, documenta cualquier cambio manual que hagas en los archivos del tema, prueba las actualizaciones del tema en un entorno de pruebas antes de aplicarlas en producción, y mantén copias de seguridad regulares para poder recuperarte rápidamente si una actualización del tema causa problemas. El tema es la base del front end de tu tienda. Invertir tiempo en elegir el correcto, ya sea gratuito o premium, previene problemas que son caros y disruptivos de corregir más adelante.

Leer respuesta completa

Por qué el exceso de módulos es el asesino silencioso del rendimiento de PrestaShop

Toda tienda PrestaShop empieza siendo rápida. Luego instalas cinco módulos, diez módulos, treinta módulos, y de repente tu página de inicio tarda cuatro segundos en cargar. El culpable rara vez es un solo módulo masivo. En cambio, son docenas de pequeños módulos, cada uno añadiendo su propio archivo CSS, su propio archivo JavaScript y sus propias consultas a la base de datos en cada carga de página. Este peso acumulativo es lo que llamamos exceso de módulos (module bloat), y es la razón número uno por la que las tiendas PrestaShop se vuelven lentas con el tiempo.

El problema es que la mayoría de los propietarios de tiendas nunca auditan lo que sus módulos realmente cargan. Instalan un módulo para etiquetas de producto, otro para botones de compartir en redes sociales, otro para un popup de newsletter, otro para analítica, y cada uno se registra silenciosamente en hooks como displayHeader y actionFrontControllerSetMedia. Incluso si un módulo solo muestra contenido en las páginas de producto, puede seguir cargando sus archivos CSS y JavaScript en la página de inicio, páginas de categoría, carrito y checkout. Esto significa que tus clientes están descargando recursos que nunca usarán en esa página en particular.

Una auditoría de módulos adecuada revela exactamente lo que cada módulo aporta al peso de tu página. Te dice qué módulos son los que más sobrecargan, cuáles cargan recursos innecesariamente y cuáles puedes optimizar o eliminar por completo. Este artículo te guía a través del proceso completo de auditar tus módulos PrestaShop para rendimiento, usando las DevTools del navegador, el modo de depuración de PrestaShop y un análisis sistemático.

Paso 1: Activar el modo de depuración y el perfilado de rendimiento de PrestaShop

Antes de abrir las herramientas del navegador, necesitas activar las capacidades de perfilado integradas de PrestaShop. PrestaShop tiene un modo de depuración que revela información detallada sobre la ejecución de hooks, los tiempos de carga de módulos y las consultas a la base de datos. Para activarlo, necesitas modificar dos ajustes.

Primero, ve a Parámetros Avanzados y luego a Rendimiento en tu back office. Establece el Modo de Depuración en Sí. Esto activa el reporte de errores y el registro adicional que ayuda a identificar módulos problemáticos. Sin embargo, el verdadero poder proviene de la función de perfilado.

Para activar el perfilado completo, necesitas editar el archivo defines.inc.php ubicado en el directorio config de tu PrestaShop. Busca la línea que define _PS_DEBUG_PROFILING_ y establécela en true. En PrestaShop 1.7 y 8.x, esta constante controla si la barra de perfilado aparece en la parte inferior de cada página del front office. Una vez activada, recarga cualquier página de tu tienda y verás un panel de perfilado detallado mostrando los tiempos de ejecución de cada hook, cada módulo y cada consulta SQL.

El panel de perfilado se divide en varias secciones. La sección de hooks te muestra cada hook que se ejecutó en la página actual, qué módulos están vinculados a cada hook y cuánto tiempo tardó cada módulo en ejecutarse. La sección SQL muestra cada consulta a la base de datos, su tiempo de ejecución y qué módulo o función del núcleo la disparó. La sección de módulos te da un resumen del tiempo total de ejecución por módulo a través de todos los hooks.

Presta especial atención a la columna de tiempo total de ejecución. Un módulo bien optimizado debería contribuir menos de 10 milisegundos a la carga de una página. Si ves un módulo tardando 50, 100 o incluso 500 milisegundos, eso es un problema de rendimiento serio que necesita investigación.

Paso 2: Usar las DevTools del navegador para mapear los recursos de los módulos

El perfilado integrado de PrestaShop te informa sobre el rendimiento del lado del servidor, pero no te muestra la imagen completa de lo que sucede en el navegador. Para eso, necesitas las Herramientas de Desarrollo de tu navegador. Abre Chrome o Firefox, pulsa F12 y navega a la pestaña Red (Network).

Recarga tu página de inicio con la pestaña Red abierta. Verás cada petición que hace el navegador: HTML, archivos CSS, archivos JavaScript, imágenes, fuentes y llamadas AJAX. El objetivo es identificar cuáles de estas peticiones provienen de módulos.

En PrestaShop, los recursos de módulos siguen un patrón de URL predecible. Los archivos CSS de módulos se sirven típicamente desde rutas como /modules/nombremodulo/views/css/archivo.css o /modules/nombremodulo/css/archivo.css. Los archivos JavaScript siguen el mismo patrón con js en lugar de css. Usa la barra de filtro en la pestaña Red para filtrar por "modules/" y verás instantáneamente cada recurso cargado desde tus módulos instalados.

Para cada recurso de módulo que encuentres, anota la siguiente información: el nombre del archivo, su tamaño (tanto transferido como sin comprimir) y si se carga en el tipo de página actual. Quieres construir una hoja de cálculo o lista simple que mapee cada módulo a sus recursos. Una auditoría típica podría revelar algo como esto: el módulo A carga dos archivos CSS que suman 45 KB y un archivo JavaScript de 120 KB en cada página, pero solo muestra contenido en las páginas de producto. Eso significa que las páginas de categoría, la página de inicio y el carrito están cargando 165 KB de recursos innecesarios.

La pestaña Red también te muestra la vista de cascada (waterfall), que revela cuándo empieza a cargar cada recurso y cuánto tarda. Los recursos que bloquean el renderizado (CSS que bloquea el renderizado y JavaScript síncrono) son particularmente dañinos porque impiden que el navegador muestre cualquier contenido hasta que terminan de cargarse. Busca archivos JavaScript de módulos que se cargan en el head sin atributos async o defer, ya que estos son los peores infractores en cuanto al tiempo de carga percibido.

Paso 3: Analizando la cascada de red por módulo

La vista de cascada en DevTools merece su propia sección porque revela problemas de rendimiento que los tamaños de archivo por sí solos no muestran. Cuando miras la cascada, quieres identificar tres tipos de problemas.

Primero, busca recursos que bloquean el renderizado provenientes de módulos. Estos aparecen como barras que comienzan temprano en la cascada y retrasan el evento de primer pintado (la línea vertical verde o azul). En PrestaShop, los archivos CSS añadidos a través del hook displayHeader o mediante addCSS en setMedia son típicamente bloqueantes del renderizado. Si un módulo añade un archivo CSS grande que solo se necesita en páginas específicas, bloquea el renderizado en todas las páginas sin razón.

Segundo, busca cadenas de carga secuencial. Algunos módulos cargan un archivo JavaScript que luego dispara la carga de recursos adicionales: más archivos JavaScript, archivos CSS, fuentes web o llamadas a APIs externas. Cada eslabón en esta cadena añade latencia. Un módulo que carga jQuery UI, luego un CSS de tema jQuery UI, luego un JavaScript de widget personalizado y luego el CSS del widget crea una cadena de cuatro peticiones secuenciales que podrían tardar de 200 a 400 milisegundos incluso en una conexión rápida.

Tercero, busca peticiones externas. Algunos módulos hacen llamadas a servidores externos para analítica, seguimiento, carga de fuentes, widgets de redes sociales o datos de API. Estas peticiones son particularmente peligrosas porque no tienes control sobre el tiempo de respuesta del servidor externo. Un módulo de compartir en redes sociales que llama a las APIs de Facebook, Twitter y Pinterest en cada carga de página puede añadir 500 milisegundos o más de latencia, y si alguno de esos servidores está lento o inaccesible, puede bloquear toda tu página impidiendo que termine de cargar.

Para cuantificar el impacto por módulo, usa la función de bloqueo de Chrome DevTools. Haz clic derecho en una petición de un módulo específico y elige "Bloquear dominio de solicitud" o "Bloquear URL de solicitud". Luego recarga la página y compara el tiempo de carga. Esto te da una medición directa de cuánto contribuyen los recursos de ese módulo a tu tiempo total de carga de página. Repite esto para cada módulo para construir un ranking de más pesados a más ligeros.

Paso 4: Análisis de ejecución de hooks

Entender qué hooks usa cada módulo es crítico para identificar cargas innecesarias. El sistema de hooks de PrestaShop es el mecanismo mediante el cual los módulos inyectan su contenido, recursos y lógica en las páginas. Los hooks más relevantes para el rendimiento en las páginas del front office son displayHeader, actionFrontControllerSetMedia, displayTop, displayHome, displayFooter, displayProductAdditionalInfo y displayProductListFunctionalButtons.

El hook displayHeader es el hook más comúnmente abusado en el ecosistema PrestaShop. Los módulos se registran en este hook para añadir su CSS y JavaScript al head de la página. El problema es que displayHeader se ejecuta en absolutamente todas las páginas del front office. Si un módulo se registra en displayHeader sin verificar qué página está viendo el cliente actualmente, carga sus recursos en todas partes.

Para ver qué módulos están registrados en cada hook, ve a Diseño y luego a Posiciones en tu back office. Esta página muestra cada hook y cada módulo vinculado a él. Mira específicamente displayHeader y actionFrontControllerSetMedia. Cuenta cuántos módulos están registrados ahí. En una tienda típica con 30 o más módulos instalados, podrías encontrar de 15 a 20 módulos solo en displayHeader. Cada uno está añadiendo al menos un archivo CSS o JavaScript a cada página.

Ahora cruza esta información con tus hallazgos de DevTools. Para cada módulo en displayHeader, verifica si ese módulo realmente necesita cargarse en la página actual. Un módulo de reseñas de productos solo necesita sus recursos en las páginas de producto. Un módulo de lista de deseos solo necesita sus recursos en las páginas de producto y de cuenta. Un módulo de guía de tallas solo necesita sus recursos en las páginas de producto. Sin embargo, todos ellos están cargando en tu página de inicio, tus páginas de categoría, tus páginas CMS y tu checkout.

Los datos de perfilado del Paso 1 añaden otra dimensión a este análisis. Algunos módulos no solo cargan recursos innecesarios sino que también ejecutan código PHP costoso en cada llamada de hook. Un módulo que ejecuta consultas a la base de datos en su método hookDisplayHeader para verificar valores de configuración o recuperar datos está desperdiciando recursos del servidor en cada página, incluso cuando su salida no es necesaria.

Paso 5: Identificando los módulos más pesados

Con los datos del perfilado, DevTools y el análisis de hooks, ahora puedes clasificar tus módulos por su impacto en el rendimiento. Crea una lista con las siguientes columnas: nombre del módulo, número de archivos CSS cargados, tamaño total de CSS, número de archivos JavaScript cargados, tamaño total de JavaScript, tiempo de ejecución del servidor según el perfilado, número de consultas a la base de datos y páginas donde el módulo realmente muestra contenido.

Los módulos que puntúan más alto en estas métricas son los que más sobrecargan tu tienda. Según nuestra experiencia auditando cientos de tiendas PrestaShop, las siguientes categorías de módulos son consistentemente las de peor rendimiento.

Los módulos constructores de páginas (page builders) suelen ser los más pesados. Cargan grandes frameworks CSS, múltiples bibliotecas JavaScript para su editor visual, y a veces incluso cargan recursos del editor en el front office. Un constructor de páginas que carga 300 KB de CSS y 500 KB de JavaScript en cada página no es inusual.

Los módulos de redes sociales que incrustan widgets de Facebook, Instagram o Twitter cargan archivos externos que son tanto grandes como impredecibles en su tiempo de carga. Un único widget de feed de Instagram puede añadir 1 MB o más de JavaScript a tu página.

Los módulos de analítica y seguimiento que usan múltiples píxeles de seguimiento cargan archivos desde dominios externos. Cada píxel de seguimiento típicamente añade de 20 a 50 KB de JavaScript más peticiones de red adicionales para imágenes de píxel y llamadas a APIs.

Los módulos de sliders y carruseles cargan grandes bibliotecas JavaScript como Slick, Owl Carousel o Swiper junto con su CSS. Incluso si el slider solo aparece en la página de inicio, los recursos a menudo se cargan en todas las páginas.

Los módulos de chat en vivo cargan paquetes JavaScript sustanciales para la interfaz del widget de chat, típicamente de 100 a 300 KB, además de establecer conexiones WebSocket que consumen recursos durante toda la sesión de navegación.

Paso 6: Medir el rendimiento antes y después

Antes de empezar a desactivar hooks o eliminar módulos, establece una medición de referencia. Usa múltiples herramientas para obtener una imagen completa.

En Chrome DevTools, ve a la pestaña Lighthouse y ejecuta una auditoría de rendimiento. Registra la Puntuación de Rendimiento, First Contentful Paint (FCP), Largest Contentful Paint (LCP), Total Blocking Time (TBT) y Cumulative Layout Shift (CLS). Ejecuta la auditoría tres veces y promedia los resultados para compensar la variabilidad.

Usa la pestaña Performance en DevTools para grabar una traza de carga de página. Esto te da un gráfico de llama (flame chart) que muestra exactamente lo que el navegador está haciendo en cada milisegundo. Busca tareas largas (bloques de más de 50 milisegundos) e identifica qué archivos de módulos las causan.

También mide el peso de tu página. En la pestaña Red, mira el número total de peticiones y el tamaño total transferido en la parte inferior del panel. Filtra por CSS y JS por separado para obtener totales específicos de módulos.

Registra todos estos números antes de hacer cualquier cambio. Luego, a medida que optimices módulos desvinculando hooks innecesarios o desactivándolos por completo, vuelve a ejecutar las mismas mediciones. La diferencia te dice exactamente cuánto rendimiento ganaste con cada cambio.

Una auditoría de módulos bien ejecutada típicamente reduce el peso de la página entre un 30 y un 50 por ciento y mejora los tiempos de carga de uno a dos segundos. En tiendas con muchos módulos mal optimizados, la mejora puede ser aún más dramática.

Paso 7: Desactivar hooks innecesarios

Una vez que hayas identificado qué módulos cargan recursos en páginas donde no son necesarios, tienes varias opciones de optimización. El enfoque más sencillo es desvincular módulos de hooks donde no necesitan estar.

Ve a Diseño y luego a Posiciones en tu back office. Encuentra el módulo en el hook del que quieres eliminarlo. Haz clic en el icono de papelera o el botón de desvincular para eliminar el módulo de ese hook específico. Esto evita que el módulo se ejecute en ese hook por completo.

Sin embargo, ten cuidado con este enfoque. Algunos módulos usan displayHeader no solo para cargar CSS y JavaScript sino también para realizar tareas de inicialización esenciales. Desvincular un módulo así de displayHeader podría romper su funcionalidad en las páginas donde realmente se necesita. Siempre prueba en un entorno de staging o como mínimo prueba las páginas específicas donde el módulo debería seguir funcionando después de desvincularlo.

Un mejor enfoque a largo plazo es contactar al desarrollador del módulo y solicitar carga condicional de recursos. Un módulo bien codificado debería verificar el controlador o tipo de página actual antes de cargar sus recursos. Por ejemplo, un módulo de reseñas de productos debería solo cargar su CSS y JavaScript cuando el controlador actual es ProductController. De esta forma, el módulo permanece vinculado a displayHeader por compatibilidad pero solo carga recursos cuando realmente se necesitan.

Si te sientes cómodo editando código de módulos, puedes añadir verificaciones condicionales tú mismo. En el método hookDisplayHeader o hookActionFrontControllerSetMedia del módulo, añade una verificación del nombre del controlador actual. Si el controlador no es uno donde el módulo muestra contenido, retorna tempranamente sin añadir ningún recurso. Esta es la optimización más precisa y efectiva que puedes hacer.

Lista de verificación práctica para tu auditoría de módulos

Para resumir todo el proceso de auditoría, aquí tienes una lista de verificación práctica que puedes seguir. Comienza activando el perfilado de depuración de PrestaShop. Abre la pestaña Red de DevTools y recarga tu página de inicio. Filtra las peticiones por la ruta de módulos y lista cada recurso de módulo. Anota el tamaño y tipo de cada recurso. Revisa Diseño y luego Posiciones para ver los módulos en displayHeader. Cruza los registros de hooks con dónde los módulos realmente muestran contenido. Usa el bloqueo de peticiones de DevTools para medir el impacto por módulo. Registra las puntuaciones base de Lighthouse. Desvincula los módulos de hooks donde no son necesarios. Añade carga condicional a los módulos que cargan globalmente. Vuelve a medir las puntuaciones de Lighthouse después de cada cambio. Documenta tus hallazgos y cambios para referencia futura.

Este enfoque sistemático asegura que no pierdas ninguna oportunidad de rendimiento y te da datos concretos para justificar cada cambio que hagas. El exceso de módulos no es un misterio. Es un problema medible y solucionable, y toda tienda PrestaShop se beneficia de una auditoría exhaustiva de módulos al menos una vez al año.

Leer respuesta completa

La causa raíz: cómo el sistema de hooks de PrestaShop gestiona los recursos

Si alguna vez has inspeccionado el código fuente de tu tienda PrestaShop y te has preguntado por qué un módulo que solo muestra un widget en las páginas de producto está cargando su CSS y JavaScript en tu página de inicio, tus páginas de categoría e incluso tu checkout, no estás solo. Este es uno de los problemas de rendimiento más comunes en el ecosistema PrestaShop, y se origina en cómo funciona el sistema de hooks combinado con prácticas de desarrollo descuidadas.

PrestaShop utiliza una arquitectura basada en hooks para permitir que los módulos inyecten contenido, recursos y lógica en diferentes partes de una página. Cuando un módulo necesita añadir archivos CSS o JavaScript a la página, típicamente lo hace a través de uno de dos hooks: displayHeader o actionFrontControllerSetMedia. Ambos hooks se ejecutan en todas las páginas del front office sin excepción. No existe un mecanismo integrado en el propio sistema de hooks para restringir una llamada de hook a tipos de página específicos. Es enteramente responsabilidad del desarrollador del módulo verificar qué página se está cargando y decidir si añadir recursos o no.

El problema es que muchos desarrolladores de módulos toman atajos. En lugar de escribir lógica condicional que verifique el controlador actual, simplemente registran sus recursos en cada llamada de hook. El razonamiento es sencillo: si los recursos se cargan siempre, el módulo funcionará siempre sin importar dónde aparezca su contenido. Este enfoque de "disparar y olvidar" garantiza que el módulo funcione correctamente, pero también garantiza un rendimiento deficiente.

Cómo el abuso del hook displayHeader crea sobrecarga en las páginas

El hook displayHeader es el mecanismo principal por el cual los módulos añaden contenido a la sección head del HTML de cada página. Cuando un módulo implementa el método hookDisplayHeader, PrestaShop llama a ese método en cada carga de página del front office. Dentro de este método, los módulos típicamente llaman a $this->context->controller->addCSS() y $this->context->controller->addJS() para registrar sus archivos de recursos.

Esto es lo que sucede en una tienda típica con 25 módulos instalados. Quince de esos módulos tienen un método hookDisplayHeader. Cada uno añade entre uno y cuatro archivos CSS y JavaScript. Eso significa que cada página de tu tienda carga de 15 a 60 peticiones HTTP adicionales solo de módulos, sin importar si esos módulos muestran algo en la página actual.

Consideremos un ejemplo concreto. Un módulo que añade un popup de guía de tallas a las páginas de producto necesita un archivo CSS para el estilo del popup y un archivo JavaScript para el comportamiento del popup. Si el desarrollador registra estos recursos en hookDisplayHeader sin ninguna verificación condicional, esos dos archivos se cargan en la página de inicio, en cada página de categoría, en la página del carrito, en la página de checkout y en cada página CMS. La guía de tallas nunca aparecerá en ninguna de esas páginas, pero el navegador igualmente descarga, analiza y procesa los archivos CSS y JavaScript.

Multiplica esto por cada módulo que sigue el mismo patrón, y empezarás a entender por qué algunas tiendas PrestaShop cargan 2 MB o más de recursos de módulos en páginas donde la mayoría de esos recursos son completamente innecesarios.

El hook actionFrontControllerSetMedia

PrestaShop 1.7 introdujo el hook actionFrontControllerSetMedia como una alternativa más moderna a displayHeader para el registro de recursos. Este hook fue diseñado específicamente para registrar archivos CSS y JavaScript usando los nuevos métodos registerStylesheet y registerJavascript. Estos métodos ofrecen ventajas sobre las funciones antiguas addCSS y addJS, incluyendo la capacidad de establecer prioridad de carga, especificar atributos async o defer y controlar la posición (head o bottom) de las etiquetas de los archivos.

Sin embargo, actionFrontControllerSetMedia sufre exactamente el mismo problema fundamental que displayHeader: se ejecuta en todas las páginas. Un módulo que registra recursos en hookActionFrontControllerSetMedia sin verificar el controlador actual carga esos recursos en todas partes, igual que el enfoque antiguo.

La única diferencia es el método de registro, no el alcance de la carga. Ya sea que un desarrollador use addCSS en displayHeader o registerStylesheet en actionFrontControllerSetMedia, el resultado es el mismo si no añade lógica condicional. Los recursos se cargan globalmente.

Carga condicional adecuada: lo que hacen los buenos módulos

Un módulo bien desarrollado verifica qué página está viendo el cliente antes de cargar cualquier recurso. La forma estándar de hacerlo en PrestaShop es verificar el nombre del controlador. Cada página del front office es servida por un controlador específico: IndexController para la página de inicio, CategoryController para las páginas de categoría, ProductController para las páginas de producto, CartController para el carrito, y así sucesivamente.

Dentro del método hookDisplayHeader o hookActionFrontControllerSetMedia, el desarrollador puede acceder al controlador actual a través de $this->context->controller. Verificando el nombre de la clase o la propiedad php_self del controlador, el módulo puede decidir si cargar sus recursos. Un módulo de reseñas de productos, por ejemplo, debería verificar si la página actual es una página de producto y solo cargar su CSS y JavaScript en ese caso.

Este enfoque condicional no es difícil de implementar. Añade quizás de cinco a diez líneas de código al método del hook. Sin embargo, un número sorprendente de módulos, incluyendo módulos de pago populares en el marketplace de PrestaShop Addons y módulos gratuitos muy conocidos, omiten esta verificación por completo. La razón es una combinación de comodidad del desarrollador y el hecho de que PrestaShop no exige ni siquiera promueve la carga condicional en su documentación de desarrollo de módulos.

Algunos desarrolladores argumentan que cargar recursos globalmente asegura la compatibilidad con temas personalizados o configuraciones de página inusuales donde el contenido del módulo podría aparecer inesperadamente. Aunque este argumento tiene algo de verdad, no justifica el coste de rendimiento. Un mejor enfoque es cargar recursos condicionalmente por defecto y proporcionar una opción de configuración para habilitar la carga global en las tiendas que lo necesiten.

El método setMedia: mejores prácticas para desarrolladores de módulos

Para los desarrolladores de módulos que lean este artículo, estas son las mejores prácticas para la carga de recursos que respetan el rendimiento del sitio de sus usuarios.

Primero, usa siempre el hook actionFrontControllerSetMedia en lugar de displayHeader para el registro de recursos en PrestaShop 1.7 y posteriores. El hook más nuevo proporciona mejor control sobre el comportamiento de carga de recursos y mantiene tu registro de recursos separado de la salida HTML.

Segundo, verifica siempre el controlador actual antes de registrar recursos. Usa un enfoque de lista blanca: define la lista de controladores donde tu módulo muestra contenido y solo registra recursos cuando el controlador actual está en esa lista. Esto es más mantenible que un enfoque de lista negra porque los nuevos tipos de página añadidos en futuras versiones de PrestaShop no cargarán accidentalmente tus recursos.

Tercero, usa registerStylesheet y registerJavascript en lugar de addCSS y addJS. Los métodos más nuevos te permiten especificar un id para cada recurso, lo que hace posible que los temas y otros módulos anulen o eliminen tus recursos de forma limpia. También soportan ajustes de prioridad que controlan el orden en que se cargan los recursos.

Cuarto, considera si tu JavaScript realmente necesita cargarse en el head o si puede cargarse en la parte inferior de la página con el atributo defer. El JavaScript en el head bloquea el renderizado, lo que significa que el navegador no puede mostrar ningún contenido hasta que tu archivo termine de descargarse y analizarse. Mover los archivos a la parte inferior o añadir defer elimina este comportamiento de bloqueo del renderizado.

Quinto, minimiza el tamaño de tus archivos de recursos. Minifica tus archivos CSS y JavaScript antes de distribuir tu módulo. Elimina las reglas CSS no utilizadas. Evita incluir bibliotecas completas como jQuery UI o Bootstrap cuando solo usas una pequeña parte de su funcionalidad. Cada kilobyte cuenta cuando los recursos de tu módulo se cargan en miles de visitas de página al día.

Midiendo el impacto en el rendimiento de los recursos globales

Para entender cuánto cuesta a tu tienda la carga global de recursos, necesitas mediciones concretas. Abre Chrome DevTools en tu página de inicio y ve a la pestaña Red (Network). Recarga la página y filtra las peticiones por la ruta /modules/. Cuenta el número total de peticiones y su tamaño combinado. Esta es la sobrecarga de recursos de módulos en una página donde la mayoría de los módulos no muestran ningún contenido.

Ahora haz lo mismo en una página de producto, donde muchos módulos legítimamente necesitan sus recursos. Compara los números. En una tienda bien optimizada, la página de producto debería cargar significativamente más recursos de módulos que la página de inicio porque es donde la mayoría de los módulos muestran su contenido. En una tienda mal optimizada, los números son casi idénticos porque cada módulo carga todo en todas partes.

Un dato concreto de auditorías reales: una tienda con 35 módulos instalados cargaba 1,8 MB de CSS y JavaScript de módulos en la página de inicio. Después de implementar carga condicional en todos los módulos, los recursos de módulos en la página de inicio cayeron a 340 KB. La página de producto, donde la mayoría de los módulos legítimamente necesitaban sus recursos, pasó de 2,1 MB a 1,4 MB. El tiempo de carga de la página de inicio mejoró en 1,3 segundos y la puntuación de rendimiento de Lighthouse pasó de 42 a 71.

Estos números no son inusuales. La carga global de recursos es una de las mayores fuentes individuales de peso innecesario de página en las tiendas PrestaShop, y corregirla suele producir las mejoras de rendimiento más dramáticas.

Cómo identificar los módulos infractores en tu tienda

Encontrar qué módulos cargan recursos globalmente requiere un enfoque sistemático. Comienza con la pestaña Red en DevTools como se describió anteriormente. Para cada recurso de módulo que encuentres cargándose en la página de inicio, pregúntate: ¿este módulo muestra algún contenido en la página de inicio? Si la respuesta es no, ese módulo está cargando recursos innecesariamente.

Otro enfoque es usar el modo de perfilado de depuración de PrestaShop. Cuando el perfilado está activado (estableciendo _PS_DEBUG_PROFILING_ a true en tu config/defines.inc.php), PrestaShop muestra datos detallados de ejecución de hooks en la parte inferior de cada página. Estos datos te muestran exactamente qué módulos se ejecutan en cada hook y cuánto tardan. Cualquier módulo que se ejecuta en displayHeader o actionFrontControllerSetMedia pero no se ejecuta en ningún hook de visualización que produzca salida visible en la página actual es un candidato para optimización.

También puedes verificar programáticamente examinando el código fuente de cada módulo. Mira los métodos hookDisplayHeader y hookActionFrontControllerSetMedia en el archivo PHP principal del módulo. Si el método contiene llamadas a addCSS, addJS, registerStylesheet o registerJavascript sin ninguna verificación condicional del nombre del controlador, ese módulo carga recursos globalmente.

Para tiendas con muchos módulos, esta revisión manual puede ser lenta. Un atajo práctico es centrarse primero en los recursos más grandes. Ordena los recursos de módulos en la pestaña Red por tamaño y empieza investigando los archivos más grandes. Un archivo JavaScript de 200 KB cargándose globalmente es un problema mucho mayor que un archivo CSS de 3 KB, así que prioriza en consecuencia.

Solicitar correcciones a los desarrolladores de módulos

Cuando identifiques un módulo que carga recursos globalmente, tu primer paso debería ser contactar al desarrollador y solicitar una corrección. La mayoría de los desarrolladores profesionales de módulos son receptivos a las solicitudes de mejora de rendimiento, especialmente cuando puedes proporcionar datos específicos sobre el impacto.

Escribe un mensaje claro y técnico que explique el problema. Menciona que el método hookDisplayHeader del módulo carga CSS y JavaScript en todas las páginas sin verificar el controlador actual. Especifica qué páginas realmente necesitan los recursos y cuáles los están cargando innecesariamente. Incluye los tamaños de archivo y el impacto estimado en el rendimiento. Si tienes puntuaciones de Lighthouse mostrando el antes y el después cuando los recursos del módulo están bloqueados, inclúyelas.

Si el desarrollador es receptivo, típicamente publicará una actualización en pocas semanas que añada carga condicional. Si el desarrollador no responde o desestima la preocupación, tienes varias opciones: implementar la carga condicional tú mismo editando el código del módulo, usar un módulo de rendimiento que pueda bloquear selectivamente recursos en páginas específicas, o encontrar un módulo alternativo que siga mejores prácticas de desarrollo.

Soluciones alternativas cuando no puedes modificar el módulo

A veces no puedes modificar un módulo directamente. Puede estar cifrado con IonCube, puede ser un módulo del que no quieres mantener un fork, o el módulo podría sobrescribir tus cambios en cada actualización. En estos casos, necesitas soluciones alternativas.

Una solución alternativa efectiva es crear un pequeño módulo personalizado que desvinculle el módulo infractor de displayHeader y actionFrontControllerSetMedia, y luego vuelva a añadir los recursos solo en las páginas donde se necesitan. Este módulo personalizado usaría el hook actionFrontControllerSetMedia con una prioridad alta (para que se ejecute después del módulo infractor) y llamaría a Media::unregisterStylesheet y Media::unregisterJavascript para eliminar los recursos cargados globalmente. Luego, en las páginas donde los recursos son realmente necesarios, los volvería a registrar.

Otra solución alternativa es usar el archivo Theme.yml para anular los recursos de módulos. En PrestaShop 1.7 y posteriores, el archivo de configuración theme.yml del tema puede eliminar recursos específicos de módulos de la carga. Esta es una solución a nivel de tema que persiste a través de las actualizaciones de módulos. Sin embargo, elimina los recursos de todas las páginas, no selectivamente, por lo que necesitarías combinarlo con la re-adición de los recursos en páginas específicas mediante un módulo personalizado o una plantilla del tema.

Una tercera opción, disponible en PrestaShop 8.x, es usar las funciones integradas de prioridad y eliminación del sistema de gestión de recursos. PrestaShop 8 mejoró el pipeline de recursos para dar a los temas más control sobre qué recursos de módulos se cargan. Consulta la documentación de tu tema para instrucciones específicas sobre cómo aprovechar estas funcionalidades.

Independientemente del enfoque que elijas, siempre prueba exhaustivamente después de hacer cambios. Eliminar el CSS de un módulo puede romper su apariencia visual, y eliminar su JavaScript puede romper funciones interactivas. Prueba cada tipo de página donde el módulo debería seguir funcionando correctamente.

Prevención: evaluar los módulos antes de la instalación

La mejor forma de evitar los problemas de carga global de recursos es evaluar los módulos antes de instalarlos. Aunque esto no siempre es posible, hay verificaciones que puedes realizar.

Si el módulo proporciona una tienda de demostración, visítala e inspecciona la página de inicio con DevTools. Comprueba si los recursos del módulo se cargan en páginas donde el módulo no muestra contenido. Si los recursos se cargan globalmente en la demo, se cargarán globalmente en tu tienda también.

Si tienes acceso al código fuente del módulo antes de comprarlo (algunos marketplaces ofrecen previsualizaciones de código), mira los métodos hookDisplayHeader y hookActionFrontControllerSetMedia. Busca lógica de carga condicional. La ausencia de cualquier verificación de controlador es una señal de alarma.

Lee las reseñas y el foro de soporte del módulo. Los usuarios preocupados por el rendimiento a menudo informan sobre problemas de carga global de recursos en las reseñas. Si múltiples usuarios se han quejado de que el módulo ralentiza su tienda, toma esos comentarios en serio.

Finalmente, considera la calidad general del código del desarrollador. Los desarrolladores que siguen las mejores prácticas en un área tienden a seguirlas en otras. Si el código de un módulo es limpio, está bien documentado y sigue los estándares de codificación de PrestaShop, es más probable que gestione la carga de recursos correctamente. Si el código es desordenado y está mal estructurado, la carga global de recursos probablemente es solo uno de muchos problemas.

Leer respuesta completa

¿Por qué usar Cloudflare con PrestaShop?

Cloudflare se sitúa entre tus visitantes y tu servidor PrestaShop, actuando como un proxy inverso que proporciona protección DDoS, un Firewall de Aplicaciones Web (WAF), una CDN global para recursos estáticos y terminación SSL/TLS. Cuando se configura correctamente, Cloudflare puede mejorar drásticamente los tiempos de carga de tu tienda, reducir el ancho de banda del servidor y bloquear tráfico malicioso antes de que llegue a tu alojamiento. Sin embargo, una configuración incorrecta de Cloudflare es una de las causas más comunes de bucles de redirección, checkouts rotos, IPs de clientes incorrectas y desastres de caché en PrestaShop. Esta guía te lleva paso a paso por una configuración correcta.

Paso 1: Configuración DNS

Después de añadir tu dominio a Cloudflare, necesitas configurar tus registros DNS. La decisión más importante es qué registros deben estar proxificados (nube naranja) frente a solo DNS (nube gris).

Registros proxificados (nube naranja):

Tu registro A o AAAA principal apuntando a la IP de tu servidor (por ejemplo, ejemplo.com y www.ejemplo.com)
Cualquier CNAME para subdominios que sirven contenido web

Registros solo DNS (nube gris):

Registros MX (correo) — estos nunca deben proxificarse
Registros utilizados para FTP, SSH u otros servicios no HTTP
Registros que apuntan a servidores de correo (por ejemplo, mail.ejemplo.com)

Importante: Si usas un subdominio para el back office de tu PrestaShop (por ejemplo, admin.ejemplo.com), puedes proxificarlo, pero ten en cuenta las reglas de caché que se discuten más adelante. Nunca crees un registro DNS que exponga innecesariamente la IP real de tu servidor — una vez que tu dominio principal está proxificado, los atacantes que conozcan la IP real pueden eludir Cloudflare por completo. Considera cambiar la IP de tu servidor después de activar Cloudflare si anteriormente era pública.

Paso 2: Configuración SSL/TLS — Usa Full (Strict)

Este es el ajuste más crítico de todos. Navega a SSL/TLS > Overview en tu panel de Cloudflare.

Usa siempre el modo Full (Strict). Esto es lo que hace cada modo y por qué los demás son incorrectos para PrestaShop:

Off: Sin cifrado en absoluto. Nunca uses esto para una tienda de comercio electrónico.
Flexible: Cifra el tráfico entre el visitante y Cloudflare, pero envía HTTP sin cifrar a tu servidor. Esto causa bucles de redirección infinitos en PrestaShop porque el servidor ve HTTP, establece force_ssl = 1, redirige a HTTPS, Cloudflare lo entrega por HTTPS, pero la siguiente petición llega al servidor como HTTP de nuevo. Este es el error número uno de Cloudflare con PrestaShop.
Full: Cifra de extremo a extremo pero no valida el certificado SSL de tu servidor. Aceptable pero no recomendado.
Full (Strict): Cifra de extremo a extremo y valida tu certificado de origen. Esto es lo correcto. Si no tienes un certificado SSL de pago, usa un Certificado de Origen de Cloudflare gratuito (válido por 15 años) instalado en tu servidor.

Para instalar un Certificado de Origen de Cloudflare: ve a SSL/TLS > Origin Server > Create Certificate. Descarga el certificado y la clave privada, instálalos en tu servidor web (Apache o Nginx) y reinicia el servicio. Este certificado solo es válido para el tráfico que pasa a través de Cloudflare — se mostrará como inválido si se accede directamente.

En SSL/TLS > Edge Certificates, activa:

Always Use HTTPS: Sí
Automatic HTTPS Rewrites: Sí (corrige el contenido mixto reescribiendo URLs HTTP a HTTPS)
Minimum TLS Version: TLS 1.2

Paso 3: Configuración de caché

El comportamiento de caché predeterminado de Cloudflare funciona bien para recursos estáticos pero puede causar problemas graves si cachea páginas dinámicas de PrestaShop. Navega a Caching > Configuration.

Ajustes recomendados:

Caching Level: Standard
Browser Cache TTL: Respect Existing Headers (deja que PrestaShop controle la caché del navegador a través de sus ajustes CCC)
Always Online: Desactiva esto para tiendas de comercio electrónico — mostrar páginas de producto obsoletas con precios incorrectos o artículos agotados es peor que mostrar una página de error

Lo que Cloudflare cachea por defecto: Solo extensiones de archivos estáticos como .js, .css, .png, .jpg, .gif, .svg, .woff2, .ico. NO cachea páginas HTML por defecto, lo cual es correcto para PrestaShop. No actives "Cache Everything" sin reglas de exclusión adecuadas, o tus clientes verán los carritos, sesiones y datos personales de otros clientes.

Paso 4: Page Rules y Cache Rules

Las Page Rules (o las más recientes Cache Rules) te permiten personalizar el comportamiento de Cloudflare para patrones de URL específicos. Para PrestaShop, necesitas reglas que protejan el panel de administración y el checkout del cacheo mientras optimizan la entrega de contenido estático.

Regla 1: Excluir caché para el panel de administración

Crea una regla que coincida con ejemplo.com/admin* (reemplaza "admin" con el nombre real de tu directorio de back office):

Cache Level: Bypass
Disable Performance: Sí (desactiva Rocket Loader, Mirage y otras optimizaciones que pueden romper el JS del panel admin)
Security Level: High

Regla 2: Excluir caché para el checkout y el carrito

Crea una regla que coincida con ejemplo.com/order* y otra para ejemplo.com/cart* (o usa ejemplo.com/*order* si utilizas URLs amigables):

Cache Level: Bypass
Disable Performance: Sí

Si tu PrestaShop usa URLs de checkout generadas por módulos (como los de módulos de checkout express), añade reglas también para esas rutas.

Regla 3: Excluir caché para la cuenta de cliente

Coincide con ejemplo.com/my-account* o ejemplo.com/identity* y cualquier otra página autenticada dirigida al cliente:

Cache Level: Bypass

Regla 4: Cachear recursos estáticos agresivamente

Coincide con ejemplo.com/themes/*, ejemplo.com/js/* y ejemplo.com/modules/*/views/css/*:

Cache Level: Cache Everything
Edge Cache TTL: 1 mes
Browser Cache TTL: 1 semana

Nota sobre el nuevo sistema de reglas: Cloudflare está migrando de Page Rules a Cache Rules, Configuration Rules y Transform Rules separadas. La lógica es la misma — crea una Cache Rule con una expresión de filtro personalizada como (http.request.uri.path contains "/admin") y establece la acción para excluir la caché.

Paso 5: Rocket Loader — Desactívalo

Rocket Loader es la funcionalidad de Cloudflare que difiere la carga de todo el JavaScript en tus páginas. Navega a Speed > Optimization > Content Optimization y desactiva Rocket Loader.

Aunque suena beneficioso, Rocket Loader causa problemas graves con PrestaShop:

Botones de añadir al carrito rotos: PrestaShop depende de bloques de JavaScript en línea y manejadores jQuery ready que deben ejecutarse en orden. Rocket Loader los difiere y reordena.
Fallos en módulos de pago: Las pasarelas de pago como PayPal, Stripe y Mollie inyectan su propio JavaScript con el que Rocket Loader interfiere, causando fallos en el checkout y pedidos perdidos.
Panel de administración roto: El back office usa ampliamente JavaScript en línea para la validación de formularios, llamadas AJAX y páginas de configuración de módulos. Rocket Loader rompe todo esto.
Módulos de consentimiento de cookies y RGPD: Estos dependen de bloquear ciertos recursos hasta que se otorgue el consentimiento. Rocket Loader socava esto al reescribir cómo se cargan todos los recursos externos.

Incluso si estableces una Page Rule para desactivar las funciones de rendimiento en /admin*, el front office seguirá rompiéndose. El enfoque más seguro es desactivar Rocket Loader globalmente.

Paso 6: Restauración de la IP real

Cuando Cloudflare proxifica el tráfico, tu servidor ve las direcciones IP de Cloudflare en lugar de las IPs reales de tus visitantes. Esto rompe PrestaShop de varias formas: los registros de pedidos muestran IPs de Cloudflare, la detección de fraude falla, la geolocalización es incorrecta, la limitación de tasa no funciona y los datos de analítica son inútiles.

Apache (mod_remoteip)

Instala y activa el módulo:

sudo a2enmod remoteip
sudo systemctl restart apache2

Añade a tu configuración de Apache (virtual host o global):

RemoteIPHeader CF-Connecting-IP
RemoteIPTrustedProxy 173.245.48.0/20
RemoteIPTrustedProxy 103.21.244.0/22
RemoteIPTrustedProxy 103.22.200.0/22
RemoteIPTrustedProxy 103.31.4.0/22
RemoteIPTrustedProxy 141.101.64.0/18
RemoteIPTrustedProxy 108.162.192.0/18
RemoteIPTrustedProxy 190.93.240.0/20
RemoteIPTrustedProxy 188.114.96.0/20
RemoteIPTrustedProxy 197.234.240.0/22
RemoteIPTrustedProxy 198.41.128.0/17
RemoteIPTrustedProxy 162.158.0.0/15
RemoteIPTrustedProxy 104.16.0.0/13
RemoteIPTrustedProxy 104.24.0.0/14
RemoteIPTrustedProxy 172.64.0.0/13
RemoteIPTrustedProxy 131.0.72.0/22

Cloudflare publica sus rangos de IP en cloudflare.com/ips — revísalo periódicamente y actualiza tu configuración si cambian.

Nginx

Usa el módulo ngx_http_realip_module (normalmente compilado por defecto):

set_real_ip_from 173.245.48.0/20;
set_real_ip_from 103.21.244.0/22;
# ... añade todos los rangos de Cloudflare ...
real_ip_header CF-Connecting-IP;

Configuración de PrestaShop

Incluso con mod_remoteip, algunos módulos de PrestaShop leen la IP desde $_SERVER['HTTP_CF_CONNECTING_IP'] o $_SERVER['HTTP_X_FORWARDED_FOR']. Si aún ves IPs de Cloudflare en los pedidos después de configurar mod_remoteip, revisa el archivo config/defines.inc.php de tu PrestaShop para ver si hay sobreescrituras relacionadas con IPs o añade lo siguiente (no siempre es necesario si mod_remoteip funciona correctamente):

if (isset($_SERVER['HTTP_CF_CONNECTING_IP'])) {
    $_SERVER['REMOTE_ADDR'] = $_SERVER['HTTP_CF_CONNECTING_IP'];
}

Paso 7: Reglas WAF (Firewall de Aplicaciones Web)

El WAF de Cloudflare protege tu tienda contra inyección SQL, XSS y otros ataques. En el plan gratuito, obtienes protección básica. En Pro y superiores, obtienes los conjuntos de reglas gestionadas.

Configuración WAF recomendada

Security Level: Medium (en Security > Settings). "High" puede activar desafíos para clientes legítimos en redes móviles o VPNs.
Challenge Passage: 30 minutos (cuánto tiempo permanece verificado un visitante después de resolver un desafío)
Bot Fight Mode: Actívalo con precaución — puede bloquear callbacks de pasarelas de pago (IPNs) de PayPal, Stripe, etc. Si lo activas, añade excepciones WAF para las rutas de webhook conocidas como /module/paypal/notify.

Reglas WAF personalizadas para PrestaShop

Crea estas reglas de firewall en Security > WAF > Custom Rules:

Bloquear acceso directo a archivos sensibles:

Expresión: (http.request.uri.path contains "config/settings.inc.php") or (http.request.uri.path contains ".env") or (http.request.uri.path contains "composer.json") or (http.request.uri.path contains "var/logs/")

Acción: Block

Limitar tasa de intentos de inicio de sesión:

Usa reglas de limitación de tasa para restringir las peticiones a tu URL de inicio de sesión admin (por ejemplo, /adminXYZ/index.php) a 5 peticiones por minuto por IP. Esto previene ataques de fuerza bruta en el back office.

Lista blanca de IPs de proveedores de pago:

Si usas Bot Fight Mode, crea una regla Allow para las IPs de webhook de tu proveedor de pago para que sus callbacks de servidor a servidor nunca sean desafiados.

Paso 8: Configuración de rendimiento

Navega a Speed > Optimization y configura:

Auto Minify: Activa para JavaScript, CSS y HTML. El CCC (Combinar, Comprimir, Cachear) de PrestaShop hace su propia minificación, así que puede haber doble minificación, pero esto suele ser inofensivo. Si ves problemas de renderizado, desactiva la minificación CSS de Cloudflare y confía en el CCC de PrestaShop en su lugar.
Brotli: Activar — mejor compresión que gzip, soportada por todos los navegadores modernos
Early Hints: Activar — indica a los navegadores que precarguen recursos críticos antes de que el HTML se entregue completamente
HTTP/2: Activado por defecto en todos los planes de Cloudflare
HTTP/3 (QUIC): Activar para mejor rendimiento en redes móviles

Mirage (plan Pro): Si está disponible, actívalo. Mirage carga las imágenes de forma diferida y sirve imágenes dimensionadas apropiadamente según el dispositivo del visitante. Funciona bien con las imágenes de producto de PrestaShop.

Polish (plan Pro): Activar con compresión "Lossy" para imágenes de producto, o "Lossless" si la calidad de imagen es crítica (por ejemplo, impresiones artísticas). Polish comprime las imágenes al vuelo en el borde sin modificar tus originales.

Paso 9: Purgar la caché de Cloudflare

Cuando actualizas el diseño de tu tienda, añades nuevos productos o cambias archivos CSS/JS, necesitas purgar la caché de Cloudflare para que los visitantes vean la versión más reciente.

Métodos para purgar:

Purge Everything: Dashboard > Caching > Configuration > Purge Everything. Úsalo con moderación — fuerza a que todos los recursos se vuelvan a obtener de tu servidor.
Purge by URL: Purga archivos específicos como ejemplo.com/themes/tu-tema/assets/css/theme.css
Purge by Tag / Prefix: Disponible en planes Enterprise
Purga basada en API: Usa la API de Cloudflare para automatizar la purga de caché después de los despliegues. Puedes integrar esto en tu flujo de trabajo de despliegue de módulos PrestaShop.

El sistema CCC de PrestaShop añade cadenas de versión a los archivos CSS y JS (por ejemplo, theme.css?v=12345), lo que invalida naturalmente la caché de Cloudflare cuando los archivos cambian. Si dependes correctamente del CCC, raramente necesitarás purgas manuales de caché para recursos estáticos.

Errores comunes y cómo evitarlos

Error 1: SSL configurado en Flexible

Síntomas: Bucle de redirección infinito, ERR_TOO_MANY_REDIRECTS, página en blanco. Solución: Cambia el modo SSL a Full (Strict) e instala un certificado de origen en tu servidor.

Error 2: Cachear páginas dinámicas

Síntomas: El cliente A ve el carrito o los detalles de cuenta del cliente B, precios incorrectos mostrados, usuarios logueados ven contenido de no logueados. Solución: Nunca uses "Cache Everything" como configuración global. Solo cachea rutas de recursos estáticos. Excluye siempre la caché para /order, /cart, /my-account y el panel de administración.

Error 3: Rocket Loader activado

Síntomas: Añadir al carrito no funciona, los formularios de pago no se cargan, los módulos del back office muestran errores de JavaScript, las galerías de la página de producto están rotas. Solución: Desactiva Rocket Loader globalmente.

Error 4: No restaurar las IPs reales

Síntomas: Todos los pedidos muestran la misma dirección IP (una IP de Cloudflare), los módulos de geolocalización muestran países incorrectos, la limitación de tasa bloquea a Cloudflare en vez de a los atacantes. Solución: Configura mod_remoteip o ngx_http_realip_module como se describe arriba.

Error 5: Bot Fight Mode bloqueando webhooks

Síntomas: Las confirmaciones de pago nunca llegan, los pedidos permanecen en estado "En espera de pago", los logs de IPN/webhook muestran 403 o respuestas de desafío. Solución: Crea reglas de excepción WAF para las URLs y rangos de IP de los webhooks de tu proveedor de pago.

Error 6: Problemas de correo electrónico después de la configuración

Síntomas: Los correos electrónicos dejan de funcionar, la validación SPF/DKIM falla. Causa: Los registros DNS relacionados con el correo (MX, SPF TXT, DKIM) se configuraron accidentalmente como proxificados (nube naranja). Solución: Todos los registros DNS de correo electrónico deben estar en solo DNS (nube gris). La proxificación solo funciona para tráfico HTTP/HTTPS.

Error 7: Modo de desarrollo dejado activado

Síntomas: La caché nunca funciona, alta carga en el servidor de origen. Causa: El modo de desarrollo se activó durante la configuración y se olvidó. Solución: Desactiva el modo de desarrollo en Caching > Configuration una vez completada tu configuración. El modo de desarrollo se desactiva automáticamente después de 3 horas, pero verifícalo de todas formas.

Lista de verificación para la resolución de problemas

Cuando algo sale mal con Cloudflare y PrestaShop, sigue esta lista de verificación:

Bucles de redirección: Verifica el modo SSL (debe ser Full o Full Strict), comprueba el .htaccess para redirecciones HTTPS duplicadas, verifica que PS_SSL_ENABLED está establecido en 1 en la base de datos.
Advertencias de contenido mixto: Activa Automatic HTTPS Rewrites en Cloudflare, busca URLs http:// codificadas directamente en tu tema o páginas CMS.
TTFB lento (Time to First Byte): Cloudflare no cachea HTML por defecto. Un TTFB lento es tu servidor de origen siendo lento — optimiza PrestaShop (activa CCC, configura OPcache, revisa consultas de base de datos) en lugar de culpar a Cloudflare.
CSS/JS no se actualiza: Limpia la caché CCC de PrestaShop (back office > Rendimiento), luego purga la caché de Cloudflare. Verifica que CCC está añadiendo cadenas de versión a las URLs de los archivos.
Panel de administración lento o roto: Asegúrate de que tu Page Rule excluye la caché y desactiva las funciones de rendimiento para el directorio de administración. Verifica que el WAF de Cloudflare no está bloqueando peticiones AJAX del panel admin.
Clientes recibiendo desafíos: Baja el Security Level a Medium o Low. Comprueba que el modo Under Attack no está activado (solo debe usarse durante ataques DDoS activos). Revisa los eventos del firewall en Security > Events para ver qué reglas se están activando.
Llamadas API fallando: Si tu tienda tiene endpoints de API REST o servicios web, asegúrate de que Cloudflare no está desafiando o bloqueando las peticiones API. Crea una regla WAF para permitir peticiones a /api/* desde rangos de IP conocidos.
Imágenes no se cargan: Comprueba si la Protección de Hotlink está activada y accidentalmente bloqueando tu propio dominio. Verifica que las URLs de imágenes usan HTTPS.

Cloudflare con PrestaShop Multitienda

Si ejecutas PrestaShop multitienda con múltiples dominios, cada dominio debe añadirse a Cloudflare por separado (en el plan gratuito, cada dominio es una zona separada). Asegúrate de que:

El modo SSL está configurado en Full (Strict) en cada zona
Las Page Rules están duplicadas para cada dominio
La restauración de la IP real cubre todos los dominios (mod_remoteip es global, así que una sola configuración gestiona todos los virtual hosts)

Plan de Cloudflare recomendado para PrestaShop

El plan gratuito cubre la mayoría de las necesidades: DNS, CDN, WAF básico y SSL. El plan Pro (aproximadamente 20 USD/mes) añade Mirage, Polish, conjuntos de reglas WAF gestionadas y más Page Rules. Para tiendas de alto tráfico, el plan Business añade reglas WAF personalizadas y funciones de rendimiento adicionales. La mayoría de las tiendas PrestaShop pequeñas y medianas funcionan perfectamente bien con el plan gratuito o Pro.

Resumen

Configurar Cloudflare con PrestaShop correctamente se reduce a unas pocas decisiones críticas: usar SSL Full (Strict), desactivar Rocket Loader, excluir la caché en páginas dinámicas, restaurar las IPs reales de los visitantes y proteger los webhooks de pago de la protección contra bots. Acértalos desde el principio y Cloudflare se convierte en un poderoso aliado para el rendimiento y la seguridad de tu tienda. Falla en ellos y pasarás horas depurando bucles de redirección, checkouts rotos y pedidos fantasma. Tómate el tiempo de configurarlo correctamente una vez, y tu tienda PrestaShop se beneficiará de tiempos de carga más rápidos a nivel mundial, menor carga del servidor y una protección robusta contra ataques.

Leer respuesta completa

Qué es WebP y por qué importa para PrestaShop

WebP es un formato de imagen moderno desarrollado por Google que proporciona compresión tanto con pérdida como sin pérdida para imágenes web. Comparado con formatos tradicionales como JPEG y PNG, WebP típicamente ofrece archivos un 25-35% más pequeños con calidad visual equivalente. Para una tienda de comercio electrónico que ejecuta PrestaShop, donde las páginas de producto a menudo contienen docenas de imágenes, cambiar a WebP puede reducir drásticamente el peso de la página, mejorar los tiempos de carga y aumentar las puntuaciones de Core Web Vitals—todo lo cual impacta directamente en las clasificaciones SEO y las tasas de conversión.

A diferencia de formatos de nueva generación más antiguos que lucharon con la adopción, WebP ha alcanzado un soporte de navegadores casi universal. A partir de 2026, todos los navegadores principales—Chrome, Firefox, Safari, Edge, Opera y sus equivalentes móviles—soportan WebP completamente. Incluso los últimos bastiones como las versiones antiguas de Safari en macOS Catalina son ahora estadísticamente irrelevantes, representando menos del 0,3% del tráfico global. Esto significa que puedes servir imágenes WebP con confianza a prácticamente todos los visitantes sin preocuparte por problemas de compatibilidad.

Para los comerciantes de PrestaShop, las ganancias de rendimiento son sustanciales. Un catálogo de productos típico con 1.000 productos y 5 imágenes cada uno puede ver reducido el peso total de imágenes de 500 MB a menos de 350 MB. En las páginas de listado de productos que muestran de 20 a 40 miniaturas, esto se traduce en 200-400 KB ahorrados por carga de página—suficiente para mejorar significativamente las métricas de Time to First Contentful Paint y Largest Contentful Paint.

Activar WebP en PrestaShop 1.7 y 8.x

PrestaShop 1.7.8+ y todas las versiones 8.x incluyen soporte nativo para WebP. La funcionalidad está integrada en el sistema de regeneración de imágenes y puede activarse a través del back office. Así es cómo activarlo:

Navega a Diseño > Ajustes de imágenes (en PS 8.x) o Preferencias > Imágenes (en PS 1.7).
Busca la sección Opciones de generación de imágenes en la parte inferior de la página.
Encuentra el ajuste Formato de imagen y selecciona una de las opciones relacionadas con WebP. PrestaShop típicamente ofrece: solo JPEG, solo PNG, solo WebP, o JPEG/PNG + WebP (genera ambos formatos).
Selecciona JPEG/PNG + WebP si quieres compatibilidad con fallback, o Solo WebP si estás seguro de que todos tus visitantes usan navegadores modernos.
Establece el deslizador de calidad WebP. Un valor entre 80 y 85 proporciona un excelente equilibrio entre tamaño de archivo y calidad visual para fotografía de productos.
Haz clic en Guardar, luego haz clic en Regenerar miniaturas para crear versiones WebP de todas las imágenes existentes.

El proceso de regeneración puede llevar un tiempo considerable en catálogos grandes. Para una tienda con más de 5.000 productos, espera que el proceso dure de 30 minutos a varias horas dependiendo de los recursos del servidor. Es altamente recomendable ejecutar la regeneración durante las horas de menor actividad o vía CLI para evitar problemas de timeout de PHP.

Regeneración por CLI para catálogos grandes

Para tiendas con miles de productos, la regeneración desde el navegador probablemente excederá el tiempo límite. Usa el enfoque por CLI en su lugar:

php bin/console prestashop:image:regenerate --format=all

Este comando se ejecuta sin las restricciones de timeout del servidor web. También puedes apuntar a tipos de imagen específicos:

php bin/console prestashop:image:regenerate --type=products --format=all
php bin/console prestashop:image:regenerate --type=categories --format=all

En versiones de PrestaShop 1.7 que carecen del comando de consola, puedes aumentar los límites de timeout de PHP y ejecutar la regeneración a través del panel de administración, o usar un PHP personalizado que llame a la clase ImageManager directamente.

Configuración del servidor: reglas .htaccess de Apache

Incluso después de activar la generación de WebP en PrestaShop, tu servidor debe estar configurado para servir el formato correcto. PrestaShop genera archivos WebP junto con los archivos JPEG/PNG originales, pero el servidor necesita saber cuándo servir qué formato.

Para servidores Apache, añade las siguientes reglas a tu archivo .htaccess en el directorio raíz de PrestaShop o en el directorio img/:

<IfModule mod_rewrite.c>
  RewriteEngine On

  # Servir imágenes WebP si el navegador las soporta y el archivo existe
  RewriteCond %{HTTP_ACCEPT} image/webp
  RewriteCond %{REQUEST_FILENAME} (.+)\.(jpe?g|png)$
  RewriteCond %1.webp -f
  RewriteRule (.+)\.(jpe?g|png)$ $1.webp [T=image/webp,E=REQUEST_image,L]
</IfModule>

# Establecer el tipo MIME correcto para WebP
<IfModule mod_mime.c>
  AddType image/webp .webp
</IfModule>

# Cabecera Vary para prevenir problemas de caché
<IfModule mod_headers.c>
  Header append Vary Accept env=REQUEST_image
</IfModule>

Estas reglas funcionan de la siguiente manera: cuando un navegador solicita un archivo JPEG o PNG, el servidor verifica si el navegador envía una cabecera Accept: image/webp. Si lo hace, y existe una versión .webp del archivo en el disco, el servidor sirve de forma transparente el archivo WebP en su lugar. La cabecera Vary: Accept asegura que los proxies de caché almacenen versiones separadas para navegadores compatibles con WebP y navegadores que no lo son.

Asegúrate de que mod_rewrite, mod_mime y mod_headers están activados en tu instalación de Apache. La mayoría de los entornos de alojamiento compartido los tienen activados por defecto, pero puedes verificarlo con tu proveedor de hosting.

Configuración de Nginx

Para tiendas que ejecutan Nginx, la configuración va en tu bloque server o en un bloque location dentro del archivo de configuración de tu sitio:

map $http_accept $webp_suffix {
  default "";
  "~*image/webp" ".webp";
}

server {
  # ... configuración existente ...

  location ~* ^(/img/.+)\.(jpe?g|png)$ {
    set $img_path $1;
    add_header Vary Accept;
    try_files $img_path$webp_suffix $uri =404;
  }
}

La directiva map a nivel http verifica si el cliente envía una cabecera Accept compatible con WebP y establece una variable en consecuencia. El bloque location luego usa try_files para intentar primero servir la versión WebP, recurriendo al formato original si el archivo WebP no existe.

Después de modificar la configuración de Nginx, siempre prueba antes de recargar:

nginx -t
nginx -s reload

Consideraciones sobre CDN

Si usas un CDN como Cloudflare, KeyCDN o Bunny.net delante de tu tienda PrestaShop, la entrega de WebP requiere atención adicional.

Cloudflare

Cloudflare ofrece conversión WebP integrada a través de su funcionalidad Polish (disponible en planes Pro y superiores). Cuando Polish está activado con conversión WebP, Cloudflare convierte automáticamente las imágenes a WebP en el borde—lo que significa que no necesitas generar archivos WebP en tu servidor en absoluto. Sin embargo, ten en cuenta estas advertencias:

Polish solo funciona para imágenes servidas a través del proxy de Cloudflare (nube naranja activada).
No convierte imágenes mayores de 10 MB o imágenes con ciertos perfiles de color.
La conversión inicial añade latencia en la primera petición; las peticiones posteriores se sirven desde la caché.
Si también generas WebP localmente, podrías terminar con doble conversión, lo que puede degradar ligeramente la calidad.

Si prefieres servir tus propios archivos WebP a través de Cloudflare, asegúrate de que la cabecera Vary: Accept se gestione correctamente. Por defecto, Cloudflare elimina la cabecera Vary. Puede que necesites crear una Cache Rule o usar un Worker para asegurar una negociación de contenido adecuada.

Otros CDN

La mayoría de los CDN modernos soportan la negociación de contenido basada en la cabecera Accept, pero debes activarla explícitamente. Consulta la documentación de tu CDN para "soporte de cabecera Vary" o "negociación de contenido". Algunos CDN requieren que actives "Cache by Accept header" en tus reglas de caché. Sin esto, el CDN puede cachear la primera versión que vea (JPEG o WebP) y servirla a todos los visitantes independientemente del soporte del navegador.

Ajustes de calidad de imagen

Elegir el ajuste de calidad WebP correcto es crucial. Demasiado alto, y pierdes los beneficios de tamaño de archivo; demasiado bajo, y las imágenes de producto se ven borrosas o muestran artefactos de compresión—algo inaceptable para el comercio electrónico.

Estos son los ajustes de calidad recomendados por tipo de imagen:

Imágenes de producto (vistas grandes/detalladas): Calidad 82-88. Las fotos de producto necesitan verse nítidas, especialmente para artículos donde la textura y el detalle importan (moda, joyería, electrónica). Con calidad 85, una imagen de producto típica de 800x800 se comprime de ~120 KB (JPEG) a ~80 KB (WebP) sin pérdida de calidad visible.
Banners de categoría e imágenes hero: Calidad 78-82. Estas se visualizan típicamente a tamaños grandes pero con menor escrutinio del detalle fino.
Miniaturas e imágenes de listado: Calidad 75-80. En tamaños de visualización pequeños, la menor calidad es menos perceptible. Una miniatura con calidad 75 puede ser un 50-60% más pequeña que su equivalente JPEG.
Logos y gráficos con bordes nítidos: Usa WebP sin pérdida o manténlos como PNG. La compresión con pérdida crea artefactos visibles alrededor del texto y gráficos con bordes duros.

PrestaShop aplica un único ajuste de calidad de forma global. Si necesitas diferentes niveles de calidad para diferentes tipos de imagen, necesitarías modificar la clase ImageManager o usar un módulo de terceros que proporcione un control más granular.

Estrategias de fallback

Aunque el soporte de navegadores para WebP es casi universal en 2026, implementar una estrategia de fallback sigue considerándose una buena práctica, especialmente si tu tienda sirve a clientes que usan dispositivos antiguos o entornos corporativos restringidos.

Negociación de contenido del lado del servidor

Las reglas de .htaccess y Nginx descritas anteriormente implementan la negociación de contenido del lado del servidor. Este es el enfoque recomendado porque es transparente para la capa de aplicación. El navegador solicita la URL original, y el servidor decide qué formato entregar basándose en la cabecera Accept. No se requieren cambios en las plantillas ni en el código del front end.

El elemento HTML Picture

Un enfoque alternativo usa el elemento <picture> para dejar que el navegador elija el mejor formato:

<picture>
  <source srcset="imagen.webp" type="image/webp">
  <img src="imagen.jpg" alt="Nombre del producto">
</picture>

Esto requiere modificar las plantillas de PrestaShop (Smarty o Twig dependiendo de tu versión). Aunque te da control explícito, es más invasivo y más difícil de mantener a través de las actualizaciones del tema. La negociación del lado del servidor es generalmente preferida para despliegues de PrestaShop.

Fallback integrado de PrestaShop

Cuando seleccionas la opción "JPEG/PNG + WebP" en los ajustes de imagen de PrestaShop, el sistema genera ambos formatos. PrestaShop 8.x gestiona el fallback automáticamente en sus plantillas principales, verificando si el archivo WebP existe antes de referenciarlo. Si usas un tema personalizado, verifica que las plantillas de imágenes de producto del tema soporten este enfoque de formato dual.

Problemas comunes y cómo solucionarlos

1. Imágenes rotas después de activar WebP

El problema más común después de activar WebP son imágenes rotas en toda la tienda. Esto suele ocurrir porque:

Los archivos WebP no fueron generados. Activar el ajuste solo afecta a las imágenes recién subidas. Debes hacer clic en "Regenerar miniaturas" para crear versiones WebP de las imágenes existentes. Para catálogos grandes, usa el comando CLI.
Los permisos de archivo son incorrectos. El usuario del servidor web (típicamente www-data) debe tener permisos de escritura en el árbol de directorios img/. Después de la regeneración, verifica los permisos: find img/ -name "*.webp" -exec ls -la {} \;
Las reglas .htaccess entran en conflicto. El .htaccess predeterminado de PrestaShop contiene reglas de reescritura que pueden entrar en conflicto con las reglas de reescritura WebP. Coloca las reglas WebP antes del bloque de reescritura predeterminado de PrestaShop para asegurar que se evalúen primero.

2. Extensiones GD o Imagick faltantes

La generación de WebP requiere que PHP tenga la biblioteca GD o la extensión ImageMagick compilada con soporte WebP. Para verificar:

php -r "echo gd_info()['WebP Support'] ? 'GD WebP OK' : 'GD WebP FALTA';"

O para ImageMagick:

php -r "echo in_array('WEBP', Imagick::queryFormats()) ? 'Imagick WebP OK' : 'Imagick WebP FALTA';"

Si el soporte WebP falta, necesitas recompilar PHP con los flags apropiados o instalar los paquetes correctos. En Debian/Ubuntu: apt-get install libwebp-dev seguido de recompilar la extensión GD, o instalar una versión de PHP que incluya soporte WebP (PHP 7.4+ típicamente lo incluye por defecto).

En alojamiento compartido, si tu compilación de PHP carece de soporte WebP, contacta a tu proveedor de hosting. La mayoría de los entornos de alojamiento modernos incluyen soporte WebP en las instalaciones de PHP 8.x.

3. Problemas de caché

Los problemas relacionados con la caché están entre los problemas WebP más frustrantes:

Caché del navegador: Después de activar WebP, los navegadores pueden seguir mostrando versiones JPEG/PNG cacheadas. Aconseja a los usuarios hacer una recarga forzada (Ctrl+Shift+R), pero esto se resuelve solo a medida que las imágenes cacheadas expiran.
Caché del lado del servidor: Si usas Varnish, Redis o cualquier caché de página completa, la caché debe purgarse después de activar WebP. De lo contrario, las páginas cacheadas referenciarán URLs de imágenes o tipos MIME antiguos.
Caché del CDN: Purga la caché de tu CDN completamente después de activar WebP. Presta especial atención a las claves de caché del CDN—si el CDN no varía la caché por cabecera Accept, puede servir WebP a navegadores que no lo soportan (o viceversa).
OPcache: Si modificaste archivos PHP como parte de la activación de WebP (por ejemplo, sobreescrituras personalizadas de ImageManager), reinicia OPcache para asegurar que el nuevo código surta efecto.
Caché Smarty de PrestaShop: Limpia la caché Smarty desde el back office (Parámetros Avanzados > Rendimiento) o elimina el contenido del directorio var/cache/.

4. Tipos MIME incorrectos

Si tu servidor no reconoce la extensión .webp, los navegadores no podrán renderizar las imágenes aunque los archivos sean válidos. Asegúrate de que la configuración de tu servidor incluya el mapeo de tipo MIME correcto: image/webp para archivos .webp. La directiva AddType en la sección de Apache anterior se encarga de esto.

5. Problemas de subida de imágenes en el back office

El back office de PrestaShop valida los formatos de imagen subidos. En algunas versiones, subir una imagen WebP directamente a través del editor de productos puede fallar con un error de validación. Esto se debe a que la lista blanca del validador de subidas puede no incluir WebP. Verifica las extensiones permitidas en Parámetros Avanzados > Administración o en la configuración correspondiente.

6. Incompatibilidad con módulos de terceros

Algunos módulos de terceros (especialmente sliders, módulos de galería y módulos de zoom de imágenes de producto) codifican las extensiones de archivo de imágenes de forma fija o no soportan WebP. Después de activar WebP, prueba todos los módulos que muestran imágenes. Los síntomas comunes incluyen miniaturas faltantes en módulos de slider o funcionalidad de zoom rota. Contacta al desarrollador del módulo para actualizaciones, o asegúrate de que la negociación de contenido del lado del servidor gestione correctamente el fallback.

Verificar la entrega de WebP

Después de la configuración, verifica que las imágenes WebP realmente se están sirviendo. Estos son varios métodos:

Herramientas de desarrollo del navegador

Abre tu tienda en Chrome o Firefox.
Abre DevTools (F12) y ve a la pestaña Network (Red).
Filtra por tipo Img.
Recarga la página.
Haz clic en cualquier petición de imagen y comprueba las Response Headers (Cabeceras de respuesta). El Content-Type debería ser image/webp.
También comprueba la columna Type en la lista de red—debería mostrar "webp" para las imágenes convertidas.

Pruebas por línea de comandos

Usa curl para verificar que la negociación de contenido funciona correctamente:

# Petición con soporte WebP
curl -s -I -H "Accept: image/webp,image/*" https://tutienda.com/img/p/1/2/3/456-home_default.jpg | grep Content-Type
# Esperado: Content-Type: image/webp

# Petición sin soporte WebP
curl -s -I -H "Accept: image/jpeg" https://tutienda.com/img/p/1/2/3/456-home_default.jpg | grep Content-Type
# Esperado: Content-Type: image/jpeg

Herramientas online

Google PageSpeed Insights y Lighthouse marcan las imágenes que no se sirven en formatos de nueva generación. Ejecuta una auditoría Lighthouse en tus páginas de producto—si WebP está correctamente configurado, no deberías ver la recomendación "Serve images in next-gen formats" (Servir imágenes en formatos de nueva generación).

Impacto en el rendimiento

El impacto real en el rendimiento de WebP en una tienda PrestaShop depende del tamaño del catálogo y la composición de la página, pero las mejoras típicas incluyen:

Reducción total del peso de página: 15-30% en páginas de listado de productos y 10-20% en páginas de detalle de producto, donde las imágenes constituyen la mayoría de los bytes descargados.
Largest Contentful Paint (LCP): Mejora de 200-600ms en promedio, ya que la imagen principal del producto se carga más rápido. Esta es una de las tres Core Web Vitals y afecta directamente las clasificaciones de búsqueda.
Time to Interactive (TTI): Mejora marginal, ya que la carga de imágenes compite con la ejecución de JavaScript por el ancho de banda pero no por la CPU.
Ahorro de ancho de banda del servidor: Para una tienda que sirve 100.000 páginas vistas al mes, WebP puede reducir el uso mensual de ancho de banda en 20-50 GB, potencialmente reduciendo los costes de alojamiento.
Rendimiento móvil: Las ganancias más significativas son en conexiones móviles, donde los tamaños de imagen reducidos se traducen directamente en tiempos de carga más rápidos en redes 4G/5G. La indexación mobile-first de Google hace esto especialmente importante.

Ten en cuenta que la generación de WebP añade carga de CPU durante el procesamiento de imágenes (subidas y regeneración). En alojamiento compartido con recursos limitados, regenerar las miniaturas de un catálogo grande puede ralentizar temporalmente el servidor. Programa la regeneración durante períodos de bajo tráfico.

Lista de verificación resumen

Para desplegar WebP con éxito en tu tienda PrestaShop, sigue esta lista de verificación:

Verifica que PHP tiene GD o ImageMagick con soporte WebP.
Activa la generación WebP en los ajustes de imagen de PrestaShop (usa JPEG/PNG + WebP por seguridad).
Establece la calidad en 82-85 para un equilibrio óptimo.
Regenera todas las miniaturas (usa CLI para catálogos grandes).
Añade reglas de negociación de contenido del lado del servidor (.htaccess o configuración Nginx).
Configura tu CDN para variar la caché por cabecera Accept.
Purga todas las cachés (navegador, servidor, CDN, Smarty, OPcache).
Prueba la entrega usando DevTools del navegador y curl.
Verifica que los módulos de terceros muestran las imágenes correctamente.
Ejecuta una auditoría Lighthouse para confirmar que no quedan advertencias de "formatos de nueva generación".

WebP ya no es opcional para un comercio electrónico competitivo. Con el soporte integrado de PrestaShop y una configuración de servidor sencilla, no hay razón para seguir sirviendo archivos JPEG y PNG sobredimensionados. La configuración lleva menos de una hora, y los beneficios de rendimiento son inmediatos y medibles.

Leer respuesta completa

¿Qué es el CSS Crítico y Por Qué es Importante para PrestaShop?

El CSS crítico se refiere al conjunto mínimo de reglas CSS necesarias para renderizar el contenido visible en la parte superior de la página web (above the fold). Cuando un navegador carga tu tienda PrestaShop, debe descargar, analizar y aplicar cada archivo CSS antes de poder mostrar cualquier contenido en pantalla. Esto significa que una instalación típica de PrestaShop con una hoja de estilos del tema, hojas de estilos de módulos y posiblemente un framework CSS puede obligar a los visitantes a mirar una página en blanco durante varios segundos mientras el navegador procesa cientos de kilobytes de CSS que pueden no ser relevantes para lo que el visitante ve inicialmente.

El concepto detrás del CSS crítico es sencillo: extraer solo los estilos necesarios para la visualización inicial del viewport, incorporarlos directamente en el documento HTML y diferir todo lo demás. Esto permite al navegador comenzar a renderizar la página casi de inmediato, mejorando drásticamente el tiempo de carga percibido y varias métricas clave de rendimiento.

Cómo el CSS que Bloquea el Renderizado Perjudica los Core Web Vitals

Los Core Web Vitals de Google son un conjunto de métricas que influyen directamente en el posicionamiento en los motores de búsqueda. El CSS que bloquea el renderizado afecta negativamente a múltiples métricas de forma simultánea.

Largest Contentful Paint (LCP) mide cuándo el elemento visible más grande termina de renderizarse. Dado que el CSS bloquea completamente el renderizado, cada milisegundo empleado en descargar y analizar CSS se suma directamente a tu puntuación LCP. Una tienda PrestaShop que carga 300KB de CSS antes de renderizar cualquier contenido superará constantemente el umbral de 2,5 segundos para LCP, especialmente en conexiones móviles.

First Contentful Paint (FCP) registra cuándo el navegador renderiza por primera vez cualquier contenido. El CSS que bloquea el renderizado retrasa el FCP porque el navegador no puede pintar un solo píxel hasta que todas las hojas de estilos bloqueantes se hayan procesado. Las tiendas con numerosos módulos, cada uno inyectando sus propios archivos CSS, a menudo registran tiempos de FCP superiores a 3-4 segundos en conexiones 3G.

Cumulative Layout Shift (CLS) también puede verse afectado indirectamente. Cuando el CSS se carga tarde o de forma asíncrona sin un CSS crítico adecuado implementado, los elementos pueden renderizarse sin estilos y luego cambiar de posición una vez que se aplican los estilos. Esto crea inestabilidad visual que frustra a los usuarios y aumenta las puntuaciones de CLS.

Interaction to Next Paint (INP) se ve afectado porque el hilo principal está ocupado analizando archivos CSS de gran tamaño en lugar de responder a la entrada del usuario. Incluso después del renderizado inicial, el navegador aún debe procesar las hojas de estilos diferidas, y si esto ocurre durante la interacción del usuario, se produce un retraso notable.

Identificar los Recursos que Bloquean el Renderizado en PrestaShop

Antes de poder eliminar el CSS que bloquea el renderizado, necesitas identificar exactamente qué recursos están causando problemas. Varias herramientas pueden ayudar con este análisis.

Google PageSpeed Insights proporciona una auditoría específica llamada "Eliminar los recursos que bloquean el renderizado" que enumera cada archivo CSS y JavaScript que bloquea el renderizado inicial. Ejecuta la página principal y las páginas clave de categoría/producto de tu PrestaShop con esta herramienta. Presta atención a la columna de ahorro estimado, que muestra cuántos milisegundos podrías recuperar al diferir cada recurso.

Chrome DevTools - Pestaña Coverage es invaluable para comprender la utilización del CSS. Abre DevTools, navega a la pestaña Coverage (Ctrl+Shift+P, luego escribe "coverage") y recarga la página. Esto te muestra exactamente cuánto de cada archivo CSS se utiliza realmente durante el renderizado inicial. En una tienda PrestaShop típica, descubrirás que el 70-85% del CSS cargado en cualquier página no se utiliza para esa página específica.

WebPageTest ofrece vistas de filmstrip y cascada que muestran claramente cuándo se solicitan los archivos CSS, cuándo terminan de cargarse y cuándo ocurre el primer renderizado. La brecha entre la llegada del HTML y el primer renderizado es causada en gran parte por el CSS que bloquea el renderizado.

Una tienda PrestaShop típica 1.7 u 8.x carga los siguientes recursos CSS que bloquean el renderizado: la hoja de estilos del tema (frecuentemente 200-400KB), un archivo del framework Bootstrap (150KB+), Font Awesome o fuentes de iconos (50-100KB) y entre 3 y 15 hojas de estilos específicas de módulos. Combinados, pueden superar fácilmente los 500KB de CSS que bloquea el renderizado.

Extracción Manual del CSS Crítico

La extracción manual implica identificar las reglas CSS necesarias para el contenido above the fold y separarlas del resto. Aunque es laboriosa, este enfoque te da el máximo control sobre el resultado.

Comienza identificando qué aparece above the fold en cada tipo de página. Para una tienda PrestaShop, las plantillas de página principales son: página de inicio, listado de categorías, página de producto, carrito y proceso de pago. Cada una tiene un contenido above the fold diferente. La página de inicio típicamente muestra el encabezado, la navegación y un banner o slider principal. Las páginas de categoría muestran el encabezado, las migas de pan y la primera fila de productos. Las páginas de producto muestran el encabezado, la imagen del producto, el título y el precio.

Utiliza la pestaña Coverage de Chrome DevTools para identificar qué reglas CSS se aplican a los elementos above the fold. También puedes usar el panel "Computed" en la pestaña Elements para ver exactamente qué reglas afectan a cada elemento visible.

Extrae estas reglas en un archivo separado o en un bloque inline. Un payload típico de CSS crítico para una página PrestaShop debería estar entre 10KB y 30KB (antes de la compresión gzip). Si tu CSS crítico supera los 50KB, probablemente estás incluyendo demasiadas reglas. Concéntrate estrictamente en el layout (grid, flexbox), la tipografía (font-family, font-size, line-height para el texto visible), los colores y fondos de los elementos visibles, la estructura del encabezado y la navegación, y el layout del área de contenido principal.

El enfoque manual es más adecuado para tiendas con un diseño fijo que cambia raramente. Si actualizas frecuentemente el tema o añades módulos, la carga de mantenimiento del CSS crítico manual se vuelve insostenible.

Herramientas Automatizadas para CSS Crítico

Las herramientas automatizadas generan CSS crítico renderizando la página en un navegador headless y extrayendo solo los estilos aplicados a los elementos dentro del viewport. Dos herramientas dominan este espacio.

Critters (de Google Chrome Labs)

Critters es un plugin de Webpack que incorpora el CSS crítico inline en tiempo de compilación. A diferencia de otras herramientas, Critters no utiliza un navegador headless. En su lugar, analiza estáticamente el HTML y CSS, identificando qué selectores coinciden con los elementos presentes en el documento HTML. Esto lo hace más rápido y predecible que los enfoques basados en navegador.

Para la integración con PrestaShop, Critters funciona bien cuando se incorpora en un pipeline de compilación personalizado. Procesa la salida HTML renderizada e incorpora los estilos críticos inline mientras convierte los enlaces restantes de hojas de estilos para cargarse de forma asíncrona. La ventaja principal de Critters es su velocidad y fiabilidad durante los procesos de compilación. Al no necesitar una instancia de navegador en ejecución, puede procesar páginas rápida y consistentemente.

Las consideraciones de configuración para Critters en PrestaShop incluyen establecer el ancho de viewport apropiado (típicamente 1350px para escritorio, 375px para móvil), excluir ciertos selectores generados dinámicamente (como las clases específicas de módulos añadidas mediante JavaScript) y manejar correctamente las declaraciones font-face para evitar el flash of invisible text (FOIT).

Critical (de Addy Osmani)

El paquete npm Critical utiliza un navegador headless (Puppeteer) para renderizar páginas y extraer el CSS above the fold. Produce resultados más precisos que el análisis estático porque ve la página exactamente como lo haría un navegador real, incluyendo el contenido renderizado con JavaScript y los estilos aplicados dinámicamente.

Para usar Critical con PrestaShop, crearías un paso de compilación que obtiene cada tipo de página de tu tienda en producción o staging, extrae el CSS crítico y lo inyecta en las plantillas del tema. Este enfoque requiere un manejo cuidadoso de la autenticación para las páginas detrás de inicio de sesión (checkout, páginas de cuenta) y la consideración de diferentes viewports para el CSS crítico responsive.

Critical puede ejecutarse como un paso posterior al despliegue. Después de desplegar una actualización del tema, regeneras el CSS crítico para cada tipo de página y actualizas los estilos inline en consecuencia. Esto asegura que el CSS crítico se mantenga sincronizado con los estilos reales del tema.

Configuración CCC de PrestaShop: Combinar, Comprimir, Caché

PrestaShop incluye una optimización CSS integrada a través de su función CCC (Combinar, Comprimir, Caché), accesible en el Back Office bajo Parámetros Avanzados > Rendimiento. Comprender estas configuraciones es esencial antes de implementar el CSS crítico, ya que interactúan con tu estrategia de optimización.

Combinar archivos CSS fusiona todos los archivos CSS en un único archivo combinado. Esto reduce el número de solicitudes HTTP, lo cual era crucial en entornos HTTP/1.1. Con HTTP/2 y HTTP/3, el beneficio de combinar se reduce porque múltiples archivos pueden descargarse en paralelo. Sin embargo, combinar todavía ayuda con el bloqueo del renderizado porque el navegador solo necesita esperar por un archivo en lugar de potencialmente docenas.

Comprimir CSS (minificación) elimina espacios en blanco, comentarios y caracteres innecesarios de los archivos CSS. Esto reduce típicamente el tamaño de los archivos CSS entre un 15-25%. Activa siempre esta opción en producción.

Caché CSS añade un hash único a los nombres de los archivos CSS combinados, habilitando un almacenamiento en caché agresivo del navegador mientras asegura que los visitantes obtengan los estilos actualizados después de los cambios. Esto funciona tanto con el sistema integrado de PrestaShop como con las configuraciones CDN.

Al implementar el CSS crítico junto con CCC, la configuración recomendada es habilitar las tres opciones CCC. El archivo CSS combinado y minificado se convierte en tu hoja de estilos diferida (no crítica), mientras que el CSS crítico se incorpora inline en el head HTML. Esto te da lo mejor de ambos mundos: renderizado inmediato del CSS crítico inline y almacenamiento en caché eficiente de la hoja de estilos completa para las cargas de página posteriores.

Una advertencia importante: después de habilitar o cambiar la configuración CCC, debes vaciar la caché de PrestaShop. Navega a Parámetros Avanzados > Rendimiento y haz clic en "Vaciar caché" o elimina el contenido de los directorios /var/cache/prod/ y /var/cache/dev/. Las plantillas compiladas de Smarty en /var/cache/smarty/compile/ también deben vaciarse.

Implementar CSS Crítico Inline en PrestaShop

La implementación real del CSS crítico en PrestaShop implica modificar la plantilla head del tema para incorporar los estilos críticos inline y diferir el CSS restante.

En el archivo _partials/head.tpl de tu tema (o el equivalente en tu tema), necesitas añadir el CSS crítico inline dentro de una etiqueta style en el head del documento. Esto reemplaza el enlace normal a la hoja de estilos para los estilos above the fold. El CSS crítico debe colocarse inmediatamente después de las etiquetas meta y antes de cualquier otro recurso.

Un enfoque práctico es crear una plantilla Smarty que incluya el CSS crítico inline. Crea un archivo en tu tema en _partials/critical-css.tpl que contenga los estilos críticos envueltos en un elemento style. Luego incluye este parcial en tu plantilla head. Esto mantiene el CSS crítico manejable y separado de la lógica principal de la plantilla.

Para diferentes tipos de página, puedes cargar condicionalmente diferentes CSS críticos. PrestaShop proporciona la variable $page.page_name en Smarty que indica qué tipo de página se está renderizando. Úsala para cargar CSS crítico específico por página: un conjunto para la página de inicio, otro para las páginas de categoría, otro para las páginas de producto y un fallback genérico para todas las demás páginas.

Carga Asíncrona del CSS Restante

Una vez que el CSS crítico está incorporado inline, el CSS restante debe cargarse sin bloquear el renderizado. Existen varias técnicas para esto.

La técnica de intercambio del atributo media es el enfoque más ampliamente soportado. Cambia el atributo media del enlace de la hoja de estilos a "print" y añade un manejador onload que lo cambia a "all" una vez cargado. Esto le indica al navegador que la hoja de estilos es solo para impresión, por lo que la descarga con prioridad baja y no bloquea el renderizado. Una vez cargada, el manejador onload cambia el tipo de media a "all", aplicando los estilos a la pantalla. Incluye un fallback noscript con el enlace original para usuarios sin JavaScript.

El enfoque rel="preload" utiliza la precarga de enlaces para obtener la hoja de estilos con alta prioridad pero sin bloquear el renderizado. Añade rel="preload" y as="style" al elemento link, junto con un manejador onload que cambia el rel a "stylesheet". Este enfoque proporciona mejor prioridad de carga que la técnica de intercambio de media, pero tiene un soporte de navegador ligeramente inferior en navegadores más antiguos.

La librería loadCSS de Filament Group proporciona una solución JavaScript robusta para la carga asíncrona de CSS con amplio soporte de navegadores. Maneja casos extremos y fallbacks que las implementaciones manuales podrían pasar por alto. Para las tiendas PrestaShop que necesitan soportar navegadores más antiguos, esta es la opción más segura.

Cualquiera que sea la técnica que elijas, incluye siempre un fallback <noscript> que contenga el enlace normal a la hoja de estilos. Esto asegura que el sitio permanezca funcional para el pequeño porcentaje de visitantes con JavaScript deshabilitado.

Problemas de CSS Específicos de los Módulos en PrestaShop

Los módulos de PrestaShop son una de las mayores fuentes de CSS que bloquea el renderizado y presentan desafíos únicos para la optimización del CSS crítico.

Patrones de inyección de CSS de los módulos: La mayoría de los módulos PrestaShop registran su CSS a través del hookDisplayHeader o mediante el método setMedia() del módulo, que llama a $this->context->controller->addCSS(). Estas hojas de estilos se añaden al head de la página y bloquean el renderizado por defecto. Cuando CCC está habilitado, PrestaShop combina estas hojas de estilos de módulos con el CSS del tema, lo que significa que no pueden diferirse individualmente.

CSS innecesario de módulos en páginas irrelevantes: Un problema común es que los módulos cargan su CSS en todas las páginas incluso cuando la funcionalidad del módulo solo se usa en páginas específicas. Un módulo de pago que carga su CSS en la página de inicio, o un módulo de comparación de productos que carga CSS en la página de checkout, desperdicia ancho de banda y aumenta el tiempo de bloqueo del renderizado. Audita tus módulos y asegúrate de que cada uno solo cargue CSS en las páginas donde realmente se necesita. Muchos módulos ofrecen una opción de configuración para esto. Para los que no la tienen, puedes sobrescribir el hook de cabecera del módulo para añadir condiciones por tipo de página.

Calidad del CSS de módulos de terceros: Los módulos de terceros a menudo incluyen CSS pobremente optimizado. Puedes encontrar módulos que incluyen archivos CSS de 50KB+ cuando solo necesitan 5KB. Algunos incluyen frameworks CSS completos dentro del módulo. Otros incluyen CSS de desarrollo sin minificar. Identifica estos módulos usando la pestaña Coverage de Chrome DevTools y considera crear versiones optimizadas de sus hojas de estilos en el directorio de sobrescritura de módulos del tema en /themes/tu-tema/modules/nombre-modulo/views/css/.

Orden de carga del CSS de módulos: PrestaShop carga el CSS de los módulos en el orden en que los módulos están registrados para los hooks. Si el CSS de un módulo crítico se carga de último en el archivo combinado, el navegador debe analizar todo el CSS precedente antes de alcanzar los estilos esenciales. Puedes influir en el orden de carga a través de la página de posiciones de módulos en el Back Office (Diseño > Posiciones), moviendo los módulos esenciales más arriba en el hook displayHeader.

Medir la Mejora: Antes y Después

Medir el impacto de la implementación del CSS crítico requiere una metodología de pruebas consistente y las métricas correctas.

Herramientas para la medición: Usa Google PageSpeed Insights para datos de laboratorio y de campo, WebPageTest para un análisis detallado de la cascada, y Chrome DevTools Lighthouse para auditorías locales rápidas. Ejecuta pruebas desde múltiples ubicaciones y velocidades de conexión. El rendimiento móvil en conexiones 3G típicamente muestra la mejora más dramática con el CSS crítico porque el retraso del bloqueo del renderizado es proporcional a la velocidad de conexión.

Métricas clave a monitorear: El First Contentful Paint es la métrica más directamente mejorada por el CSS crítico, ya que mide el primer evento de renderizado. El LCP también debería mejorar porque el navegador puede comenzar a renderizar y cargar imágenes visibles antes. El Time to Interactive podría mejorar ligeramente porque el hilo principal dedica menos tiempo al análisis inicial del CSS.

Metodología de pruebas: Ejecuta siempre al menos 5 pruebas antes y 5 pruebas después de la implementación, y luego compara las medianas en lugar de ejecuciones individuales. Las condiciones de red, la carga del servidor y la caché del CDN pueden causar variaciones significativas entre ejecuciones individuales de prueba. Herramientas como WebPageTest permiten especificar el número de ejecuciones y calculan automáticamente las medianas.

Números de Rendimiento en el Mundo Real

Basándose en optimizaciones reales de tiendas PrestaShop, aquí están las mejoras de rendimiento que puedes esperar típicamente al implementar correctamente el CSS crítico.

First Contentful Paint: Mejora típica de 1,2 a 2,5 segundos en conexiones móviles 3G. Una tienda que anteriormente tenía un FCP de 4,2 segundos puede alcanzar de forma realista 1,8-2,0 segundos con CSS crítico correctamente implementado. En conexiones de escritorio de banda ancha, la mejora es típicamente de 0,3-0,8 segundos.

Largest Contentful Paint: Una mejora de 0,8-2,0 segundos es común. El LCP se beneficia porque el navegador puede comenzar a cargar imágenes y otros elementos grandes antes cuando el CSS ya no bloquea el renderizado. Una tienda PrestaShop con LCP de 5,1 segundos en móvil a menudo puede reducirlo por debajo de 3,0 segundos con CSS crítico combinado con optimización de imágenes.

Puntuación PageSpeed: Las puntuaciones PageSpeed móvil típicamente aumentan entre 15 y 30 puntos después de eliminar el CSS que bloquea el renderizado. Una tienda con puntuación de 35-45 en móvil puede alcanzar de forma realista 60-75 solo con CSS crítico. Combinado con otras optimizaciones (compresión de imágenes, diferimiento de JavaScript, caché del lado del servidor), puntuaciones superiores a 85 son alcanzables.

Total Blocking Time: Una reducción de 200-500 milisegundos es típica, ya que el hilo principal dedica menos tiempo al análisis del CSS durante la fase crítica de carga.

Estos números asumen una instalación PrestaShop bien configurada con un tema moderno, tiempos de respuesta del servidor razonables (menos de 500ms TTFB) y una configuración CDN adecuada. Las tiendas con hosting extremadamente lento, un número excesivo de módulos o temas fuertemente personalizados pueden ver resultados diferentes.

Lista de Verificación para la Implementación

Para resumir el proceso completo de implementación del CSS crítico en tu tienda PrestaShop, sigue estos pasos en orden. Primero, audita tu panorama CSS actual usando Chrome DevTools Coverage para entender cuánto CSS se carga y cuánto se utiliza realmente above the fold. Segundo, habilita la configuración CCC de PrestaShop (Combinar, Comprimir, Caché) como optimización base. Tercero, elige tu método de generación de CSS crítico: extracción manual para temas simples y estables, o herramientas automatizadas como Critters o Critical para tiendas complejas o frecuentemente actualizadas. Cuarto, genera el CSS crítico para cada tipo de página principal: página de inicio, categoría, producto, carrito y checkout. Quinto, implementa el CSS crítico inline en la plantilla head del tema con carga condicional por tipo de página. Sexto, configura la carga asíncrona para el archivo CSS combinado restante usando la técnica de intercambio de media o preload. Séptimo, audita el CSS de los módulos para eliminar la carga de hojas de estilos innecesarias en páginas irrelevantes. Octavo, mide los resultados usando PageSpeed Insights, WebPageTest y Lighthouse, comparando las métricas antes y después. Noveno, establece un proceso para regenerar el CSS crítico después de actualizaciones del tema o cambios significativos en los módulos. Finalmente, monitorea los Core Web Vitals en Google Search Console para verificar las mejoras en el mundo real para los visitantes reales a lo largo del tiempo.

La optimización del CSS crítico es una de las mejoras de rendimiento de mayor impacto que puedes realizar en una tienda PrestaShop. Aunque la implementación inicial requiere esfuerzo, la mejora resultante en los Core Web Vitals, la experiencia del usuario y el posicionamiento en los motores de búsqueda hace que la inversión valga absolutamente la pena.

Leer respuesta completa

Por Qué Deberías Cambiar la URL Admin Predeterminada

Cada instalación de PrestaShop crea un directorio admin con un nombre como admin1234 — los dígitos se generan aleatoriamente durante la instalación. Este directorio es donde accedes al back office de tu tienda. Aunque el sufijo aleatorio proporciona cierta oscuridad básica, no es una medida de seguridad robusta. Bots automatizados y atacantes escanean rutinariamente patrones comunes de URL admin en miles de sitios web. Cambiar tu URL admin por algo impredecible añade una capa significativa de defensa.

La razón principal para cambiar el nombre de la carpeta admin es reducir la exposición a ataques de fuerza bruta. Si un atacante no puede encontrar tu página de inicio de sesión, no puede intentar adivinar tu contraseña. Esto no reemplaza las contraseñas seguras y otras medidas de seguridad, pero es un primer paso efectivo que no cuesta nada y solo toma unos minutos de implementar.

Además, una URL admin personalizada hace que tu tienda se vea más profesional si empleados o clientes necesitan acceder al back office. Una URL como tudominio.com/gestionar-tienda/ es más fácil de recordar y comunicar que tudominio.com/admin7382pqxz/.

Cómo Funcionan las URL Admin de PrestaShop

El directorio admin de PrestaShop es una carpeta física en tu servidor. Cuando escribes tudominio.com/admin1234/ en tu navegador, el servidor web busca el directorio admin1234 y sirve el archivo index.php que contiene. Esto significa que cambiar la URL admin es principalmente cuestión de renombrar el directorio en el sistema de archivos del servidor.

Dentro del directorio admin, PrestaShop almacena archivos de controladores, archivos de plantillas y configuración que hacen referencia a la ruta admin. En PrestaShop 1.7 y 8.x, el directorio admin también contiene componentes de enrutamiento de Symfony. La configuración interna almacena el nombre del directorio admin en el archivo app/config/parameters.php (o config/parameters.php en versiones anteriores) bajo la clave ps_admin_dir. Este valor debe coincidir con el nombre real del directorio para que el back office funcione correctamente.

Paso a Paso: Renombrar el Directorio Admin

Método 1: Vía FTP o Administrador de Archivos

Este es el método más seguro y directo. Funciona en todos los tipos de hosting y todas las versiones de PrestaShop desde la 1.6 hasta la 8.x y 9.x.

Conéctate a tu servidor vía FTP (FileZilla, WinSCP) o usa el administrador de archivos del panel de control de tu hosting (cPanel, Plesk).
Navega al directorio raíz de PrestaShop — es donde ves carpetas como classes/, modules/, themes/ y tu carpeta admin actual.
Identifica tu carpeta admin actual. Tendrá un nombre como admin1234 o admin-dev (en instalaciones de desarrollo). No la confundas con la carpeta admin-dev/ si tienes la versión con código fuente instalada.
Renombra la carpeta al nombre deseado. Haz clic derecho en la carpeta en tu cliente FTP y selecciona "Renombrar". Elige un nombre difícil de adivinar pero fácil de recordar. Buenos ejemplos: manage-xyz, backoffice-abc, control-2024. Evita nombres obvios como admin, administrator, backend, dashboard o manage.
Actualiza el archivo de configuración. Abre app/config/parameters.php en un editor de texto y encuentra la línea que contiene ps_admin_dir. Cambia el valor para que coincida exactamente con el nuevo nombre del directorio.
Vacía la caché. Elimina el contenido de var/cache/prod/ y var/cache/dev/ (si existe). La caché antigua contiene referencias al nombre del directorio admin anterior.
Prueba la nueva URL. Abre tu navegador y navega a tudominio.com/tu-nuevo-nombre-admin/. Deberías ver la página de inicio de sesión de PrestaShop.

Método 2: Vía SSH (Línea de Comandos)

Si tienes acceso SSH a tu servidor, puedes renombrar el directorio con un solo comando:

cd /var/www/html/prestashop
mv admin1234 tu-nuevo-nombre

Luego actualiza la configuración:

sed -i "s/admin1234/tu-nuevo-nombre/g" app/config/parameters.php

Y vacía la caché:

rm -rf var/cache/prod/* var/cache/dev/*

Este método es más rápido y menos propenso a errores que usar FTP, especialmente si el nombre del directorio aparece en múltiples lugares del archivo de configuración.

Diferencias Entre las Versiones de PrestaShop

PrestaShop 1.6

En PrestaShop 1.6, el nombre del directorio admin se almacena en config/settings.inc.php en lugar de app/config/parameters.php. Busca una línea como:

define('_PS_ADMIN_DIR_', '/var/www/html/prestashop/admin1234');

Cambia la ruta para que coincida con el nuevo nombre del directorio. La estructura del directorio app/ no existe en la 1.6 porque es anterior a la integración con Symfony. Por lo demás, el proceso de renombrar el directorio es idéntico.

PrestaShop 1.7

PrestaShop 1.7 introdujo el framework Symfony, añadiendo el archivo app/config/parameters.php. Sin embargo, la 1.7 aún mantiene compatibilidad retroactiva con el enrutamiento admin legacy. Después de renombrar, vacía tanto la caché de Smarty (var/cache/) como la caché de Symfony. El nombre del directorio admin se almacena en parameters.php dentro del array parameters:

'parameters' => array(
    // ...
    'ps_admin_dir' => 'tu-nuevo-nombre',
    // ...
)

PrestaShop 8.x

PrestaShop 8.x continúa la arquitectura de la 1.7 con una integración de Symfony más profunda. El proceso es el mismo que en la 1.7, pero el archivo parameters.php puede usar la configuración basada en YAML de Symfony en algunas configuraciones. Verifica tanto app/config/parameters.php como app/config/parameters.yml si está presente. Después de renombrar, siempre vacía la caché completamente.

PrestaShop 9.x

PrestaShop 9.x refina aún más la integración con Symfony. El concepto de directorio admin permanece, pero el enrutamiento está más basado en Symfony. El archivo parameters.php o parameters.yml aún contiene la referencia al directorio admin. El proceso de renombrar no cambia, pero presta especial atención a vaciar todos los niveles de caché, ya que la caché de enrutamiento de Symfony es más agresiva en la 9.x.

Actualización de .htaccess Después de Renombrar

En la mayoría de los casos, no necesitas modificar el archivo .htaccess en el directorio raíz de PrestaShop después de renombrar la carpeta admin. Las reglas .htaccess de PrestaShop típicamente no hacen referencia al directorio admin por nombre. Las reglas de reescritura manejan el front office (URLs de cara al cliente), y el directorio admin se accede directamente sin reescritura.

Sin embargo, hay excepciones. Si has añadido reglas de seguridad personalizadas al .htaccess que hacen referencia al antiguo nombre del directorio admin, debes actualizar esas reglas. Por ejemplo, si previamente añadiste listas blancas de IP para el área admin:

# Regla antigua
<Directory /var/www/html/prestashop/admin1234>
    Order Deny,Allow
    Deny from all
    Allow from 203.0.113.50
</Directory>

Esta debe actualizarse para hacer referencia al nuevo nombre del directorio. Del mismo modo, verifica cualquier plugin de seguridad (como las reglas de mod_security) o configuraciones CDN (reglas de página de Cloudflare) que puedan hacer referencia a la antigua ruta admin.

También verifica el archivo .htaccess dentro del directorio admin mismo. PrestaShop coloca uno allí para el enrutamiento interno. Este archivo generalmente no necesita modificación porque usa rutas relativas, pero verifícalo después de renombrar para asegurarte de que nada esté roto.

Errores Comunes y Qué NO Hacer

No Uses Symlinks como Atajo

Algunos administradores crean un enlace simbólico desde un nuevo nombre al antiguo directorio admin en lugar de renombrarlo realmente. Esto anula completamente el propósito porque el directorio antiguo sigue existiendo y es accesible. Siempre realiza un renombrado real, no un symlink.

No Olvides Actualizar parameters.php

El error más común es renombrar el directorio pero olvidar actualizar el archivo de configuración. Cuando esto sucede, verás una página en blanco o un error 500 al intentar acceder al panel admin. PrestaShop internamente hace referencia al nombre del directorio admin desde la configuración, y una discrepancia causa un fallo inmediato.

No Elijas Nombres Obvios

Renombrar tu directorio admin de admin1234 a admin o administrator es contraproducente. Los escáneres automatizados verifican estos nombres obvios primero. Elige algo que combine palabras y números de una manera que no sea fácilmente adivinable: store-mgmt-7x9, bo-access-42, o incluso una cadena completamente aleatoria como kx9m4p2q.

No Renombres Mientras los Usuarios Están Conectados

Las sesiones activas del back office se interrumpirán inmediatamente cuando renombres el directorio. Cualquier usuario admin actualmente conectado verá un error y perderá el trabajo no guardado. Realiza el renombrado durante un período de bajo tráfico y notifica a cualquier miembro del personal que use el back office.

No Olvides los Marcadores y Enlaces Guardados

Después de renombrar, actualiza todos los marcadores, contraseñas guardadas del navegador, entradas del administrador de contraseñas y documentación que hagan referencia a la antigua URL admin. Notifica a todos los miembros del personal que acceden al back office sobre la nueva URL.

No Uses Caracteres Especiales ni Espacios

El nombre del directorio admin debe ser un componente de ruta URL válido. Usa solo letras minúsculas, números y guiones. Evita espacios, guiones bajos (aunque funcionan, los guiones son más limpios), caracteres acentuados y cualquier carácter especial.

Conflictos de Módulos y Consideraciones de Terceros

La mayoría de los módulos PrestaShop bien escritos usan las funciones internas de PrestaShop para determinar la ruta del directorio admin en lugar de codificarla directamente. Estos módulos continuarán funcionando después del renombrado sin ninguna intervención. Sin embargo, algunos módulos mal codificados pueden codificar directamente la ruta admin en sus archivos de configuración, JavaScript o endpoints AJAX.

Después de renombrar tu directorio admin, prueba lo siguiente en tu back office:

Todos los módulos instalados — abre la página de configuración de cada módulo
Cualquier módulo que use llamadas AJAX (verifica la consola del navegador para errores 404)
Callbacks y webhooks de módulos de pago
Cualquier integración personalizada o conexión ERP que haga referencia a la URL admin
Trabajos cron que llamen a scripts del lado admin

Si un módulo deja de funcionar después del renombrado, verifica sus archivos de configuración para rutas admin codificadas directamente. Muchos módulos almacenan sus configuraciones en la tabla de base de datos ps_configuration, y algunos de estos valores pueden contener el antiguo nombre del directorio admin.

Para buscar en tu base de datos referencias al antiguo directorio admin:

SELECT * FROM ps_configuration WHERE value LIKE '%admin1234%';

Reemplaza admin1234 con tu antiguo nombre de directorio y ps_ con tu prefijo de base de datos real.

Medidas de Seguridad Adicionales para el Área Admin

Renombrar el directorio admin es un buen primer paso, pero debería ser parte de una estrategia de seguridad integral. Considera estas medidas adicionales:

Lista Blanca de Direcciones IP

Si tú y tu equipo siempre acceden al back office desde direcciones IP fijas, puedes restringir el acceso a nivel del servidor web. Para Apache, añade al .htaccess de tu directorio admin:

Order Deny,Allow
Deny from all
Allow from 203.0.113.50
Allow from 198.51.100.25

Para Nginx, añade a tu bloque server:

location /tu-nombre-admin/ {
    allow 203.0.113.50;
    allow 198.51.100.25;
    deny all;
}

Esto es extremadamente efectivo porque incluso si un atacante descubre tu URL admin, no puede acceder a la página de inicio de sesión desde una dirección IP no autorizada.

Autenticación de Dos Factores (2FA)

PrestaShop 8.x no incluye 2FA integrado, pero varios módulos proporcionan esta funcionalidad. La autenticación de dos factores requiere un segundo paso de verificación (típicamente un código de una aplicación móvil como Google Authenticator) además de la contraseña. Esto hace que los ataques de fuerza bruta sean esencialmente imposibles incluso si el atacante conoce tanto la URL admin como la contraseña.

Certificado SSL/TLS

Siempre accede a tu panel admin a través de HTTPS. Esto cifra las credenciales de inicio de sesión en tránsito, previniendo ataques man-in-the-middle. La mayoría de los proveedores de hosting ofrecen certificados SSL gratuitos a través de Let's Encrypt. El back office de PrestaShop debería estar configurado para forzar SSL en Parámetros de la Tienda > General > Habilitar SSL y Habilitar SSL en todas las páginas.

Limitación de Intentos de Inicio de Sesión

PrestaShop incluye una protección básica contra fuerza bruta que bloquea direcciones IP después de un cierto número de intentos de inicio de sesión fallidos. Asegúrate de que esté habilitada en tu configuración de seguridad. También puedes implementar limitación de velocidad a nivel del servidor web usando módulos como mod_evasive para Apache o limit_req para Nginx.

Rotación Regular de Contraseñas

Asegúrate de que todas las cuentas admin usen contraseñas seguras y únicas. Una buena contraseña tiene al menos 16 caracteres e incluye una mezcla de letras, números y símbolos. Usa un administrador de contraseñas para generar y almacenar estas contraseñas. Rota las contraseñas periódicamente, especialmente cuando un empleado deja la empresa o cuando ocurre un incidente de seguridad.

Auditoría de Cuentas Admin

Revisa regularmente la lista de cuentas admin en Parámetros Avanzados > Equipo > Empleados. Elimina o desactiva las cuentas de empleados que ya no necesitan acceso. Cada persona debería tener su propia cuenta en lugar de compartir credenciales, lo que hace posible rastrear quién hizo qué cambios.

Qué Hacer Si Pierdes el Acceso

Si renombras el directorio admin y no puedes acceder al back office, no entres en pánico. Conéctate a tu servidor vía FTP o SSH y renombra el directorio de vuelta a su nombre original o verifica el archivo parameters.php para asegurarte de que el nombre del directorio coincida. Si has perdido la pista tanto del nombre del directorio como de la configuración, mira el listado real de directorios en tu servidor — el directorio admin es el que contiene archivos como ajax-tab.php, init.php y un subdirectorio themes/ con el tema del back office.

También puedes encontrar el nombre del directorio admin en la base de datos:

SELECT value FROM ps_configuration WHERE name = 'PS_ADMIN_DIR';

Sin embargo, ten en cuenta que no todas las versiones de PrestaShop almacenan este valor en la tabla de configuración. El archivo parameters.php es la fuente autorizada.

Automatizar los Cambios de URL Admin con un Script

Si gestionas múltiples instalaciones de PrestaShop, puedes crear un sencillo script shell para automatizar el proceso de renombrado:

#!/bin/bash
OLD_NAME="$1"
NEW_NAME="$2"
PS_ROOT="/var/www/html/prestashop"

if [ -z "$OLD_NAME" ] || [ -z "$NEW_NAME" ]; then
    echo "Uso: $0 antiguo-nombre-admin nuevo-nombre-admin"
    exit 1
fi

mv "$PS_ROOT/$OLD_NAME" "$PS_ROOT/$NEW_NAME"
sed -i "s/$OLD_NAME/$NEW_NAME/g" "$PS_ROOT/app/config/parameters.php"
rm -rf "$PS_ROOT/var/cache/prod/*" "$PS_ROOT/var/cache/dev/*"
echo "Directorio admin renombrado de $OLD_NAME a $NEW_NAME"
echo "Por favor verifica el acceso en: tudominio.com/$NEW_NAME/"

Guarda esto como rename-admin.sh, hazlo ejecutable con chmod +x rename-admin.sh y ejecútalo con los nombres antiguo y nuevo del directorio como argumentos. Siempre prueba la nueva URL inmediatamente después de ejecutar la herramienta.

Siguiendo estos pasos y combinando el cambio de URL admin con medidas de seguridad adicionales, reduces significativamente la superficie de ataque del back office de tu tienda PrestaShop.

Leer respuesta completa

La transición del motor de plantillas en PrestaShop

PrestaShop está pasando por uno de los cambios arquitectónicos más significativos de su historia reciente — la migración de Smarty a Twig como su motor de plantillas principal. Esta transición, que comenzó con PrestaShop 1.7 y alcanzó un hito importante con PrestaShop 9.0 (lanzado en junio de 2025), afecta a cada desarrollador, diseñador de temas y creador de módulos que trabaja con la plataforma.

Entender este cambio es esencial ya sea que mantengas una tienda existente, planees una actualización o desarrolles nuevos módulos y temas. Esta guía cubre qué ha cambiado, qué está cambiando todavía y cómo preparar tus proyectos PrestaShop para la era Twig.

Qué son Smarty y Twig

Smarty - El motor legacy

Smarty es un motor de plantillas PHP que ha impulsado PrestaShop desde sus inicios. Separa la lógica de negocio PHP de la presentación HTML.

Características principales de Smarty -

Los archivos de plantilla usan la extensión .tpl
Las variables se acceden con llaves y signo de dólar - {$variable}
Los modificadores usan sintaxis pipe - {$variable|escape:'html'}
Los bloques usan etiquetas emparejadas - {block name='content'}{/block}
Herencia de plantillas mediante {extends file='parent.tpl'}

Twig - El motor moderno

Twig es el motor de plantillas construido por SensioLabs, la misma empresa detrás del framework Symfony. Dado que PrestaShop ha adoptado progresivamente componentes de Symfony, moverse a Twig es una alineación natural.

Características principales de Twig -

Los archivos de plantilla usan la extensión .html.twig
Las variables usan dobles llaves - {{ variable }}
Los filtros usan sintaxis pipe - {{ variable|escape('html') }}
Los bloques usan etiquetas emparejadas - {% block content %}{% endblock %}
Herencia de plantillas mediante {% extends 'parent.html.twig' %}

Comparación de sintaxis - Lado a lado

Mostrar variables

Función	Smarty	Twig
Variable simple	`{$product.name}`	`{{ product.name }}`
Acceso a array	`{$products[0].name}`	`{{ products[0].name }}`
Método de objeto	`{$product->getName()}`	`{{ product.getName() }}`
Valor por defecto	`{$var\|default:'N/A'}`	`{{ var\|default('N/A') }}`

Estructuras de control

<!-- Smarty: if/else -->
{if $product.active}
  <span class="badge badge-success">Activo</span>
{elseif $product.pending}
  <span class="badge badge-warning">Pendiente</span>
{else}
  <span class="badge badge-danger">Inactivo</span>
{/if}

<!-- Twig: if/else -->
{% if product.active %}
  <span class="badge badge-success">Activo</span>
{% elseif product.pending %}
  <span class="badge badge-warning">Pendiente</span>
{% else %}
  <span class="badge badge-danger">Inactivo</span>
{% endif %}

Bucles

<!-- Smarty: bucle foreach -->
{foreach $products as $product}
  <div class="product">
    <h3>{$product.name}</h3>
    <p>{$product.price|number_format:2:',':'.'}</p>
  </div>
{foreachelse}
  <p>No se encontraron productos.</p>
{/foreach}

<!-- Twig: bucle for -->
{% for product in products %}
  <div class="product">
    <h3>{{ product.name }}</h3>
    <p>{{ product.price|number_format(2, ',', '.') }}</p>
  </div>
{% else %}
  <p>No se encontraron productos.</p>
{% endfor %}

Qué ha cambiado ya - La cronología

PrestaShop 1.7 (2016)

Comenzó la migración. El back office empezó a adoptar controladores Symfony con plantillas Twig. El front office permaneció completamente basado en Smarty.

PrestaShop 8.x (2022-2024)

Más páginas del back office fueron migradas a Symfony y Twig.

PrestaShop 9.0 (junio 2025)

Hito importante. El back office está ahora completamente migrado a controladores Symfony y plantillas Twig. Sin embargo, Smarty sigue presente porque -

El front office (temas) aún usa principalmente Smarty
Muchos módulos de terceros aún usan plantillas Smarty
Las páginas admin de módulos con AdminControllers legacy aún dependen de Smarty

Impacto en los propietarios de tiendas

Si usas PrestaShop 1.7 o 8.x

Nada cambia inmediatamente. Tus temas y módulos actuales seguirán funcionando. Planifica la eventual actualización a PrestaShop 9.0.

Si estás actualizando a PrestaShop 9.0

El impacto más significativo es en los módulos que modifican páginas del back office. Verifica la compatibilidad con los desarrolladores de módulos antes de actualizar.

Impacto en los desarrolladores de módulos

Para compatibilidad con PrestaShop 8.x (enfoque legacy) -

class AdminMyModuleController extends ModuleAdminController
{
    public function renderList()
    {
        $this->context->smarty->assign([
            'my_data' => $this->getMyData(),
        ]);
        return $this->display(__FILE__, 'views/templates/admin/list.tpl');
    }
}

Para PrestaShop 9.0+ (enfoque moderno) -

class MyModuleAdminController extends FrameworkBundleAdminController
{
    public function listAction(): Response
    {
        return $this->render('@Modules/mymodule/views/templates/admin/list.html.twig', [
            'my_data' => $this->getMyData(),
        ]);
    }
}

Soportar múltiples versiones de PrestaShop

if (version_compare(_PS_VERSION_, '9.0.0', '>=')) {
    return $this->render('@Modules/mymodule/admin/config.html.twig', $params);
} else {
    $this->context->smarty->assign($params);
    return $this->display($this->file, 'views/templates/admin/config.tpl');
}

Ventajas de Twig sobre Smarty

Mejor seguridad

Twig escapa automáticamente la salida por defecto, reduciendo significativamente los riesgos de XSS.

<!-- Twig: escapado automáticamente por defecto -->
{{ user_input }}  <!-- Entidades HTML escapadas automáticamente -->
{{ trusted_html|raw }}  <!-- Explícitamente marcado como seguro -->

<!-- Smarty: escapado manual necesario -->
{$user_input|escape:'html'}  <!-- Debes recordar escapar -->
{$user_input}  <!-- PELIGROSO: sin escapado -->

Integración con Symfony

Twig se integra nativamente con el enrutamiento, renderizado de formularios, sistema de traducción y componentes de seguridad de Symfony.

Mejores mensajes de error

Twig proporciona mensajes de error claros con números de línea exactos.

Patrones de migración comunes

Traducir cadenas

<!-- Smarty -->
{l s='Añadir al carrito' mod='mymodule'}

<!-- Twig -->
{{ 'Añadir al carrito'|trans({}, 'Modules.Mymodule.Shop') }}

Renderizado de hooks

<!-- Smarty -->
{hook h='displayProductButtons'}

<!-- Twig -->
{{ renderhook('displayProductButtons') }}

Sobrescrituras de plantillas del back office en PrestaShop 9

modules/mymodule/views/PrestaShop/Admin/Product/CatalogPage/catalog.html.twig

{% extends '@PrestaShopCore/Admin/Product/CatalogPage/catalog.html.twig' %}

{% block product_catalog_tools %}
  {{ parent() }}
  <div class="my-custom-toolbar">
    <!-- Contenido adicional de la barra de herramientas -->
  </div>
{% endblock %}

Consejos prácticos para propietarios de tiendas

No entres en pánico

La migración es gradual. Smarty no será eliminado de la noche a la mañana.

Verifica la compatibilidad de módulos antes de actualizar

Antes de actualizar a PrestaShop 9.0, verifica que cada módulo sea compatible.

Considera ayuda profesional para tiendas complejas

Con personalizaciones extensas, contrata un desarrollador PrestaShop experimentado en Smarty y Twig.

Prueba todo en un entorno de staging

Nunca actualices tu tienda en producción directamente.

Leer respuesta completa

Por qué la migración de servidor requiere planificación

Mover una tienda PrestaShop a un nuevo servidor es una de las operaciones más críticas. Con una planificación adecuada, puedes reducir el tiempo de inactividad a minutos — o incluso lograr una transición sin interrupciones.

Lista de verificación pre-migración

Verificar requisitos del nuevo servidor
Documentar la configuración actual
Listar todos los dominios y subdominios
Identificar archivos personalizados
Planificar el certificado SSL

Fase 1 - Preparar el nuevo servidor

sudo apt update
sudo apt install apache2 mysql-server php8.1 php8.1-mysql \
  php8.1-gd php8.1-curl php8.1-intl php8.1-mbstring \
  php8.1-zip php8.1-xml php8.1-bcmath
sudo a2enmod rewrite ssl headers expires

Configurar PHP

memory_limit = 512M
max_execution_time = 300
post_max_size = 64M
upload_max_filesize = 64M

Crear la base de datos

CREATE DATABASE prestashop CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;
CREATE USER 'ps_user'@'localhost' IDENTIFIED BY 'contrasena_fuerte';
GRANT ALL PRIVILEGES ON prestashop.* TO 'ps_user'@'localhost';

Fase 2 - Transferir archivos

rsync -avz --progress -e ssh \
  /var/www/html/prestashop/ \
  user@nuevo-servidor:/var/www/html/prestashop/

find /var/www/html/prestashop -type d -exec chmod 755 {} \;
find /var/www/html/prestashop -type f -exec chmod 644 {} \;
chown -R www-data:www-data /var/www/html/prestashop

Fase 3 - Transferir la base de datos

mysqldump -u root -p --single-transaction --routines --triggers \
  prestashop > /tmp/prestashop_db.sql

scp /tmp/prestashop_db.sql user@nuevo-servidor:/tmp/
mysql -u ps_user -p prestashop < /tmp/prestashop_db.sql

Fase 4 - Actualizar configuración

Edita app/config/parameters.php con las nuevas credenciales. NO cambies las URLs de la tienda.

Fase 5 - Probar en el nuevo servidor

Modifica tu archivo hosts local para apuntar al nuevo servidor y prueba todo el sitio a fondo.

Fase 6 - El cambio

Bajar el TTL DNS 48 horas antes
Poner la tienda vieja en mantenimiento
Sincronización final de la base de datos
Sincronización final de archivos
Cambiar los registros DNS
Sacar la nueva tienda del mantenimiento

Fase 7 - Verificación post-migración

Limpiar todas las cachés
Regenerar el .htaccess
Verificar SSL
Probar envío de emails
Verificar tareas cron
Mantener ambos servidores 48-72 horas

Trampas comunes de migración

Rutas hardcodeadas en archivos de módulos
Configuración de email
URLs de imágenes
Contenido mixto después de SSL

Leer respuesta completa

Por qué entender la base de datos importa

PrestaShop almacena todo — productos, pedidos, clientes, configuraciones, traducciones, imágenes, precios — en una base de datos MySQL. Entender la estructura de la base de datos te da superpoderes para diagnosticar problemas, realizar operaciones masivas y recuperarte de errores.

Tablas de productos

ps_product

La tabla principal de productos con datos fundamentales -

Columna	Propósito
id_product	Identificador único del producto
price	Precio base (sin impuestos)
reference	Referencia/SKU del producto
active	Habilitado (1) o deshabilitado (0)

ps_product_lang

Datos del producto específicos por idioma - nombre, descripción, meta título, URL.

ps_stock_available

La tabla real de seguimiento de inventario.

SELECT * FROM ps_stock_available 
WHERE id_product = 42 AND id_product_attribute = 0;

Tablas de pedidos

ps_orders

La tabla comercial más importante. Cada fila es un pedido completado.

ps_order_detail

Las líneas individuales dentro de un pedido con producto, cantidad y precio.

SELECT o.reference, o.date_add, o.total_paid_tax_incl,
  od.product_name, od.product_quantity, od.unit_price_tax_incl
FROM ps_orders o
JOIN ps_order_detail od ON o.id_order = od.id_order
WHERE o.id_order = 12345;

Tablas de clientes

ps_customer

Cuentas de clientes con email, contraseña hasheada, nombre, estado de newsletter.

SELECT c.id_customer, c.email, c.firstname, c.date_add
FROM ps_customer c
LEFT JOIN ps_orders o ON c.id_customer = o.id_customer
WHERE o.id_order IS NULL AND c.active = 1;

Tablas del carrito

ps_cart y ps_cart_product

Carritos y sus productos. Los carritos abandonados permanecen aquí.

Tablas de configuración

ps_configuration

Almacén clave-valor para todas las configuraciones.

SELECT name, value FROM ps_configuration 
WHERE name IN ('PS_SHOP_DOMAIN', 'PS_SSL_ENABLED', 'PS_SHOP_ENABLE');

Tablas de módulos y hooks

ps_module, ps_hook, ps_hook_module

Módulos, hooks y sus asociaciones.

Operaciones comunes

-- Aumento de precios del 10%
UPDATE ps_product SET price = price * 1.10;

-- Desactivar productos agotados
UPDATE ps_product p
JOIN ps_stock_available sa ON p.id_product = sa.id_product 
SET p.active = 0
WHERE sa.quantity <= 0 AND sa.id_product_attribute = 0;

Reglas de seguridad de la base de datos

Siempre respaldar antes de modificar
Nunca modificar ps_shop_url directamente
Probar consultas con SELECT antes de UPDATE o DELETE

Leer respuesta completa

Qué son los hooks en PrestaShop

Los hooks son el mecanismo de extensión de PrestaShop — los puntos en el código donde los módulos pueden engancharse para agregar funcionalidad, modificar comportamiento o inyectar contenido en las páginas.

Dos tipos de hooks

Hooks de visualización

Los hooks de visualización (con prefijo display) inyectan contenido HTML en la página. Ejemplos -

displayHeader — dentro de la sección <head>
displayHome — área de contenido de la página principal
displayFooter — área del pie de página
displayProductAdditionalInfo — info adicional del producto

Hooks de acción

Los hooks de acción (con prefijo action) ejecutan lógica sin devolver HTML. Ejemplos -

actionCartSave — cuando un carrito se guarda
actionOrderStatusUpdate — cuando el estado del pedido cambia
actionValidateOrder — cuando un pedido se valida

Cómo funciona el orden de ejecución

PrestaShop consulta la tabla ps_hook_module para encontrar los módulos registrados en un hook. Los módulos se ejecutan en el orden de la columna position.

SELECT hm.position, m.name AS module_name, h.name AS hook_name
FROM ps_hook_module hm
JOIN ps_module m ON hm.id_module = m.id_module
JOIN ps_hook h ON hm.id_hook = h.id_hook
WHERE h.name = 'displayHeader'
ORDER BY hm.position ASC;

Registrar hooks en tu módulo

public function install()
{
    return parent::install()
        && $this->registerHook('displayHeader')
        && $this->registerHook('displayProductAdditionalInfo')
        && $this->registerHook('actionCartSave');
}

public function hookDisplayHeader($params)
{
    $this->context->controller->addCSS($this->_path . 'views/css/style.css');
}

public function hookActionCartSave($params)
{
    $cart = $params['cart'];
    $this->logCartActivity($cart);
}

Gestionar posiciones de hooks en el Back Office

Navega a Diseño > Posiciones para ver todos los hooks y sus módulos asociados. Puedes reordenar con arrastrar y soltar o trasplantar módulos.

Problemas comunes de ejecución de hooks

Conflictos entre módulos

Cuando dos módulos en el mismo hook producen contenido duplicado, reordénalos o desengáncha el módulo problemático.

Impacto en el rendimiento

SELECT h.name, COUNT(*) AS module_count
FROM ps_hook_module hm
JOIN ps_hook h ON hm.id_hook = h.id_hook
GROUP BY h.name
ORDER BY module_count DESC
LIMIT 20;

Hooks importantes para propietarios de tiendas

Checkout - displayPayment, paymentOptions, actionValidateOrder
SEO - displayHeader, filterHtmlContent
Visualización de producto - displayProductAdditionalInfo, displayAfterProductThumbs

Leer respuesta completa

RGPD y comercio electronico: lo que los propietarios de tiendas deben entender

El Reglamento General de Proteccion de Datos (RGPD) entro en vigor en mayo de 2018 y cambio fundamentalmente la forma en que las empresas de comercio electronico manejan los datos personales. Si tu tienda PrestaShop atiende a clientes en el Espacio Economico Europeo, estas sujeto al RGPD independientemente de donde se encuentre fisicamente tu negocio. El reglamento otorga a los individuos derechos especificos sobre sus datos personales, y tu tienda debe tener la capacidad tecnica y organizativa para cumplir con esos derechos.

Para los propietarios de tiendas PrestaShop, los aspectos operativamente mas exigentes del RGPD son las Solicitudes de Acceso del Interesado (SAR) y las solicitudes de supresion. Una SAR es cuando un cliente te pide que proporciones una copia de todos los datos personales que tienes sobre el. Una solicitud de supresion, tambien conocida como el derecho al olvido, es cuando un cliente te pide que elimines sus datos personales. Ambas deben gestionarse dentro de plazos estrictos, y el incumplimiento puede resultar en multas significativas.

Este articulo cubre la parte practica: que datos almacena PrestaShop, como exportarlos, como eliminarlos o anonimizarlos, que debes retener por razones legales y como construir un proceso confiable alrededor de estas solicitudes.

Que datos personales almacena PrestaShop

Antes de poder responder a cualquier solicitud de datos del interesado, necesitas saber exactamente donde residen los datos personales en tu instalacion de PrestaShop. Los datos personales son cualquier informacion que pueda identificar a una persona fisica, directa o indirectamente. En una tienda PrestaShop tipica, los datos personales estan distribuidos en muchas tablas de la base de datos y potencialmente en modulos de terceros.

Tablas principales de PrestaShop que contienen datos personales

La tabla ps_customer almacena el registro principal del cliente: nombre, direccion de correo electronico, fecha de nacimiento, fecha de creacion, direccion IP de registro y opciones de consentimiento para marketing. La tabla ps_address almacena las direcciones de entrega y facturacion, incluyendo nombre completo, direccion postal, ciudad, codigo postal, pais y numeros de telefono. Un solo cliente puede tener multiples direcciones.

La tabla ps_orders contiene el historial de pedidos vinculado a los clientes, incluyendo metodos de pago y detalles de entrega. La tabla ps_order_detail contiene las lineas de detalle de cada pedido. La tabla ps_cart almacena los datos del carrito de compras, que incluyen las selecciones de productos y pueden vincularse a un cliente. Las tablas ps_message y ps_customer_message contienen los mensajes intercambiados entre el cliente y tu tienda a traves del formulario de contacto o el sistema de mensajeria de pedidos.

Las tablas ps_connections y ps_connections_source rastrean las conexiones de visitantes, incluyendo direcciones IP y URLs de referencia. La tabla ps_guest almacena datos de visitantes invitados vinculados a cookies. La tabla ps_customer_session (en versiones mas recientes) registra las sesiones de inicio de sesion.

Datos en modulos de terceros

Cualquier modulo que recopile o procese datos de clientes crea ubicaciones de almacenamiento de datos adicionales. Los modulos de boletin informativo almacenan direcciones de correo electronico. Los modulos de resenas almacenan nombres de clientes y texto de resenas. Los modulos de lista de deseos vinculan preferencias de productos a cuentas de clientes. Los modulos de fidelidad y recompensas rastrean el comportamiento de compra. Los modulos de analitica pueden almacenar patrones de navegacion. Cada uno de estos modulos debe considerarse al responder a una solicitud de datos del interesado.

Por esta razon, mantener un inventario de procesamiento de datos, un documento que enumere cada lugar donde se almacenan datos personales, no es solo una buena practica sino un requisito del RGPD. Sin el, no puedes garantizar la completitud al responder a una SAR.

El modulo RGPD de PrestaShop

PrestaShop proporciona un modulo oficial de cumplimiento RGPD (psgdpr) que maneja los requisitos basicos de las solicitudes de datos del interesado. Este modulo esta disponible para PrestaShop 1.7 y versiones posteriores y puede instalarse desde el catalogo de modulos en tu back office.

Que hace el modulo

El modulo RGPD agrega un marco de gestion de consentimiento a tu tienda, permitiendote rastrear cuando y donde los clientes dieron su consentimiento para el procesamiento de datos. Agrega casillas de verificacion de consentimiento a los formularios de registro, formularios de contacto y formularios de suscripcion al boletin informativo. Cada accion de consentimiento se registra con una marca de tiempo.

Para las solicitudes de datos del interesado, el modulo proporciona dos funciones clave. La funcion de exportacion de datos genera un archivo PDF o CSV que contiene todos los datos personales asociados con la direccion de correo electronico de un cliente. La funcion de supresion de datos anonimiza o elimina los datos personales de un cliente determinado.

El modulo tambien agrega una seccion a la pagina de cuenta del cliente en el front office donde los clientes pueden ver y descargar sus propios datos y enviar solicitudes de supresion directamente.

Configuracion del modulo

Despues de la instalacion, navega a la pagina de configuracion del modulo. Encontraras secciones para gestionar las casillas de verificacion de consentimiento (que formularios requieren consentimiento y que texto mostrar), configurar que modulos son compatibles con el RGPD (el modulo puede consultar modulos compatibles para obtener sus datos almacenados) y configurar las paginas de portabilidad de datos y supresion orientadas al cliente.

El modulo se conecta con otros modulos compatibles con el RGPD a traves de una interfaz estandarizada. Cuando un modulo implementa los hooks del RGPD, el modulo psgdpr puede incluir automaticamente los datos de ese modulo en las operaciones de exportacion y supresion. Verifica cuales de tus modulos instalados soportan esta integracion, porque los modulos que no la soportan deberan manejarse manualmente.

Gestion de Solicitudes de Acceso del Interesado (SAR)

Cuando un cliente solicita acceso a sus datos personales, tienes un mes calendario para responder. Este plazo comienza desde el dia en que recibes la solicitud e incluye el tiempo necesario para verificar la identidad del solicitante. Si la solicitud es compleja o recibes un alto volumen de solicitudes, puedes extender esto por dos meses adicionales, pero debes informar al cliente de la extension dentro del primer mes.

Verificacion de identidad

Antes de liberar cualquier dato personal, debes verificar que la persona que realiza la solicitud es quien dice ser. Si la solicitud proviene de una cuenta de cliente logueada, eso es generalmente suficiente como verificacion. Si la solicitud llega por correo electronico, debes pedir al solicitante que confirme detalles que solo el titular de la cuenta conoceria, como numeros de pedido recientes o la direccion registrada. No pidas documentos de verificacion excesivos, ya que esto en si mismo podria ser una violacion del RGPD (principio de minimizacion de datos), pero realiza la verificacion suficiente para prevenir la divulgacion no autorizada de datos.

Uso del modulo RGPD para exportacion

En el back office de PrestaShop, ve a la configuracion del modulo RGPD y busca la seccion de gestion de datos personales. Ingresa la direccion de correo electronico del cliente y usa la funcion de exportacion. El modulo generara un archivo que contiene datos de las tablas principales de PrestaShop y de cualquier modulo compatible con el RGPD.

Revisa los datos exportados antes de enviarlos al cliente. La exportacion debe incluir: detalles de la cuenta del cliente (nombre, correo electronico, fecha de nacimiento, fecha de registro), todas las direcciones registradas, historial de pedidos con detalles de pedidos, historial del carrito, mensajes y registros de comunicacion, registros de consentimiento y cualquier dato especifico de modulos (suscripciones al boletin informativo, resenas, listas de deseos).

Que debe incluir la exportacion

Segun el Articulo 15 del RGPD, la exportacion de datos debe incluir no solo los datos en bruto sino tambien informacion sobre como se procesan los datos. Especificamente, debes proporcionar: las categorias de datos personales que procesas, los propositos del procesamiento, cualquier tercero con el que se hayan compartido los datos (procesadores de pago, transportistas, plataformas de marketing), el periodo de retencion o los criterios para determinarlo, e informacion sobre los derechos del cliente (rectificacion, supresion, restriccion, objecion).

El modulo RGPD maneja la exportacion de datos en bruto, pero la informacion contextual sobre los propositos de procesamiento y el intercambio con terceros tipicamente debe provenir de tu politica de privacidad. Considera incluir un enlace a tu politica de privacidad junto con la exportacion de datos o adjuntar una carta de presentacion que resuma esta informacion.

Exportacion manual para modulos no integrados

Para los modulos que no se integran con el modulo RGPD, necesitas extraer los datos manualmente. Esto tipicamente implica consultar las tablas de la base de datos del modulo directamente. Por ejemplo, un modulo de resenas de productos podria almacenar datos en una tabla como ps_product_comment con el ID del cliente como clave foranea. Necesitarias exportar todas las filas asociadas con el ID del cliente.

Documenta estos pasos manuales en tu procedimiento de manejo de SAR para que no se pasen por alto cuando un miembro diferente del equipo gestione una solicitud.

Derecho a la supresion: anonimizacion vs. eliminacion completa

El derecho a la supresion (Articulo 17) permite a los clientes solicitar que se eliminen sus datos personales. Sin embargo, este derecho no es absoluto. Existen razones legitimas para retener ciertos datos, y comprender estas excepciones es critico para manejar las solicitudes de supresion correctamente.

Cuando debes eliminar

Si un cliente solicita la supresion y ninguna de las exenciones aplica, debes eliminar o anonimizar sus datos personales sin demora indebida (el mismo plazo de un mes que las SAR). Los datos deben eliminarse de todos los sistemas, incluyendo las copias de seguridad si es tecnicamente factible. Tambien debes notificar a cualquier tercero con el que hayas compartido los datos (procesadores de pago, herramientas de marketing) para que puedan eliminar sus copias.

Cuando puedes rechazar la eliminacion

El Articulo 17(3) del RGPD enumera varias exenciones donde puedes rechazar una solicitud de supresion. Las mas relevantes para el comercio electronico son:

Obligacion legal: La legislacion fiscal en la mayoria de los paises de la UE requiere que retengas facturas y registros financieros durante un periodo especifico, tipicamente entre 5 y 10 anos dependiendo de la jurisdiccion. Esto significa que no puedes eliminar datos de pedidos que son necesarios para el cumplimiento fiscal, incluso si el cliente solicita la supresion. Debes retener los datos de la factura (nombre, direccion, detalles del pedido, importes) durante el periodo legalmente requerido.

Reclamaciones legales: Si hay una disputa en curso, una reclamacion de garantia o una posible accion legal relacionada con los pedidos de un cliente, puedes retener los datos necesarios para establecer, ejercer o defender reclamaciones legales.

Obligacion contractual: Si un pedido todavia esta siendo procesado, enviado o esta dentro de un periodo de devolucion/garantia, tienes una razon legitima para retener los datos asociados hasta que la transaccion se complete por completo.

El enfoque de anonimizacion

La solucion practica para la mayoria de las tiendas de comercio electronico es la anonimizacion en lugar de la eliminacion completa. La anonimizacion significa reemplazar los datos personales con marcadores de posicion no identificativos mientras se retienen los registros transaccionales necesarios para la contabilidad y el cumplimiento legal.

Por ejemplo, en lugar de eliminar un registro de pedido por completo, reemplazarias el nombre del cliente con algo como "Cliente Anonimizado" o un hash, reemplazarias el correo electronico con un marcador de posicion como "eliminado@anonimizado.invalid", reemplazarias la direccion con valores genericos ("Direccion Eliminada", "Ciudad Eliminada") y eliminarias los numeros de telefono. El pedido en si, incluyendo los detalles del producto, cantidades, precios e importes de impuestos, permanece intacto para propositos contables, pero ya no puede vincularse a un individuo identificable.

El modulo RGPD de PrestaShop utiliza este enfoque de anonimizacion por defecto. Cuando procesas una solicitud de supresion a traves del modulo, este reemplaza los identificadores personales con valores anonimizados en lugar de eliminar los registros directamente.

Que se anonimiza vs. que se elimina

En una operacion tipica de supresion RGPD en PrestaShop, sucede lo siguiente. La cuenta del cliente se desactiva y los campos personales se anonimizan (el nombre se convierte en anonimo, el correo electronico se convierte en un hash, la fecha de nacimiento se borra). Todas las direcciones asociadas al cliente se anonimizan (nombres, direcciones postales y numeros de telefono reemplazados). Los carritos del cliente se eliminan por completo ya que no tienen requisito de retencion legal. Los mensajes y las comunicaciones del servicio al cliente se anonimizan o eliminan. Las suscripciones al boletin informativo se eliminan. Los registros de invitados y los registros de conexion asociados al cliente se purgan.

Los registros de pedidos se anonimizan pero se retienen: el nombre del cliente y la direccion en el pedido se reemplazan con valores anonimos, pero los detalles del pedido (productos, precios, impuestos) permanecen para el cumplimiento contable. Las facturas generadas a partir de estos pedidos continuan existiendo pero con datos de cliente anonimizados.

Pasos tecnicos para procesar una solicitud de supresion

Paso 1: Verificar identidad y documentar la solicitud

Antes de procesar cualquier supresion, verifica la identidad del solicitante usando los mismos metodos descritos para las SAR. Registra la solicitud con una marca de tiempo, la identidad del solicitante y el metodo de verificacion utilizado. Este registro es en si mismo un requisito de cumplimiento. Necesitas demostrar que procesaste la solicitud y cuando.

Paso 2: Verificar exenciones de retencion

Revisa el historial de pedidos del cliente. Si tiene pedidos dentro de tu periodo de retencion legal (verifica los requisitos de tu legislacion fiscal local), esos registros de pedidos deben retenerse en forma anonimizada. Si hay pedidos abiertos, disputas en curso o reclamaciones de garantia activas, la supresion de los datos relacionados debe posponerse hasta que estos se resuelvan.

Paso 3: Procesar la supresion

Utiliza la funcion de supresion del modulo RGPD para los datos principales. Ingresa la direccion de correo electronico del cliente en el panel de administracion del modulo y ejecuta la supresion. El modulo anonimizara los datos en las tablas principales y en cualquier modulo integrado con el RGPD.

Para los modulos que no estan integrados con el modulo RGPD, necesitaras manejar la supresion manualmente. Esto puede implicar ejecutar consultas SQL para anonimizar o eliminar datos en tablas especificas del modulo, o usar la propia interfaz de administracion del modulo para eliminar los datos del cliente.

Paso 4: Gestionar procesadores de datos de terceros

Identifica todos los servicios de terceros que hayan recibido los datos del cliente. Esto tipicamente incluye tu procesador de pagos (Stripe, PayPal, Mollie), los transportistas que recibieron direcciones de entrega, las plataformas de marketing por correo electronico (Mailchimp, Sendinblue) y cualquier servicio de analitica que procese datos personales. Contacta a cada procesador y solicita la supresion de los datos del cliente. La mayoria de los procesadores principales tienen sus propios procesos de eliminacion de datos del RGPD. Documenta cada comunicacion.

Paso 5: Confirmar la finalizacion

Envia una confirmacion al cliente (a su direccion de correo electronico, antes de anonimizarla, o a traves del canal de comunicacion que usaron para la solicitud) indicando que sus datos han sido suprimidos. Incluye la fecha de supresion y una nota sobre cualquier dato que se haya retenido bajo exenciones legales, explicando la base legal para la retencion.

Requisitos de retencion de datos de pedidos

La interseccion entre el derecho a la supresion del RGPD y los requisitos de retencion de la legislacion fiscal es una de las areas mas comunmente malinterpretadas. Aqui hay un desglose practico por las principales jurisdicciones de la UE.

Alemania: Los registros comerciales y fiscales deben retenerse durante 10 anos (Seccion 147 AO, Seccion 257 HGB). Esto incluye facturas, registros contables y correspondencia relacionada.

Francia: Los documentos comerciales deben retenerse durante 10 anos (Articulo L123-22 Code de Commerce). Los documentos relacionados con impuestos durante 6 anos despues de la ultima operacion fiscalmente relevante.

Paises Bajos: Los registros de administracion fiscal deben retenerse durante 7 anos (Articulo 52 AWR).

Italia: El codigo civil requiere 10 anos para los registros comerciales (Articulo 2220 CC). Los documentos fiscales durante un minimo de 5 anos.

Espana: Los registros comerciales durante 6 anos (Articulo 30 Codigo de Comercio). Los documentos fiscales durante 4 anos.

En todos los casos, lo que debe retenerse es el registro financiero y transaccional, no el perfil de marketing. Debes conservar los datos de la factura (que se compro, por cuanto, impuestos pagados) pero puedes anonimizar los identificadores personales una vez que la relacion contractual haya concluido completamente (todas las entregas realizadas, periodos de devolucion expirados, pagos liquidados).

Un enfoque practico es implementar un proceso de dos etapas: anonimizacion inmediata de los datos no esenciales (preferencias de marketing, historial de navegacion, suscripciones al boletin informativo, datos del carrito) combinada con la anonimizacion programada de los datos personales relacionados con pedidos una vez que expire el periodo de retencion legal.

Construir un registro de auditoria

El RGPD requiere que puedas demostrar el cumplimiento, no solo alcanzarlo. Esto significa mantener registros de cada solicitud de datos del interesado recibida y como fue gestionada.

Que registrar

Para cada solicitud, registra lo siguiente: la fecha en que se recibio la solicitud, el tipo de solicitud (acceso, supresion, rectificacion, etc.), la identidad del solicitante y como se verifico su identidad, la fecha en que se proceso la solicitud, que acciones se tomaron (datos exportados, datos anonimizados, etc.), cualquier exencion aplicada y la base legal para ellas, cualquier tercero notificado y la fecha en que se informo al solicitante del resultado.

Donde almacenar el registro

El registro de solicitudes debe almacenarse por separado de los datos del cliente. Si los datos del cliente se suprimen, necesitas retener la entrada del registro que muestre que procesaste la solicitud de supresion. Sin embargo, el registro en si debe contener datos personales minimos. Registra la solicitud usando un numero de referencia en lugar de almacenar el nombre completo y el correo electronico del cliente en el registro. Una referencia como "RGPD-2026-0042" vinculada a un documento de solicitud original almacenado de forma segura es preferible a repetir datos personales en multiples sistemas.

El modulo RGPD de PrestaShop mantiene su propio registro de operaciones de datos, al que puedes acceder en la seccion de administracion del modulo. Complementa esto con tus propios registros si tu proceso involucra pasos manuales o comunicaciones con terceros.

Plazos de respuesta y flujo de trabajo practico

La regla de un mes

Tienes un mes calendario desde la recepcion de la solicitud para responder. Esto significa que si recibes una solicitud el 15 de marzo, debes responder antes del 15 de abril. Si una solicitud llega el 31 de enero, la fecha limite es el 28 de febrero (o 29 en ano bisiesto). Si la fecha limite cae en un fin de semana o dia festivo, se extiende al siguiente dia habil.

Extension para solicitudes complejas

Si la solicitud es particularmente compleja (por ejemplo, el cliente tiene un extenso historial de pedidos a lo largo de muchos anos) o si recibes un alto volumen de solicitudes simultaneamente, puedes extender el plazo en dos meses adicionales. Pero debes informar al solicitante dentro del primer mes de que estas tomando la extension y explicar por que.

Construir un flujo de trabajo interno

Para tiendas que reciben solicitudes RGPD regulares, establece un flujo de trabajo estandarizado. Designa a una persona o equipo responsable de gestionar las solicitudes. Crea una bandeja de entrada compartida o un sistema de tickets donde se registren las solicitudes. Desarrolla listas de verificacion paso a paso para cada tipo de solicitud. Establece plazos internos que sean mas cortos que el plazo legal para permitir la revision y el control de calidad. Realiza capacitaciones periodicas para que el personal de atencion al cliente reconozca las solicitudes de datos del interesado (los clientes no siempre usan terminologia legal).

Un cliente podria decir "quiero que se elimine mi cuenta" o "envienme todo lo que saben sobre mi" sin mencionar nunca el RGPD o los derechos de los interesados. Tu equipo debe reconocer estas como solicitudes formales y canalizarlas adecuadamente.

Autoservicio en el front office

El modulo RGPD de PrestaShop agrega una seccion al area de cuenta del cliente donde los clientes logueados pueden ver sus datos almacenados e iniciar solicitudes por si mismos. Este enfoque de autoservicio tiene varias ventajas.

Reduce la carga de trabajo manual de tu equipo porque los clientes pueden exportar sus propios datos sin involucrar a tu personal. Proporciona una respuesta inmediata para las solicitudes de acceso a datos ya que la exportacion se genera en el momento. Y crea un rastro documentado de la solicitud y su cumplimiento.

Sin embargo, las solicitudes de supresion enviadas a traves del portal de autoservicio deben revisarse antes de procesarse. Una supresion automatica inmediata podria causar problemas si el cliente tiene pedidos abiertos o si hay requisitos de retencion que necesitan evaluarse. Configura el modulo para tratar las solicitudes de supresion de autoservicio como solicitudes que requieren tu revision y aprobacion en lugar de ejecucion automatica.

Gestion de casos especiales

Compras como invitado

Los clientes que realizaron compras como invitados (sin crear una cuenta) aun pueden presentar solicitudes de datos del interesado. Sus datos estan vinculados a su direccion de correo electronico en lugar de un ID de cuenta de cliente. El modulo RGPD puede buscar por direccion de correo electronico para encontrar datos de pedidos de invitados. Se aplican los mismos procedimientos de exportacion y anonimizacion.

Clientes con multiples cuentas

Algunos clientes crean multiples cuentas usando diferentes direcciones de correo electronico. Al procesar una solicitud, verifica si el cliente tiene cuentas adicionales. El cliente deberia poder indicarte que direcciones de correo electronico ha utilizado. Procesa cada cuenta por separado a menos que puedas verificar que todas las cuentas pertenecen a la misma persona.

Datos en copias de seguridad

El RGPD reconoce que eliminar datos de las copias de seguridad puede no ser siempre tecnicamente factible. Si tus copias de seguridad de la base de datos contienen datos personales que han sido suprimidos del sistema en vivo, documenta esto en tus registros. Si alguna vez se restaura una copia de seguridad, debes reprocesar cualquier solicitud de supresion que se haya cumplido despues de que se realizo la copia de seguridad. Mantiene tu registro de solicitudes RGPD separado de la base de datos para que sobreviva a una restauracion de copia de seguridad.

Empleados que acceden a datos de clientes

El RGPD requiere que los datos personales sean accesibles solo para aquellos que los necesitan para su funcion. Revisa los permisos de tus empleados en PrestaShop para asegurar que solo el personal autorizado pueda acceder a los datos de clientes, ejecutar exportaciones de datos o procesar solicitudes de supresion. El sistema de perfiles de empleados en PrestaShop te permite restringir el acceso a secciones especificas del back office.

Consecuencias del incumplimiento

La aplicacion del RGPD esta a cargo de las Autoridades de Proteccion de Datos (APD) nacionales. Las multas pueden alcanzar hasta 20 millones de euros o el 4% de la facturacion global anual, lo que sea mayor. En la practica, las multas para las empresas de comercio electronico pequenas y medianas han sido significativamente menores, pero no son insignificantes. Las APD han impuesto multas en el rango de decenas de miles de euros por no responder a las solicitudes de datos del interesado dentro del plazo requerido.

Mas alla de las multas, no gestionar correctamente las solicitudes de datos del interesado dana la confianza del cliente. Los clientes que sienten que sus derechos de privacidad estan siendo ignorados llevaran su negocio a otra parte y pueden presentar quejas ante su APD nacional, lo que desencadena investigaciones que consumen tiempo y recursos independientemente del resultado.

Resumen y lista de verificacion

Gestionar las solicitudes de datos del interesado bajo el RGPD en PrestaShop requiere preparacion, no solo reaccion. Instala y configura el modulo oficial de RGPD. Crea un inventario de procesamiento de datos que mapee cada ubicacion donde se almacenan datos personales, incluyendo modulos de terceros y servicios externos. Establece un flujo de trabajo documentado para recibir, verificar, procesar y responder a las solicitudes. Comprende los requisitos de retencion de datos de tu legislacion local para saber que debe conservarse y durante cuanto tiempo. Implementa la anonimizacion en lugar de la eliminacion completa para los datos con obligaciones de retencion legal. Mantiene un registro de auditoria de cada solicitud y accion tomada. Capacita a tu equipo para reconocer las solicitudes de datos del interesado incluso cuando se expresan de manera informal.

El cumplimiento del RGPD no es una configuracion unica sino un compromiso operativo continuo. Las revisiones periodicas de tus actividades de procesamiento de datos, integraciones de modulos y procedimientos de gestion garantizan que sigas cumpliendo a medida que tu tienda evoluciona y que la orientacion regulatoria se desarrolla.

Leer respuesta completa

Por qué la elección del servidor web importa para PrestaShop

PrestaShop es una aplicación PHP que genera páginas HTML dinámicamente, sirve recursos estáticos como imágenes, archivos CSS y JavaScript, y gestiona peticiones AJAX tanto del front office como del back office. El servidor web se encuentra entre los visitantes y la aplicación PHP, manejando cada petición HTTP individual. Su arquitectura afecta directamente a cuántos visitantes simultáneos puede manejar la tienda, a la velocidad de carga de las páginas y a cuánta memoria del servidor consume cada visitante.

Apache y Nginx son los dos servidores web dominantes para alojar PrestaShop. Apache ha sido la opción predeterminada desde las primeras versiones de PrestaShop, y PrestaShop viene con archivos .htaccess diseñados específicamente para Apache. Nginx ha ganado una adopción masiva durante la última década gracias a su superior manejo de conexiones simultáneas y su menor huella de memoria. Ambos pueden ejecutar PrestaShop de forma efectiva, pero difieren en aspectos que importan para el rendimiento de la tienda, la complejidad de la configuración y la sobrecarga operativa.

Arquitectura: Modelo de procesos vs Bucle de eventos

La diferencia fundamental entre Apache y Nginx radica en cómo manejan las conexiones entrantes. Esta diferencia arquitectónica impulsa cada diferencia de rendimiento entre ambos servidores.

El modelo de procesos/hilos de Apache

Apache tradicionalmente utiliza un modelo basado en procesos a través de su módulo prefork MPM (Multi-Processing Module). En este modelo, Apache genera un pool de procesos trabajadores, y cada proceso maneja una petición a la vez. Cuando llega una petición, se le asigna un proceso. Ese proceso lee la petición, ejecuta el código PHP (si utiliza mod_php), envía la respuesta y solo entonces queda disponible para la siguiente petición.

El worker MPM utiliza hilos en lugar de procesos separados, permitiendo más conexiones simultáneas con menos memoria. El event MPM va más allá utilizando un enfoque basado en eventos para las conexiones keepalive mientras sigue usando hilos para el procesamiento activo de peticiones. Las instalaciones modernas de Apache típicamente usan el event MPM, pero el modelo fundamental sigue implicando dedicar un hilo a cada petición activa.

La implicación práctica es que la concurrencia de Apache está limitada por el número de hilos o procesos trabajadores configurados. Si configuras 150 workers y llegan 151 peticiones simultáneamente, la última espera en una cola. Cada worker consume memoria (típicamente 10-30 MB por proceso con mod_php, menos con PHP-FPM), por lo que el número máximo de workers está limitado por la RAM disponible.

El modelo orientado a eventos de Nginx

Nginx utiliza una arquitectura asíncrona orientada a eventos. Un pequeño número de procesos trabajadores (típicamente uno por núcleo de CPU) maneja miles de conexiones simultáneamente utilizando un bucle de eventos. Cuando llega una petición, Nginx la procesa de manera no bloqueante. Si Nginx necesita esperar por algo (una respuesta de PHP-FPM, una lectura de archivo del disco, una respuesta de un servidor backend), no bloquea el worker. En su lugar, pasa a manejar otras conexiones y regresa cuando la operación esperada se completa.

Esto significa que un proceso trabajador de Nginx manejando 1.000 conexiones simultáneas utiliza aproximadamente la misma memoria que cuando maneja 10 conexiones. La huella de memoria está determinada por el número de procesos trabajadores (un puñado), no por el número de conexiones (potencialmente miles). Por esto Nginx sobresale bajo alta concurrencia y es la opción preferida para sitios de alto tráfico.

.htaccess vs configuración del servidor

Una de las diferencias prácticas más significativas entre Apache y Nginx es cómo se manejan la reescritura de URLs, el control de acceso y otras configuraciones por directorio.

Apache y .htaccess

Apache soporta archivos .htaccess, que son archivos de configuración por directorio que pueden anular la configuración global del servidor. PrestaShop depende en gran medida de .htaccess para la reescritura de URLs amigables, el control de acceso, las cabeceras de caché y las cabeceras de seguridad. Cuando activas las URLs amigables en PrestaShop, genera un archivo .htaccess con reglas mod_rewrite que traducen URLs limpias como /shoes/running-shoe en la URL interna del dispatcher.

La ventaja de .htaccess es la comodidad. No necesitas acceso root para modificar el comportamiento del servidor web, y los cambios tienen efecto inmediato sin reiniciar el servidor. PrestaShop puede escribir su propio archivo .htaccess desde el back office, lo que significa que funcionalidades como URLs amigables, configuración del servidor de medios y ciertos ajustes de seguridad funcionan de forma inmediata.

La desventaja es el rendimiento. Cada petición hace que Apache busque y analice archivos .htaccess en cada directorio desde la raíz del documento hasta el directorio del archivo solicitado. En una petición típica de PrestaShop, Apache podría buscar .htaccess en /, /var, /var/www, /var/www/html y más. Esto añade E/S de disco y tiempo de procesamiento a cada petición. Para un sitio que maneja cientos de peticiones por segundo, esta sobrecarga es medible.

Si tienes acceso root a la configuración de Apache, puedes mover todas las directivas de .htaccess a la configuración del VirtualHost y desactivar el procesamiento de .htaccess con AllowOverride None. Esto elimina la sobrecarga por petición manteniendo la misma funcionalidad. Sin embargo, los cambios entonces requieren un reload de Apache para tener efecto.

Configuración de Nginx

Nginx no soporta archivos .htaccess. Toda la configuración reside en los archivos de configuración de los bloques server, típicamente bajo /etc/nginx/sites-available/ o /etc/nginx/conf.d/. Cada regla de reescritura de URL, directiva de control de acceso y cabecera de caché debe definirse en estos archivos.

Esto significa que cuando configuras PrestaShop en Nginx, debes traducir manualmente las reglas .htaccess de PrestaShop a la sintaxis de configuración de Nginx. Las reglas de reescritura son fundamentalmente diferentes entre ambos servidores. Apache usa RewriteRule con patrones regex y flags como [L,R=301], mientras que Nginx usa bloques location con directivas try_files, rewrite y return.

La ventaja de la configuración centralizada es el rendimiento (sin escaneo de archivos por petición) y la claridad (todas las reglas en un solo lugar). La desventaja es que PrestaShop no puede generar la configuración de Nginx por ti. Debes escribirla y mantenerla tú mismo, y cualquier cambio requiere ejecutar nginx -t para probar la sintaxis y systemctl reload nginx para aplicarlo.

Integración con PHP

Ambos servidores web necesitan ejecutar código PHP para generar las páginas de PrestaShop. El método de integración con PHP afecta al rendimiento, la estabilidad y la gestión de recursos.

Apache con mod_php

El enfoque tradicional es Apache con mod_php, donde PHP se ejecuta como un módulo dentro de cada proceso de Apache. Esto es sencillo de configurar y no tiene sobrecarga de comunicación entre procesos porque PHP se ejecuta en el mismo proceso que maneja la petición HTTP. Sin embargo, cada proceso trabajador de Apache lleva el runtime completo de PHP en memoria, incluso cuando sirve archivos estáticos como imágenes o CSS. Esto desperdicia memoria porque la mayoría de las peticiones a una tienda PrestaShop son para recursos estáticos, no páginas PHP.

Apache o Nginx con PHP-FPM

PHP-FPM (FastCGI Process Manager) ejecuta PHP como un pool de procesos separado. El servidor web se comunica con PHP-FPM a través de un socket Unix o una conexión TCP usando el protocolo FastCGI. Cuando una petición requiere procesamiento PHP, el servidor web la reenvía a PHP-FPM. Cuando el procesamiento PHP se completa, PHP-FPM devuelve el resultado al servidor web, que lo envía al cliente.

Con PHP-FPM, los procesos del servidor web que manejan archivos estáticos no llevan el runtime de PHP, ahorrando una cantidad significativa de memoria. PHP-FPM también ofrece su propia gestión de procesos con funcionalidades como el dimensionamiento dinámico del pool, el slow log (registro cuando una petición tarda más que un umbral) y la capacidad de ejecutar múltiples versiones de PHP simultáneamente para diferentes sitios.

Nginx utiliza exclusivamente PHP-FPM porque su arquitectura orientada a eventos es incompatible con incrustar PHP. Apache puede usar PHP-FPM a través de mod_proxy_fcgi. En implementaciones modernas, PHP-FPM es el enfoque recomendado para ambos servidores.

Configuración de PHP-FPM para PrestaShop

Independientemente del servidor web que elijas, la configuración de PHP-FPM afecta significativamente al rendimiento de PrestaShop. Los ajustes clave incluyen:

pm = dynamic es generalmente el mejor modo del administrador de procesos. Inicia un número base de workers y genera más bajo carga, hasta un máximo configurado. Esto equilibra el uso de memoria y la capacidad de respuesta.

pm.max_children determina el número máximo de procesos PHP. Cada petición de PrestaShop típicamente usa 30-80 MB de memoria, así que divide tu RAM disponible (menos lo que necesitan el servidor web y el sistema operativo) entre 80 para obtener un máximo conservador. Para un servidor con 4 GB de RAM utilizable, 50 procesos hijos es un punto de partida razonable.

pm.max_requests = 500 recicla cada worker después de 500 peticiones, previniendo que se acumulen fugas de memoria. Los módulos de PrestaShop ocasionalmente tienen pequeñas fugas de memoria, y este ajuste previene que se conviertan en un problema.

Servicio de archivos estáticos

Una tienda PrestaShop sirve grandes cantidades de archivos estáticos: imágenes de productos, hojas de estilo CSS, archivos JavaScript, fuentes y archivos multimedia subidos. El rendimiento del servicio de archivos estáticos afecta directamente a los tiempos de carga de las páginas y al uso de recursos del servidor.

Rendimiento de archivos estáticos en Apache

Apache sirve archivos estáticos a través de sus procesos trabajadores. Cada petición de archivo estático ocupa un worker durante la duración de la transferencia. Para archivos pequeños (CSS, JS, imágenes pequeñas), esto es rápido. Para archivos grandes o conexiones de cliente lentas, el worker está ocupado más tiempo. Con mod_php cargado, cada worker lleva una sobrecarga de memoria PHP innecesaria incluso para las peticiones estáticas.

Apache soporta sendfile, que permite al kernel transferir archivos directamente del disco al socket de red sin copiar datos a través del espacio de usuario. Esto está habilitado por defecto y ayuda con las transferencias de archivos grandes. Apache también soporta negociación de contenido, rangos de bytes y peticiones condicionales (If-Modified-Since) de forma nativa.

Rendimiento de archivos estáticos en Nginx

Nginx sobresale en el servicio de archivos estáticos porque su modelo orientado a eventos puede manejar miles de transferencias de archivos simultáneas sin aumentar proporcionalmente el uso de recursos. Un solo proceso trabajador de Nginx puede servir cientos de peticiones de archivos estáticos simultáneas. Combinado con el uso eficiente de la llamada al sistema sendfile y su soporte integrado para la caché de archivos abiertos (almacenamiento en caché de descriptores de archivo para archivos de acceso frecuente), el servicio de archivos estáticos es extraordinariamente rápido.

Para las tiendas PrestaShop con muchas imágenes de producto (que son la mayoría de las tiendas), la ventaja de rendimiento de Nginx en el servicio de archivos estáticos es significativa. Las páginas de producto con 5-10 imágenes, más archivos CSS, JavaScript y fuentes, generan 20-30 peticiones de archivos estáticos por carga de página. Bajo tráfico elevado, Nginx maneja estas peticiones con sustancialmente menos recursos que Apache.

Terminación SSL/TLS

Toda tienda PrestaShop debería funcionar sobre HTTPS, y el servidor web maneja la encriptación y desencriptación SSL/TLS (terminación). Ambos servidores soportan bien el TLS moderno, pero existen diferencias en configuración y rendimiento.

Apache configura SSL a través de mod_ssl, con directivas como SSLEngine on, SSLCertificateFile y SSLProtocol en el bloque VirtualHost. El grapado OCSP, el almacenamiento en caché de sesiones y la selección de suites de cifrado son todos configurables.

Nginx configura SSL en el bloque server con directivas como ssl_certificate, ssl_protocols y ssl_ciphers. Nginx también soporta grapado OCSP y almacenamiento en caché de sesiones, y su configuración tiende a ser más concisa.

En cuanto a rendimiento, el handshake TLS es intensivo en CPU debido a la encriptación asimétrica involucrada. La capacidad de Nginx para manejar muchas conexiones simultáneas con pocos procesos trabajadores significa que puede manejar más handshakes TLS por segundo con menos memoria. Para tiendas que reciben grandes oleadas de nuevos visitantes (durante una oferta, por ejemplo), la ventaja de rendimiento TLS de Nginx puede prevenir la puesta en cola de conexiones.

Reverse proxy y balanceo de carga

Para tiendas PrestaShop de alto tráfico, una arquitectura de reverse proxy separa responsabilidades y mejora la escalabilidad. La configuración más común utiliza Nginx como reverse proxy delante de Apache o de otra instancia de Nginx ejecutando PHP-FPM.

Nginx como reverse proxy para Apache

Esta configuración híbrida combina las fortalezas de ambos servidores. Nginx se sitúa al frente, manejando todas las conexiones entrantes, sirviendo archivos estáticos directamente, gestionando la terminación SSL y reenviando solo las peticiones PHP a Apache. Apache maneja el procesamiento PHP, y como solo recibe peticiones PHP (no peticiones de archivos estáticos), necesita muchos menos procesos trabajadores.

Esta arquitectura ofrece la eficiencia de manejo de conexiones de Nginx y el rendimiento en archivos estáticos, preservando al mismo tiempo el soporte de .htaccess de Apache para las reglas de reescritura generadas por PrestaShop. Es una ruta de migración común para tiendas que quieren el rendimiento de Nginx sin reescribir toda su configuración de Apache.

La configuración proxy de Nginx utiliza la directiva proxy_pass para reenviar peticiones a Apache, que típicamente se ejecuta en un puerto no estándar como 8080. Los archivos estáticos son servidos directamente por Nginx usando un bloque location que coincide con extensiones de archivo como .jpg, .css, .js y .png.

Configuración completa de Nginx

Para el máximo rendimiento, Nginx sirve todo: archivos estáticos y peticiones PHP (a través de PHP-FPM). No hay Apache en la pila. Esto elimina la comunicación entre procesos entre Nginx y Apache y elimina la sobrecarga de memoria de ejecutar dos servidores web. Sin embargo, requiere crear y mantener manualmente la configuración de Nginx para la reescritura de URLs de PrestaShop, lo que supone más trabajo inicial.

Configuración recomendada de Nginx para PrestaShop

Una configuración de Nginx en producción para PrestaShop necesita manejar URLs amigables, acceso al panel de administración, almacenamiento en caché de archivos estáticos, comunicación con PHP-FPM y seguridad. Los elementos clave incluyen un bloque server escuchando en los puertos 80 y 443, un bloque de configuración SSL con tus certificados, una directiva root apuntando a tu instalación de PrestaShop y varios bloques location.

El bloque location principal utiliza try_files $uri $uri/ /index.php?$args para manejar las URLs amigables de PrestaShop. Intenta servir la petición como archivo estático primero, luego como directorio, y finalmente la pasa al dispatcher de PrestaShop a través de index.php.

Un bloque location que coincide con ~ \.php$ reenvía las peticiones PHP a PHP-FPM usando fastcgi_pass. Incluye los parámetros FastCGI estándar y establece SCRIPT_FILENAME a la ruta correcta.

Un bloque location para recursos estáticos establece cabeceras de expiración de caché largas y desactiva el registro de acceso para reducir la E/S. Patrones de coincidencia como \.(jpg|jpeg|gif|png|svg|css|js|ico|woff|woff2|ttf|eot)$ capturan los tipos de archivo estático comunes.

Los bloques location relacionados con la seguridad deniegan el acceso a archivos y directorios sensibles: .htaccess, .git, config/ (excepto config/xml/ que PrestaShop necesita), vendor/, app/config/ y otros directorios que nunca deberían ser accesibles desde la web.

Configuración recomendada de Apache para PrestaShop

Apache con event MPM y PHP-FPM proporciona el mejor hosting de PrestaShop basado en Apache. La configuración del VirtualHost debería habilitar los módulos rewrite, headers, expires, deflate y proxy_fcgi.

El DocumentRoot apunta a tu instalación de PrestaShop. AllowOverride All habilita el procesamiento de .htaccess, que es necesario a menos que muevas todas las reglas de reescritura de PrestaShop a la configuración del VirtualHost.

La integración con PHP-FPM utiliza SetHandler o ProxyPassMatch para reenviar las peticiones .php al socket de PHP-FPM. El enfoque SetHandler con proxy:unix:/run/php/php-fpm.sock|fcgi://localhost es más sencillo y se recomienda para la mayoría de las configuraciones.

Habilita la compresión gzip con mod_deflate para tipos de contenido basados en texto: HTML, CSS, JavaScript, JSON, XML y SVG. Habilita el almacenamiento en caché del navegador con mod_expires, estableciendo tiempos de expiración largos para recursos estáticos y más cortos para HTML.

Benchmarks de rendimiento y diferencias en el mundo real

Los números crudos de los benchmarks varían enormemente según el hardware, la configuración, la versión de PHP y la versión de PrestaShop. En lugar de presentar números específicos que serían engañosos fuera de contexto, estos son los patrones que emergen consistentemente en los benchmarks de hosting de PrestaShop.

Para el servicio de archivos estáticos, Nginx es consistentemente 2-3 veces más rápido que Apache y usa significativamente menos memoria. Esta brecha se amplía a medida que aumenta la concurrencia. Con 100 conexiones simultáneas, la diferencia podría ser del 20%. Con 1.000 conexiones simultáneas, Nginx podría usar 10 veces menos memoria.

Para el procesamiento de peticiones PHP, el servidor web no es el cuello de botella. El tiempo de procesamiento de PHP-FPM domina el ciclo de vida de la petición, y ambos servidores web añaden una sobrecarga insignificante comparada con el tiempo que PHP pasa ejecutando código PrestaShop, consultando la base de datos y renderizando plantillas. La diferencia en el manejo de peticiones PHP entre Apache con PHP-FPM y Nginx con PHP-FPM es típicamente inferior al 5%, lo que está dentro del margen de error de medición para la mayoría de las tiendas.

Para cargas de trabajo mixtas (el escenario realista), la ventaja de Nginx proviene de su manejo eficiente de archivos estáticos junto con las peticiones PHP. La carga de una página genera una petición PHP y 20-30 peticiones de archivos estáticos. Nginx maneja las 20-30 peticiones estáticas con un consumo trivial de recursos, mientras que Apache asigna un hilo trabajador a cada una. Bajo tráfico elevado, esta diferencia en el consumo de recursos significa que Nginx puede sostener una concurrencia más alta antes de que el rendimiento se degrade.

La conclusión práctica es que para tiendas con menos de 50 visitantes simultáneos, la elección del servidor web no marca prácticamente ninguna diferencia perceptible. Para tiendas que se acercan o superan los 100 visitantes simultáneos, las ventajas arquitectónicas de Nginx se vuelven significativas.

Guía de migración: de Apache a Nginx

La migración de una tienda PrestaShop existente de Apache a Nginx implica traducir la configuración, probar exhaustivamente y realizar el cambio.

Paso 1: Traduce las reglas .htaccess

Abre tu archivo .htaccess de PrestaShop e identifica todas las reglas de reescritura activas. La sección crítica es la reescritura de URLs amigables, que típicamente comienza con RewriteCond %{REQUEST_FILENAME} !-f y RewriteRule .* - [E=REWRITEBASE:/]. Estas se traducen a la directiva try_files de Nginx mencionada en la sección de configuración anterior.

Las reescrituras del servidor de medios, el manejo de prefijos de idioma y cualquier redirección personalizada también necesitan traducción. Cada par de RewriteRule y RewriteCond de Apache debe convertirse a la directiva location, rewrite o return equivalente de Nginx.

Paso 2: Configura Nginx junto a Apache

Instala Nginx y configúralo para escuchar en un puerto diferente (como 8080) mientras Apache continúa ejecutándose en el puerto 80. Esto te permite probar la configuración de Nginx sin afectar al sitio en producción. Apunta Nginx a la misma raíz de documentos que Apache para que sirva los mismos archivos.

Paso 3: Prueba todo

Accede al sitio a través del puerto de Nginx y prueba todos los aspectos: la página principal, las páginas de categorías, las páginas de productos, el carrito, el proceso de pago, el panel de administración, las URLs amigables, la carga de imágenes y el enrutamiento de URLs multilingüe. Presta especial atención a los patrones de URL que involucran caracteres especiales o parámetros de consulta.

Paso 4: Realiza el cambio

Una vez completadas las pruebas, detén Apache y reconfigura Nginx para escuchar en los puertos 80 y 443. Recarga Nginx y verifica que el sitio en producción funcione correctamente. Mantén la configuración de Apache intacta durante unos días en caso de que necesites hacer un rollback.

Problemas comunes en la migración

El problema más común son las reglas de reescritura faltantes para el enrutamiento de URLs multilingüe de PrestaShop. Si tu tienda usa múltiples idiomas con códigos de idioma en la URL (como /en/, /de/, /fr/), asegúrate de que la configuración de Nginx maneje correctamente estos prefijos.

Otro problema común son los límites de tamaño de subida de archivos. Apache usa LimitRequestBody mientras que Nginx usa client_max_body_size. Si importas productos con imágenes grandes, establece client_max_body_size a al menos 20M.

Las peticiones AJAX del panel de administración que dependen de la reescritura de .htaccess pueden fallar si las reglas correspondientes de Nginx no están presentes. Prueba el panel de administración exhaustivamente, incluyendo la edición de productos, la gestión de pedidos y la configuración de módulos.

Cuál deberías elegir

Elige Apache si estás en un hosting compartido donde no controlas el servidor web, si dependes en gran medida de .htaccess para la configuración (reglas generadas por módulos, plugins de seguridad) o si no te sientes cómodo escribiendo y manteniendo archivos de configuración de Nginx. Apache con event MPM y PHP-FPM es una configuración sólida y bien soportada para tiendas PrestaShop con tráfico moderado.

Elige Nginx si tienes acceso root a tu servidor, tu tienda maneja un tráfico significativo (cientos o miles de visitantes simultáneos), quieres el menor uso de recursos posible para un nivel de tráfico dado o estás configurando un servidor nuevo y prefieres los beneficios a largo plazo de la arquitectura de Nginx. El esfuerzo inicial de configuración es un coste único que se amortiza en rendimiento y eficiencia de recursos.

Elige el enfoque de reverse proxy Nginx delante de Apache si quieres el rendimiento de Nginx para archivos estáticos y el manejo de conexiones pero necesitas el soporte de .htaccess de Apache para la compatibilidad con módulos PrestaShop que generan o dependen de reglas .htaccess.

Para la mayoría de las nuevas instalaciones de PrestaShop en un VPS o servidor dedicado, Nginx con PHP-FPM es la opción recomendada. La configuración está bien documentada, las ventajas de rendimiento son reales y la simplicidad operativa de una pila de servidor web único reduce la sobrecarga de mantenimiento. Para tiendas existentes en Apache que funcionan adecuadamente, la migración a Nginx es una optimización valiosa pero no una necesidad urgente, a menos que estés alcanzando los límites de rendimiento.

Leer respuesta completa

Cómo funciona internamente la búsqueda en PrestaShop

PrestaShop incluye un motor de búsqueda de productos integrado que opera sobre un índice de texto completo almacenado directamente en la base de datos MySQL. A diferencia de los servicios de búsqueda externos, este índice reside junto a los datos de los productos en la misma base de datos, lo que significa que es rápido de consultar pero requiere mantenimiento explícito para mantenerse actualizado. Comprender cómo funciona este sistema de búsqueda es el primer paso para diagnosticar y resolver problemas de búsqueda.

Cuando un cliente escribe una consulta en la barra de búsqueda de tu tienda, PrestaShop no escanea en tiempo real cada nombre y descripción de producto. En su lugar, busca los términos de la consulta en un índice pre-construido que mapea palabras individuales a productos. Este índice se construye descomponiendo los campos de texto de los productos en palabras individuales (tokenización), normalizándolas (conversión a minúsculas, eliminación de acentos) y almacenando la relación entre cada palabra y los productos en los que aparece, junto con un peso de relevancia.

Este enfoque es fundamentalmente el mismo que utilizan los motores de búsqueda como Google, solo que a una escala mucho menor. La contrapartida es que el índice debe reconstruirse cada vez que los datos de los productos cambian de maneras que la indexación automática no detecta, lo cual es la causa raíz de la mayoría de los problemas de búsqueda en PrestaShop.

Las tablas de la base de datos de búsqueda

El índice de búsqueda de PrestaShop está distribuido en varias tablas de la base de datos, cada una con un propósito específico en el proceso de búsqueda.

ps_search_word

Esta tabla almacena cada palabra única extraída de los datos de los productos, junto con el idioma al que pertenece. Cada palabra recibe un id_word que sirve como clave de referencia. La tabla es consciente de los idiomas, lo que significa que la palabra "shoe" en tu catálogo en inglés y "Schuh" en tu catálogo en alemán son entradas separadas, cada una vinculada a su respectivo ID de idioma.

Cuando miras esta tabla, verás miles o decenas de miles de filas dependiendo del tamaño de tu catálogo y el número de idiomas. Cada palabra distinta de cada campo de producto indexado está representada aquí.

ps_search_index

Esta es la tabla de mapeo principal. Cada fila vincula un producto (id_product) a una palabra (id_word) con un valor de peso. El peso determina cuán relevante es esa palabra para ese producto. Una palabra que aparece en el nombre del producto tiene más peso que la misma palabra que aparece en la descripción, y los valores de peso son configurables en el back office.

Cuando un cliente busca "cartera cuero azul", PrestaShop busca cada palabra en ps_search_word, encuentra los valores id_word correspondientes, y luego consulta ps_search_index para los productos que coinciden con esos IDs de palabras. Los productos se clasifican por la suma de sus pesos para las palabras coincidentes, con los productos de mayor peso total apareciendo primero en los resultados.

ps_search_engine

Esta tabla almacena los patrones de motores de búsqueda de referencia utilizados para rastrear qué motores de búsqueda envían tráfico a tu tienda. No está directamente relacionada con la funcionalidad de búsqueda interna pero a menudo se confunde con ella debido a la nomenclatura similar.

ps_alias

La tabla de alias almacena los alias de términos de búsqueda, que son grafías alternativas o sinónimos que deberían mapearse a un término de búsqueda canónico. Por ejemplo, podrías configurar "zapatillas" como alias de "tenis" para que los clientes que busquen cualquiera de los dos términos obtengan los mismos resultados. Los alias se configuran en el back office en Parámetros de la tienda > Búsqueda > Buscar > Alias.

Cuándo y por qué es necesaria la reindexación

PrestaShop tiene una función de indexación automática que actualiza el índice de búsqueda cada vez que un producto se guarda a través del back office. Cuando editas un producto y haces clic en Guardar, PrestaShop reindexa ese producto específico, actualizando sus entradas en ps_search_word y ps_search_index. Esto funciona bien para la gestión diaria de productos.

Sin embargo, la indexación automática no cubre todos los escenarios. Hay varias situaciones comunes en las que es necesaria una reindexación completa.

Importaciones masivas de productos

Cuando importas productos mediante CSV, el proceso de importación puede no activar los hooks de indexación de búsqueda para cada producto. Esto es especialmente común con importaciones grandes donde las optimizaciones de rendimiento omiten pasos de procesamiento no esenciales. Después de una importación masiva, los nuevos productos pueden existir en el catálogo pero ser completamente invisibles para la búsqueda del sitio.

Modificaciones directas a la base de datos

Si tú o un módulo modificáis datos de productos directamente en la base de datos (omitiendo el modelo de objetos de PrestaShop), el índice de búsqueda no se actualizará. Esto incluye actualizaciones SQL a nombres de productos, descripciones u otros campos indexados. Cualquier migración de base de datos, limpieza de datos o herramienta de sincronización externa que escriba directamente en ps_product_lang dejará el índice de búsqueda desactualizado.

Cambios de idiomas

Añadir un nuevo idioma a tu tienda requiere una reindexación completa porque el índice de búsqueda es específico por idioma. Los productos existentes necesitan que su contenido en el nuevo idioma sea tokenizado y añadido al índice. De manera similar, si editas el contenido de productos en un idioma específico (especialmente a través de operaciones masivas), una reindexación asegura que los cambios se reflejen en la búsqueda.

Cambios en la configuración de pesos

Cuando cambias los valores de peso asignados a diferentes campos de producto (más sobre esto a continuación), las entradas existentes del índice retienen sus pesos antiguos. Una reindexación recalcula todos los pesos usando la nueva configuración.

Instalaciones o actualizaciones de módulos

Algunos módulos modifican las estructuras de datos de productos o añaden campos buscables. Después de instalar o actualizar tales módulos, una reindexación asegura que los datos nuevos o modificados se incluyan en el índice de búsqueda.

Índice corrupto

Caídas de la base de datos, migraciones fallidas u operaciones de indexación interrumpidas pueden dejar el índice de búsqueda en un estado inconsistente. Los síntomas incluyen productos que deberían aparecer en los resultados de búsqueda pero no aparecen, productos que aparecen para términos de búsqueda completamente incorrectos, o la búsqueda que no devuelve ningún resultado. Una reindexación completa reconstruye el índice desde cero, resolviendo estas inconsistencias.

Cómo reindexar productos

Método desde el back office

Navega a Parámetros de la tienda > Búsqueda en tu back office de PrestaShop. En la parte superior de la página encontrarás una sección de "Indexación" con opciones para reconstruir el índice de búsqueda. Típicamente hay dos opciones: añadir al índice los productos que aún no han sido indexados (incremental) o reconstruir el índice completo desde cero (reindexación completa).

Para la mayoría de los escenarios de resolución de problemas, elige la reconstrucción completa. La opción incremental solo añade productos faltantes y no actualiza entradas existentes que pueden tener datos desactualizados.

El método del back office funciona bien para catálogos pequeños y medianos (hasta unos pocos miles de productos). Para catálogos más grandes, puede agotar el tiempo debido a los límites de tiempo de ejecución de PHP, lo que hace necesario el método CLI.

Comando CLI para la reindexación

Para catálogos grandes o flujos de trabajo automatizados, usa la línea de comandos para activar una reindexación. En PrestaShop 1.7 y posteriores, el comando es:

php bin/console prestashop:search-index:rebuild

Para PrestaShop 1.6, llamarías directamente al script de indexación. La ruta exacta depende de tu instalación, pero la lógica de indexación reside en la clase Search.

El método CLI no tiene las mismas restricciones de timeout que la interfaz web. Para catálogos muy grandes (decenas de miles de productos en múltiples idiomas), la reindexación puede tardar varios minutos. Puedes monitorear el progreso a través de la salida.

Si ejecutas PrestaShop en Docker, ejecuta el comando dentro del contexto del contenedor donde PHP y la base de código de PrestaShop están disponibles. Asegúrate de ejecutarlo como el usuario del servidor web para evitar problemas de permisos con los archivos de caché que se generan durante el proceso.

Automatización de la reindexación

Si tu tienda depende de importaciones automatizadas de productos o sincronización de datos externa, programa la reindexación periódica como un cron job. Una reindexación nocturna asegura que los productos añadidos o modificados a través de procesos automatizados sean buscables al día siguiente. La entrada del cron llamaría al mismo comando CLI según un horario.

Ten en cuenta que la reindexación bloquea brevemente las tablas de búsqueda durante la reconstrucción. En una tienda con mucho tráfico, programa la reindexación durante las horas de bajo tráfico para evitar impactar la disponibilidad de la búsqueda para los clientes activos.

Configuración de pesos: Controlando la relevancia de la búsqueda

PrestaShop te permite configurar cuánto peso tienen diferentes campos de producto en los resultados de búsqueda. Esta es una de las características más potentes y más infrautilizadas del sistema de búsqueda integrado.

Campos de peso disponibles

La configuración de pesos se encuentra en Parámetros de la tienda > Búsqueda. Puedes asignar un peso (típicamente de 1 a 10, aunque valores más altos también funcionan) a cada uno de estos campos de producto:

Nombre del producto: Este debería típicamente tener el peso más alto. Cuando un cliente busca un producto por nombre, el producto con ese nombre exacto debería aparecer primero.

Referencia: Los códigos de referencia de productos son frecuentemente utilizados por clientes B2B que conocen el SKU exacto que necesitan. Un peso moderado asegura que las búsquedas por referencia funcionen bien sin sobrepasar las búsquedas por nombre.

Descripción corta: La descripción corta a menudo contiene puntos de venta clave y características del producto. Un peso moderado es apropiado.

Descripción: La descripción completa contiene el mayor texto y por lo tanto el mayor número de posibles coincidencias de palabras clave. Sin embargo, dado que contiene tanto texto, un peso alto puede causar coincidencias irrelevantes donde un término de búsqueda aparece incidentalmente en una descripción larga. Se recomienda un peso menor relativo al nombre del producto.

Categoría: Incluir los nombres de las categorías en la búsqueda permite a los clientes encontrar productos por términos de categoría incluso cuando esos términos no aparecen en el texto del propio producto.

Marca (fabricante): Los clientes a menudo buscan por nombre de marca. Un peso de moderado a alto asegura que las búsquedas por marca devuelvan resultados relevantes.

Etiquetas: Las etiquetas son términos de búsqueda explícitamente asignados a los productos. Un peso alto para las etiquetas te da control directo sobre qué productos aparecen para consultas de búsqueda específicas.

Atributos: Los valores de atributos del producto (talla, color, material) pueden incluirse en el índice de búsqueda. Esto permite búsquedas como "rojo XL" para devolver productos con esas combinaciones de atributos.

Características: Los valores de las características del producto (peso, dimensiones, tipo de material) también pueden indexarse.

Estrategia de pesos

Una configuración inicial razonable podría ser: nombre del producto a 6, referencia a 4, descripción corta a 3, descripción a 1, categoría a 2, fabricante a 3, etiquetas a 4, atributos a 2, características a 2. Pero los pesos óptimos dependen enteramente de tu catálogo y del comportamiento de búsqueda de tus clientes.

Si tus clientes buscan frecuentemente por SKU o número de referencia, aumenta el peso de la referencia. Si las búsquedas por marca son importantes, aumenta el peso del fabricante. Si encuentras que las descripciones largas causan resultados irrelevantes con alta clasificación, reduce el peso de la descripción o establécelo en cero para excluir completamente las descripciones del índice.

Después de cambiar los pesos, siempre realiza una reindexación completa para que los nuevos valores surtan efecto en todos los productos.

Problemas comunes de búsqueda y soluciones

Productos que no aparecen en los resultados de búsqueda

Esta es la queja más común sobre la búsqueda. Un producto existe en el catálogo pero buscarlo por nombre no devuelve resultados. Las causas incluyen: el producto fue añadido a través de una importación que no activó la indexación, el producto está deshabilitado o sin stock y la búsqueda está configurada para excluir tales productos, o el índice de búsqueda está corrupto.

Solución: Primero, verifica que el producto esté activo y visible. Luego ejecuta una reindexación completa. Si el producto aún no aparece, comprueba si el nombre del producto contiene caracteres especiales que podrían eliminarse durante la tokenización, y comprueba si el ajuste de longitud mínima de palabra (en la configuración de búsqueda) está excluyendo palabras cortas del nombre del producto.

Productos incorrectos clasificados primero

Cuando una búsqueda de "widget azul" devuelve un producto llamado "soporte de widgets" antes del producto real "widget azul", usualmente es un problema de configuración de pesos. El producto que se clasifica más alto ha acumulado más peso total en todos los campos indexados. Quizás "widget" aparece muchas veces en la descripción del producto soporte, y con un peso de descripción alto, esas ocurrencias superan una sola coincidencia en el nombre del producto.

Solución: Ajusta los pesos de los campos para priorizar el nombre del producto. Establece el peso del nombre del producto significativamente más alto que el peso de la descripción. Reindexa después de hacer los cambios.

La búsqueda devuelve demasiados resultados irrelevantes

Esto ocurre cuando el peso de la descripción es demasiado alto o cuando palabras comunes aparecen en muchas descripciones de productos. Una búsqueda de "premium" devuelve cada producto cuya descripción contiene la palabra "premium" incluso cuando no es una característica definitoria de esos productos.

Solución: Reduce el peso de la descripción o usa la función de lista negra de palabras para excluir palabras comunes no discriminatorias del índice. La lista negra se configura en Parámetros de la tienda > Búsqueda y te permite especificar palabras que deben ignorarse durante la indexación.

La búsqueda no encuentra coincidencias parciales

La búsqueda integrada de PrestaShop no soporta coincidencias difusas verdaderas. Si un cliente busca "zapato" no encontrará productos que solo contengan la palabra "zapatos" a menos que las funciones de stemming o alias manejen la variación. Esta es una limitación fundamental del enfoque basado en índice de palabras.

Solución: Usa la función de alias para mapear variaciones comunes ("zapato" a "zapatos", "TV" a "televisión"). Para coincidencias parciales más completas, considera una solución de búsqueda externa como Elasticsearch.

Caracteres acentuados causando fallos

PrestaShop normaliza los caracteres acentuados durante la indexación (por ejemplo, convirtiendo "cafe" y "café" a la misma forma base). Si esta normalización no funciona correctamente, las búsquedas con o sin acentos pueden producir resultados diferentes.

Solución: Verifica que la configuración de búsqueda tenga la eliminación de acentos habilitada. Reindexa después de verificar. Si el problema persiste, comprueba el conjunto de caracteres y la collation de la base de datos, ya que las codificaciones no coincidentes pueden interferir con la normalización del texto.

Optimización del rendimiento de búsqueda

Para tiendas con catálogos grandes (más de 10.000 productos), el rendimiento de búsqueda puede convertirse en un problema. La búsqueda integrada ejecuta consultas a la base de datos contra las tablas del índice en cada petición de búsqueda, y con un índice grande, estas consultas pueden volverse lentas.

Indexación de la base de datos

Asegúrate de que las tablas ps_search_word y ps_search_index tengan índices de base de datos apropiados. PrestaShop los crea por defecto, pero si las tablas han sido alteradas o reconstruidas, los índices pueden faltar. Los índices clave son en id_word e id_lang en ps_search_word, y en id_product e id_word en ps_search_index.

Longitud mínima de palabra

El ajuste de longitud mínima de palabra controla la palabra más corta que se indexa. El valor predeterminado es usualmente 3 caracteres, lo que significa que las palabras de uno y dos caracteres se excluyen. Aumentar esto a 4 reduce el tamaño del índice y puede mejorar la velocidad de búsqueda, pero significa que las búsquedas de términos cortos como "XL" o "TV" no funcionarán. Equilibra el tamaño del índice con tus requisitos de búsqueda.

Palabras en lista negra

Añadir palabras comunes ("el", "y", "para", "con") a la lista negra reduce significativamente el tamaño del índice porque estas palabras aparecen en casi todas las descripciones de productos. Tablas de índice más pequeñas significan consultas más rápidas.

Optimización de tablas

Después de una reindexación completa, ejecuta OPTIMIZE TABLE ps_search_word, ps_search_index en MySQL. El proceso de reindexación elimina y reinserta grandes cantidades de filas, lo que puede dejar las tablas fragmentadas. La optimización recupera ese espacio y mejora el rendimiento de las consultas.

Elasticsearch como alternativa

Para tiendas que han superado la búsqueda integrada de PrestaShop, Elasticsearch proporciona una mejora significativa tanto en la calidad de búsqueda como en el rendimiento. Elasticsearch es un motor de búsqueda dedicado que se ejecuta como un servicio separado y ofrece características que la búsqueda integrada basada en MySQL no puede igualar.

Qué añade Elasticsearch

La coincidencia difusa permite a Elasticsearch encontrar resultados incluso cuando el término de búsqueda está mal escrito. Una búsqueda de "cuero" seguirá encontrando productos que contengan "cuero". El stemming reduce las palabras a su forma raíz, por lo que "corriendo", "corre" y "corrió" coinciden con productos que contienen cualquiera de estas variaciones. El soporte de sinónimos te permite definir relaciones entre palabras ("sofá" y "sillón") a nivel del motor de búsqueda en lugar de mediante alias manuales.

La búsqueda facetada (filtrar resultados por atributos como rango de precios, color, marca) es drásticamente más rápida con Elasticsearch porque está diseñado exactamente para este tipo de consultas de agregación. Las sugerencias de autocompletado y las funciones de "quizás quisiste decir" también son capacidades nativas de Elasticsearch.

En cuanto a rendimiento, Elasticsearch maneja catálogos grandes (más de 100.000 productos) con tiempos de respuesta inferiores al segundo porque utiliza índices invertidos optimizados para búsqueda de texto completo, a diferencia de MySQL que está diseñado principalmente para datos relacionales.

Integración con PrestaShop

Varios módulos de PrestaShop proporcionan integración con Elasticsearch. Estos módulos típicamente reemplazan el controlador de búsqueda predeterminado por uno que consulta Elasticsearch en lugar de las tablas de búsqueda MySQL. Los datos de los productos se sincronizan de PrestaShop a Elasticsearch en tiempo real (al guardar el producto) o mediante sincronización por lotes periódica.

Ejecutar Elasticsearch requiere un servidor o contenedor dedicado con RAM adecuada (mínimo 2GB para catálogos pequeños, más para los más grandes). Añade complejidad operativa ya que ahora tienes otro servicio que monitorear y mantener. Para muchas tiendas pequeñas y medianas, la búsqueda integrada con una configuración de pesos adecuada y reindexación regular es suficiente.

Cuándo considerar Elasticsearch

Considera Elasticsearch cuando tu catálogo excede los 10.000 productos y el rendimiento de búsqueda está degradándose, cuando los clientes frecuentemente escriben mal los términos de búsqueda y esperan coincidencia difusa, cuando necesitas características avanzadas como autocompletado o filtrado facetado, o cuando la calidad de búsqueda es un diferenciador competitivo para tu negocio (tiendas B2B con catálogos de productos complejos, por ejemplo).

La lista de verificación de reindexación

Cuando la búsqueda no funciona correctamente en tu tienda PrestaShop, sigue este proceso de diagnóstico y resolución. Primero, verifica que los productos problemáticos estén activos, visibles y en stock (si tu búsqueda excluye productos agotados). Segundo, comprueba la configuración de pesos de búsqueda y asegúrate de que coincida con tus prioridades. Tercero, ejecuta una reconstrucción completa del índice de búsqueda desde el back office o CLI. Cuarto, limpia la caché de PrestaShop después de la reindexación. Quinto, prueba la búsqueda con términos específicos para verificar la corrección. Sexto, si los problemas persisten, comprueba las tablas ps_search_word y ps_search_index directamente para verificar que los productos problemáticos tengan entradas. Séptimo, si el índice parece correcto pero la búsqueda aún falla, investiga la lógica del controlador de búsqueda y cualquier módulo que lo sobreescriba.

La reindexación regular, combinada con una configuración de pesos reflexiva y una lista de alias bien mantenida, mantiene la búsqueda integrada de PrestaShop funcionando de manera confiable para la mayoría de las tiendas. Para aquellos que necesitan más, Elasticsearch proporciona una ruta de mejora sin requerir un cambio de plataforma.

Leer respuesta completa

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.

Leer respuesta completa

What Content Security Policy Is and Why It Matters

Content Security Policy (CSP) is a security mechanism implemented through HTTP headers that tells the browser exactly which resources are allowed to load on your pages. It prevents cross-site scripting (XSS) attacks, data injection attacks, and other code injection vulnerabilities by giving you granular control over where JavaScript, CSS, images, fonts, frames, and other resources can originate from.

Without CSP, a browser will execute any JavaScript it encounters on your page, regardless of where it came from. If an attacker manages to inject a malicious script (through a vulnerable module, a compromised third-party library, or a stored XSS vulnerability), the browser happily executes it with full access to the page content, including customer data, form inputs, and session cookies.

With CSP, you declare a whitelist of trusted sources. If the browser encounters a resource that does not match the policy, it blocks it and logs a violation. This means that even if an attacker finds a way to inject code into your page, the browser refuses to execute it because it does not come from an approved source.

For PrestaShop stores that handle customer personal information, payment data, and authentication credentials, CSP is a critical security layer. It is not a replacement for fixing vulnerabilities in your code, but it is an effective defense-in-depth measure that limits the damage when a vulnerability exists.

CSP Directives Explained

A Content Security Policy consists of one or more directives, each controlling a specific type of resource. The most important directives for PrestaShop are:

default-src: The fallback directive. If a more specific directive is not set, the browser uses default-src. Setting default-src 'self' means that by default, only resources from your own domain are allowed.

script-src: Controls where JavaScript can be loaded from. This is the most critical directive for XSS prevention. Common values include 'self' (your own domain), specific CDN domains, and analytics domains.

style-src: Controls where CSS can be loaded from. PrestaShop themes and modules frequently use inline styles, which means you may need 'unsafe-inline' unless you implement a nonce-based approach.

img-src: Controls where images can be loaded from. PrestaShop stores often load images from their own domain, CDN domains, and third-party services like Google (for user avatars or Maps).

font-src: Controls where fonts can be loaded from. Google Fonts, Font Awesome CDN, and your own domain are common sources.

connect-src: Controls which URLs can be contacted via JavaScript (AJAX requests, WebSocket connections, EventSource). Payment gateways, analytics endpoints, and your own API endpoints need to be listed here.

frame-src: Controls which domains can be embedded in iframes. Payment gateways like PayPal, Stripe, and Klarna use iframes for their payment forms. YouTube and Vimeo embeds also require frame-src entries.

frame-ancestors: Controls which domains can embed your page in an iframe. Setting frame-ancestors 'self' prevents clickjacking attacks by ensuring your store cannot be embedded in another site's iframe.

object-src: Controls plugin content like Flash. Set this to 'none' because Flash is obsolete and no PrestaShop functionality requires it.

base-uri: Controls which URLs can be used in the <base> element. Set to 'self' to prevent base URI manipulation attacks.

form-action: Controls which URLs forms can submit to. This should include your own domain and any external payment processing endpoints.

Starting with Report-Only Mode

Deploying CSP on a PrestaShop store requires careful preparation because an overly restrictive policy will break functionality. The right approach is to start with report-only mode, which tells the browser to report violations without actually blocking anything.

Instead of using the Content-Security-Policy header, use Content-Security-Policy-Report-Only. This header accepts the exact same directives but only generates reports without enforcing the policy. Your store continues to function normally while you collect data about what would be blocked.

Setting Up Violation Reporting

Add a report-uri directive to your policy that points to an endpoint that collects violation reports. You can use a free service like Report URI (report-uri.com), which provides a dashboard for viewing and analyzing CSP violations, or you can set up your own endpoint.

The browser sends violation reports as JSON POST requests. Each report includes the blocked URI, the directive that was violated, the page where the violation occurred, and other useful debugging information. Collecting these reports for a week or two on a live store gives you a comprehensive picture of all the resources your store loads and where they come from.

Building Your Initial Policy

Using the violation reports from report-only mode, build a whitelist of all legitimate resource sources. Group them by directive type. Your initial policy will likely include:

Your own domain for all resource types. CDN domains (like cdnjs.cloudflare.com, fonts.googleapis.com, fonts.gstatic.com) for scripts, styles, and fonts. Analytics domains (like google-analytics.com, googletagmanager.com, connect.facebook.net) for tracking. Payment gateway domains for scripts, frames, and connections. Chat widget domains if you use live chat. Social media domains for embedded content or share buttons.

Building a CSP for PrestaShop

PrestaShop presents specific challenges for CSP implementation because of its architecture and the modules ecosystem.

Handling Inline Styles and Scripts

PrestaShop core, themes, and many modules use inline styles and inline JavaScript extensively. Inline code is blocked by default in CSP because an attacker who injects content into your page would be injecting inline code. There are three approaches to handling this:

Using 'unsafe-inline': The simplest but least secure approach. Adding 'unsafe-inline' to script-src and style-src allows all inline code, which significantly weakens CSP's XSS protection. For style-src, this is generally acceptable because inline styles pose a much lower security risk than inline scripts. For script-src, avoid 'unsafe-inline' if at all possible.

Using nonces: The recommended approach. A nonce is a random, single-use token generated on each request. You add the nonce to your CSP header (script-src 'nonce-abc123') and to each legitimate inline script tag (<script nonce="abc123">). The browser only executes inline scripts that have the correct nonce. Since the nonce changes on every request and an attacker cannot predict it, injected scripts without the nonce are blocked.

Implementing nonces in PrestaShop requires modifying the theme to add nonce attributes to all inline script tags and creating a mechanism (typically a module or a custom hook) that generates the nonce, adds it to the CSP header, and makes it available to templates. This is a significant implementation effort but provides strong XSS protection.

Using hashes: You can whitelist specific inline scripts by their SHA-256 hash. The browser computes the hash of each inline script it encounters and checks it against the hashes listed in the CSP. This approach works for inline scripts that do not change between requests (static inline scripts), but it is impractical for PrestaShop because many inline scripts include dynamic content like product IDs, prices, and user-specific data that change the hash.

Handling eval and Dynamic Code

Some JavaScript libraries use eval() or new Function() to dynamically create and execute code. CSP blocks these by default. If a module or library requires eval, you must add 'unsafe-eval' to script-src. Common culprits include older versions of jQuery templates, some analytics scripts, and certain payment gateway libraries.

Check your violation reports for entries with eval or inline as the blocked URI. These indicate code that uses dynamic evaluation. Where possible, replace the library with a version that does not use eval. When that is not possible (such as with a third-party payment gateway library you cannot modify), 'unsafe-eval' is the only option.

Third-Party Services

Most PrestaShop stores rely on multiple third-party services, each of which needs to be whitelisted in your CSP. Here are the most common ones and the directives they require:

Google Analytics and Google Tag Manager: These require entries in script-src for www.google-analytics.com, www.googletagmanager.com, and tagmanager.google.com. They also need connect-src entries for www.google-analytics.com and analytics.google.com (for sending tracking data), and img-src entries for www.google-analytics.com (for the tracking pixel). Google Tag Manager is particularly challenging because it dynamically loads scripts from domains you may not know in advance, as the scripts loaded depend on the tags configured in GTM.

PayPal: Requires script-src and frame-src entries for *.paypal.com and *.paypalobjects.com. The exact domains depend on whether you use PayPal Standard, PayPal Express, or the newer PayPal Commerce Platform integration.

Stripe: Requires script-src for js.stripe.com, frame-src for js.stripe.com and hooks.stripe.com, and connect-src for api.stripe.com.

Google Fonts: Requires style-src for fonts.googleapis.com and font-src for fonts.gstatic.com.

YouTube embeds: Require frame-src for www.youtube.com and www.youtube-nocookie.com.

Facebook Pixel and social plugins: Require script-src and connect-src for connect.facebook.net and www.facebook.com, plus img-src for www.facebook.com and *.fbcdn.net.

Live chat widgets (Tidio, Crisp, Intercom, etc.): Each has its own set of domains for scripts, styles, WebSocket connections, and images. Check your violation reports or the provider's documentation for the exact domains required.

A Complete CSP Example for PrestaShop

Here is a realistic CSP header for a PrestaShop store that uses Google Analytics, Google Fonts, PayPal, YouTube embeds, and has inline styles:

Content-Security-Policy: default-src 'self'; script-src 'self' www.google-analytics.com www.googletagmanager.com js.stripe.com 'unsafe-inline' 'unsafe-eval'; style-src 'self' fonts.googleapis.com 'unsafe-inline'; img-src 'self' data: www.google-analytics.com *.paypal.com; font-src 'self' fonts.gstatic.com; connect-src 'self' www.google-analytics.com analytics.google.com api.stripe.com; frame-src 'self' www.youtube.com www.youtube-nocookie.com js.stripe.com *.paypal.com; frame-ancestors 'self'; object-src 'none'; base-uri 'self'; form-action 'self' *.paypal.com;

This policy includes 'unsafe-inline' and 'unsafe-eval' for scripts, which weakens XSS protection but is necessary for most PrestaShop installations that have not been modified to support nonces. For img-src, the data: source is included because PrestaShop and many modules use data URIs for small images and icons.

Implementing CSP in PrestaShop

Via .htaccess (Apache)

For Apache servers, add the CSP header in your .htaccess file. Place it near the top of the file, before the PrestaShop rewrite rules:

Header set Content-Security-Policy "default-src 'self'; script-src 'self' ..."

This requires the mod_headers module to be enabled. You can verify by checking if your server returns the header using browser DevTools (Network tab, click on the main document request, check the Response Headers).

Via Nginx Configuration

For Nginx, add the header in your server block:

add_header Content-Security-Policy "default-src 'self'; script-src 'self' ..." always;

The always parameter ensures the header is sent even for error responses, which is important because error pages can also be targets for XSS attacks.

Via a PrestaShop Module

Implementing CSP through a module gives you the ability to manage the policy from the back office. The module hooks into the actionOutputHTMLBefore or uses PHP's header() function in a front controller hook to add the CSP header to every response. A module-based approach is easier to maintain because you can update the policy without editing server configuration files and without restarting the web server.

Testing Your CSP with Browser DevTools

After implementing your CSP (in report-only mode initially), use browser DevTools to monitor for violations. Open the Console tab and look for messages that start with "[Report Only]" (in report-only mode) or "Refused to" (in enforcement mode). Each message tells you exactly what was blocked and which directive was responsible.

Test every page type on your store: the home page, category pages, product pages, the cart, the checkout process (including each step and each payment method), the customer account pages, and CMS pages. Each page type may load different resources, and you need to ensure your policy covers all of them.

Pay special attention to the checkout process. A blocked payment gateway script or iframe during checkout directly prevents customers from completing purchases. Test every payment method you offer, including the 3D Secure verification flow if applicable, because these often load additional resources from domains that are not obvious.

Common Testing Pitfalls

Testing in a development environment may not reveal all violations because your development setup may not include all the third-party services that run on production (analytics, advertising pixels, live chat, A/B testing tools). Always deploy CSP in report-only mode on production first and collect reports for at least one to two weeks before switching to enforcement.

Some violations only occur under specific conditions. For example, a payment gateway might load additional verification scripts only when a customer's card requires 3D Secure authentication. Social sharing buttons might load scripts only when a visitor clicks them. Dynamic content loaded via AJAX may reference resources that are not present on the initial page load. Run through every possible user flow during testing.

Gradual Enforcement Strategy

The recommended deployment strategy for CSP on PrestaShop follows these steps:

Phase 1: Discovery. Deploy a permissive Content-Security-Policy-Report-Only header with default-src * 'unsafe-inline' 'unsafe-eval' data: blob:; and a report-uri. This logs all resources without blocking anything, giving you a complete inventory of what your store loads.

Phase 2: Draft policy. Based on the violation reports, build a whitelist policy that covers all legitimate resources. Deploy it in report-only mode and monitor for violations that indicate you missed a resource.

Phase 3: Refine. Over one to two weeks, check violation reports daily and add any legitimate sources you missed. Pay attention to reports that come from specific page types or user flows you might not have tested manually.

Phase 4: Enforce. Switch from Content-Security-Policy-Report-Only to Content-Security-Policy. Keep the report-uri directive so you continue receiving violation reports. Monitor closely for the first week after enforcement to catch any legitimate resources that are being blocked.

Phase 5: Tighten. Once enforcement is stable, look for opportunities to tighten the policy. Can you replace 'unsafe-inline' in script-src with nonces? Can you narrow wildcard domains to specific subdomains? Can you remove sources that are no longer used? Each tightening step improves your security posture.

Maintaining Your CSP

A CSP is not a set-and-forget configuration. Every time you install a new module, add a third-party service, change payment gateways, or update your theme, you may need to update your CSP to include new resource sources. Make CSP review part of your module installation and update process.

Keep your report-uri active even after enforcement so you receive alerts about new violations. A sudden increase in violation reports might indicate that a module update introduced new resource requirements, or it might indicate an actual XSS attack attempt that your CSP is successfully blocking. Either way, you want to know about it.

Document your CSP and the reason for each entry. Over time, policies accumulate entries for services you no longer use. Periodic reviews to remove unnecessary entries keep the policy clean and reduce the attack surface. A CSP with fewer allowed sources is inherently more secure than one with many.

Leer respuesta completa

Qué es Varnish y por qué importa para PrestaShop

Varnish Cache es un proxy inverso HTTP que se sitúa entre tu servidor web e internet, sirviendo copias cacheadas de las páginas sin tocar jamás PHP ni MySQL. Cuando un visitante solicita una página que Varnish tiene en caché, la respuesta llega directamente desde la memoria en microsegundos. PHP nunca se ejecuta. MySQL nunca recibe una consulta. El servidor web apenas nota que la solicitud ha ocurrido.

Esto es fundamentalmente diferente de cómo funcionan los módulos de full page cache (FPC) basados en PHP en PrestaShop. Un módulo FPC sigue ejecutándose dentro de PHP. La solicitud llega a Apache o Nginx, PHP se inicia, PrestaShop se inicializa (cargando la configuración, estableciendo conexiones a la base de datos, analizando las rutas), y luego el módulo FPC intercepta la solicitud antes de que se ejecute la lógica completa del controlador, sirviendo un archivo HTML cacheado. Aunque esto es significativamente más rápido que renderizar la página desde cero, aún implica iniciar PHP y cargar el framework de PrestaShop. Esa sobrecarga, típicamente de 50-200 milisegundos incluso para un acierto de caché, se acumula bajo carga.

Varnish elimina completamente esa sobrecarga. Un acierto de caché de Varnish se sirve en 1-5 milisegundos. Con tráfico elevado, la diferencia es dramática. Una tienda PrestaShop que lucha por manejar 100 usuarios simultáneos con un módulo FPC puede servir miles de usuarios simultáneos con Varnish, porque la gran mayoría de las solicitudes nunca llegan al backend PHP.

Cuándo los módulos PHP Full Page Cache son suficientes

Antes de invertir en Varnish, vale la pena entender cuándo un módulo FPC basado en PHP es suficientemente bueno. Para muchas tiendas PrestaShop, lo es.

Si tu tienda recibe menos de 50.000 páginas vistas diarias, un módulo FPC bien configurado manejará la carga sin problemas. La complejidad adicional de Varnish no está justificada cuando tu servidor tiene capacidad de reserva. Si los tiempos de respuesta del servidor con FPC son consistentemente inferiores a 200 milisegundos, tus visitantes ya están obteniendo cargas de página rápidas. El cuello de botella en ese punto es probablemente el renderizado frontend (CSS, JavaScript, imágenes) en lugar del tiempo de respuesta del servidor.

Los módulos FPC manejan algunos escenarios específicos de PrestaShop con más elegancia que Varnish porque se ejecutan dentro de la aplicación. Pueden verificar si un usuario está conectado, si el carrito tiene artículos y si cierto contenido dinámico necesita personalización — todo dentro del mismo proceso PHP. Con Varnish, estas comprobaciones deben manejarse mediante la inspección de cookies y reglas de variación de caché, lo que añade complejidad a la configuración.

Considera Varnish cuando tu tienda maneja regularmente picos de tráfico (ventas flash, campañas de marketing, picos estacionales) que sobrecargan tu capacidad PHP, cuando necesitas tiempos de respuesta inferiores a 10 ms por razones de SEO o experiencia de usuario, cuando tu presupuesto de hosting es limitado y necesitas servir más tráfico con el mismo hardware, o cuando tu tienda sirve una alta proporción de navegación anónima (páginas de categoría, páginas de producto) en relación con la actividad del carrito y el checkout.

Cómo funciona Varnish: El flujo de solicitudes

Comprender el flujo de solicitudes a través de Varnish es esencial para configurarlo correctamente con PrestaShop.

Llegada de la solicitud

Cuando un visitante solicita una página, la solicitud llega primero a Varnish (Varnish escucha en el puerto 80 o 443 si la terminación SSL es manejada por un proxy frontend). Varnish examina la solicitud: la URL, el método HTTP, las cookies y los encabezados.

Búsqueda en caché

Varnish comprueba su caché en busca de una respuesta almacenada que coincida con esta solicitud. La clave de caché se basa típicamente en la URL y encabezados seleccionados. Si existe una respuesta coincidente y no ha expirado, Varnish la sirve directamente. Esto es un acierto de caché (cache hit). La respuesta se envía al visitante y el servidor backend nunca es contactado.

Fallo de caché

Si no existe una respuesta cacheada coincidente, Varnish reenvía la solicitud al servidor backend (Apache o Nginx ejecutando PrestaShop). PrestaShop procesa la solicitud normalmente, genera la respuesta HTML y la envía de vuelta a Varnish. Varnish almacena la respuesta en su caché (si la respuesta es cacheable) y la reenvía al visitante. Las solicitudes posteriores de la misma página se servirán desde la caché.

Invalidación de caché

Cuando los datos del producto cambian, los precios se actualizan o el contenido se modifica, la versión en caché se vuelve obsoleta. Varnish necesita ser informado de descartar la versión antigua cacheada para que obtenga una nueva del backend. Esto es la invalidación de caché, y es la parte más difícil de cualquier sistema de caché para implementar correctamente.

Configuración VCL para PrestaShop

Varnish Configuration Language (VCL) es un lenguaje específico de dominio que controla cómo Varnish maneja las solicitudes. Una configuración VCL adecuada para PrestaShop debe manejar varios comportamientos específicos de PrestaShop.

Definición del backend

La definición del backend le indica a Varnish dónde reenviar los fallos de caché. Para una configuración típica de PrestaShop donde Apache o Nginx se ejecuta en el mismo servidor en el puerto 8080:

backend default { .host = "127.0.0.1"; .port = "8080"; .connect_timeout = 5s; .first_byte_timeout = 60s; .between_bytes_timeout = 10s; }

Los timeouts son importantes. Las páginas de PrestaShop pueden tardar varios segundos en generarse con caché fría, especialmente las páginas de categoría con muchos productos. Configurar first_byte_timeout demasiado bajo hace que Varnish devuelva un error 503 antes de que PrestaShop termine de generar la página.

Manejo de cookies y sesiones

Las cookies son el mayor desafío al hacer caché de PrestaShop con Varnish. PrestaShop establece varias cookies por defecto, y Varnish trata cualquier solicitud con cookies como no cacheable a menos que se le indique lo contrario. Si no manejas las cookies en tu VCL, Varnish no cacheará prácticamente nada.

PrestaShop establece estas cookies en la mayoría de las solicitudes: la cookie de sesión (típicamente llamada PrestaShop-xxxx), las cookies relacionadas con el carrito, las cookies de Google Analytics (_ga, _gid, _gat) y varias cookies de seguimiento de herramientas de marketing. De estas, solo la cookie de sesión de PrestaShop importa para el comportamiento de la caché. Las cookies de analytics y seguimiento deben eliminarse de la solicitud antes de la búsqueda en caché para que no impidan el caching.

En tu subrutina VCL vcl_recv, elimina las cookies no esenciales:

sub vcl_recv { # Eliminar cookies de Google Analytics y otros rastreadores set req.http.Cookie = regsuball(req.http.Cookie, "(^|;\s*)(_ga|_gid|_gat|__utm[a-z]+|_fbp|_gcl_[a-z]+)=[^;]*", ""); # Eliminar encabezado de cookie vacío if (req.http.Cookie ~ "^\s*$") { unset req.http.Cookie; } }

Decidir qué cachear

No todas las páginas de PrestaShop deben cachearse. El VCL debe distinguir entre solicitudes cacheables y no cacheables.

Cachear siempre: Páginas de producto para visitantes anónimos, páginas de listado de categorías, páginas CMS (acerca de, términos, contacto), la página de inicio, páginas de fabricantes y proveedores, páginas del mapa del sitio.

Nunca cachear: La página del carrito, las páginas de checkout (todos los pasos), el área de cuenta del cliente (pedidos, direcciones, información personal), las páginas de login y registro, cualquier página para un cliente conectado, solicitudes POST, solicitudes AJAX que modifican el estado (añadir al carrito, actualizar cantidad).

La lógica VCL para esto típicamente comprueba la ruta de la URL y la presencia de cookies de sesión:

sub vcl_recv { # No cachear solicitudes POST if (req.method == "POST") { return (pass); } # No cachear área de administración if (req.url ~ "^/admin") { return (pass); } # No cachear checkout y carrito if (req.url ~ "(cart|order|login|my-account|module/)" ) { return (pass); } # No cachear si el cliente tiene artículos en el carrito if (req.http.Cookie ~ "PrestaShop-") { return (pass); } return (hash); }

Establecer la duración de la caché

En la subrutina vcl_backend_response, controlas cuánto tiempo Varnish cachea cada respuesta. PrestaShop envía encabezados Cache-Control que típicamente dicen no-cache o private porque asume que cada respuesta puede contener contenido personalizado. Necesitas sobrescribirlos para las páginas que sabes que son seguras para cachear:

sub vcl_backend_response { # Cachear páginas de producto y categoría por 1 hora if (bereq.url ~ "^/([0-9]+-|[a-z]+-[0-9]+)") { set beresp.ttl = 1h; unset beresp.http.Set-Cookie; } # Cachear activos estáticos por 1 día if (bereq.url ~ "\.(css|js|jpg|jpeg|png|gif|ico|svg|woff|woff2|ttf)$") { set beresp.ttl = 1d; unset beresp.http.Set-Cookie; } }

Eliminar Set-Cookie de las respuestas cacheadas es crítico. Si una respuesta cacheada incluye un encabezado Set-Cookie, Varnish no la cacheará por defecto, e incluso si se le obliga a cachear, establecería la misma cookie de sesión para cada visitante, causando secuestro de sesión (session hijacking).

Invalidación de caché con solicitudes PURGE

Cuando el precio de un producto cambia, se añade un nuevo producto o se actualiza el contenido, la versión cacheada debe invalidarse. Varnish soporta solicitudes PURGE: un método HTTP especial que le indica a Varnish que elimine una URL específica de su caché.

Configurar el soporte PURGE

Añade el manejo de PURGE a tu VCL:

acl purge { "127.0.0.1"; "localhost"; } sub vcl_recv { if (req.method == "PURGE") { if (!client.ip ~ purge) { return (synth(405, "Not allowed.")); } return (purge); } }

La ACL restringe las solicitudes PURGE a localhost, impidiendo que usuarios externos vacíen tu caché.

Disparar purgas desde PrestaShop

PrestaShop no envía nativamente solicitudes PURGE. Necesitas un módulo o hook personalizado que detecte cuándo cambia el contenido cacheable y envíe una solicitud PURGE a Varnish. El módulo se engancha a eventos de PrestaShop como actionProductUpdate, actionCategoryUpdate y actionCMSPageUpdate. Cuando estos eventos se disparan, el módulo envía una solicitud HTTP PURGE a la URL correspondiente en el servidor Varnish.

Para una actualización de producto, el módulo purgaría la URL del producto, las URLs de las categorías a las que pertenece el producto (porque las páginas de listado de categorías muestran precios y disponibilidad de productos) y potencialmente la página de inicio si muestra productos destacados. Esta cascada de purgas es necesaria para evitar que datos obsoletos aparezcan en cualquier parte del sitio.

Invalidación basada en BAN

Para escenarios donde muchas URLs necesitan purgarse a la vez (una actualización de precios a nivel de sitio, un cambio de diseño, un nuevo banner promocional), las solicitudes PURGE individuales son impracticables. Varnish soporta bans, que son reglas de invalidación basadas en patrones. Un ban le indica a Varnish que descarte cualquier objeto cacheado que coincida con un patrón:

sub vcl_recv { if (req.method == "BAN") { if (!client.ip ~ purge) { return (synth(405, "Not allowed.")); } ban("req.url ~ " + req.http.X-Ban-Pattern); return (synth(200, "Banned.")); } }

Enviar una solicitud BAN con el encabezado X-Ban-Pattern: /category/ invalidaría todas las páginas de categoría cacheadas en una sola operación.

Edge Side Includes (ESI) para bloques dinámicos

Muchas páginas de PrestaShop contienen una mezcla de contenido estático y dinámico. El listado de productos en una página de categoría es el mismo para cada visitante, pero el encabezado que muestra el contador del carrito es personalizado. Sin ESI, no puedes cachear la página en absoluto porque el encabezado dinámico hace que toda la respuesta sea específica del visitante.

Los Edge Side Includes resuelven esto permitiéndote marcar secciones de la página como fragmentos recuperados por separado. Varnish ensambla la página final a partir de fragmentos cacheados y no cacheados.

Cómo funciona ESI

En tu plantilla Smarty, en lugar de renderizar el widget del carrito directamente, incluyes una etiqueta ESI:

<esi:include src="/module/cartwidget/ajax" />

Cuando Varnish procesa la página cacheada, encuentra la etiqueta ESI y realiza una solicitud separada al backend para ese fragmento. El cuerpo principal de la página se sirve desde la caché, mientras que el widget del carrito se obtiene fresco de PrestaShop. La respuesta ensamblada incluye tanto el cuerpo cacheado como el widget del carrito actualizado.

Habilita el procesamiento ESI en tu VCL:

sub vcl_backend_response { set beresp.do_esi = true; }

Consideraciones ESI para PrestaShop

Implementar ESI requiere modificar tus plantillas de PrestaShop para separar el contenido dinámico en fragmentos compatibles con ESI. Cada fragmento necesita su propio endpoint URL que devuelva solo el HTML para ese bloque. Los fragmentos que típicamente son dinámicos y necesitan tratamiento ESI incluyen el widget resumen del carrito (conteo de artículos, total), el saludo al cliente ("Hola, Juan"), cualquier recomendación personalizada de productos, el enlace de login/logout y los productos vistos recientemente.

El esfuerzo requerido para implementar ESI correctamente es significativo. Cada fragmento dinámico necesita un controlador dedicado, las plantillas requieren reestructuración y las reglas de caching para cada fragmento necesitan ajuste individual. Esta es una de las razones por las que Varnish se considera una optimización avanzada — funciona mejor cuando la aplicación está diseñada teniéndolo en cuenta.

Comprobaciones de salud del backend

Varnish puede monitorear la salud de tu servidor backend y actuar cuando se vuelve no disponible. Esto se configura en la definición del backend:

backend default { .host = "127.0.0.1"; .port = "8080"; .probe = { .url = "/ping.php"; .timeout = 2s; .interval = 5s; .window = 5; .threshold = 3; } }

Varnish envía una solicitud a /ping.php cada 5 segundos. Si 3 de las últimas 5 comprobaciones fallan, Varnish marca el backend como enfermo. Mientras el backend está enfermo, Varnish puede servir contenido cacheado obsoleto (modo grace) en lugar de devolver errores a los visitantes. Esto significa que tu tienda permanece parcialmente disponible incluso cuando el backend PHP se cae o se reinicia.

La configuración del modo grace determina cuánto tiempo Varnish servirá contenido obsoleto:

sub vcl_backend_response { set beresp.grace = 6h; }

Con un grace de 6 horas, si tu backend cae, los visitantes verán páginas cacheadas (aunque tengan hasta 6 horas de antigüedad) en lugar de páginas de error. Los precios de los productos podrían estar ligeramente desactualizados, pero la tienda sigue funcional mientras solucionas el problema del backend.

Benchmarks de rendimiento

La diferencia de rendimiento entre sin caché, PHP FPC y Varnish es sustancial y medible.

Sin caché (PrestaShop puro): Una página de producto típica de PrestaShop tarda 200-800 milisegundos en generarse, dependiendo del hardware del servidor, el número de módulos cargados y la cantidad de consultas a la base de datos. Bajo carga, los tiempos de respuesta aumentan porque los workers PHP están saturados. Un solo servidor puede manejar 20-50 usuarios simultáneos antes de que los tiempos de respuesta se vuelvan inaceptables.

Módulo PHP FPC: Los aciertos de caché se sirven en 30-100 milisegundos porque PHP aún se inicia y el framework se inicializa parcialmente. Bajo carga, el rendimiento es mucho mejor porque las respuestas cacheadas requieren un tiempo de procesamiento PHP mínimo. Un solo servidor puede manejar 200-500 usuarios simultáneos dependiendo de la configuración. Los fallos de caché aún toman el tiempo completo de renderizado.

Varnish: Los aciertos de caché se sirven en 1-5 milisegundos. Bajo carga, Varnish mismo puede manejar miles de conexiones simultáneas porque está escrito en C y diseñado específicamente para este tipo de carga de trabajo. El servidor backend solo maneja los fallos de caché, que son una pequeña fracción del tráfico total en un sistema correctamente configurado. El mismo hardware que lucha con 50 usuarios simultáneos sin caché puede manejar 5.000 o más con Varnish.

Estos números ilustran por qué Varnish vale la complejidad de configuración para tiendas de alto tráfico. La mejora de rendimiento no es incremental — es de un orden de magnitud.

Requisitos de hosting

Varnish tiene requisitos de hosting específicos que no todos los entornos de hosting PrestaShop pueden satisfacer.

Acceso al servidor

Necesitas acceso root para instalar y configurar Varnish. Los planes de hosting compartido no soportan Varnish porque requiere su propio proceso escuchando en un puerto e interceptando todo el tráfico HTTP. Necesitas un VPS, servidor dedicado o instancia en la nube donde controles la pila completa del servidor.

Memoria

Varnish almacena su caché en RAM. La cantidad de RAM que necesitas depende del número de páginas únicas en tu catálogo y el tamaño de cada respuesta cacheada. Una fórmula aproximada: el número de páginas cacheables multiplicado por el tamaño promedio de página te da el tamaño mínimo de caché. Una tienda con 5.000 productos, 200 categorías y un tamaño promedio de página de 50KB necesita aproximadamente 260MB de caché RAM. Añade la sobrecarga para Varnish mismo y deberías asignar al menos 512MB. Para catálogos más grandes, 1-2GB es lo habitual.

Configuración de puertos

En una configuración estándar, Varnish escucha en el puerto 80 (el puerto HTTP por defecto) y reenvía los fallos de caché al servidor web en un puerto diferente (comúnmente 8080). Esto significa que necesitas reconfigurar Apache o Nginx para escuchar en el puerto 8080 en lugar del 80. Si usas HTTPS (y deberías), típicamente colocas Nginx delante de Varnish para manejar la terminación SSL: Nginx en el puerto 443 termina SSL y reenvía a Varnish en el puerto 80, que reenvía los fallos de caché a Apache o PHP-FPM en el puerto 8080.

Ejemplo de configuración Docker

Ejecutar Varnish en Docker junto a un contenedor PrestaShop es una forma limpia de añadir Varnish a una configuración existente sin modificar el sistema host.

Configuración Docker Compose

Una configuración básica de Docker Compose con Varnish, Nginx para SSL y PrestaShop:

services: varnish: image: varnish:7.4 ports: - "80:80" volumes: - ./varnish/default.vcl:/etc/varnish/default.vcl:ro environment: - VARNISH_SIZE=512m depends_on: - prestashop prestashop: image: prestashop/prestashop:8 expose: - "80" environment: - DB_SERVER=db db: image: mysql:8.0 environment: - MYSQL_ROOT_PASSWORD=secretpassword - MYSQL_DATABASE=prestashop

En esta configuración, Varnish es el punto de entrada en el puerto 80. El contenedor PrestaShop no expone su puerto al host, solo a la red Docker. El host del backend VCL sería prestashop (el nombre del servicio Docker) en el puerto 80.

VCL para Docker

La definición del backend VCL para Docker usa el nombre del servicio en lugar de localhost:

backend default { .host = "prestashop"; .port = "80"; }

El DNS interno de Docker resuelve el nombre del servicio a la IP del contenedor. El resto de la configuración VCL permanece igual que en una configuración sin Docker.

Almacenamiento de caché en Docker

Por defecto, la imagen Docker de Varnish usa almacenamiento en memoria (malloc), que es ideal para el rendimiento. La variable de entorno VARNISH_SIZE controla cuánta memoria Varnish asigna para su caché. Establece este valor en uno que quepa dentro de los límites de memoria de tu contenedor dejando espacio para el propio proceso Varnish.

Para una caché persistente que sobreviva a los reinicios del contenedor, puedes usar almacenamiento basado en archivos montando un volumen, pero esto rara vez es necesario. La caché se calienta rápidamente (en minutos de recibir tráfico) y el almacenamiento basado en archivos es más lento que el almacenamiento en memoria.

Monitorización del rendimiento de Varnish

Varnish proporciona herramientas integradas para monitorizar el rendimiento de la caché.

El comando varnishstat muestra estadísticas en tiempo real incluyendo la tasa de aciertos de caché, conexiones al backend y uso de memoria. La métrica más importante es la tasa de aciertos, que debería ser del 85% o superior para una configuración bien ajustada. Si tu tasa de aciertos está por debajo del 70%, revisa tus reglas VCL porque demasiadas solicitudes están pasando al backend.

El comando varnishlog muestra logs detallados por solicitud, que son invaluables para depurar por qué solicitudes específicas no se están cacheando. Puedes filtrar por patrón de URL, código de respuesta o estado de acierto/fallo de caché.

El comando varnishtop muestra una lista clasificada de las entradas de log más frecuentes, ayudándote a identificar patrones en los fallos de caché o errores.

Errores comunes

Olvidar eliminar cookies

La mala configuración de Varnish más común con PrestaShop es no eliminar las cookies de analytics y seguimiento. Estas cookies están presentes en prácticamente cada solicitud y hacen que cada solicitud sea única desde la perspectiva de Varnish, resultando en una tasa de aciertos del 0%. Elimina siempre las cookies que no necesitas para la variación de caché.

Cachear contenido personalizado

Si tu VCL es demasiado agresivo, cacheará páginas que contienen contenido personalizado (saludo del usuario conectado, contenido del carrito) y las servirá a otros visitantes. Esto causa serios problemas de usabilidad y potenciales problemas de privacidad. Pasa siempre las solicitudes que contienen cookies de sesión al backend.

No invalidar al cambiar contenido

Sin un mecanismo de purga adecuado, los cambios de contenido en el back office no serán visibles hasta que las páginas cacheadas expiren naturalmente. Para una tienda con cambios activos de inventario, esto significa que los visitantes podrían ver productos agotados, precios incorrectos o descripciones desactualizadas. Implementa soporte PURGE o BAN e intégralo con los hooks de actualización de PrestaShop.

Ignorar HTTPS

Varnish no maneja SSL de forma nativa. Debes colocar un proxy de terminación SSL (Nginx, HAProxy o un balanceador de carga en la nube) delante de Varnish. No planificar esto en tu arquitectura conduce a problemas de contenido mixto (mixed content), bucles de redirección o la imposibilidad de servir tráfico HTTPS en absoluto.

¿Es Varnish adecuado para tu tienda?

Varnish es una herramienta poderosa, pero no es la elección correcta para cada tienda PrestaShop. Añade complejidad operativa: otro servicio que monitorizar, otro lenguaje de configuración que aprender, otra capa en tu proceso de depuración. Los beneficios son claros y medibles para las tiendas que los necesitan, pero vienen con un coste en tiempo de configuración, mantenimiento y dificultad de resolución de problemas.

Si tu tienda sirve menos de 50.000 páginas vistas al día y tu servidor maneja la carga cómodamente con un módulo FPC, Varnish es complejidad innecesaria. Si tu tienda enfrenta regularmente picos de tráfico que sobrecargan tu servidor, sirve un alto volumen de tráfico de navegación anónima o necesita los tiempos de respuesta más rápidos posibles para SEO o experiencia de usuario, Varnish proporciona un nivel de rendimiento que ninguna solución de caching basada en PHP puede igualar.

Comienza con una optimización adecuada de PrestaShop (optimización de consultas, auditoría de módulos, PHP OPcache, optimización de imágenes) y un módulo FPC. Si esas optimizaciones no son suficientes, Varnish es el siguiente paso en la escalera de escalado del rendimiento.

Leer respuesta completa

Cómo PrestaShop gestiona las imágenes de productos

Cada imagen subida a PrestaShop pasa por un pipeline de procesamiento. Cuando añades una imagen de producto, el sistema almacena el archivo original y luego genera múltiples versiones redimensionadas llamadas miniaturas (thumbnails). Cada miniatura corresponde a un tipo de imagen definido en el back office bajo Diseño > Ajustes de imágenes. Estos tipos de imagen especifican dimensiones exactas en píxeles y están vinculados a contextos específicos: listados de productos, páginas de producto, vistas previas del carrito, cabeceras de categorías, logotipos de fabricantes y más.

PrestaShop almacena las imágenes en el directorio /img/. En PrestaShop 1.7 y 8.x, las imágenes de productos están organizadas usando una estructura de directorios basada en el ID de la imagen. Por ejemplo, una imagen con ID 1234 se almacena en /img/p/1/2/3/4/. Dentro de ese directorio encontrarás la imagen original (nombrada por ID, como 1234.jpg) y todas las miniaturas generadas (como 1234-home_default.jpg, 1234-large_default.jpg, 1234-small_default.jpg).

La convención de nombres sigue el patrón: {image_id}-{image_type_name}.{extension}. Esto significa que cada tipo de imagen que definas crea un archivo adicional por cada imagen de producto en tu catálogo. Una tienda con 5.000 imágenes de producto y 8 tipos de imagen tendrá aproximadamente 45.000 archivos de imagen (5.000 originales más 5.000 por 8 miniaturas). Esta escala importa cuando necesitas regenerarlas.

Comprender los tipos de imagen

Los tipos de imagen están definidos en la tabla de base de datos ps_image_type y se gestionan a través del back office. Cada tipo de imagen tiene un nombre, ancho, alto y flags que indican a qué tipos de entidad se aplica (productos, categorías, fabricantes, proveedores, tiendas). La instalación predeterminada de PrestaShop incluye varios tipos de imagen:

cart_default es típicamente de 125x125 píxeles, usado en el carrito y el mini carrito. small_default es de unos 98x98 píxeles, usado en listados de productos en algunos temas. medium_default es de unos 452x452 píxeles, usado para las miniaturas de productos en la página de producto. home_default es de unos 250x250 píxeles, usado en la página de inicio y listados de categorías. large_default es de unos 800x800 píxeles, usado como la imagen principal del producto en la página de producto.

Los temas pueden definir sus propios requisitos de tipos de imagen. Cuando instalas un nuevo tema, típicamente registra sus tipos de imagen preferidos durante la instalación. El punto crítico es que los archivos de imagen reales en disco deben coincidir con lo que el tema espera. Si el tema requiere home_default a 340x340 pero tus archivos de imagen fueron generados a 250x250 porque usabas un tema diferente anteriormente, cada listado de productos mostrará imágenes con dimensiones incorrectas.

Cuándo es necesaria la regeneración de imágenes

Varias situaciones requieren una regeneración total o parcial de miniaturas. Comprender cuándo es verdaderamente necesaria te ahorra ejecutar un proceso que puede tomar horas en catálogos grandes.

Cambio de tema

Esta es la razón más común. Diferentes temas requieren diferentes dimensiones de imagen. Cuando cambias de un tema a otro, las plantillas del nuevo tema hacen referencia a tipos de imagen con dimensiones específicas. Si esas dimensiones no coinciden con los archivos de miniatura existentes, las imágenes aparecen estiradas, recortadas incorrectamente o borrosas. Después de instalar un nuevo tema, siempre verifica sus requisitos de tipos de imagen y regenera las miniaturas para que coincidan.

Cambios en las dimensiones del tipo de imagen

Si modificas el ancho o alto de un tipo de imagen existente a través de Diseño > Ajustes de imágenes, el cambio solo afecta la definición en la base de datos. Todos los archivos de miniatura existentes en disco conservan sus dimensiones antiguas. Debes regenerar las miniaturas para el tipo de imagen modificado para aplicar las nuevas dimensiones a las imágenes existentes.

Añadir un nuevo tipo de imagen

Cuando creas un nuevo tipo de imagen, aún no existen archivos de miniatura para él. Si una plantilla hace referencia a este nuevo tipo de imagen, mostrará enlaces de imagen rotos hasta que regeneres. El proceso de regeneración crea los archivos de miniatura faltantes para cada imagen existente.

Problemas de calidad de imagen

Si cambias la configuración de calidad de compresión JPEG en PrestaShop (que se encuentra en Rendimiento > Ajustes de imágenes o la sección de configuración de imágenes dependiendo de tu versión), las miniaturas existentes fueron generadas con la configuración de calidad anterior. La regeneración aplica el nuevo nivel de calidad a todas las miniaturas.

Después de una migración o cambio de servidor

A veces durante la migración, los archivos de miniatura se pierden o corrompen mientras las imágenes originales sobreviven. Si las imágenes de productos aparecen rotas pero los originales existen en los directorios esperados, la regeneración recrea todas las miniaturas a partir de los originales.

Habilitar el formato WebP

PrestaShop 8.x introdujo soporte WebP para imágenes de productos. Cuando habilitas la generación WebP, las imágenes existentes no obtienen automáticamente variantes WebP. Debes regenerar las miniaturas para crear las versiones .webp junto a los archivos JPEG o PNG existentes.

Regeneración a través del panel de administración

PrestaShop proporciona una herramienta de regeneración integrada en el back office bajo Diseño > Ajustes de imágenes (o Preferencias > Imágenes en versiones anteriores). En la parte inferior de la página encontrarás la sección de regeneración.

Opciones disponibles

Puedes elegir borrar las imágenes anteriores antes de regenerar. Cuando está habilitado, PrestaShop elimina todas las miniaturas existentes antes de crear nuevas. Esto es útil cuando quieres eliminar miniaturas para tipos de imagen que ya no existen, pero significa que todas las imágenes estarán no disponibles durante el proceso de regeneración. Cuando está deshabilitado, PrestaShop sobrescribe las miniaturas existentes y crea las faltantes sin eliminar nada primero.

Puedes seleccionar qué tipos de entidad regenerar: productos, categorías, fabricantes, proveedores o tiendas. Si solo cambiaste las dimensiones de imágenes de productos, no hay necesidad de regenerar imágenes de categorías o fabricantes.

Limitaciones del enfoque del panel de administración

La regeneración del panel de administración se ejecuta como una solicitud web. Esto crea varios problemas para catálogos grandes. Los servidores web tienen límites de tiempo de ejecución, típicamente de 30 a 300 segundos dependiendo de tu configuración. Una tienda con 10.000 imágenes de producto y 8 tipos de imagen necesita generar 80.000 archivos de miniatura. Incluso a un ritmo generoso de 10 imágenes por segundo, eso toma más de dos horas. La mayoría de los servidores web terminarán el proceso mucho antes de que finalice.

Los límites de memoria también aplican. Cada imagen debe cargarse en memoria, redimensionarse usando GD o ImageMagick, y guardarse. Las imágenes originales de alta resolución pueden consumir de 20 a 50 MB de memoria cada una durante el procesamiento. El límite de memoria predeterminado de PHP de 128 MB o 256 MB puede agotarse rápidamente, especialmente al procesar imágenes en secuencia sin una limpieza de memoria adecuada.

Si el proceso es interrumpido por un timeout o error de memoria, terminas con un catálogo parcialmente regenerado. Algunos productos tienen nuevas miniaturas, otros tienen las antiguas y algunos podrían no tener ninguna. Este estado inconsistente es peor que el problema original.

Regeneración CLI para catálogos grandes

Para tiendas con más de unos pocos cientos de productos, la regeneración por línea de comandos es fuertemente recomendada. Evita los límites de timeout del servidor web y puede configurarse con límites de memoria más altos.

Uso de la consola PrestaShop

PrestaShop 1.7.5 y posteriores incluyen una consola Symfony. Puedes regenerar miniaturas usando:

php bin/console prestashop:image:regenerate

Este comando acepta varias opciones. Para regenerar solo tipos de imagen específicos, usa el flag --image-type seguido del nombre del tipo de imagen. Para procesar solo productos, categorías u otros tipos de entidad específicos, usa el flag --entity. El flag --format te permite especificar qué formatos de salida generar (jpg, png, webp).

Ejecuta el comando desde el directorio raíz de PrestaShop. Si usas Docker, ejecútalo dentro del contenedor:

docker exec -u www-data your-container php bin/console prestashop:image:regenerate

El flag -u www-data asegura que los archivos generados sean propiedad del usuario del servidor web. Ejecutar como root crea archivos que el servidor web no puede servir ni modificar posteriormente.

Configuración de memoria y tiempo

Para la ejecución CLI, puedes aumentar los límites de PHP directamente en el comando:

php -d memory_limit=512M -d max_execution_time=0 bin/console prestashop:image:regenerate

Establecer max_execution_time=0 elimina completamente el límite de tiempo, y 512 MB de memoria son suficientes para la mayoría de los catálogos. Para tiendas con originales de resolución extremadamente alta (4000x4000 píxeles o más), podrías necesitar 1 GB o más.

Enfoque de regeneración personalizado

Para catálogos muy grandes (50.000 o más imágenes), incluso el comando de consola puede ser lento o problemático. Un enfoque PHP personalizado te permite procesar imágenes en lotes con seguimiento de progreso, manejo de errores y la capacidad de reanudar después de una interrupción.

El enfoque consiste en consultar la base de datos para todos los registros de imagen, iterar a través de ellos en lotes de 100 o 200, generar miniaturas para cada imagen y registrar el progreso. Si el proceso se interrumpe, puedes reanudarlo desde donde se detuvo verificando qué miniaturas ya existen.

Un enfoque por lotes también permite distribuir la regeneración en múltiples ejecuciones durante las horas de menor tráfico, evitando el impacto en el rendimiento de la tienda activa.

Generación WebP durante la regeneración

WebP es un formato de imagen moderno que proporciona tamaños de archivo significativamente menores que JPEG a calidad comparable. PrestaShop 8.x puede generar versiones WebP de las miniaturas durante el proceso de regeneración.

Habilitar el soporte WebP

Antes de regenerar, habilita WebP en la configuración de PrestaShop. En PrestaShop 8.x, esta opción está en los ajustes de imágenes. Cuando está habilitada, el proceso de regeneración crea tanto la miniatura tradicional JPEG/PNG como una versión .webp para cada tipo de imagen.

Requisitos del servidor

La generación WebP requiere la extensión GD compilada con soporte WebP (--with-webp) o la extensión ImageMagick con delegados WebP. Puedes verificar el soporte GD con phpinfo() o gd_info(). Busca WebP Support en la salida. Si el soporte WebP falta, el proceso de regeneración silenciosamente omite la creación WebP sin producir errores.

Consideraciones de espacio en disco

Los archivos WebP son típicamente del 25 al 35 por ciento más pequeños que los archivos JPEG equivalentes, pero estás almacenando ambos formatos. Una tienda con 40.000 miniaturas JPEG que ocupan 2 GB de espacio en disco necesitará aproximadamente 3,4 GB en total después de la generación WebP (los 2 GB originales más aproximadamente 1,4 GB de archivos WebP). Planifica tu espacio en disco en consecuencia antes de iniciar una regeneración completa.

Servir WebP a los navegadores

Generar archivos WebP es solo la mitad de la solución. Tu tema y servidor deben estar configurados para servir WebP a los navegadores que lo soportan con fallback a JPEG/PNG para los que no. Esto se maneja típicamente a través de elementos <picture> en las plantillas del tema o mediante negociación de contenido del lado del servidor usando el encabezado Accept.

En Apache, puedes añadir reglas de reescritura que verifican el soporte WebP y sirven la versión WebP cuando está disponible. En Nginx, la directiva try_files puede verificar si existe una versión .webp de la imagen solicitada y servirla si el encabezado Accept del navegador incluye image/webp.

Impacto en el rendimiento y mitigación

La regeneración de imágenes es intensiva en CPU y pesada en E/S. En una tienda activa, puede degradar significativamente el rendimiento si no se gestiona cuidadosamente.

Impacto en la CPU

Cada operación de redimensionamiento de imagen requiere cargar el original en memoria, ejecutar el algoritmo de redimensionamiento, aplicar las configuraciones de calidad/compresión y escribir el resultado en disco. La operación de redimensionamiento en sí es computacionalmente costosa, especialmente para imágenes grandes que se reducen a miniaturas pequeñas. En un entorno de hosting compartido, esto puede saturar la CPU y ralentizar toda la tienda.

Impacto en E/S

La regeneración lee cada imagen original y escribe múltiples archivos de miniatura. En discos duros tradicionales, esto crea una carga de E/S significativa. En almacenamiento SSD, el impacto es mucho menor pero aún notable a escala. El patrón de E/S es particularmente hostil para los discos giratorios porque involucra lecturas aleatorias (originales dispersos por directorios) combinadas con escrituras secuenciales (miniaturas en los mismos directorios).

Ejecutar la regeneración en horas de bajo tráfico

Programa la regeneración para tu período de menor tráfico. Para tiendas europeas, esto es típicamente entre las 2:00 y las 6:00 de la madrugada. Para tiendas con tráfico global, puede que no haya un verdadero periodo de bajo tráfico, pero puedes identificar puntos relativamente bajos a partir de tus datos de analytics.

Uso de nice e ionice

En servidores Linux, puedes reducir la prioridad del proceso de regeneración para que no prive a otros procesos de recursos. El comando nice reduce la prioridad de CPU, e ionice reduce la prioridad de E/S:

nice -n 19 ionice -c 3 php bin/console prestashop:image:regenerate

Un valor nice de 19 es la prioridad más baja. La clase ionice 3 es la clase idle, lo que significa que el proceso solo obtiene tiempo de E/S cuando nada más lo necesita. Esto reduce drásticamente el impacto en la tienda activa pero hace que la regeneración tarde más.

Escalado temporal

Si estás en un servidor en la nube, considera escalar temporalmente tu servidor (más cores de CPU, más RAM, almacenamiento más rápido) durante la duración de la regeneración, y luego reducir. El costo extra de unas pocas horas de recursos de nivel superior es usualmente mínimo comparado con el impacto de una regeneración lenta de varios días en el rendimiento de tu tienda.

Evitar timeouts durante la regeneración

Los timeouts son el problema más común con la regeneración de imágenes. Aquí están las configuraciones específicas que los previenen.

Configuración PHP

La directiva max_execution_time limita cuánto tiempo puede ejecutarse un proceso PHP. Para la ejecución CLI, típicamente ya está establecida en 0 (ilimitado), pero verifica comprobando php -i | grep max_execution_time. Para la regeneración web a través del panel de administración, aumenta este valor en tu php.ini o .htaccess:

php_value max_execution_time 7200

También aumenta max_input_time si usas el panel de administración, ya que el timeout de envío del formulario es separado del timeout de ejecución:

php_value max_input_time 7200

Timeout del servidor web

La directiva Timeout de Apache y proxy_read_timeout / fastcgi_read_timeout de Nginx pueden terminar solicitudes de larga duración incluso si PHP mismo no ha superado el timeout. Para Apache: Timeout 7200. Para Nginx, añade a tu bloque server: fastcgi_read_timeout 7200; o proxy_read_timeout 7200;.

Configuración PHP-FPM

Si usas PHP-FPM (como la mayoría de las configuraciones modernas), el request_terminate_timeout en la configuración de tu pool también puede matar procesos de larga duración. Establécelo en 0 para deshabilitar el timeout, o iguálalo al tiempo máximo de ejecución deseado:

request_terminate_timeout = 7200

Timeouts de Cloudflare y CDN

Si tu tienda está detrás de Cloudflare u otro CDN, el CDN tiene su propio timeout de solicitudes (el plan gratuito de Cloudflare tiene un timeout de 100 segundos). Esto hace que la regeneración por panel de administración detrás de un CDN sea efectivamente imposible. Debes usar la regeneración CLI, evitar el CDN para el acceso de administración, o usar una solución que procese imágenes de forma asíncrona.

Estrategias de regeneración incremental

La regeneración completa procesa cada imagen en el catálogo. Para tiendas con decenas de miles de imágenes, esto puede tomar muchas horas. Los enfoques incrementales procesan solo las imágenes que realmente necesitan nuevas miniaturas.

Regeneración selectiva de tipo de imagen

Si solo añadiste o modificaste un tipo de imagen, no necesitas regenerar todos los tipos de imagen. Usa la opción --image-type en el comando de consola para apuntar solo al tipo de imagen específico que cambió. Esto reduce el trabajo a un octavo (o cualquier fracción de tus tipos de imagen totales) de una regeneración completa.

Procesamiento basado en fecha

Si necesitas regenerar miniaturas solo para productos añadidos recientemente (por ejemplo, después de corregir un problema de procesamiento de imágenes), puedes consultar la base de datos para imágenes añadidas después de una fecha específica y procesar solo esas. La tabla ps_image no tiene una columna de fecha por defecto, pero la tabla asociada ps_product tiene campos date_add y date_upd que pueden usarse para identificar productos modificados recientemente.

Detección de miniaturas faltantes

En lugar de regenerar todo, escanea los directorios de imágenes para encontrar imágenes a las que les faltan miniaturas específicas y regenera solo esas. Este es el enfoque más rápido cuando has añadido un nuevo tipo de imagen o cuando una regeneración parcial fue interrumpida.

La lógica es directa: para cada ID de imagen en la base de datos, verifica si el archivo de miniatura esperado existe en disco. Si no existe, regenera solo esa miniatura. Esto convierte una regeneración completa de varias horas en un proceso dirigido que podría tomar minutos.

Procesamiento paralelo

Para catálogos muy grandes, puedes dividir el rango de IDs de imagen en bloques y procesarlos en paralelo usando múltiples procesos PHP. Por ejemplo, un proceso maneja los IDs de imagen de 1 a 10000, otro maneja de 10001 a 20000, y así sucesivamente. Cada proceso funciona independientemente, y el throughput combinado es aproximadamente proporcional al número de procesos paralelos (limitado por los cores de CPU y el ancho de banda de E/S).

Ten cuidado con el procesamiento paralelo y la E/S de disco. Ejecutar demasiados procesos simultáneamente en un disco duro tradicional causará contención de E/S y realmente ralentizará las cosas. En almacenamiento SSD, de 4 a 8 procesos paralelos típicamente funcionan bien.

Consideraciones sobre el formato de imagen

PrestaShop soporta JPEG, PNG y GIF como formatos fuente, y puede generar miniaturas en estos formatos más WebP. El formato fuente afecta el comportamiento de la regeneración.

Imágenes JPEG

JPEG es el formato más común para fotos de productos. Soporta compresión con pérdida, lo que significa que cada vez que se guarda un JPEG, se pierde algo de calidad. Por eso regenerar miniaturas desde las subidas originales produce mejores resultados que regenerar desde miniaturas previamente redimensionadas. Siempre asegúrate de estar trabajando desde la imagen original subida, no desde una miniatura generada previamente.

Imágenes PNG

PNG soporta transparencia y compresión sin pérdida. Si tus imágenes de producto usan fondos transparentes, las miniaturas PNG preservan esa transparencia. Sin embargo, los archivos PNG son típicamente mucho más grandes que los archivos JPEG. Considera si realmente necesitas la transparencia. Si no, convertir las imágenes de producto PNG a JPEG durante la regeneración puede reducir significativamente el espacio en disco y mejorar los tiempos de carga de página.

Manejo de GIF

PrestaShop puede aceptar subidas GIF, pero las miniaturas generadas desde fuentes GIF son estáticas (la animación no se preserva). Si tienes imágenes de producto GIF animadas, ten en cuenta que la regeneración produce miniaturas estáticas del primer fotograma.

Verificación post-regeneración

Después de que la regeneración se complete, verifica los resultados antes de asumir que todo está correcto.

Verificación visual de la calidad de imágenes

Abre varias páginas de producto e inspecciona las imágenes visualmente. Verifica que las miniaturas sean nítidas, correctamente proporcionadas y no estén estiradas ni pixeladas. Presta especial atención a las imágenes que eran originalmente pequeñas (cercanas o menores que las dimensiones de la miniatura), ya que estas tienen más probabilidades de mostrar problemas de calidad al ser ampliadas.

Verificación del conteo de archivos

Compara el número de miniaturas generadas con las expectativas. Si tienes 5.000 imágenes de producto y 8 tipos de imagen, deberías tener aproximadamente 40.000 archivos de miniatura (más los originales y potencialmente las variantes WebP). Un conteo significativamente menor indica que el proceso de regeneración fue interrumpido o encontró errores en algunas imágenes.

Verificación de permisos de archivos

Verifica que los archivos regenerados sean propiedad del usuario del servidor web (típicamente www-data en Debian/Ubuntu o apache en CentOS). Si ejecutaste la regeneración como root, los archivos podrían no ser legibles por el servidor web, causando imágenes rotas en el frontend. Corrige con: chown -R www-data:www-data img/p/.

Limpieza de caché

Después de la regeneración, limpia todas las cachés. Esto incluye la caché interna de PrestaShop (Parámetros avanzados > Rendimiento), cualquier caché de opcode (OPcache) y cualquier caché CDN o proxy inverso. Las páginas cacheadas antiguas podrían seguir haciendo referencia a URLs o dimensiones de imagen antiguas. Si usas un módulo que genera sprites CSS o imágenes inline, regenéralos también.

Si tu tienda está detrás de Cloudflare, purga la caché para la ruta /img/ o haz una purga completa de caché. Cloudflare cachea imágenes agresivamente, y los visitantes podrían ver miniaturas antiguas hasta que la caché del CDN expire o sea purgada.

Resolución de problemas comunes de regeneración

Miniaturas negras o corrompidas

Esto generalmente indica un problema con la librería GD. La extensión GD podría no soportar el formato fuente (por ejemplo, GD compilado sin soporte JPEG). Verifica las capacidades de GD con gd_info(). Otra causa es memoria insuficiente: si PHP no puede asignar suficiente memoria para cargar la imagen original, GD podría producir una imagen negra en lugar de lanzar un error.

Dimensiones incorrectas en las miniaturas generadas

Si las miniaturas tienen dimensiones inesperadas, verifica las definiciones de tipos de imagen en la base de datos. El panel de administración podría mostrar un valor mientras la base de datos contiene otro (esto puede suceder después de una importación fallida o una modificación manual de la base de datos). Consulta directamente: SELECT * FROM ps_image_type WHERE name = 'home_default';

La regeneración se cuelga sin progreso

Un proceso de regeneración colgado generalmente significa que encontró una imagen muy grande que agotó la memoria disponible. Verifica el log de errores PHP buscando fallos de asignación de memoria. La solución es aumentar el límite de memoria o pre-procesar las imágenes fuente problemáticas para reducir su resolución antes de la regeneración.

Errores de permiso denegado

Si la regeneración reporta errores de permiso, el proceso PHP no puede escribir en los directorios de imágenes. Esto ocurre comúnmente en entornos Docker donde los volúmenes bind-mounted tienen diferente propiedad dentro y fuera del contenedor. Asegúrate de que el usuario que ejecuta el comando de regeneración tenga acceso de escritura al árbol completo del directorio /img/.

Resumen

La regeneración de imágenes es una tarea de mantenimiento que todo propietario de tienda PrestaShop encuentra, generalmente durante un cambio de tema o al optimizar los ajustes de imagen. Para catálogos pequeños (menos de 500 productos), la herramienta del panel de administración funciona adecuadamente. Para cualquier cosa mayor, la regeneración CLI es el único enfoque fiable. Los principios clave son: siempre trabaja desde las imágenes originales, haz coincidir las definiciones de tus tipos de imagen con los requisitos de tu tema, gestiona proactivamente los recursos del servidor y los timeouts, usa enfoques incrementales cuando sea posible y verifica los resultados después de que el proceso se complete. Con WebP convirtiéndose en el estándar para imágenes web, la regeneración también sirve como el mecanismo para crear variantes de formato moderno de todo tu catálogo de productos, ofreciendo tamaños de archivo más pequeños y cargas de página más rápidas a tus clientes.

Leer respuesta completa

Matriz de compatibilidad de versiones PHP para PrestaShop

Elegir la versión correcta de PHP para tu tienda PrestaShop es una de las decisiones de infraestructura más críticas que tomarás. Ejecutar una versión PHP incompatible puede causar pantallas en blanco, flujos de pago defectuosos, fallos en módulos y vulnerabilidades de seguridad. Esta guía completa cubre cada versión de PrestaShop desde 1.6 hasta 9.x y asocia cada una con sus versiones PHP compatibles, configuraciones recomendadas y consideraciones de actualización.

Por qué la versión PHP importa para PrestaShop

PHP es el lenguaje del lado del servidor que impulsa PrestaShop. Cada versión principal de PHP introduce mejoras de rendimiento, nuevas características del lenguaje y depreca funciones más antiguas. El código fuente de PrestaShop evoluciona en paralelo con PHP, lo que significa que las versiones más recientes de PrestaShop aprovechan las características modernas de PHP mientras abandonan el soporte para las obsoletas.

Usar la versión PHP incorrecta causa tres categorías de problemas:

Errores fatales - Las funciones eliminadas en versiones PHP más recientes (por ejemplo, las funciones mysql_* eliminadas en PHP 7.0, each() eliminada en PHP 8.0) causan fallos inmediatos.
Advertencias de deprecación - Las funciones deprecadas generan advertencias que pueden romper las respuestas AJAX, la salida JSON y la generación de PDF cuando display_errors está habilitado.
Exposición a riesgos de seguridad - Las versiones PHP que han llegado al final de su vida útil ya no reciben parches de seguridad, dejando tu tienda vulnerable.

Matriz de compatibilidad completa

PrestaShop 1.6.x

Versión PrestaShop	PHP 5.4	PHP 5.5	PHP 5.6	PHP 7.0	PHP 7.1	PHP 7.2+
1.6.0.x - 1.6.0.14	Sí	Sí	Sí	No	No	No
1.6.1.0 - 1.6.1.4	Sí	Sí	Sí	Parcial	No	No
1.6.1.5 - 1.6.1.23	Sí	Sí	Sí	Sí	Sí	No
1.6.1.24+	Sí	Sí	Sí	Sí	Sí	No

PHP recomendado para 1.6.x - PHP 7.1. Ofrece el mejor equilibrio entre rendimiento y compatibilidad. Ejecutar 1.6.x en PHP 7.2+ requiere modificaciones en archivos del núcleo que interrumpen la ruta de actualización y no es recomendable.

PrestaShop 1.7.x

Versión PrestaShop	PHP 7.1	PHP 7.2	PHP 7.3	PHP 7.4	PHP 8.0+
1.7.0.x - 1.7.4.x	Sí (recomendado)	No	No	No	No
1.7.5.x	Sí	Sí (recomendado)	No	No	No
1.7.6.x	Sí	Sí (recomendado)	Sí	No	No
1.7.7.x	Sí	Sí	Sí (recomendado)	Parcial	No
1.7.8.x	Sí	Sí	Sí	Sí (recomendado)	No

Advertencia crítica - Ninguna versión de PrestaShop 1.7 soporta PHP 8.0 o posterior. Si ejecutas PS 1.7.6 en PHP 8, Smarty se bloqueará inmediatamente porque el motor de plantillas utiliza funciones eliminadas en PHP 8.0. La eliminación de la función each() y los cambios en el funcionamiento de array_key_exists() con objetos causan errores fatales.

PrestaShop 8.x

Versión PrestaShop	PHP 7.2	PHP 7.3	PHP 7.4	PHP 8.0	PHP 8.1	PHP 8.2	PHP 8.3
8.0.0 - 8.0.2	Sí (mín)	Sí	Sí	Sí	Parcial	No	No
8.0.3 - 8.0.5	Sí (mín)	Sí	Sí	Sí	Sí (recomendado)	No	No
8.1.0 - 8.1.2	No	Sí (mín)	Sí	Sí	Sí (recomendado)	Parcial	No
8.1.3 - 8.1.7	No	Sí (mín)	Sí	Sí	Sí (recomendado)	Sí	Parcial

PHP recomendado para 8.x - PHP 8.1. Es el punto óptimo que ofrece compatibilidad completa, soporte de seguridad activo y excelente rendimiento con compilación JIT. PHP 8.1 trae fibers, enums, propiedades readonly y tipos intersection que PrestaShop 8 puede aprovechar.

PrestaShop 9.x

Versión PrestaShop	PHP 8.1	PHP 8.2	PHP 8.3	PHP 8.4
9.0.x	Sí (mín)	Sí	Sí (recomendado)	Sí

PHP recomendado para 9.x - PHP 8.3 o 8.4. PrestaShop 9 funciona con Symfony 6.4 LTS y requiere PHP 8.1 como mínimo. PHP 8.4 introduce Property Hooks y visibilidad asimétrica que futuras actualizaciones de PrestaShop aprovecharán.

Fechas de fin de vida de PHP que debes conocer

Versión PHP	Soporte activo hasta	Correcciones de seguridad hasta	Estado (2026)
PHP 7.4	Nov 2021	Nov 2022	EOL - Peligroso
PHP 8.0	Nov 2022	Nov 2023	EOL - Peligroso
PHP 8.1	Nov 2023	Dic 2025	EOL - Actualizar pronto
PHP 8.2	Dic 2024	Dic 2026	Solo seguridad
PHP 8.3	Dic 2025	Dic 2027	Solo seguridad
PHP 8.4	Dic 2026	Dic 2028	Soporte activo

Si en 2026 estás usando PHP 7.4 o 8.0, estás operando con una versión no soportada que ya no recibe parches de seguridad. Este es un riesgo crítico para cualquier tienda de comercio electrónico que maneja datos de pago.

Cómo verificar tu versión PHP actual

Método 1 - Back Office de PrestaShop

Navega a Parámetros avanzados > Información. La sección Información del servidor muestra tu versión PHP, junto con el límite de memoria, tiempo máximo de ejecución y otras configuraciones relevantes.

Método 2 - Archivo PHP Info

Crea un archivo llamado phpinfo.php en el directorio raíz de tu tienda con este contenido:

<?php phpinfo();

Accede a él a través de tu navegador en https://tutienda.com/phpinfo.php. Elimina este archivo inmediatamente después de verificar - expone detalles sensibles de configuración del servidor.

Método 3 - Línea de comandos

php -v
php -r "echo PHP_VERSION;"

Ten en cuenta que la versión PHP del CLI puede diferir de la versión PHP del servidor web. Verifica siempre a través de la interfaz web o phpinfo().

Problemas comunes con la versión PHP incorrecta

Pantalla blanca de la muerte (WSOD)

El síntoma más común de incompatibilidad PHP. Revisa tu log de errores PHP (normalmente en /var/log/php-errors.log o accesible a través de tu panel de hosting). Errores típicos:

Fatal error: Uncaught Error: Call to undefined function mysql_connect()
Fatal error: Uncaught Error: Call to undefined function each()
Fatal error: Cannot use "parent" when current class scope has no parent

Las advertencias de deprecación rompen AJAX

Cuando display_errors = On y actualizas PHP, los avisos de deprecación se anteponen a las respuestas AJAX. Esto rompe el parsing JSON en el back office, causando que funciones como la búsqueda de productos, búsqueda de clientes y creación de pedidos fallen silenciosamente. La solución:

; php.ini
display_errors = Off
log_errors = On
error_log = /ruta/hacia/php-error.log

Incompatibilidad de módulos

Los módulos de terceros pueden no soportar tu versión PHP. Antes de actualizar PHP, verifica la compatibilidad de cada módulo instalado. Áreas problemáticas comunes:

Módulos que usan create_function() - eliminada en PHP 8.0
Módulos que usan funciones mysql_* - eliminadas en PHP 7.0
Módulos que usan acceso posicional a cadenas con llaves $str{0} - eliminado en PHP 8.0
Módulos que no manejan tipos de retorno nullable - más estrictos desde PHP 8.1+

Cómo actualizar PHP para PrestaShop de forma segura

Paso 1 - Auditar tu configuración actual

Antes de cambiar nada, documenta tu entorno actual:

php -v                    # Versión PHP actual
php -m                    # Extensiones cargadas
php -i | grep memory      # Límite de memoria
php -i | grep max_exec    # Límite de tiempo de ejecución

Paso 2 - Verificar la compatibilidad de módulos

Revisa cada módulo instalado. Consulta la documentación del desarrollador del módulo sobre el soporte de versiones PHP. Si un módulo no se ha actualizado en más de dos años, es probable que sea incompatible con PHP 8.x.

Paso 3 - Probar primero en staging

Nunca actualices PHP en tu servidor de producción sin pruebas previas. Crea una copia staging de tu tienda y prueba con la nueva versión PHP. Verifica:

Las páginas del front office cargan correctamente
Páginas de producto, páginas de categoría, páginas CMS
El proceso de carrito y checkout se completa
Los módulos de pago procesan transacciones de prueba
La funcionalidad del back office funciona (edición de productos, gestión de pedidos)
Todos los módulos de terceros funcionan correctamente
Los cron jobs se ejecutan sin errores

Paso 4 - Actualización con plan de rollback

La mayoría de los proveedores de hosting permiten cambiar la versión PHP desde el panel de control (cPanel, Plesk, DirectAdmin). Mantén la versión PHP anterior disponible para un rollback rápido si surgen problemas.

Paso 5 - Limpiar todas las cachés después de la actualización

Después de cambiar la versión PHP, limpia cada capa de caché:

# Limpiar la caché de PrestaShop
rm -rf var/cache/prod/* var/cache/dev/*

# Limpiar las plantillas Smarty compiladas
rm -rf var/cache/smarty/compile/* var/cache/smarty/cache/*

# Si usas OPcache, reiniciar PHP-FPM
systemctl restart php8.3-fpm

# Limpiar la caché del CDN (Cloudflare, etc.)

Mejores prácticas de configuración PHP para PrestaShop

Independientemente de la versión PHP elegida, estas configuraciones son esenciales para un rendimiento óptimo de PrestaShop:

; Configuraciones php.ini recomendadas
memory_limit = 512M
max_execution_time = 300
max_input_vars = 10000
post_max_size = 32M
upload_max_filesize = 32M

; Configuraciones OPcache (críticas para el rendimiento)
opcache.enable = 1
opcache.memory_consumption = 256
opcache.interned_strings_buffer = 32
opcache.max_accelerated_files = 16229
opcache.revalidate_freq = 60
opcache.fast_shutdown = 1

; Extensiones requeridas
extension = intl
extension = zip
extension = gd
extension = curl
extension = mbstring
extension = openssl
extension = pdo_mysql
extension = fileinfo

Consideraciones para desarrolladores de módulos

Si desarrollas módulos de PrestaShop, debes considerar cuidadosamente la compatibilidad PHP:

Versión PHP mínima - Apunta a PHP 7.2 como mínimo para módulos que deben funcionar en PrestaShop 8.0+, o PHP 8.1 para módulos exclusivos de PrestaShop 9.
Usa PHPStan o Psalm - Las herramientas de análisis estático detectan incompatibilidades de versión PHP antes que tus usuarios.
Evita la sintaxis específica de versión - Características como las expresiones match (PHP 8.0), los enums (PHP 8.1) y las propiedades readonly (PHP 8.1) limitan tu módulo a esas versiones PHP y superiores.
Prueba en múltiples versiones - Usa contenedores Docker con diferentes versiones PHP para probar tu módulo en todo el rango de compatibilidad.

Preguntas frecuentes

¿Puedo ejecutar PrestaShop 1.7 en PHP 8?

No. Ninguna versión de PrestaShop 1.7 soporta oficialmente PHP 8.0 o posterior. Aunque algunos usuarios han aplicado parches para hacerlo funcionar parcialmente, esto no está soportado y causará problemas con las actualizaciones. El camino correcto es migrar a PrestaShop 8.x.

¿Debería usar PHP 8.4 con PrestaShop 8.1?

No recomendado. PrestaShop 8.1 fue desarrollado y probado principalmente con PHP 8.1. Aunque PHP 8.2 tiene soporte parcial en versiones 8.1.x posteriores, PHP 8.4 introduce cambios que pueden causar problemas con componentes Symfony más antiguos. Quédate con PHP 8.1 para PrestaShop 8.x.

¿Cuánto más rápido es PHP 8.x en comparación con 7.x?

Los benchmarks muestran que PHP 8.1 es aproximadamente 20-30% más rápido que PHP 7.4 para cargas de trabajo típicas de PrestaShop. El compilador JIT proporciona el mayor beneficio para tareas computacionales. Para operaciones vinculadas a E/S (consultas de base de datos, lectura de archivos), la mejora es menor pero aún medible.

¿Actualizar PHP requiere actualizar PrestaShop?

No necesariamente, pero ambos van de la mano. Puedes actualizar PHP dentro del rango soportado para tu versión de PrestaShop sin actualizar PrestaShop en sí. Sin embargo, si quieres usar una versión PHP moderna (8.3+), necesitarás PrestaShop 8.1 o 9.x.

Leer respuesta completa

Lazy Loading en 2026: que manejan los navegadores de forma nativa y que necesita un modulo

El lazy loading es una tecnica de optimizacion del rendimiento que aplaza la carga de recursos fuera de pantalla hasta que el usuario se desplaza cerca de ellos. En 2026, el soporte nativo de los navegadores para lazy loading ha madurado significativamente, pero todavia hay escenarios donde los propietarios de tiendas PrestaShop necesitan modulos adicionales o implementaciones personalizadas. Esta guia explica exactamente que manejan los navegadores por si solos, que brechas quedan y como implementar la mejor estrategia de lazy loading para tu tienda PrestaShop.

Que cubre el lazy loading nativo en 2026

El atributo HTML loading="lazy" ahora esta soportado por mas del 95% de los navegadores a nivel mundial. Esto incluye Chrome (desde v77), Firefox (desde v75), Safari (desde v15.4), Edge (desde v79) y todos los navegadores basados en Chromium.

Como funciona el lazy loading nativo

<img src="imagen-producto.jpg" 
     loading="lazy" 
     width="800" 
     height="600" 
     alt="Nombre del producto">

Que manejan los navegadores nativamente

Funcionalidad	Soporte nativo	Notas
Imagenes (`<img>`)	Si - todos los navegadores principales	Usa `loading="lazy"`
Iframes (`<iframe>`)	Si	Usa `loading="lazy"`
Imagenes responsivas (`<picture>`)	Si	`loading="lazy"` en el `<img>` interior

Que los navegadores NO manejan

Funcionalidad	Soporte nativo	Solucion necesaria
Imagenes de fondo CSS	No	API IntersectionObserver o modulo
Elementos de video	No	JavaScript personalizado o modulo
Efectos placeholder/blur-up	No	Libreria JavaScript o modulo
Contenido cargado dinamicamente/AJAX	No	Lazy loading basado en JavaScript

Implementar lazy loading nativo en PrestaShop

Para temas PrestaShop 8.x y 9.x

{* Antes - sin lazy loading *}
<img src="{$product.cover.bySize.home_default.url}" 
     alt="{$product.name}">

{* Despues - con lazy loading nativo *}
<img src="{$product.cover.bySize.home_default.url}" 
     loading="lazy" 
     width="{$product.cover.bySize.home_default.width}"
     height="{$product.cover.bySize.home_default.height}"
     alt="{$product.name}">

Regla critica: nunca apliques lazy loading a imagenes above-the-fold

El error mas comun del lazy loading es aplicarlo a imagenes visibles sin desplazamiento. Esto en realidad perjudica el rendimiento porque el navegador retrasa la carga del contenido que el usuario ve inmediatamente.

Imagenes que NO deben ser lazy loaded:

El logo de tu tienda
Imagenes hero/banner en la parte superior de la pagina
Las primeras 1-2 imagenes de producto en paginas de categoria

<img src="hero-banner.jpg" 
     loading="eager" 
     fetchpriority="high" 
     width="1200" 
     height="400" 
     alt="Banner promocion de verano">

Cuando necesitas un modulo: imagenes de fondo CSS

Los temas PrestaShop frecuentemente usan imagenes de fondo CSS para sliders, banners y cabeceras de categoria.

document.addEventListener('DOMContentLoaded', function() {
    const lazyBackgrounds = document.querySelectorAll('[data-bg]');
    const observer = new IntersectionObserver(function(entries) {
        entries.forEach(function(entry) {
            if (entry.isIntersecting) {
                entry.target.style.backgroundImage = 'url(' + entry.target.dataset.bg + ')';
                observer.unobserve(entry.target);
            }
        });
    }, { rootMargin: '200px 0px' });
    lazyBackgrounds.forEach(function(bg) { observer.observe(bg); });
});

Cuando necesitas un modulo: efectos placeholder

Efecto blur-up (LQIP) - Carga primero una version pequena y borrosa
Pantallas esqueleto - Bloques placeholder grises
Placeholders de color dominante - Usa el color dominante de la imagen como fondo

Impacto en rendimiento y Core Web Vitals

LCP - El lazy loading de imagenes above-the-fold PERJUDICA el LCP
CLS - Imagenes sin atributos width/height causan cambios de diseno
INP - Menos recursos cargandose simultaneamente mejoran la interactividad

<!-- MAL - causa cambio de diseno -->
<img src="producto.jpg" loading="lazy" alt="Producto">

<!-- BIEN - reserva espacio -->
<img src="producto.jpg" loading="lazy" 
     width="400" height="400" alt="Producto">

Recomendaciones especificas para PrestaShop

Paginas de listado de productos

Lazy loadear todas las imagenes de producto excepto la primera fila. Aplicar fetchpriority="high" a la primera fila.

Paginas de detalle de producto

La imagen principal debe cargarse eager con fetchpriority="high". Las miniaturas de la galeria pueden ser lazy loaded.

Resumen: Modulo vs. Nativo

Escenario	Solucion
Imagenes de producto estandar	Nativo `loading="lazy"` - sin modulo
Imagenes de fondo CSS	Modulo o JS con IntersectionObserver
Placeholders blur-up/LQIP	Modulo o libreria JS
Lazy loading de video	JS personalizado
Embeds YouTube/Vimeo	Nativo `loading="lazy"` en iframe
Imagenes contenido CMS	Modulo para auto-agregar atributo

Leer respuesta completa

Redirecciones .htaccess en PrestaShop: escribir reglas sin romper tu tienda

El archivo .htaccess es uno de los archivos mas poderosos y peligrosos en tu instalacion PrestaShop. Un solo caracter mal colocado puede dejar toda tu tienda fuera de linea. Pero dominar las redirecciones .htaccess es esencial para el SEO.

Como PrestaShop usa .htaccess

PrestaShop genera y gestiona automaticamente el archivo .htaccess. Cuando activas las URLs amigables en la configuracion SEO y URLs, PrestaShop escribe reglas de reescritura entre dos comentarios marcadores.

Regla critica - Nunca agregues tus redirecciones personalizadas dentro de este bloque. PrestaShop las sobreescribira en la proxima regeneracion. Coloca tus reglas ANTES del bloque PrestaShop.

Tipos de redirecciones

301 - Redireccion permanente

Usa cuando una pagina se ha movido permanentemente. Los motores de busqueda transfieren el valor SEO a la nueva URL.

302 - Redireccion temporal

Usa cuando una pagina esta temporalmente no disponible.

410 - Gone (Eliminado)

Usa cuando una pagina ha sido eliminada permanentemente sin reemplazo.

Sintaxis basica de redirecciones

Redirect 301 /pagina-antigua.html https://tutienda.com/pagina-nueva.html
Redirect 301 /producto-antiguo.html https://tutienda.com/es/producto-nuevo.html

Redirecciones basadas en patrones con RewriteRule

RewriteEngine On
RewriteRule ^carpeta-antigua/(.*)$ https://tutienda.com/carpeta-nueva/$1 [R=301,L]

Escenarios comunes de redireccion PrestaShop

Escenario 1 - Migracion desde otra plataforma

RewriteRule ^product/slug-antiguo/?$ https://tutienda.com/es/nueva-url.html [R=301,L]

Escenario 2 - Forzar HTTPS y WWW

RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

Reglas que pueden romper PrestaShop

Bucles de redireccion infinitos

El error mas peligroso. Siempre usa condiciones para prevenir bucles.

# PELIGROSO
RewriteRule ^(.*)$ https://tutienda.com/$1 [R=301,L]

# SEGURO
RewriteCond %{HTTP_HOST} !^www\.tutienda\.com$ [NC]
RewriteRule ^(.*)$ https://www.tutienda.com/$1 [R=301,L]

Romper el acceso al back office

# SEGURO - excluir admin y API
RewriteCond %{REQUEST_URI} !^/admin [NC]
RewriteCond %{REQUEST_URI} !^/api [NC]
RewriteRule ^(.*)$ https://tutienda.com/es/$1 [R=301,L]

Probar redirecciones de forma segura

cp .htaccess .htaccess.backup
curl -I -L https://tutienda.com/pagina-antigua.html

Donde colocar las reglas personalizadas

# TUS REDIRECCIONES AQUI (antes del bloque PrestaShop)
Redirect 301 /pagina-antigua.html https://tutienda.com/pagina-nueva.html

# ~~start~~ Bloque PrestaShop
# ... reglas auto-generadas ...
# ~~end~~ Bloque PrestaShop

Cuando usar un modulo

Considera un modulo de redirecciones cuando personal no tecnico necesite gestionar redirecciones, tengas cientos de redirecciones, o necesites deteccion automatica de 404.

Leer respuesta completa

Metodo	Protege contra	Costo
.htaccess	Scrapers conocidos	Gratis
fail2ban	Brute force	Gratis
Nginx	Peticiones excesivas	Gratis
CAPTCHA	Spam	Gratis
Cloudflare Free	Bots, DDoS	Gratis

Cómo funcionan las plantillas de correo electrónico de PrestaShop

PrestaShop envía correos electrónicos transaccionales en cada momento clave del recorrido del cliente: creación de cuenta, confirmación de pedido, notificación de envío, restablecimiento de contraseña y mucho más. Estos correos electrónicos se generan a partir de archivos de plantilla almacenados en su servidor y son completamente personalizables. Comprender cómo funciona el sistema de plantillas es el primer paso para crear correos electrónicos de confirmación de pedido profesionales y coherentes con la marca, que refuercen la identidad de su tienda.

Cada correo electrónico de PrestaShop consta de dos archivos de plantilla: una versión HTML para los clientes de correo que soportan formato enriquecido, y una versión de texto plano (TXT) para los clientes de correo que no lo soportan. Ambos archivos deben existir para que un correo electrónico se envíe correctamente. La versión HTML es la que verá la gran mayoría de sus clientes. La versión TXT sirve como alternativa y también es utilizada por herramientas de accesibilidad y algunos filtros de correo corporativo.

Las plantillas de correo electrónico se encuentran en la estructura de directorios mails/. La ubicación exacta depende de si está utilizando correos electrónicos del núcleo, correos electrónicos sobrescritos por el tema o correos electrónicos específicos de un módulo. Comprender esta jerarquía es esencial, ya que PrestaShop comprueba múltiples ubicaciones para cada plantilla y utiliza la primera que encuentra.

La estructura de directorios de las plantillas de correo electrónico

PrestaShop organiza las plantillas de correo electrónico en una jerarquía de directorios específica. Cuando necesita enviar un correo electrónico, el sistema busca en estas ubicaciones en orden de prioridad:

Sobrescrituras a nivel de tema (Prioridad más alta)

Las plantillas en /themes/su-tema/mails/es/ (donde es es el código ISO del idioma) tienen prioridad sobre todas las demás ubicaciones. Si desea personalizar una plantilla de correo electrónico sin modificar los archivos del núcleo, es aquí donde deben colocarse sus plantillas personalizadas. Este enfoque sobrevive a las actualizaciones de PrestaShop, ya que los archivos del tema no se sobrescriben durante las actualizaciones del núcleo.

Plantillas del núcleo (Predeterminadas)

Las plantillas predeterminadas se encuentran en /mails/es/ en el directorio raíz de su PrestaShop. Estas son las plantillas que se envían con PrestaShop y se utilizan cuando no existe ninguna sobrescritura del tema. Editar estos archivos directamente funciona, pero no se recomienda porque sus cambios se perderán cuando actualice PrestaShop.

Plantillas específicas de módulos

Los módulos que envían sus propios correos electrónicos almacenan las plantillas en /modules/nombre-modulo/mails/es/. Por ejemplo, los correos electrónicos de notificación de pedido enviados por los módulos de pago del núcleo se almacenan en sus respectivos directorios de módulos. Puede sobrescribirlos colocando copias modificadas en el directorio mails/ de su tema con el mismo nombre de archivo.

Subdirectorios de idiomas

Cada directorio mails/ contiene subdirectorios para cada idioma instalado, utilizando el código ISO del idioma: en para inglés, fr para francés, de para alemán, y así sucesivamente. Cuando PrestaShop envía un correo electrónico, utiliza la plantilla del directorio que coincide con la preferencia de idioma del cliente. Si una plantilla no existe en el idioma del cliente, PrestaShop recurre al idioma predeterminado.

Anatomía de una plantilla de confirmación de pedido

El correo electrónico de confirmación de pedido es el correo electrónico transaccional más importante que envía su tienda. Es el archivo denominado order_conf.html (y su compañero order_conf.txt) en su directorio mails. Examinemos su estructura en detalle.

Estructura de la plantilla HTML

Las plantillas de correo electrónico de PrestaShop son documentos HTML independientes. No utilizan archivos CSS externos porque la mayoría de los clientes de correo eliminan las hojas de estilo externas. Todo el estilo debe ser CSS en línea. Una plantilla típica de confirmación de pedido incluye estas secciones:

El documento comienza con un doctype HTML estándar y una sección head. El cuerpo contiene un diseño basado en tablas (porque los clientes de correo tienen un soporte deficiente para los métodos de diseño CSS modernos como flexbox y grid). Dentro de este diseño, encontrará una sección de encabezado con el logotipo de su tienda, el área de contenido principal con los detalles del pedido, una tabla de productos que lista cada artículo pedido, un resumen de precios con subtotales y totales, información de envío, detalles del método de pago y un pie de página con la información de contacto de la tienda y los avisos legales.

El sistema de variables

PrestaShop utiliza un sistema simple de sustitución de variables en las plantillas de correo electrónico. Las variables se encierran entre llaves: {nombre_variable}. Cuando se genera el correo electrónico, PrestaShop reemplaza cada variable con su valor real. La plantilla de confirmación de pedido utiliza estas variables clave:

{firstname} y {lastname} contienen el nombre del cliente. {order_name} es el número de referencia del pedido (como ABCDEF123). {shop_name} es el nombre de su tienda tal como está configurado en el back office. {shop_url} es la URL de su tienda. {shop_logo} es la ruta a la imagen del logotipo de su tienda. {date} es la fecha del pedido. {payment} es el método de pago utilizado. {total_paid} es el importe total pagado. {delivery_company} y {delivery_address} contienen la información del transportista y la dirección de envío.

Para la lista de productos, PrestaShop utiliza una sintaxis de bloque especial. La sección de artículos de productos está envuelta en un bucle que se repite para cada producto del pedido: {items} contiene el HTML preformateado para toda la tabla de la lista de productos, incluyendo nombres de productos, cantidades, precios y cualquier detalle de personalización.

Referencia de variables disponibles

Para ver todas las variables disponibles para una plantilla de correo electrónico específica, consulte el código PHP que envía el correo electrónico. Para la confirmación de pedido, compruebe la clase PaymentModule (en /classes/PaymentModule.php). El método validateOrder() construye el array de variables de la plantilla. Cada clave del array corresponde a un nombre de variable que puede usar en la plantilla.

Las variables comúnmente disponibles en los correos electrónicos de confirmación de pedido incluyen: {id_order}, {order_name}, {delivery_block_txt}, {invoice_block_txt}, {delivery_block_html}, {invoice_block_html}, {delivery_company}, {delivery_firstname}, {delivery_lastname}, {delivery_address1}, {delivery_address2}, {delivery_city}, {delivery_postal_code}, {delivery_country}, {delivery_phone}, {invoice_company}, {invoice_firstname}, {invoice_lastname}, {invoice_address1}, {invoice_address2}, {invoice_city}, {invoice_postal_code}, {invoice_country}, {invoice_phone}, {message} y {total_products}.

Personalizar la plantilla de confirmación de pedido

Paso 1: Crear una sobrescritura del tema

Nunca edite directamente los archivos de plantilla del núcleo. En su lugar, copie la plantilla al directorio mails de su tema:

Copie /mails/es/order_conf.html a /themes/su-tema/mails/es/order_conf.html. Haga lo mismo para order_conf.txt. Si el directorio mails/es/ no existe en su tema, créelo.

Si su tienda admite varios idiomas, copie las plantillas para cada directorio de idioma. Su confirmación de pedido en francés va en /themes/su-tema/mails/fr/order_conf.html y así sucesivamente.

Paso 2: Modificar el diseño HTML

Abra la plantilla HTML en un editor de texto (no en un editor visual que pueda añadir código no deseado). El HTML de correo electrónico difiere del HTML web en varios aspectos importantes:

Use tablas para el diseño, no divs. Los clientes de correo, especialmente Outlook, tienen un soporte CSS muy limitado. Un diseño de tres columnas debe usar un <table> con tres elementos <td>, no columnas CSS ni flexbox.

Use estilos en línea en cada elemento. En lugar de <p class="heading"> con una hoja de estilos separada, use <p style="font-size:18px; font-weight:bold; color:#333333;">. Cada elemento con estilo necesita su propio atributo de estilo en línea.

Establezca anchos explícitos en tablas y celdas. Los clientes de correo no siempre respetan los anchos porcentuales. Use un ancho fijo para su tabla de contenido principal (600 píxeles es el estándar) con columnas internas porcentuales.

Use fuentes web seguras. No todos los clientes de correo soportan fuentes personalizadas. Utilice Arial, Helvetica, Georgia, Times New Roman, Verdana o Trebuchet MS. Puede intentar cargar una fuente personalizada como alternativa, pero siempre especifique una fuente web segura como alternativa final.

Paso 3: Añadir su branding

Reemplace el encabezado predeterminado de PrestaShop con el branding de su tienda. Esto típicamente implica actualizar el logotipo (la variable {shop_logo} utiliza automáticamente el logotipo de su tienda, pero puede querer una versión específica para correos electrónicos), cambiar el color de fondo del encabezado para que coincida con su marca, añadir la paleta de colores de su marca a los encabezados y enlaces, e incluir el eslogan de su tienda o un breve mensaje de marketing.

Mantenga la estructura general simple. Los diseños de correo electrónico excesivamente complejos se rompen en diferentes clientes de correo. Un diseño limpio de una sola columna con los colores y el logotipo de su marca es más efectivo y más fiable que un elaborado diseño de múltiples columnas.

Paso 4: Personalizar la tabla de productos

La tabla de productos predeterminada en la confirmación de pedido de PrestaShop es funcional pero básica. Puede mejorarla añadiendo imágenes de productos (use URLs absolutas a imágenes alojadas en su servidor, no rutas relativas), añadiendo enlaces a las páginas de productos para que los clientes puedan reordenar fácilmente o dejar reseñas, añadiendo campos personalizados como fechas de entrega estimadas o mensajes personalizados, y ajustando el estilo de la tabla para que coincida con su marca.

Al añadir imágenes de productos, manténgalas pequeñas (de 50 a 80 píxeles de ancho) y siempre incluya un atributo alt. Algunos clientes de correo bloquean las imágenes por defecto, y el texto alternativo garantiza que los clientes puedan identificar sus productos de todos modos.

Añadir campos personalizados a los correos electrónicos de pedido

Las variables predeterminadas de PrestaShop cubren la información estándar del pedido, pero puede querer incluir datos adicionales como puntos de fidelidad ganados, fecha de entrega estimada, un mensaje de agradecimiento personalizado o recomendaciones de productos de venta cruzada.

Añadir variables mediante un módulo

La forma más limpia de añadir variables personalizadas es a través de un módulo que se enganche al proceso de envío de correos electrónicos. Cree un módulo que registre el hook actionEmailSendBefore (disponible a partir de PrestaShop 1.7.6) o el hook actionGetExtraMailTemplateVars. En su manejador del hook, añada sus variables personalizadas al array de variables de la plantilla:

Su función de hook recibe el array de variables de la plantilla por referencia. Puede añadir nuevas variables a este array, y estarán disponibles en la plantilla usando la sintaxis estándar {nombre_variable}. Por ejemplo, después de añadir loyalty_points al array en su hook, puede usar {loyalty_points} en su plantilla HTML de confirmación de pedido.

Usar datos existentes de la base de datos

Puede incorporar cualquier dato de su base de datos PrestaShop en las variables de correo electrónico. Ejemplos comunes incluyen el recuento total de pedidos del cliente (para mostrar "¡Gracias por tu 5.° pedido!"), el saldo de puntos de fidelidad del cliente, campos de producto personalizados almacenados en características o atributos de productos, e información del almacén o proveedor para los productos pedidos.

Configuración de correos electrónicos multilingües

Si su tienda atiende a clientes en múltiples idiomas, cada plantilla de correo electrónico necesita una versión para cada idioma. PrestaShop gestiona la selección del idioma automáticamente basándose en la preferencia de idioma del cliente, pero usted debe proporcionar las plantillas.

Crear plantillas específicas para cada idioma

Para cada idioma que soporte su tienda, cree un directorio en la carpeta mails de su tema: /themes/su-tema/mails/en/, /themes/su-tema/mails/fr/, /themes/su-tema/mails/de/, y así sucesivamente. Copie y traduzca cada archivo de plantilla en el directorio apropiado.

No use traducción automática para correos electrónicos transaccionales. Estos correos representan la comunicación de su tienda con los clientes, y las traducciones deficientes dañan la confianza. Haga que cada versión de idioma sea escrita o revisada por un hablante nativo.

Soporte para idiomas de derecha a izquierda

Si soporta idiomas como el árabe o el hebreo, sus plantillas de correo electrónico necesitan soporte de diseño RTL (de derecha a izquierda). Añada dir="rtl" al elemento de tabla principal y ajuste la alineación del texto y el relleno en sus estilos en línea. Cree plantillas separadas para los idiomas RTL en lugar de intentar hacer que una sola plantilla funcione para ambas direcciones.

Formato de fechas y monedas

PrestaShop formatea automáticamente los valores de fechas y monedas según la configuración de idioma y moneda del cliente. Los valores {date}, {total_paid} y otros valores formateados ya reflejan la configuración regional correcta. Sin embargo, si añade variables personalizadas con valores de fecha o moneda, asegúrese de formatearlos correctamente para el idioma de destino.

Configuración SMTP para una entrega fiable

La mejor plantilla de correo electrónico del mundo es inútil si sus correos electrónicos no llegan a la bandeja de entrada. La configuración de correo electrónico predeterminada de PrestaShop utiliza la función mail() integrada de PHP, que no es fiable para correos electrónicos transaccionales. La mayoría de estos correos terminan en la carpeta de spam o son rechazados por completo por los proveedores de correo modernos.

Por qué importa el SMTP

El SMTP (Simple Mail Transfer Protocol) con autenticación adecuada es esencial para la entregabilidad del correo electrónico. Cuando envía correos electrónicos a través de la función mail() de PHP, el correo proviene de la dirección IP de su servidor web sin ninguna autenticación. Los proveedores de correo como Gmail, Outlook y Yahoo ven esto como una señal de alarma y frecuentemente clasifican estos correos como spam.

Con SMTP, sus correos electrónicos se envían a través de un servidor de correo autenticado con registros SPF, DKIM y DMARC adecuados. Esto demuestra a los servidores de correo receptores que el correo electrónico es legítimo y está autorizado por su dominio.

Configurar SMTP en PrestaShop

Vaya a Parámetros avanzados > Correo electrónico en su back office de PrestaShop. Cambie el método de "Usar la función mail() de PHP" a "Establecer mis propios parámetros SMTP". Introduzca los detalles de su servidor SMTP: la dirección del servidor, el puerto (típicamente 587 para TLS o 465 para SSL), el tipo de cifrado, el nombre de usuario y la contraseña.

Los proveedores SMTP comunes para PrestaShop incluyen Gmail SMTP (smtp.gmail.com, puerto 587, TLS, requiere una contraseña de aplicación si la 2FA está habilitada), Amazon SES (económico para grandes volúmenes), SendGrid (generoso nivel gratuito), Mailgun (amigable para desarrolladores con buena gestión de registros) y el servidor SMTP de su proveedor de hosting (consulte con su host para conocer la configuración).

Probar la configuración SMTP

Después de configurar el SMTP, use el botón "Enviar un correo electrónico de prueba" en la parte inferior de la página de configuración de correo electrónico. Introduzca su propia dirección de correo electrónico y compruebe que el correo de prueba llega a su bandeja de entrada (no al spam). Si el correo de prueba falla, verifique sus credenciales SMTP, asegúrese de que su servidor puede acceder al servidor SMTP en el puerto configurado (algunos proveedores de hosting bloquean los puertos salientes 25 y 587) y compruebe si su proveedor SMTP requiere configuraciones de seguridad específicas.

Registros SPF, DKIM y DMARC

Para la máxima entregabilidad, configure estos registros DNS para su dominio. SPF (Sender Policy Framework) especifica qué servidores están autorizados para enviar correos electrónicos en nombre de su dominio. DKIM (DomainKeys Identified Mail) añade una firma digital a sus correos electrónicos que demuestra que fueron enviados por su dominio. DMARC (Domain-based Message Authentication, Reporting, and Conformance) indica a los servidores receptores qué hacer con los correos electrónicos que no superan las comprobaciones SPF o DKIM.

Su proveedor SMTP le proporcionará los registros DNS específicos que debe añadir. Por ejemplo, si utiliza SendGrid, proporcionan registros SPF y DKIM durante el proceso de autenticación del dominio. Añádalos como registros TXT en la configuración DNS de su dominio.

Probar las plantillas de correo electrónico

Enviar correos electrónicos de prueba

PrestaShop no tiene una forma integrada de previsualizar plantillas de correo electrónico específicas. Para probar su plantilla de confirmación de pedido, necesita realizar un pedido de prueba real. Cree una cuenta de cliente de prueba, añada productos al carrito y complete el proceso de compra con un método de pago de prueba. Si tiene un módulo de pago en modo sandbox configurado, utilícelo. De lo contrario, los métodos de pago por transferencia bancaria o cheque le permiten completar un pedido sin procesamiento de pago real.

Pruebas en diferentes clientes de correo

El renderizado de correos electrónicos varía drásticamente entre los clientes de correo. Lo que se ve perfecto en Gmail puede estar roto en Outlook. Como mínimo, pruebe sus plantillas en Gmail (web), Outlook (escritorio y web), Apple Mail, Yahoo Mail y al menos una aplicación de correo móvil. Servicios como Litmus o Email on Acid automatizan estas pruebas renderizando su correo electrónico en docenas de clientes de correo simultáneamente, pero son servicios de pago.

Problemas de renderizado comunes

Si su correo electrónico se ve roto en Outlook, es casi con toda seguridad un problema de CSS. Outlook utiliza el motor de renderizado de Microsoft Word para los correos HTML, que tiene un soporte CSS extremadamente limitado. No soporta imágenes de fondo en las celdas de tabla (use colores de fondo en su lugar), padding en elementos de bloque (use padding de celdas de tabla), max-width (use anchos fijos), margin para centrar (use align="center" en tablas) ni floats CSS.

Para la responsividad móvil, envuelva su tabla de contenido en un contenedor con max-width:600px y añada una media query en el bloque de estilo del head (que algunos clientes de correo soportan) que establezca los anchos de tabla al 100% en pantallas pequeñas. Esto no es un diseño responsive perfecto, pero evita el desplazamiento horizontal en la mayoría de los dispositivos móviles.

Problemas comunes y resolución

Imágenes que faltan en los correos electrónicos

Este es el problema más común de las plantillas de correo electrónico. Las imágenes en los correos electrónicos deben usar URLs absolutas (que comiencen con https://), no rutas relativas. Si su plantilla hace referencia a /img/logo.png, cámbielo a https://www.sudominio.com/img/logo.png. La variable {shop_logo} genera automáticamente una URL absoluta, pero todas las imágenes que añada manualmente deben usar URLs completas.

Verifique también que sus imágenes sean accesibles desde fuera de su red. Si su tienda está detrás de un firewall o autenticación HTTP, los clientes de correo no pueden cargar las imágenes. Pruebe abriendo la URL de la imagen en una ventana de navegador privada/incógnita.

Diseño roto después de la edición

El HTML de correo electrónico es frágil. Una sola etiqueta sin cerrar o una celda de tabla faltante puede romper todo el diseño. Siempre valide su HTML después de editarlo. Cuente sus etiquetas de apertura y cierre de table, tr y td. Cada <table> necesita un </table>, cada <tr> necesita un </tr> y cada <td> necesita un </td>. Compruebe que cada fila en una tabla tenga el mismo número de celdas (o use colspan para compensar la diferencia).

Variables que no se reemplazan

Si ve el texto literal {nombre_variable} en sus correos electrónicos enviados en lugar de los valores reales, compruebe el nombre de la variable en busca de errores tipográficos. Los nombres de las variables distinguen entre mayúsculas y minúsculas. Verifique también que la variable exista para el tipo específico de correo electrónico que está personalizando. No todas las variables están disponibles en todas las plantillas de correo electrónico. Las variables específicas del pedido como {order_name} solo están disponibles en los correos electrónicos relacionados con pedidos.

Los correos electrónicos no se envían en absoluto

Si los correos electrónicos no se envían, compruebe el back office de PrestaShop en Parámetros avanzados > Correo electrónico. Allí puede ver un registro de los correos electrónicos enviados. Si el registro muestra fallos, compruebe su configuración SMTP. Si no aparecen correos electrónicos en el registro, es posible que el correo electrónico no se esté activando en absoluto. Verifique que las transiciones de estado de pedido estén configuradas para enviar correos electrónicos al cliente (Pedidos > Estados > editar estado > marcar "Enviar un correo electrónico al cliente").

Compruebe también el registro de errores PHP de su servidor en busca de errores relacionados con el correo electrónico. Los problemas comunes incluyen la función mail() de PHP deshabilitada por el proveedor de hosting, fallos de autenticación SMTP debido a contraseñas cambiadas y problemas de conectividad de red entre su servidor y el servidor SMTP.

Los correos electrónicos van al spam

Incluso con una configuración SMTP correcta, los correos electrónicos pueden seguir llegando al spam. Las razones más comunes son registros SPF/DKIM/DMARC faltantes o incorrectos, contenido de correo electrónico que activa los filtros de spam (uso excesivo de mayúsculas, palabras que activan el spam como "gratis" o "actúe ahora", demasiadas imágenes con poco texto), envío desde una dirección IP con mala reputación (común con el hosting compartido) y la dirección de correo electrónico "de" cuyo dominio no coincide con el dominio del servidor SMTP.

Corrija primero los registros DNS y luego revise el contenido de sus correos electrónicos. Use una herramienta como mail-tester.com para analizar sus correos electrónicos en busca de activadores de spam. Envíe un correo de prueba a la dirección que proporcionan y recibirá un informe detallado que muestra qué podría causar la clasificación como spam.

Sobrescrituras de correo electrónico específicas del tema

Algunos temas de PrestaShop incluyen sus propias plantillas de correo electrónico que coinciden con el diseño del tema. Si su tema tiene plantillas en /themes/su-tema/mails/, estas sobrescriben automáticamente las plantillas del núcleo.

Comprobar las plantillas de correo electrónico del tema

Busque en el directorio de su tema activo una carpeta mails. Si existe, el tema proporciona plantillas de correo electrónico personalizadas. Estas plantillas suelen coincidir con la paleta de colores y el diseño del encabezado/pie de página del tema, dando a sus correos electrónicos coherencia visual con su escaparate.

Personalizar las plantillas de correo electrónico del tema

Si su tema proporciona plantillas de correo electrónico, edite esas en lugar de copiar del directorio mails/ del núcleo. Las plantillas del tema pueden usar una estructura HTML diferente o incluir CSS adicional específico del sistema de diseño del tema. Partir de la versión del tema garantiza la coherencia visual.

Mantener las plantillas sincronizadas con las actualizaciones del tema

Cuando actualice su tema, compruebe si la actualización incluye cambios en las plantillas de correo electrónico. Si es así, sus personalizaciones podrían sobrescribirse. Antes de actualizar, haga una copia de seguridad de sus plantillas personalizadas. Después de actualizar, compare las nuevas plantillas con sus copias de seguridad y vuelva a aplicar sus personalizaciones a las versiones actualizadas. Esto es tedioso pero necesario para mantener tanto sus personalizaciones como las posibles mejoras o correcciones que el desarrollador del tema haya realizado.

Mejores prácticas para correos electrónicos de confirmación de pedido

Un correo electrónico de confirmación de pedido bien elaborado hace más que confirmar la transacción. Genera confianza, reduce las consultas de soporte y crea oportunidades de fidelización.

Incluya un número de referencia de pedido claro y destacado en la parte superior. Los clientes necesitan este número cuando contactan con soporte o hacen seguimiento de su pedido. Liste cada producto con su nombre, cantidad, precio y todas las opciones o personalizaciones. Incluya el desglose completo de subtotal, costos de envío, impuestos, descuentos y total. Muestre la dirección de entrega para que los clientes puedan verificarla y contactarle inmediatamente si es incorrecta. Indique el método de pago utilizado y cualquier detalle de transacción relevante. Proporcione un enlace a la página de seguimiento del pedido o al historial de pedidos del cliente en su cuenta. Añada su información de contacto de servicio al cliente para que los clientes sepan cómo comunicarse con usted si algo no está bien.

Mantenga el diseño limpio y adaptado a dispositivos móviles. Más de la mitad de todos los correos electrónicos se leen en dispositivos móviles. Use un diseño de una sola columna, texto grande y legible (mínimo 14px para el texto del cuerpo) y botones con objetivos táctiles adecuados (mínimo 44px de altura). Su correo electrónico de confirmación de pedido es un reflejo de la profesionalidad de su tienda. Invierta el tiempo necesario para hacerlo bien.

Leer respuesta completa

Why Regular Technical Audits Matter

PrestaShop stores degrade over time. Modules get installed and forgotten. PHP versions fall behind. Error logs fill up with warnings that nobody reads. Database tables grow bloated with abandoned cart data and expired sessions. Security patches go unapplied. Each of these issues is small on its own, but together they compound into slow page loads, security vulnerabilities, and eventually downtime or data loss.

The problem is that most store owners only discover these issues when something breaks. A customer complains about slow checkout. Google drops your rankings because your site fails Core Web Vitals. Or worse, you discover your admin panel is compromised because you never changed the default admin path and your PHP version had a known vulnerability.

A 30-minute technical health audit, performed monthly, prevents all of this. It is not a deep dive into every configuration setting. It is a focused checklist that catches the most common and most dangerous issues before they become emergencies. This guide walks through each check with approximate time estimates, giving you a repeatable process you can follow every month.

Check 1: PHP Version and Configuration (3 Minutes)

PHP is the engine that runs PrestaShop, and running an outdated version is both a performance and security risk. PHP versions receive active support for two years and security fixes for one additional year after that. After that, known vulnerabilities go unpatched.

Checking Your PHP Version

Go to your PrestaShop back office and navigate to Advanced Parameters > Information. The PHP version is listed in the Server Information section. Alternatively, you can check in your hosting control panel (cPanel, Plesk, or similar).

As of 2026, the actively supported PHP versions are 8.2, 8.3, and 8.4. If you are running PHP 8.1 or older, upgrading should be a priority. PrestaShop 8.x requires PHP 7.2 or later but performs significantly better on PHP 8.1 and above. PrestaShop 1.7.x supports PHP 7.1 through 8.1, depending on the specific version.

Key PHP Settings to Verify

While on the Information page, check these PHP configuration values:

memory_limit should be at least 256M for PrestaShop. If it is lower, you may experience white pages or incomplete operations when handling large catalogs or generating reports.

max_execution_time should be at least 300 (5 minutes). Lower values can cause timeouts during import operations, cache rebuilds, and module installations.

upload_max_filesize and post_max_size should be at least 16M, or higher if you regularly upload large product images or import files.

OPcache should be enabled. OPcache stores compiled PHP code in memory, dramatically reducing page load times. If it is disabled, your store is running significantly slower than it could be.

Check 2: Error Log Review (4 Minutes)

Error logs tell you what is breaking behind the scenes, even when the front end appears to work normally. Warnings and notices that do not crash the page still indicate problems that waste server resources and can escalate into real failures.

PrestaShop Logs

In the back office, go to Advanced Parameters > Logs. Sort by date (newest first) and scan the last week of entries. Focus on Severity 3 (Error) and Severity 4 (Critical) messages. Common critical errors include database connection failures, file permission errors, module exceptions, and payment processing errors.

If you see repeated errors from the same module, that module has a bug that needs attention. If you see database errors, your database server may be running out of connections or disk space.

PHP Error Log

The PHP error log location depends on your hosting environment. Common locations include /var/log/php/error.log, /var/log/apache2/error.log, or a path specified in your hosting control panel. Check the last 100 lines for fatal errors, warnings, and deprecation notices.

Deprecation notices are especially important to track. They warn you that a function or feature your code uses will be removed in a future PHP version. Addressing these now prevents your store from breaking when you upgrade PHP.

What to Do with Errors

Do not try to fix every error during the audit. The audit is for identification. Create a list of the most critical and most frequent errors, prioritized by severity. Fatal errors and critical errors need immediate attention. Warnings should be addressed within the month. Notices and deprecation warnings can be scheduled for your next maintenance window.

Check 3: Module Audit (5 Minutes)

Modules are the most common source of security vulnerabilities, performance problems, and compatibility issues in PrestaShop. A quick module audit identifies dead weight and potential risks.

Identifying Unused Modules

Go to Modules > Module Manager. Look for modules that are installed but disabled. These modules still have files on your server and potentially have database tables, but they are not serving any purpose. They increase your attack surface (a vulnerability in a disabled module's files can still be exploited) and slow down backups.

For each disabled module, decide whether you will use it again. If not, uninstall it completely (not just disable). Uninstalling removes the module's database tables and configuration. After uninstalling, also delete the module's directory from /modules/ to remove its files from the server entirely.

Checking for Updates

In the Module Manager, look for modules with available updates. Outdated modules are a primary vector for security exploits. Update notifications appear as badges on the module listing. Prioritize updates for modules that handle sensitive data: payment modules, customer account modules, and any module that processes forms.

Before updating any module, check the changelog to understand what changed. If the update includes security fixes, apply it immediately. If it is a feature update, test it on a staging environment first if possible.

Counting Total Modules

Check how many modules are installed in total. PrestaShop ships with many modules by default, and stores accumulate more over time. Each active module adds hooks that execute on every page load, increasing response time. If you have more than 80 to 100 active modules, review the list critically. Many default PrestaShop modules (like the social sharing buttons, customer data privacy notice, and statistics modules) can be disabled if you do not use them, resulting in measurable performance improvement.

Check 4: Database Health (4 Minutes)

Your PrestaShop database grows continuously. Every customer visit creates session data. Every abandoned cart stays in the database. Every log entry accumulates. Over months and years, this bloat slows down queries and increases backup times.

Checking Database Size

In your hosting control panel (cPanel > phpMyAdmin, for example), check the total database size. A healthy PrestaShop database for a small to medium store (under 10,000 products) should be under 500 MB. If yours is significantly larger, data bloat is likely the cause.

Identifying Large Tables

In phpMyAdmin, click on your database and sort tables by size. The usual culprits for bloat are: ps_connections and ps_connections_page (visitor tracking data that can grow to gigabytes), ps_log (PrestaShop's internal log table), ps_mail (email history), ps_cart and ps_cart_product (abandoned cart data), ps_guest (anonymous visitor records), and ps_pagenotfound (404 error tracking).

These tables can be safely cleaned of old data. For example, you do not need connection data from two years ago. PrestaShop has a built-in feature for cleaning some of these tables: go to Advanced Parameters > Administration and look for the "Automatically check for module updates" and data cleanup options. For more thorough cleanup, the free PrestaShop Cleaner module can purge old statistics data, abandoned carts, and expired sessions.

Checking for Missing Indexes

While in phpMyAdmin, check the structure of your most important tables (ps_product, ps_category_product, ps_stock_available) and verify that indexes exist on the columns used in search and filtering. Missing indexes cause slow queries that affect page load times. However, do not add indexes without understanding the trade-offs, as each index slows down write operations slightly.

Check 5: Security Basics (5 Minutes)

Security vulnerabilities in PrestaShop stores are actively exploited. Automated scanners continuously probe the internet for vulnerable installations. Five minutes of security checks can prevent a catastrophic breach.

Admin Panel URL

Your admin panel should not be accessible at a predictable URL like /admin/ or /backoffice/. PrestaShop generates a randomized admin directory name during installation (like /admin738xyz/). Verify that your admin URL is still randomized by checking the admin directory name on your server. If someone has renamed it to something guessable, rename it back to a random string.

SSL Certificate

Your entire store must run on HTTPS. Check by visiting your store's URL with http:// and verifying that it redirects to https://. In the back office, go to Shop Parameters > General and verify that "Enable SSL" and "Enable SSL on all pages" are both set to Yes.

Also check your SSL certificate's expiration date. Let's Encrypt certificates expire every 90 days and should auto-renew, but auto-renewal fails silently more often than you would expect. Click the padlock icon in your browser's address bar to see the certificate details and expiration date. If it expires within the next 30 days, verify that auto-renewal is configured and working.

File Permissions

Incorrect file permissions are a security risk. On Linux servers, your PrestaShop files should generally be owned by the web server user (typically www-data or apache) and have these permissions: directories at 755 (owner can read/write/execute, others can read/execute), files at 644 (owner can read/write, others can read only), and configuration files like config/settings.inc.php or app/config/parameters.php at 640 or 440 (restricted read access).

Check a few critical files to verify permissions are not too open. No file should be 777 (world-writable). If you find 777 permissions, fix them immediately. They allow any user on the server to modify those files.

Debug Mode

Verify that debug mode is disabled on your production store. Debug mode exposes detailed error messages, file paths, and database queries to visitors, which is valuable information for attackers. Check the file /config/defines.inc.php and ensure _PS_MODE_DEV_ is set to false. In PrestaShop 8.x, also check the .env file for the APP_DEBUG setting.

Known Vulnerabilities

Check whether your PrestaShop version has known security vulnerabilities. Visit the PrestaShop security advisories page and compare the listed versions with yours. If your version is affected by any advisory that you have not patched, prioritize applying the fix.

Check 6: Performance Quick Test (4 Minutes)

Performance directly affects conversion rates. Every additional second of page load time reduces conversions measurably. A quick performance test identifies major bottlenecks.

Running a Lighthouse Audit

Open Google Chrome, navigate to your store's homepage, open Chrome DevTools (F12), and click the Lighthouse tab. Run an audit for Performance, Best Practices, and SEO on a Mobile device. The test takes about 30 seconds.

Focus on the Performance score. A score below 50 indicates serious performance problems. Between 50 and 89 means there is room for improvement. Above 90 is good. The audit report shows specific issues and estimates of how much time each fix would save.

Key Metrics to Check

From the Lighthouse report, pay attention to Largest Contentful Paint (LCP), which measures how long it takes for the main content to appear. It should be under 2.5 seconds. First Input Delay (FID) or Interaction to Next Paint (INP) measures responsiveness. It should be under 200 milliseconds. Cumulative Layout Shift (CLS) measures visual stability. It should be under 0.1.

If LCP is high, the most common causes in PrestaShop are unoptimized images (large product images served without compression or proper sizing), slow server response time (check your hosting plan and database performance), render-blocking CSS and JavaScript (disable unnecessary modules that add their assets to every page), and disabled caching (Smarty cache and CCC should be enabled in production).

Checking Cache Configuration

In the back office, go to Advanced Parameters > Performance. Verify these settings: Smarty cache should be Yes with the cache type set to "File". CCC (Combine, Compress, Cache) should have CSS and JavaScript minification and combination enabled. Template compilation should be set to "Recompile templates if the files have been updated" (not "Force compilation" which is for development only).

If any of these are misconfigured, fixing them provides an immediate and noticeable performance improvement.

Check 7: SEO Basics (3 Minutes)

Technical SEO issues prevent search engines from properly crawling and indexing your store. A few quick checks catch the most impactful problems.

Robots.txt

Visit yourdomain.com/robots.txt in your browser. Verify that it exists and contains sensible rules. PrestaShop generates a robots.txt file automatically. Check that it is not blocking important pages. Your product pages, category pages, and CMS pages should not be disallowed. Common mistakes include blocking all URLs with parameters (which blocks filtered category pages and search results) and blocking the /modules/ directory (which can prevent CSS and JavaScript from being loaded by search engine renderers).

Also verify that the robots.txt includes a sitemap directive pointing to your XML sitemap: Sitemap: https://www.yourdomain.com/1_index_sitemap.xml.

XML Sitemap

Visit the sitemap URL listed in your robots.txt. Verify that it loads, that it is recent (check the last modification dates), and that it contains your important pages. If the sitemap is outdated or empty, regenerate it. If you use the built-in PrestaShop sitemap generator, go to Modules > Module Manager, find the Google Sitemap module, and click Configure to regenerate.

Check the number of URLs in the sitemap against your expected count. If you have 1,000 products but the sitemap only lists 200 URLs, something is wrong with the generation process. Common causes include products being disabled or out of stock being excluded from the sitemap, category visibility settings filtering out products, and the sitemap generation process timing out before completing.

Canonical URLs

Visit a few product pages and view the page source (Ctrl+U). Look for the <link rel="canonical"> tag in the head section. It should contain the clean URL of the current page without any query parameters. If canonical tags are missing or incorrect, duplicate content issues will harm your SEO. In the back office, go to Shop Parameters > Traffic & SEO and verify that "Disable Apache's MultiViews option" and "Disable Apache's mod_security module" are configured correctly for your server.

Check 8: Backup Verification (3 Minutes)

Backups that have never been tested are not backups. They are wishful thinking. This check verifies that your backup system is actually working.

Checking Backup Recency

Determine where your backups are stored. This varies by hosting provider. Check your hosting control panel for backup tools (cPanel has a Backup section, Plesk has a Backup Manager). If you use a backup module in PrestaShop, check its configuration and recent backup log.

Your most recent backup should be no more than 24 hours old for active stores. If your last backup is older than a week, your backup system is either not configured, not running, or failing silently. Fix this immediately. Data loss from a server failure or hack without a recent backup can be business-ending.

Verifying Backup Completeness

A complete PrestaShop backup includes the entire database (all tables, not just product data) and the file system (all PrestaShop files, including uploaded images, module files, and theme customizations). Many backup solutions only capture the database or only capture the files. Verify that yours captures both.

Check the backup file sizes. A database backup for a small store should be at least several megabytes. If it is suspiciously small (under 1 MB for an active store), it might be empty or corrupted. A file backup should include your /img/ directory, which is typically the largest directory and can be several gigabytes for stores with many product images.

Offsite Backup Storage

Backups stored on the same server as your store are vulnerable to the same failures. If the server's hard drive fails, you lose both the store and the backup. Verify that your backups are copied to a separate location: a different server, cloud storage (like Amazon S3, Google Cloud Storage, or Dropbox), or downloaded to a local computer.

Check 9: Update Status (2 Minutes)

Running outdated software is the single most common reason PrestaShop stores get hacked. This final check verifies that your core installation and critical modules are up to date.

PrestaShop Core Version

Check your current PrestaShop version in the back office footer or on the Advanced Parameters > Information page. Compare it against the latest stable release on the PrestaShop website or GitHub releases page. If you are more than one minor version behind (for example, running 8.1.2 when 8.1.5 is available), plan an update. If you are running a version with known security vulnerabilities, update urgently.

PrestaShop major version upgrades (like 1.7 to 8.x) are complex migration projects, not simple updates. Do not attempt these without thorough planning and testing. But minor version updates (like 8.1.2 to 8.1.5) are generally safe and primarily contain security and bug fixes.

Critical Module Updates

Some modules handle sensitive operations and must be kept current: payment modules (any module that processes credit cards, PayPal, or other payment methods), the PrestaShop autoupgrade module (used for core updates), and any security-related modules. Check the Module Manager for available updates on these specific modules.

Your 30-Minute Audit Checklist Summary

Here is the complete checklist with time allocations that you can follow each month:

Minutes 1-3: PHP Version and Configuration. Check PHP version is supported. Verify memory_limit, max_execution_time, and OPcache status.

Minutes 4-7: Error Log Review. Scan PrestaShop logs for Severity 3 and 4 entries. Check PHP error log for fatal errors and deprecation notices. Note recurring errors for follow-up.

Minutes 8-12: Module Audit. Review disabled modules and uninstall unused ones. Check for available updates, especially on payment and security modules. Count total active modules and identify candidates for removal.

Minutes 13-16: Database Health. Check total database size. Identify bloated tables. Plan cleanup of old connection, log, and cart data.

Minutes 17-21: Security Basics. Verify admin URL is randomized. Check SSL certificate and expiration. Verify file permissions. Confirm debug mode is off. Check for known vulnerabilities in your version.

Minutes 22-25: Performance Quick Test. Run Lighthouse audit on homepage. Check LCP, INP, and CLS metrics. Verify cache and CCC settings in back office.

Minutes 26-28: SEO Basics. Check robots.txt for errors. Verify sitemap is current and complete. Spot-check canonical URLs on product pages.

Minutes 29-30: Backup and Updates. Verify backup recency and completeness. Check PrestaShop core and critical module versions against latest releases.

This audit does not fix problems. It identifies them. After completing the checklist, you should have a prioritized list of issues to address. Critical security issues and broken functionality come first. Performance optimizations and cleanup tasks come second. Minor improvements and future planning come third. By performing this audit monthly, you catch problems early, maintain a clear picture of your store's technical health, and avoid the nasty surprises that come from months of neglected maintenance.

Leer respuesta completa

Cookie	Proveedor	Finalidad	Duración
PrestaShop-*	PrestaShop	Gestión de sesión y funcionalidad del carrito	Sesión
PHPSESSID	PHP	Identificador de sesión PHP	Sesión
mprcr_consent	MPR Cookies Revolution	Almacena las preferencias de consentimiento de cookies	365 día(s)
mprcr_version	MPR Cookies Revolution	Rastrea la version de la configuración del consentimiento	365 día(s)

Cookie	Proveedor	Finalidad	Duración
TawkConnectionTime	Tawk.to	Rastreo del tiempo de conexion de la sesion de chat	Sesión
__tawkuuid	Tawk.to	Identifica a los visitantes recurrentes del chat	6 mes(es)