10 formas prácticas de acelerar tu tienda PrestaShop 9
PrestaShop 9 ofrece a los comerciantes una base técnica más moderna, pero la velocidad de la tienda sigue dependiendo mucho de la configuración, los módulos, el diseño de la base de datos, las imágenes, el alojamiento y las tareas en segundo plano.
No existe una única casilla que haga rápidas todas las tiendas PrestaShop.
El enfoque más eficaz consiste en identificar los principales cuellos de botella y solucionarlos por orden.
Esta guía se centra en diez mejoras que pueden ofrecer resultados significativos en tiendas reales, sin recurrir a consejos vagos como «contrata un alojamiento mejor».
Nota sobre versiones: Este artículo se verificó el 22 de septiembre de 2026. PrestaShop 9.0 recomienda PHP 8.4, mientras que PrestaShop 9.1 admite y recomienda PHP 8.5. PrestaShop 9 incorpora compatibilidad nativa con WebP y AVIF y varias mejoras de rendimiento del front office.
Antes de cambiar nada: mide la tienda
Antes de aplicar optimizaciones, registra un punto de referencia.
Prueba varios tipos de páginas:
- página de inicio;
- categoría;
- producto;
- búsqueda;
- carrito;
- proceso de compra;
- página de producto del back office;
- página de pedido del back office.
Mide:
- Time to First Byte;
- peso total de la página;
- número de solicitudes;
- Largest Contentful Paint;
- tiempo de respuesta del servidor;
- tiempo de ejecución de PHP;
- consultas lentas a la base de datos;
- duración de cron.
Si es posible, realiza las pruebas mientras se ejecutan las tareas habituales en segundo plano.
Una tienda puede parecer rápida cuando no hay importaciones ni sincronizaciones activas y ralentizarse mucho cuando empiezan esas tareas.
La finalidad del punto de referencia es sencilla: vuelve a medir después de cada cambio importante.
1. Usar la versión correcta de PHP
Una de las comprobaciones más sencillas es el entorno de ejecución de PHP.
La tabla actual de compatibilidad de PrestaShop recomienda:
- PHP 8.4 para PrestaShop 9.0;
- PHP 8.5 para PrestaShop 9.1.
Las versiones modernas de PHP incluyen mejoras de rendimiento y del motor, pero hay que comprobar la compatibilidad.
No cambies directamente la versión de PHP en producción.
Crea un entorno de pruebas y comprueba:
- página de inicio;
- páginas de producto;
- proceso de compra;
- módulos de pago;
- módulos de envío;
- importaciones;
- tareas cron;
- comandos CLI;
- módulos personalizados.
Comprueba también PHP en la CLI
Un error habitual es comprobar únicamente la versión de PHP utilizada por el sitio web.
Ejecuta:
php -v
desde el mismo entorno que utiliza cron.
Es posible que:
PHP web = 8.5
PHP CLI = 8.2
Esto puede provocar errores desconcertantes: la tienda funciona en el navegador, pero los comandos programados fallan.
Activar OPcache
Una tienda PrestaShop en producción normalmente debería utilizar OPcache.
OPcache mantiene en memoria el bytecode PHP compilado, en lugar de analizar y compilar los archivos PHP una y otra vez.
Comprueba que esté realmente habilitado y que el tamaño de la caché sea suficiente para:
- el núcleo de PrestaShop;
- Symfony;
- los módulos;
- el código personalizado.
No des por hecho que la configuración predeterminada del servidor es óptima.
2. Encontrar los módulos más lentos
La cantidad de módulos instalados no es el principal indicador de rendimiento.
Un único módulo mal diseñado puede ser más lento que cincuenta buenos.
Un módulo puede ralentizar la tienda si:
- ejecuta SQL costoso en cada página;
- realiza solicitudes a API remotas;
- carga grandes conjuntos de datos;
- conecta procesos pesados a hooks globales;
- recalcula datos que podrían almacenarse en caché;
- realiza operaciones con archivos durante la visualización del front office.
Realiza una prueba controlada
En el entorno de pruebas:
- mide una página lenta;
- desactiva un módulo no esencial;
- vuelve a medir;
- repite.
Si el tiempo de carga pasa de:
1.8 segundos
a:
600 milisegundos
al desactivar un solo módulo, has encontrado un objetivo de optimización muy valioso.
No elimines simplemente el módulo si es importante.
Perfila su código e identifica la operación costosa.
3. Optimizar las consultas a la base de datos
Las tiendas PrestaShop grandes suelen estar limitadas por la base de datos.
Una consulta que tarda 20 ms con 1000 productos puede tardar varios segundos tras años de crecimiento del catálogo.
Activa el registro de consultas lentas de la base de datos durante un periodo controlado.
Busca consultas relacionadas con:
- listados de productos;
- páginas de categoría;
- búsqueda;
- cuadrículas del back office;
- sincronización de existencias;
- importaciones;
- feeds.
Después utiliza:
EXPLAIN
para examinar cómo ejecuta la consulta la base de datos.
Presta atención a los escaneos completos
Un módulo puede ejecutar repetidamente algo como:
SELECT *
FROM ps_custom_queue
WHERE status = 'pending'
AND id_shop = 2
ORDER BY id_queue
LIMIT 100;
Si la tabla contiene millones de filas y carece de un índice útil, la base de datos puede recorrer muchos más datos de los necesarios.
Un índice compuesto adecuado podría ser:
(id_shop, status, id_queue)
Pero nunca añadas índices a ciegas.
El índice correcto depende de la consulta real y de la distribución de los datos.
Evitar escrituras redundantes
Actualizar un producto cuando no ha cambiado nada genera innecesariamente:
- escrituras SQL;
- mantenimiento de índices;
- invalidación de caché;
- ejecutar hooks.
Las integraciones con proveedores deberían utilizar marcas de tiempo, hashes o seguimiento de cambios siempre que sea posible.
4. Usar WebP y AVIF correctamente
PrestaShop 9 introdujo compatibilidad nativa con formatos de imagen modernos, entre ellos:
- WebP;
- AVIF.
Estos formatos pueden reducir considerablemente los bytes transferidos de las imágenes.
Pero activar WebP o AVIF no garantiza por sí solo una tienda rápida.
También debes comprobar:
- dimensiones de las imágenes originales;
- tipos de imágenes generadas;
- calidad de compresión;
- tamaños de imagen adaptables;
- carga diferida;
- comportamiento de la CDN.
No cargues una imagen enorme en una tarjeta pequeña
Si una tarjeta de producto de una categoría tiene 320 píxeles de ancho, descargar una imagen de 2000 píxeles es un desperdicio.
El navegador puede mostrarla a 320 píxeles, pero el cliente sigue pagando el coste de descarga y decodificación.
Utiliza un tamaño generado adecuado.
Auditar los tipos de imagen
Los temas y módulos pueden crear muchos tamaños de miniaturas.
Imagina:
80,000 productos
× 4 fotos
× 10 tipos de imagen
Eso puede producir:
3,200,000 imágenes generadas
Si el tema solo utiliza seis tipos de imagen, los demás quizá sean innecesarios.
No los elimines hasta comprobar que:
- los módulos;
- los feeds;
- los correos electrónicos;
- los marketplaces;
no los utilizan.
5. Trasladar el trabajo pesado a CLI y cron
Una solicitud del navegador no es un buen lugar para procesar 100 000 productos.
Las operaciones largas pueden alcanzar:
- los tiempos de espera del proxy;
- los límites de ejecución de PHP;
- las desconexiones del navegador;
- los límites de memoria.
Utiliza CLI, cron o trabajadores de cola para:
- importaciones de proveedores;
- procesamiento de imágenes;
- generación de feeds;
- actualizaciones de precios;
- sincronización de existencias;
- mantenimiento masivo.
Procesa en lotes
En vez de:
Procesar los 100,000 productos
utiliza:
Reservar 200 registros
Procesar
Guardar el progreso
Salir o continuar
Esto facilita:
- reanudar;
- supervisar;
- reintentar;
- detener de forma segura.
Añade bloqueos
Si cron se ejecuta cada minuto y el proceso anterior sigue activo, puede iniciarse un segundo trabajador.
Utiliza bloqueos o concesiones temporales.
Duplicar tareas pesadas puede duplicar el consumo de recursos y provocar datos incoherentes.
6. Almacenar de forma eficaz los recursos estáticos
CSS, JavaScript, las fuentes y las imágenes cambian con mucha menos frecuencia que el HTML.
Configura cabeceras útiles de caché del navegador.
Los recursos estáticos permiten tiempos de caché prolongados cuando los nombres de archivo o las URL cambian con cada despliegue.
Ejemplos:
CSS
JavaScript
JPG
PNG
WebP
AVIF
fuentes
Esto reduce las descargas repetidas y el tráfico del servidor.
Usa una CDN cuando convenga
Una CDN puede mejorar la entrega de archivos estáticos a clientes alejados del servidor de origen.
También puede reducir la carga del servidor web.
Sin embargo, una CDN no soluciona un PHP lento.
Si el Time to First Byte ya tarda dos segundos antes de que el navegador empiece a descargar imágenes, optimiza primero la aplicación.
7. Ten cuidado con la caché de página completa
La caché de página completa parece atractiva porque puede evitar buena parte de la ejecución de PHP.
Pero las páginas de comercio electrónico suelen estar personalizadas.
El contenido puede variar según:
- el cliente;
- el grupo de clientes;
- la moneda;
- el país;
- el idioma;
- las reglas fiscales;
- el contenido del carrito;
- la tienda.
Una caché de páginas mal diseñada puede mostrar incorrectamente:
- el precio;
- el carrito;
- el descuento;
- el bloque de cliente.
Utiliza una caché agresiva solo si su clave representa correctamente todos los contextos importantes.
Para muchas tiendas, la caché de recursos estáticos y la caché a nivel de aplicación son puntos de partida más seguros.
8. Eliminar módulos sin uso y código antiguo
El código que no se utiliza aumenta la complejidad del mantenimiento.
Los módulos antiguos todavía pueden:
- registrar hooks;
- cargar autocargadores;
- dejar tareas cron activas;
- generar consultas a la base de datos;
- introducir problemas de compatibilidad con PHP.
Audita la instalación de producción.
Para cada módulo, pregunta:
- ¿Se utiliza?
- ¿Quién es el responsable?
- ¿Cuándo se actualizó por última vez?
- ¿Tiene alguna tarea programada?
- ¿Almacena datos empresariales?
- ¿Existe alguna alternativa?
Elimina los módulos obsoletos con cuidado.
No borres un módulo sin comprobar si otro sistema depende de sus datos.
Revisa también los overrides
Un override antiguo puede sustituir un método del núcleo por código escrito para una generación anterior de PrestaShop.
Eso puede ocasionar problemas de rendimiento y compatibilidad.
9. Controlar la concurrencia de PHP-FPM
Tener más trabajadores PHP no siempre es mejor.
Supongamos:
Proceso ocupado medio = 180 MB
Si:
pm.max_children = 40
entonces la memoria potencial de los trabajadores es:
7.2 GB
sin contar:
- MySQL;
- Redis;
- Nginx;
- sistema operativo;
- tareas CLI.
En un servidor de 8 GB, eso es arriesgado.
Cuando se agota la memoria, Linux puede utilizar swap o finalizar procesos, lo que provoca latencias graves.
Mide la memoria de los trabajadores con tráfico realista y establece un límite seguro.
El objetivo es tener suficiente concurrencia sin agotar el margen de memoria.
10. Supervisar continuamente el rendimiento
La optimización no es un proyecto que se realiza una sola vez.
El rendimiento cambia cuando:
- crece el catálogo;
- se actualizan los módulos;
- cambia el tema;
- aumenta el tráfico de marketing;
- los proveedores añaden más productos;
- las tareas cron duran más.
Supervisa:
- tiempo de respuesta;
- tasa de HTTP 5xx;
- CPU;
- RAM;
- cola de PHP-FPM;
- conexiones a la base de datos;
- consultas lentas;
- E/S de disco;
- espacio libre en disco;
- uso de inodos;
- trabajos pendientes en la cola;
- duración de cron.
Supervisa también los procesos empresariales
Una importación de productos que tarda 20 minutos hoy y 90 el mes que viene es una regresión de rendimiento, aunque la tienda siga pareciendo rápida.
Registra la duración y el rendimiento de los trabajos.
Auditoría rápida de velocidad de PrestaShop en 30 minutos
Si solo tienes media hora, haz lo siguiente:
1. Comprobar PHP
Confirma:
php -v
y la versión de PHP utilizada por la web.
2. Confirmar OPcache
Asegúrate de que esté activado.
3. Medir tres páginas
Registra:
- página de inicio;
- categoría;
- producto.
4. Revisar SQL lento
Examina las consultas más lentas de la base de datos.
5. Comprobar tamaños de imágenes
Compara las dimensiones mostradas con las dimensiones descargadas.
6. Revisar tareas cron activas
Identifica las tareas que se ejecutan en horas punta.
7. Comprobar la presión del servidor
Inspecciona:
- RAM;
- CPU;
- disco;
- tiempo de espera de E/S.
Esta auditoría breve suele indicar la próxima acción útil.
Ejemplo: corregir una página de categoría lenta
Supongamos que una página de categoría tarda:
2.1 segundos TTFB
El perfilado muestra:
Módulo de filtro personalizado: 950 ms
Consulta de base de datos: 600 ms
Otro procesamiento PHP: 350 ms
Trabajo restante: 200 ms
En lugar de comprar un servidor más grande, comienza por el módulo de filtros personalizado.
Puede que a la consulta le falte un índice.
Después de añadir el índice correcto:
Consulta de base de datos: 80 ms
Después almacena en caché los metadatos de los filtros:
Módulo de filtro: 150 ms
Nuevo TTFB:
780 ms
Es un resultado mucho más eficiente que añadir hardware a ciegas.
Ejemplo: corregir las ralentizaciones provocadas por importaciones
Imagina que la tienda es rápida casi todo el día, pero lenta entre las 02:00 y las 04:00.
La importación del proveedor ejecuta:
análisis completo de productos
descarga completa de imágenes
actualización completa de stock
actualización completa de precios
para cada producto.
Un diseño mejor separa el trabajo:
Análisis del proveedor
↓
Detectar registros modificados
↓
Cola de actualización de productos
├── proceso de precios
├── proceso de stock
└── proceso de imágenes
Ahora se omiten los productos sin cambios.
El trabajador de imágenes puede limitarse a uno o dos procesos.
Las actualizaciones de existencias pueden seguir siendo frecuentes.
Esto reduce los picos de carga del servidor y acorta el trabajo total.
Qué no hacer
No instales todos los «módulos de velocidad» que encuentres
Los módulos de rendimiento pueden entrar en conflicto o almacenar contenido incorrecto en caché.
No vacíes todas las cachés cada minuto
La invalidación constante elimina las ventajas de la caché.
No añadas índices aleatorios a la base de datos
Los índices deben respaldar consultas reales.
No aumentes indefinidamente los límites de memoria
Corrige los algoritmos que consumen demasiada memoria.
No ejecutes cinco trabajadores de imágenes porque uno es lento
Comprueba si el CPU o el disco ya están saturados.
No hagas pruebas de rendimiento solo de la página de inicio
Las cargas de categorías, productos, pago y back office son diferentes.
Lista de comprobación de velocidad de PrestaShop 9
- Versión de PHP compatible y adecuada
- OPcache habilitado
- OPcache con tamaño correcto
- Concurrencia de PHP-FPM medida
- Consultas lentas de base de datos revisadas
- Índices validados con
EXPLAIN - Módulos costosos identificados
- Solicitudes API remotas eliminadas de las rutas críticas
- WebP/AVIF evaluados
- Dimensiones de imágenes correctas
- Tipos de imágenes sin uso eliminados
- Recursos estáticos almacenados en caché
- CDN considerada
- Tareas pesadas ejecutadas en CLI
- Tareas cron con bloqueos
- Importaciones procesadas en lotes
- Productos sin cambios omitidos
- Colas pendientes supervisadas
- Uso de disco e inodos supervisado
- Punto de referencia de rendimiento conservado
Preguntas frecuentes
¿Por qué mi tienda PrestaShop 9 es lenta?
Entre las causas habituales están los módulos lentos, el SQL ineficiente, las imágenes demasiado grandes, demasiados trabajadores PHP, un alojamiento sobrecargado y tareas en segundo plano que compiten con el tráfico de clientes.
¿Qué debo optimizar primero?
El componente más lento según las mediciones. No elijas la solución antes de medir el cuello de botella.
¿PrestaShop 9 admite WebP?
Sí. PrestaShop 9 incorpora soporte nativo para WebP.
¿PrestaShop 9 admite AVIF?
Sí. PrestaShop 9 también incorpora soporte nativo para AVIF.
¿Debo usar PHP 8.5?
PrestaShop 9.1 admite y recomienda actualmente PHP 8.5. PrestaShop 9.0 recomienda PHP 8.4. Prueba los módulos antes de cambiar.
¿Redis mejora la velocidad de PrestaShop?
Puede mejorar algunas cargas de trabajo, pero no soluciona automáticamente el SQL lento ni los módulos ineficientes.
¿Debo actualizar primero el servidor?
Solo cuando la supervisión demuestre que los recursos del servidor son el límite real. Las correcciones de código y base de datos suelen aportar más.
¿Cómo puedo acelerar una importación grande de productos?
Lee los datos de origen en streaming, procesa por lotes, omite registros sin cambios, separa las actualizaciones de productos de las imágenes y limita la concurrencia de trabajadores.