Optimización del rendimiento PrestaShop: Acelera tu tienda

Por qué la velocidad de la tienda no es opcional

Cada 100 milisegundos de tiempo de carga adicional le cuesta conversiones. Amazon descubrió que un retraso de 100ms reducía los ingresos en un 1%. Google confirmó que las páginas que tardan más de 3 segundos en cargar pierden el 53% de los visitantes móviles antes de que vean sus productos.

Para una tienda PrestaShop, la velocidad afecta directamente a tres aspectos:

• Tasas de conversión: Una tienda que carga en 2 segundos convierte aproximadamente al doble que una que carga en 5 segundos. Sus clientes no van a esperar — comprarán en una tienda más rápida.
• Posicionamiento SEO: Google utiliza la velocidad de página como factor de clasificación. Desde 2021, los Core Web Vitals forman parte del algoritmo. Una tienda lenta se posiciona peor, recibe menos tráfico orgánico y paga más por visibilidad.
• Experiencia móvil: Más del 70% del tráfico de comercio electrónico es móvil. Procesadores más lentos, menos memoria, peores conexiónes. Si su tienda es lenta en escritorio, en móvil es insoportable.

La optimización de velocidad no es una tarea puntual — es una disciplina continua. Cada módulo que instala, cada cambio de tema, cada imagen de producto afecta al rendimiento. Trate la velocidad como una característica que se mantiene, no como un proyecto que se termina.

Mida antes de optimizar

Lo peor que puede hacer es empezar a “optimizar” sin saber dónde están sus problemas reales. Mida siempre primero.

Las herramientas adecuadas

• Google PageSpeed Insights: Gratuita, utiliza datos reales de usuarios de Chrome (CrUX). Pruebe su página de inicio, una página de categoría y una página de producto — son sus puntos de entrada más habituales.
• GTmetrix: Le proporciona un gráfico en cascada que muestra exactamente qué se carga, en qué orden y cuánto tarda cada solicitud. Indispensable para encontrar cuellos de botella.
• WebPageTest: La herramienta más detallada disponible. Permite realizar pruebas desde diferentes ubicaciones y velocidades de conexión con vistas de tira de fotogramas.

Core Web Vitals explicados

Estas son las tres métricas que Google utiliza para evaluar la experiencia del usuario:

• LCP (Largest Contentful Paint): Tiempo hasta que el elemento visible más grande termina de cargarse. Objetivo: menos de 2,5 segundos. La mayoría de las tiendas PrestaShop tienen dificultades aquí — las imágenes sin optimizar y los scripts que bloquean el renderizado son los culpables.
• INP (Interaction to Next Paint): Cuánto tarda la página en responder a clics y toques. Sustituyó a FID en marzo de 2024. Objetivo: menos de 200ms. El JavaScript pesado y los scripts de módulos mal programados causan un INP alto.
• CLS (Cumulative Layout Shift): Cuánto se desplaza el diseño durante la carga. Objetivo: menos de 0,1. Las imágenes sin dimensiones, los banners que cargan tarde y los cambios de fuente causan CLS.

Objetivos realistas

Una tienda PrestaShop con muchas funcionalidades nunca obtendrá 100 en PageSpeed. Apunte a: móvil 50-70, escritorio 80-95, LCP inferior a 3s en móvil / 2s en escritorio, peso total de página inferior a 2MB, menos de 80 solicitudes HTTP.

No persiga una puntuación perfecta en PageSpeed. Una puntuación de 65 con un 3% de tasa de conversión supera a una puntuación de 98 en una página despojada de la que nadie compra. Optimice para la experiencia real del usuario, no para un número.

Optimización del servidor

Ningún truco de frontend puede compensar un servidor lento. Si su servidor tarda 2 segundos en generar el HTML antes de que el navegador siquiera empiece a cargar los recursos, ya ha perdido.

Configuración de PHP OPcache

OPcache almacena bytecode PHP precompilado en memoria para que PHP no tenga que volver a analizar los archivos en cada solicitud. Para PrestaShop (cientos de archivos PHP por página), esto es obligatorio.

opcache.enable=1
opcache.memory_consumption=256
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=20000
opcache.validate_timestamps=1
opcache.revalidate_freq=60
opcache.save_comments=1

Los valores predeterminados son demasiado bajos para PrestaShop. max_accelerated_files debe ser al menos 20000 (el valor predeterminado es 4000, pero una instalación típica de PS tiene entre 10.000 y 15.000 archivos PHP). Establezca memory_consumption en 128-256MB — si la memoria de OPcache se llena, descarta entradas y se pierde el beneficio.

En servidores cPanel con validate_timestamps=0, OPcache NUNCA volverá a leer los archivos del disco. Debe restablecerlo mediante una solicitud web después de cada despliegue — los reinicios por CLI solo limpian la caché de CLI, no la caché web.

Ajuste de MySQL / MariaDB

Una página de producto típica de PrestaShop ejecuta entre 50 y 200 consultas SQL. El parámetro de base de datos más importante es:

[mysqld]
# Set to 50-70% of available RAM on dedicated DB server
innodb_buffer_pool_size = 1G
innodb_log_file_size = 256M
innodb_flush_log_at_trx_commit = 2

# MySQL 5.7 / MariaDB only (removed in MySQL 8.0)
query_cache_type = 1
query_cache_size = 64M

# Find problem queries
slow_query_log = 1
long_query_time = 1

# Connection settings
max_connections = 150
tmp_table_size = 64M
max_heap_table_size = 64M

El innodb_buffer_pool_size determina cuántos datos de la base de datos se mantienen en RAM. Si su base de datos ocupa 500MB y el buffer pool es de 1GB, la mayoría de las consultas se sirven desde memoria. Active el registro de consultas lentas y revíselo semanalmente — las consultas que tardan más de 1 segundo son problemas esperando a manifestarse durante los picos de tráfico.

Alojamiento: compartido vs VPS vs dedicado

• Alojamiento compartido ($5-15/mes): Comparte CPU y RAM con cientos de sitios. Aceptable solo para tiendas muy pequeñas con menos de 500 productos.
• VPS ($20-60/mes): Recursos dedicados. La mejor opción para la mayoría de las tiendas. Consiga al menos 4GB de RAM, 2 núcleos de CPU y almacenamiento SSD.
• Dedicado ($80-300/mes): Para tiendas con mucho tráfico (más de 1000 pedidos diarios) o catálogos de más de 100.000 productos.

Si tiene alojamiento compartido y su tienda es lenta, cambiar a un VPS le proporcionará una mejora de velocidad mayor que todas las demás optimizaciónes juntas.

PHP-FPM y Redis

Utilice PHP-FPM en lugar de mod_php — ejecuta PHP como un servicio independiente, reduciendo el uso de memoria y mejorando la gestión de procesos. Utilice Redis para el almacenamiento de sesiones y caché en lugar del sistema de archivos. Configure en app/config/parameters.php:

'ps_cache_enable' => true,
'ps_caching' => 'CacheRedis',

Optimizaciones integradas de PrestaShop

CCC (Combine, Compress, Cache)

Se encuentra en Advanced Parameters → Performance. CCC combina archivos CSS/JS en archivos únicos y los minifica. Actívelo siempre en producción. Tenga en cuenta estos aspectos:

• Los archivos con atributos defer o async permanecen separados (por diseño)
• Los archivos externos (Google Fonts, Stripe.js) nunca se combinan
• Los módulos mal programados pueden fallar cuando CCC reordena los recursos — si activar CCC rompe su proceso de pago, desactívelo e identifique el módulo problemático
• Limpie siempre la caché y realice pruebas exhaustivas después de activarlo

Configuración de plantillas Smarty

Establezca la compilación de plantillas en “Recompile templates if the files have been updated” en producción. Nunca utilice “Force compilation” — recompila cada plantilla en cada carga de página.

Modo Debug — compruebe esto primero

El modo debug desactiva toda la caché, fuerza la recompilación de plantillas y registra todo. Verifique que está desactivado:

// In app/config/defines.inc.php — MUST be false on production
define('_PS_MODE_DEV_', false);

Hemos visto tiendas funcionando en modo debug durante meses. Su problema de “tienda lenta” desapareció cuando se corrigió este único ajuste.

Desactive los módulos innecesarios

Cada módulo activado se conecta al sistema de eventos de PrestaShop. Una instalación nueva incluye más de 80 módulos. Cada uno carga clases PHP, puede registrar CSS/JS en cada página, ejecuta callbacks de hooks y puede realizar consultas a la base de datos — incluso cuando devuelve contenido vacío.

Revise Modules → Module Manager y desinstale todo lo que no utilice activamente. Si tiene tres módulos de analítica haciendo lo mismo, conserve uno.

Optimización de imágenes

Las imágenes representan normalmente entre el 60% y el 80% del peso total de una página. Aquí es donde la mayoría de las tiendas tienen el mayor margen de mejora.

WebP y dimensiones correctas

Las imágenes WebP son entre un 25% y un 35% más pequeñas que JPEG sin pérdida visible de calidad. PrestaShop 8.x soporta WebP de forma nativa. Para versiones anteriores, utilice conversión del lado del servidor o un módulo.

El desperdicio más común: servir imágenes de 2000x2000px en miniaturas de 300px. Configure los tipos de imagen en Design → Image Settings para que coincidan con los tamaños reales de visualización de su tema. No suba imágenes de origen de 4000px “por si acaso” — 1200px es suficiente para el zoom de la página de producto en pantallas retina.

Carga diferida (Lazy Loading)

Difiera la carga de las imágenes que están fuera de la vista inicial hasta que el usuario se desplace hasta ellas:

<img src="product.jpg" loading="lazy" width="300" height="300" alt="Product Name">

NO aplique carga diferida a las imágenes de la parte superior visible (logotipo, banner principal, primera fila de productos) — estas afectan al LCP y deben cargarse de inmediato.

Regeneración de imágenes

Después de cambiar las dimensiones de las imágenes, regenere las existentes a través de Design → Image Settings o por línea de comandos:

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

Optimización del frontend

Minimice las solicitudes HTTP

Revise su gráfico en cascada en GTmetrix. Más de 100 solicitudes significa problemas. Causas habituales: módulos que cargan sus propios archivos CSS/JS, Google Fonts con múltiples pesos, widgets de redes sociales y múltiples herramientas de analítica.

CSS crítico

Los navegadores detienen el renderizado hasta que todo el CSS del <head> se ha descargado. El CSS crítico extrae solo los estilos necesarios para la vista inicial y los incorpora en línea. La hoja de estilos completa se carga de forma asíncrona. Esto puede reducir el tiempo de carga percibido entre 1 y 3 segundos en móvil, pero requiere regeneración cada vez que cambia el CSS del tema.

JavaScript: defer y async

Utilice defer para la mayoría de los scripts de módulos (se descarga en paralelo, se ejecuta después del análisis del HTML). Utilice async solo para scripts independientes como los de analítica. En PrestaShop 1.7+:

$this->context->controller->registerJavascript(
    'module-my-script',
    'modules/mymodule/views/js/front.js',
    ['position' => 'bottom', 'priority' => 200, 'attribute' => 'defer']
);

Optimización de fuentes

Las fuentes personalizadas añaden silenciosamente entre 200 y 400KB de descargas. Buenas prácticas:

• Aloje las fuentes en su propio servidor en lugar de usar Google Fonts (elimina una búsqueda DNS adicional)
• Cree subconjuntos con solo los caracteres que necesita (los subconjuntos solo latín son un 60-80% más pequeños)
• Utilice font-display: swap para que el texto sea visible de inmediato con una fuente alternativa
• Limítese a 2 pesos — regular (400) y negrita (700) cubren la mayoría de necesidades
• Utilice el formato WOFF2 — la mejor compresión, compatibilidad universal con navegadores

@font-face {
    font-family: 'YourFont';
    src: url('/themes/your-theme/assets/fonts/yourfont.woff2') format('woff2');
    font-weight: 400;
    font-style: normal;
    font-display: swap;
}

Conceptos básicos de CDN

Un CDN sirve archivos estáticos desde servidores cercanos a sus visitantes. Cloudflare es la opción gratuita más popular. Configure un dominio CDN en Advanced Parameters → Performance → Media Servers para imágenes, CSS y JS.

Optimización de la base de datos

Las bases de datos de PrestaShop crecen silenciosamente. Tablas que estaban bien en el lanzamiento se convierten en problemas después de dos años de datos acumulados.

Limpie los carritos antiguos

ps_cart y ps_cart_product crecen con cada visitante — incluyendo bots y sesiones abandonadas. Después de un año, estas tablas pueden tener millones de filas.

-- Delete cart products for old abandoned carts (not linked to orders)
DELETE cp FROM ps_cart_product cp
INNER JOIN ps_cart c ON cp.id_cart = c.id_cart
LEFT JOIN ps_orders o ON c.id_cart = o.id_cart
WHERE o.id_order IS NULL
AND c.date_add < DATE_SUB(NOW(), INTERVAL 3 MONTH);

-- Delete the empty carts
DELETE c FROM ps_cart c
LEFT JOIN ps_orders o ON c.id_cart = o.id_cart
LEFT JOIN ps_cart_product cp ON c.id_cart = cp.id_cart
WHERE o.id_order IS NULL AND cp.id_cart IS NULL
AND c.date_add < DATE_SUB(NOW(), INTERVAL 3 MONTH);

Realice siempre una copia de seguridad de su base de datos antes de ejecutar consultas DELETE. Pruebe siempre primero en un entorno de pruebas. El patrón LEFT JOIN + IS NULL garantiza que los carritos vinculados a pedidos nunca se eliminen.

Limpie los registros y conexiónes

-- Application logs
DELETE FROM ps_log WHERE date_add < DATE_SUB(NOW(), INTERVAL 30 DAY);

-- Visitor tracking
DELETE FROM ps_connections_page WHERE id_connections IN (
    SELECT id_connections FROM ps_connections
    WHERE date_add < DATE_SUB(NOW(), INTERVAL 3 MONTH)
);
DELETE FROM ps_connections WHERE date_add < DATE_SUB(NOW(), INTERVAL 3 MONTH);

-- Orphaned guest records
DELETE g FROM ps_guest g
LEFT JOIN ps_connections c ON g.id_guest = c.id_guest
WHERE c.id_guest IS NULL;

-- Search stats, 404 logs, email logs
DELETE FROM ps_statssearch WHERE date_add < DATE_SUB(NOW(), INTERVAL 6 MONTH);
DELETE FROM ps_pagenotfound WHERE date_add < DATE_SUB(NOW(), INTERVAL 30 DAY);
DELETE FROM ps_mail WHERE date_add < DATE_SUB(NOW(), INTERVAL 3 MONTH);

Limpie el índice de búsqueda

Si utiliza una solución de búsqueda externa (Elasticsearch, Algolia), estas tablas son peso muerto:

TRUNCATE TABLE ps_search_index;
TRUNCATE TABLE ps_search_word;

Optimice tablas e índices

Después de eliminaciones masivas, recupere espacio en disco:

OPTIMIZE TABLE ps_cart, ps_cart_product, ps_connections,
    ps_connections_page, ps_guest, ps_log;

Añada índices faltantes para consultas habituales:

-- Check existing indexes first: SHOW INDEX FROM ps_cart;
ALTER TABLE ps_cart ADD INDEX idx_cart_date (date_add);
ALTER TABLE ps_connections ADD INDEX idx_conn_date (date_add);
ALTER TABLE ps_orders ADD INDEX idx_orders_ref (reference);
ALTER TABLE ps_product ADD INDEX idx_product_ref (reference);

Utilice EXPLAIN en las consultas lentas para verificar que los índices se están usando — si la columna “type” muestra “ALL”, significa un escaneo completo de la tabla.

Estrategias de caché

Caché de página completa

La mejora más dramática disponible. Sin ella, cada solicitud ejecuta cientos de archivos PHP y más de 100 consultas (200-500ms). Con caché de página completa, la misma página se sirve en 5-20ms.

Varnish es el estándar de la industria. nginx FastCGI cache es más sencillo si ya utiliza nginx:

fastcgi_cache_path /var/cache/nginx levels=1:2 keys_zone=PS:100m inactive=60m;

set $skip_cache 0;
if ($http_cookie ~* "PrestaShop-") { set $skip_cache 1; }
if ($request_uri ~* "/cart|/order|/my-account|/admin") { set $skip_cache 1; }

location ~ \.php$ {
    fastcgi_cache PS;
    fastcgi_cache_valid 200 10m;
    fastcgi_cache_bypass $skip_cache;
    fastcgi_no_cache $skip_cache;
}

El desafío es la invalidación de caché — limpiar las páginas en caché cuando cambian los productos, precios o existencias. Esta complejidad es la razón por la que muchas tiendas prescinden de la caché de página completa.

Caché de objetos y caché del navegador

La caché de objetos (vía Redis) almacena en memoria los resultados de consultas costosas. Menos espectacular que la caché de página completa (reducción del 30-50% en tiempo de consulta) pero mucho más sencilla — PrestaShop gestióna la invalidación automáticamente.

Las cabeceras de caché del navegador indican a los navegadores de sus visitantes que almacenen los archivos estáticos localmente:

# Apache (.htaccess)
<IfModule mod_expires.c>
    ExpiresActive On
    ExpiresByType image/jpeg "access plus 1 year"
    ExpiresByType image/webp "access plus 1 year"
    ExpiresByType text/css "access plus 1 month"
    ExpiresByType application/javascript "access plus 1 month"
    ExpiresByType font/woff2 "access plus 1 year"
</IfModule>

Principales problemas de rendimiento

• Demasiados módulos (50+): Cada uno añade sobrecarga del autoloader, callbacks de hooks, CSS/JS y consultas. Una tienda con 30 módulos siempre supera a una con 80. No existe un módulo de coste cero.
• Módulos que cargan recursos en todas las páginas: Un módulo de popup que solo se activa en la página de inicio pero carga 150KB de JavaScript en cada página es puro desperdicio. Revise su gráfico en cascada en busca de recursos de módulos irrelevantes.
• Sliders pesados en la página de inicio: 3-5 imágenes en alta resolución más una librería JS = 1-5MB para un componente con el que menos del 1% de los usuarios interactúa más allá de la primera diapositiva. Utilice una sola imagen estática como hero en su lugar.
• Temas personalizados sin optimizar: Bootstrap completo cargado para 3 componentes, CSS/JS sin minificar, imágenes sin dimensiones, scripts síncronos. Exija auditorías de rendimiento a los desarrolladores de temas.
• Índices de base de datos faltantes: Una consulta con un índice adecuado tarda 10ms. Sin él, tarda 5 segundos — y no lo notará hasta los picos de tráfico.

Lista de verificación de monitorización del rendimiento

Comprobaciones rápidas (5 minutos)

• Ejecute PageSpeed Insights en la página de inicio, página de categoría y página de producto
• Verifique que _PS_MODE_DEV_ sea false
• Confirme que Smarty NO está configurado en “Force compilation”
• Compruebe que CCC está activado
• Verifique que OPcache está activo mediante phpinfo()

Mantenimiento mensual (30 minutos)

• Limpie los carritos abandonados en ps_cart / ps_cart_product (anteriores a 3 meses)
• Limpie ps_log, ps_connections, ps_connections_page, ps_guest
• Ejecute OPTIMIZE TABLE en las tablas limpiadas
• Revise el registro de consultas lentas
• Desinstale los módulos que no utilice

Revisión trimestral (2 horas)

• Prueba completa con GTmetrix desde múltiples ubicaciones — compare con el trimestre anterior
• Revise los Core Web Vitals en Google Search Console
• Audite los recursos de módulos en busca de CSS/JS innecesarios
• Compruebe los tamaños de las imágenes — asegúrese de que no haya subidas sobredimensionadas
• Revise el uso de recursos del servidor (CPU, RAM, E/S de disco)
• Pruebe en un dispositivo móvil real, no solo con emulación
• Verifique las cabeceras de caché del navegador
• Revise los registros de errores de PHP (los errores consumen recursos)

Después de cada despliegue

• Limpie la caché de PrestaShop
• Restablezca OPcache si validate_timestamps=0
• Ejecute una prueba rápida de PageSpeed para detectar regresiones
• Revise la consola del navegador en busca de errores de JavaScript
• Pruebe el flujo de pago de principio a fin

Empiece aquí

La optimización del rendimiento es un proceso, no un destino. Comience con los cuatro elementos de mayor impacto: corrija la configuración de su servidor, optimice sus imágenes, desactive los módulos innecesarios y limpie su base de datos. Solo esto resuelve el 80% de los problemas de rendimiento en la mayoría de las tiendas PrestaShop.

Mida antes y después de cada cambio. Lleve un registro. La mejor optimización es la que sus clientes notan — una carga de imágenes más rápida y un proceso de pago ágil se traducen directamente en confianza, satisfacción y conversiones.