Info extra del cliente (Bloqueo IP)

OPcache es una extensión de PHP que almacena en cache el código PHP compilado en memoria, de modo que PHP no tiene que recompilarlo en cada petición. Debería habilitarlo sin duda — puede mejorar el rendimiento de PrestaShop entre un 30-50% sin ningún inconveniente para producción. La mayoría de los proveedores de hosting lo tienen habilitado por defecto. La configuración importante es opcache.validate_timestamps: establézcala en 1 en desarrollo, pero muchos servidores de producción la establecen en 0 para máximo rendimiento (lo que significa que necesita restablecer OPcache manualmente después de desplegar cambios de código).

See our full guide on PHP optimization

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.

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.

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.

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

Que los navegadores NO manejan

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

Rendimiento admin PrestaShop: por que el back office es lento

Un back office PrestaShop lento es uno de los problemas mas frustrantes. Esta guia identifica las causas mas comunes y proporciona soluciones concretas.

Las causas mas comunes

1. Conexion API PrestaShop Addons

Causa numero uno. El back office hace peticiones HTTP a addons.prestashop.com. Cuando esta API es lenta, todo tu back office espera.

Solucion - Desconectarse de la cuenta Addons o desactivar las llamadas API.

2. Modo debug activado

Desactiva todas las caches y recompila los templates en cada peticion.

define('_PS_MODE_DEV_', false);

3. Demasiados modulos instalados

Cada modulo agrega sobrecarga. Desinstalar modulos no utilizados.

4. Base de datos grande sin optimizar

DELETE FROM ps_cart WHERE id_cart NOT IN (
    SELECT id_cart FROM ps_orders
) AND date_add < DATE_SUB(NOW(), INTERVAL 30 DAY);

OPTIMIZE TABLE ps_cart, ps_connections, ps_guest;

5. Limitaciones del hosting compartido

Recomendacion: VPS con 2+ CPU, 4 GB RAM, SSD y PHP 8.1+.

6. OPcache no activado

opcache.enable = 1
opcache.memory_consumption = 256

7. Widgets del dashboard lentos

Simplificar el dashboard. Eliminar widgets innecesarios.

8. Gran catalogo de productos

Reducir productos por pagina a 20-50.

Checklist de optimizacion

1. Desactivar modo debug
2. Compilacion de templates: "Nunca recompilar"
3. Activar cache (Redis preferido)
4. Activar OPcache
5. Desconectar de API Addons
6. Desinstalar modulos no usados
7. Limpiar la base de datos
8. Simplificar dashboard
9. Cambiar a VPS/dedicado
10. Usar PHP 8.1+

Limitacion de velocidad y proteccion contra bots para PrestaShop sin WAF

Los bots representan mas del 40% del trafico web en 2026. Esta guia muestra como implementar proteccion efectiva usando solo configuracion del servidor, reglas .htaccess y modulos ligeros.

Metodo 1 - Rate Limiting Apache .htaccess

RewriteCond %{HTTP_USER_AGENT} (SemrushBot|AhrefsBot|MJ12bot) [NC]
RewriteRule .* - [F,L]

Metodo 2 - Rate Limiting Nginx

limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;
location ~ /login$ {
    limit_req zone=login burst=3 nodelay;
}

Metodo 3 - fail2ban contra brute force

fail2ban monitorea los logs del servidor y bloquea automaticamente las IPs maliciosas.

Metodo 4 - Rate Limiting a nivel PHP

Para hosting compartido: rate limiter basado en archivos en PHP.

Metodo 5 - robots.txt y control de crawling

User-agent: SemrushBot
Crawl-delay: 10

Metodo 6 - CAPTCHA en formularios criticos

Agregar reCAPTCHA en login, registro, contacto y newsletter.

Metodo 7 - Cloudflare Free

Browser Integrity Check, Bot Fight Mode y Rate Limiting estan disponibles gratis.

Resumen de capas de proteccion

Cuando las combinaciones de PrestaShop matan el rendimiento: limites y soluciones

El sistema de combinaciones de PrestaShop permite crear variantes de producto. Funciona perfectamente para productos con pocas variantes. Pero cuando los productos tienen cientos o miles de combinaciones, el rendimiento se degrada dramaticamente.

Por que las combinaciones causan problemas de rendimiento

Arquitectura de la base de datos

PrestaShop almacena datos de combinaciones en multiples tablas: ps_product_attribute, ps_product_attribute_combination, ps_stock_available, ps_specific_price. Un producto con 5 tallas y 10 colores crea 50 combinaciones con mas de 350 filas en la base de datos.

El problema del crecimiento exponencial

Limites practicos

Solucion 1 - Reestructurar el catalogo

En lugar de un producto con 50 combinaciones, crear productos separados por color con 5 combinaciones cada uno. Mas rapido y mejor para SEO.

Solucion 2 - Optimizacion de base de datos y servidor

ALTER TABLE ps_product_attribute 
  ADD INDEX idx_product_default (id_product, default_on);

ALTER TABLE ps_stock_available 
  ADD INDEX idx_product_attribute (id_product, id_product_attribute);

Solucion 3 - Carga progresiva de combinaciones

En lugar de cargar todas las combinaciones al cargar la pagina, obtener datos via AJAX cuando el cliente selecciona un atributo.

Solucion 4 - Estrategias de cache

Cache de pagina completa (Varnish, LiteSpeed) para paginas de producto. Redis o Memcached para cache de objetos.

Cuando evitar las combinaciones completamente

• Productos configurables con 4+ atributos - Modulo configurador de producto
• Productos dimensionales - Modulo de dimensiones personalizadas
• Productos print-on-demand - Modulo disenador de producto

Recomendaciones por cantidad de combinaciones

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

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

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

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

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

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.

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.