Optimización del rendimiento de PrestaShop 9: guía completa

Una tienda PrestaShop lenta rara vez tiene una sola causa.

El rendimiento es el resultado conjunto de PHP, las consultas SQL, los módulos, los hooks, las imágenes, el almacenamiento, la configuración de caché, los procesos en segundo plano, los ajustes del servidor web, los servicios de terceros y la evolución del catálogo.

PrestaShop 9 ofrece una base técnica más sólida que las generaciones anteriores. Utiliza Symfony 6.4, admite versiones modernas de PHP, incorpora soporte nativo para imágenes WebP y AVIF y aporta varias mejoras del front-office y del renderizado.

Pero actualizar a PrestaShop 9 no hace que todas las tiendas sean rápidas automáticamente.

Un módulo mal programado puede seguir ejecutando una consulta SQL costosa en cada página. Una importación de proveedor puede saturar la CPU y el disco. Un tema puede cargar imágenes de producto demasiado grandes. Una base de datos grande puede seguir sufriendo por falta de índices.

Por tanto, la forma correcta de optimizar PrestaShop 9 es:

medir → identificar el cuello de botella → hacer un solo cambio → volver a medir

Este principio también se refleja en la documentación de rendimiento de PrestaShop.

Esta guía ofrece un proceso práctico de optimización para tiendas reales en producción.

Nota de versión: Este artículo se verificó el 22 de septiembre de 2026. PrestaShop 9.1 recomienda actualmente PHP 8.5, mientras que PrestaShop 9.0 recomienda PHP 8.4. Prueba siempre tus módulos y tu tema con la versión exacta de PHP que vayas a utilizar.

1. Establecer una referencia de rendimiento

No empieces cambiando ajustes al azar en el Back Office.

Primero mide el rendimiento de la tienda.

Como mínimo, registra el rendimiento de las siguientes páginas:

• página de inicio;
• página de categoría;
• página de producto;
• búsqueda;
• carrito;
• proceso de compra;
• página de producto del Back Office;
• página de pedido del Back Office.

No midas únicamente el tiempo total de carga en el navegador.

Entre las métricas útiles están:

• Time to First Byte (TTFB);
• tiempo de ejecución de PHP;
• tiempo de consultas a la base de datos;
• número de consultas SQL;
• bytes totales transferidos;
• Largest Contentful Paint;
• Interaction to Next Paint;
• Cumulative Layout Shift;
• uso de memoria de PHP;
• duración de la tarea cron más lenta.

Esto crea un punto de referencia.

Si cambias los ajustes de PHP-FPM y el TTFB empeora un 15 %, sabrás que el cambio no ha ayudado.

Sin una referencia inicial, la optimización se convierte en una suposición.

2. Probar en condiciones similares a producción

No hagas pruebas de rendimiento únicamente con el modo de depuración activado.

El modo de desarrollo cambia el comportamiento de la aplicación y puede desactivar o modificar la caché.

Tampoco midas el rendimiento solo como administrador conectado si la mayoría de los clientes navega sin iniciar sesión.

Prueba con:

• un visitante anónimo;
• un cliente con un carrito;
• un cliente que ha iniciado sesión;
• un dispositivo móvil;
• un ordenador de escritorio.

Repite también las pruebas mientras se ejecutan tareas en segundo plano.

Una tienda puede parecer rápida a las 03:00 cuando no se ejecuta nada más y volverse lenta cada mañana al comenzar una importación del proveedor.

3. Encontrar el verdadero cuello de botella

Una página lenta puede deberse a distintas capas del sistema.

Cuello de botella de CPU

Los síntomas pueden incluir:

• procesos PHP con alto uso de CPU;
• el procesamiento de imágenes que ralentiza el servidor;
• importaciones que compiten con el tráfico de clientes;
• generación de AVIF con un consumo considerable de CPU.

Cuello de botella de memoria

Los síntomas pueden incluir:

• procesos terminados por falta de memoria (OOM);
• errores de memoria de PHP;
• uso de swap por el servidor;
• la expulsión de la caché de la base de datos de la RAM.

Cuello de botella de la base de datos

Los síntomas pueden incluir:

• páginas de categoría lentas;
• listados del Back Office que agotan el tiempo de espera;
• uso elevado de CPU por la base de datos;
• crecimiento del registro de consultas lentas;
• escaneos completos de tablas.

Cuello de botella de disco

Los síntomas pueden incluir:

• generación de imágenes extremadamente lenta;
• tiempo de espera de E/S elevado;
• consultas SQL lentas pese a un uso moderado de CPU;
• operaciones del sistema de archivos que retrasan la generación de caché.

Cuello de botella de red

Los síntomas pueden incluir:

• llamadas a API remotas que retrasan PHP;
• feeds lentos de terceros;
• configuración incorrecta de la CDN;
• imágenes grandes.

No optimices la capa equivocada.

4. Utilizar la versión de PHP correcta

Los requisitos oficiales actuales de PrestaShop 9 recomiendan:

• PHP 8.4 para PrestaShop 9.0
• PHP 8.5 para PrestaShop 9.1

Utilizar una versión moderna y compatible de PHP puede mejorar tanto el rendimiento como el mantenimiento.

Pero no cambies primero la producción.

Prueba:

• el núcleo de PrestaShop;
• el tema;
• los módulos de pago;
• los módulos de envío;
• las importaciones;
• las tareas cron;
• la CLI;
• los módulos personalizados.

Los errores de PHP a menudo aparecen solo en casos excepcionales.

5. Activar OPcache

OPcache es uno de los requisitos básicos de un entorno PHP con buen rendimiento.

Sin OPcache, PHP analiza y compila repetidamente los archivos de la aplicación.

PrestaShop tiene una base de código grande y los módulos añaden todavía más archivos PHP.

Una configuración PHP de producción normalmente debería tener OPcache activado.

Un ejemplo de configuración sería:

opcache.enable=1
opcache.memory_consumption=256
opcache.interned_strings_buffer=32
opcache.max_accelerated_files=50000
opcache.validate_timestamps=1

Estos valores son ejemplos, no recomendaciones universales.

Comprueba las estadísticas reales de OPcache.

Entre las métricas importantes están:

• memoria utilizada;
• memoria libre;
• tasa de aciertos de caché;
• número de scripts almacenados en caché;
• número de reinicios.

Si OPcache se reinicia constantemente porque la caché está llena, aumenta su tamaño basándote en datos medidos.

6. No desactives la validación de marcas de tiempo a ciegas

Algunas guías de rendimiento recomiendan:

opcache.validate_timestamps=0

Esto puede reducir las comprobaciones de archivos.

Sin embargo, también significa que los cambios en archivos PHP pueden no detectarse hasta que se reinicie OPcache o PHP-FPM.

Si tu proceso de despliegue reinicia explícitamente OPcache, este enfoque puede ser seguro.

Si los administradores suben archivos de módulos manualmente, puede darse una situación confusa en la que el código nuevo está en disco pero sigue ejecutándose el bytecode antiguo.

La configuración de rendimiento debe adaptarse a tu flujo de despliegue.

7. Dimensionar correctamente PHP-FPM

Demasiados pocos workers crean colas de espera.

Demasiados workers pueden agotar la RAM.

Supongamos que un worker PHP de PrestaShop consume aproximadamente 150 MB bajo carga.

Si permites:

pm.max_children = 40

entonces la exposición teórica de memoria de los workers será:

40 × 150 MB = 6000 MB

Esto no incluye:

• MySQL/MariaDB;
• Redis;
• Nginx/Apache;
• el sistema operativo;
• la caché del sistema de archivos;
• las tareas cron.

En un servidor de 8 GB, esta configuración podría ser peligrosa.

Mide el consumo medio y máximo de memoria de los workers y deja un margen de seguridad.

8. Separar PHP web de las tareas CLI pesadas

Un cliente que abre una página de producto no debería competir directamente con una importación de tres horas usando el mismo modelo de procesos.

Las tareas pesadas deberían ejecutarse mediante:

• CLI;
• cron;
• colas;
• workers dedicados.

Ejemplos:

• análisis de XML de proveedores;
• regeneración de imágenes;
• sincronización de stock;
• actualizaciones de precios;
• generación de sitemaps;
• generación de feeds.

Esto facilita el control del uso de recursos.

9. Perfilar las consultas SQL

La optimización de la base de datos puede aportar algunas de las mayores mejoras en tiendas grandes.

Activa el registro de consultas lentas de la base de datos durante un período controlado.

Busca:

• consultas que recorren tablas enormes;
• índices ausentes;
• consultas repetidas;
• consultas que ordenan grandes conjuntos de datos;
• joins cuya cardinalidad crece desmesuradamente.

Después utiliza:

EXPLAIN

para examinar el plan de ejecución.

No optimices basándote solo en el aspecto de la consulta.

Una consulta compleja puede ser rápida con el índice adecuado.

Una consulta sencilla puede ser desastrosa si recorre millones de filas.

10. Añadir índices según las consultas reales

Los índices son extremadamente útiles, pero tienen un coste.

Cada índice:

• consume almacenamiento;
• utiliza memoria;
• aumenta el coste de escritura;
• debe mantenerse durante las inserciones y actualizaciones.

Supongamos que un proceso de un módulo ejecuta repetidamente:

SELECT *
FROM ps_module_queue
WHERE id_shop = 2
  AND status = 'pending'
ORDER BY id_queue
LIMIT 100;

Un índice compuesto adecuado puede reducir drásticamente el trabajo.

Por ejemplo:

(id_shop, status, id_queue)

Pero el índice correcto depende de la consulta real y de la distribución de los datos.

Utiliza EXPLAIN antes y después.

11. Evitar SELECT * en las rutas críticas

En consultas administrativas ocasionales, seleccionar todas las columnas puede no importar.

En consultas frecuentes sobre tablas anchas, puede desperdiciar:

• operaciones de E/S de la base de datos;
• transferencia de red;
• memoria PHP;
• tiempo de hidratación de datos.

Selecciona únicamente los campos que realmente necesita la operación.

Esto es especialmente importante en:

• procesos de colas;
• sincronización de productos;
• endpoints de estado;
• paneles de control.

12. Auditar las tablas grandes

Examina el tamaño de las tablas.

Entre las fuentes habituales de crecimiento descontrolado están:

• los registros de los módulos;
• el historial de importaciones;
• el historial de colas;
• los datos abandonados;
• las estadísticas de visitantes;
• las tablas temporales;
• los registros de auditoría.

No elimines datos solo porque una tabla sea grande.

Primero determina:

• quién es el propietario de los datos;
• si son necesarios para contabilidad;
• si son necesarios para soporte;
• si son necesarios para auditorías;
• si el módulo espera encontrarlos.

Después, define una política explícita de retención.

Inspeccionar el almacenamiento de estadísticas antes de limpiar

Utiliza el escáner gratuito Stats Table Guard Lite para revisar estimaciones del tamaño de las tablas, el historial de conexiones y el estado de recopilación de estadísticas. La evaluación es de solo lectura y puede mostrar metadatos parciales en alojamientos restringidos.

Si necesitas un proceso independiente de vista previa y limpieza, consulta Stats Table Guard Pro. La compra de Pro aún no está habilitada. Sus controles de limpieza descritos aplican un período de retención y lotes transaccionales iniciados expresamente a estadísticas históricas de conexiones; eliminar filas no garantiza una reducción inmediata del tamaño del archivo de la base de datos.

Consulta la Documentación de Stats Table Guard para conocer los pasos del análisis y el alcance de cada edición.

13. Procesar las actualizaciones masivas por lotes

Una tarea que actualiza 100.000 productos en una sola transacción es difícil de gestionar.

Los problemas incluyen:

• bloqueos prolongados;
• transacciones grandes;
• crecimiento del uso de memoria;
• riesgo de superar el tiempo de espera;
• reintentos complicados.

Un diseño más seguro procesa lotes de tamaño limitado:

100 productos
→ guardar el progreso
→ siguientes 100
→ guardar el progreso
→ continuar

El tamaño óptimo de los lotes depende de la carga de trabajo.

Prueba con 50, 100, 500 o 1000 y mide los resultados.

14. Actualizar solo los productos modificados

Una de las mejores optimizaciones en la sincronización de proveedores es evitar escrituras innecesarias.

Si los datos del proveedor no han cambiado, no vuelvas a escribir el producto.

Un método útil es emplear un hash de origen.

Por ejemplo:

datos de producto normalizados
        ↓
hash SHA-256
        ↓
comparar con el hash guardado
        ↓
sin cambios → omitir
modificado → actualizar

Los sistemas grandes pueden mantener hashes separados para:

• los datos principales del producto;
• el precio;
• las existencias;
• las características;
• las imágenes;
• las categorías.

Así, un cambio de imagen no obliga a reescribir todos los campos del producto.

15. Perfilar módulos según su coste de ejecución

No supongas que una tienda es lenta porque tiene «demasiados módulos».

El número de módulos no es el indicador principal.

Un módulo ineficiente puede ralentizar más que cincuenta módulos eficientes.

Busca módulos que:

• se ejecutan en hooks globales;
• ejecutan muchas consultas SQL;
• llaman a API remotas durante la generación de páginas;
• procesan grandes cantidades de datos en cada petición;
• cargan servicios innecesarios;
• calculan repetidamente el mismo resultado.

Desactiva los módulos no esenciales uno a uno en el entorno de pruebas y compara el rendimiento.

16. Evitar llamadas HTTP remotas durante la generación de páginas

Una página de producto no debería esperar a una API de terceros salvo que sea imprescindible.

Si un módulo ejecuta:

solicitud del cliente
→ PrestaShop
→ API remota
→ esperar
→ generar la página

entonces el servicio remoto pasa a formar parte del tiempo de respuesta de la página.

Entre las mejores alternativas se incluyen:

• una caché local;
• sincronización en segundo plano;
• actualizaciones programadas;
• procesamiento asíncrono.

Por ejemplo, los tipos de cambio pueden actualizarse periódicamente en lugar de descargarse en cada carga de página.

17. Auditar la ejecución de hooks

Algunos hooks se ejecutan en muchas páginas.

Si un módulo vincula una operación costosa a un hook global, su coste se multiplica en cada petición.

Analiza el rendimiento de:

• los hooks de cabecera;
• los hooks de pie de página;
• los hooks de presentación de productos;
• los hooks del carrito;
• los hooks de clientes.

Pregúntate si la operación debe ejecutarse cada vez.

Quizá un hook solo necesite mostrar datos previamente almacenados en caché.

18. Usar el soporte nativo de WebP y AVIF

PrestaShop 9 introdujo compatibilidad nativa con:

• WebP;
• AVIF.

La información oficial de lanzamiento de PrestaShop 9 destaca expresamente estos formatos como mejoras de rendimiento.

Los formatos modernos pueden reducir mucho el tamaño de las imágenes transferidas.

Sin embargo, el formato del archivo es solo una parte de la optimización de imágenes.

Ten en cuenta también:

• las dimensiones;
• la calidad de compresión;
• el número de tipos de imagen generados;
• las imágenes adaptables;
• la carga diferida;
• la caché de CDN.

19. Eliminar tipos de imagen no utilizados

Los temas y módulos pueden registrar varios tamaños de imagen.

Un catálogo grande puede generar millones de archivos.

Ejemplo:

100,000 productos
× 4 imágenes
× 10 tipos de imagen
= 4,000,000 archivos generados

Si el tema actual solo utiliza seis de esos tipos de imagen, los otros cuatro pueden suponer almacenamiento y regeneración innecesarios.

Revisa cada tipo de imagen antes de eliminar nada.

Comprueba:

• las plantillas del tema;
• los módulos;
• las plantillas de correo;
• los feeds;
• los marketplaces.

20. No servir imágenes demasiado grandes

Una ficha de producto mostrada a 300 × 300 píxeles no debería descargar una imagen de 2000 × 2000.

El navegador puede cambiar visualmente su tamaño, pero el cliente sigue descargando y decodificando el archivo más grande.

Sirve una imagen cercana al tamaño mostrado.

Esto reduce:

• el ancho de banda;
• el consumo de datos móviles;
• el tiempo de decodificación;
• el Largest Contentful Paint.

21. Cargar diferidamente las imágenes fuera de pantalla

Las imágenes inicialmente fuera de la zona visible no siempre deben descargarse de inmediato.

La carga diferida puede reducir mucho la carga inicial de red en:

• las páginas de categorías;
• los resultados de búsqueda;
• los carruseles de productos relacionados.

No apliques carga diferida a la imagen principal del Largest Contentful Paint de una página de producto sin probarlo.

La imagen principal destacada puede necesitar cargarse inmediatamente.

22. Utilizar la caché del navegador

La documentación actual de PrestaShop sobre optimización de Nginx recomienda configurar cabeceras de caché para archivos estáticos.

Los recursos estáticos como:

• CSS;
• JavaScript;
• las fuentes;
• JPG;
• PNG;
• WebP;
• AVIF;

pueden almacenarse en caché durante mucho tiempo si el versionado de las URL es fiable.

Esto reduce el tráfico repetido y acelera la navegación.

23. Comprimir los recursos de texto

La compresión Gzip o Brotli puede reducir el tamaño de:

• HTML;
• CSS;
• JavaScript;
• JSON;
• XML.

Los formatos de imagen como JPG, WebP y AVIF ya están comprimidos y generalmente no se benefician de gzip genérico.

Configura la compresión en el servidor web o en la CDN.

24. Usar una CDN cuando aporte ventajas

Una CDN resulta útil para:

• las imágenes;
• CSS;
• JavaScript;
• las fuentes.

Puede mejorar la latencia para clientes geográficamente distantes y reducir la carga del servidor de origen.

Pero una CDN no soluciona una respuesta PHP de 2 segundos.

Separa:

tiempo de generación del servidor

de:

tiempo de entrega de recursos

al diagnosticar el rendimiento.

25. Tener cuidado con la caché de páginas completas

La caché de página completa puede ser potente, pero el comercio electrónico es personalizado.

El contenido puede variar según:

• el cliente;
• el grupo de clientes;
• el carrito;
• la moneda;
• el idioma;
• la tienda;
• el país;
• las reglas fiscales.

Una clave de caché que ignore esas dimensiones puede mostrar datos incorrectos:

• los precios;
• los carritos;
• las promociones;
• los datos de clientes.

No sacrifiques la corrección por mejorar una puntuación de benchmark.

26. Redis es una herramienta, no un interruptor mágico

Redis puede resultar útil para:

• la caché;
• las sesiones;
• el estado de las colas;
• los bloqueos distribuidos.

Pero añadir Redis a un módulo mal diseñado no corrige sus malas consultas SQL.

Si el 80 % del tiempo de respuesta de una página corresponde a una consulta costosa, optimiza esa consulta primero.

Utiliza Redis cuando las mediciones demuestren que resuelve un problema concreto.

27. Optimizar el servidor web

La documentación de PrestaShop 9 incluye orientación específica para optimizar el servidor web.

Entre las áreas importantes se incluyen:

• keep-alive;
• compatibilidad con HTTP/2 o protocolos más recientes;
• la compresión;
• las cabeceras de caché;
• los límites de conexiones;
• la sobrecarga del registro de eventos;
• la configuración TLS.

Tanto Nginx como Apache pueden ofrecer un buen rendimiento.

No cambies de servidor web solo porque una publicación de foro afirme que uno siempre es más rápido.

28. Revisar los registros de acceso

Los registros de acceso son esenciales para diagnóstico y seguridad.

También generan operaciones de E/S.

En tiendas con mucho tráfico, registrar detalladamente cada recurso estático puede generar actividad de disco innecesaria.

Posibles estrategias:

• registros separados para recursos estáticos;
• almacenamiento en búfer;
• muestreo cuando corresponda;
• retención más breve;
• desactivar los registros de acceso para ciertos recursos estáticos poco importantes.

No elimines los registros necesarios para investigar incidentes.

29. Mover importaciones pesadas fuera de las horas punta

Si una importación grande de proveedores utiliza:

• el 80 % de la CPU;
• escrituras intensivas en la base de datos;
• procesamiento constante de imágenes;

los clientes lo notarán.

Programa las tareas pesadas en horas de menor tráfico siempre que sea posible.

Si necesitas sincronización en tiempo real, divide el proceso en pequeños lotes continuos.

30. Utilizar bloqueos para las tareas cron

La ejecución duplicada de tareas cron puede destruir el rendimiento.

Un cron que se ejecuta cada minuto puede iniciar otra instancia mientras la anterior sigue activa.

Utiliza:

• bloqueos del sistema de archivos;
• leasing de trabajos en la base de datos;
• bloqueos Redis;
• propiedad explícita de los trabajos.

Un bloqueo robusto debe caducar o permitir recuperarse después de un fallo.

No uses un indicador booleano permanente que pueda quedar bloqueado para siempre.

31. Separar los procesos cron independientes

Un único bloqueo global para todas las tareas automatizadas puede reducir innecesariamente el rendimiento.

Por ejemplo:

creación de productos nuevos
actualización de stock
actualización de precios
descarga de imágenes

pueden ser independientes.

Si la creación queda bloqueada por una categoría sin asignar, las actualizaciones de existencias de productos existentes deberían poder continuar.

Define los bloqueos en el nivel correcto del flujo de trabajo.

32. Supervisar el tamaño de las colas

Si una cola recibe trabajo más rápido de lo que los procesos lo completan, el sistema acumula retraso.

Supervisa:

• el número pendiente;
• el número de reintentos;
• el número de fallos;
• la antigüedad de la tarea pendiente más antigua;
• la tasa de procesamiento.

Una cola de 50 000 elementos no es necesariamente un problema si procesa 20 000 por hora.

Una cola de 500 elementos puede ser un problema grave si ninguno ha avanzado en dos días.

33. Limitar los reintentos

Reintenta las operaciones que hayan fallado temporalmente.

Ejemplos:

• tiempo de espera agotado del proveedor;
• HTTP 503;
• un interbloqueo temporal en la base de datos.

No reintentes indefinidamente fallos de validación permanentes.

Ejemplos:

• categoría desconocida;
• conjunto duplicado de atributos de combinación;
• campo obligatorio no válido.

Al superar un umbral, mueve el elemento a un estado bloqueado o fallido.

Así evitas que los registros defectuosos consuman recursos indefinidamente.

34. Optimizar la búsqueda por separado

La búsqueda puede tener características de rendimiento muy distintas de la navegación habitual por productos.

Los catálogos grandes pueden necesitar:

• indexación optimizada de la búsqueda nativa;
• módulos de búsqueda específicos;
• motores de búsqueda externos.

No instales una gran plataforma de búsqueda a menos que el catálogo y las necesidades de búsqueda lo justifiquen.

Mide por separado la latencia y la relevancia de la búsqueda.

35. Mantener rápido el Back Office

La optimización del rendimiento no solo afecta a los clientes.

Un Back Office lento hace perder tiempo a los empleados.

Mide:

• la página de producto;
• la tabla de productos;
• los pedidos;
• las páginas de existencias;
• la configuración de módulos;
• las acciones masivas.

Un módulo personalizado que añada una consulta lenta a cada lista de pedidos puede causar cientos de horas de trabajo perdidas al año.

36. Utilizar paginación en todas partes

Nunca muestres decenas de miles de registros en una sola tabla del Back Office.

Utiliza:

• la paginación;
• los filtros;
• la ordenación indexada;
• consultas del lado del servidor.

Del mismo modo, las páginas de estado deberían mostrar resúmenes y elementos recientes en lugar de cargar todo el historial de la cola.

37. Mantener ligeras las consultas del panel

Los paneles se abren con frecuencia.

No calcules estadísticas históricas costosas en cada carga de página.

Precalcula o almacena en caché:

• los totales;
• los agregados diarios;
• los recuentos de fallos recientes.

Un panel operativo debe responder con rapidez sin convertirse en una de las principales cargas de la base de datos.

38. Desactivar el modo depuración en producción

El modo desarrollador resulta útil para diagnosticar problemas.

No debe permanecer activado en una tienda de producción.

Los ajustes de desarrollo pueden:

• mostrar errores sensibles;
• desactivar la caché;
• aumentar el registro de eventos;
• reducir el rendimiento.

Utiliza el modo producción durante el funcionamiento normal.

39. Monitorizar el rendimiento real de usuarios

Las herramientas de pruebas sintéticas son útiles.

La monitorización de usuarios reales muestra la experiencia real de los clientes.

Sigue las métricas por:

• el dispositivo;
• el país;
• el tipo de página;
• el navegador.

Una prueba en escritorio con conexión rápida puede ocultar una página de categoría lenta en móviles.

40. Configurar alertas de rendimiento

Establece umbrales que sean relevantes para el negocio.

Ejemplos:

• TTFB del producto superior a 800 ms;
• cola de PHP-FPM por encima de un umbral;
• CPU de la base de datos por encima del 90 % durante cinco minutos;
• espacio libre en disco inferior al 15 %;
• la duración de una tarea cron se duplica;
• el elemento más antiguo de la cola de importación supera una hora.

Las alertas deben dar lugar a acciones.

Evita alertas por cada fluctuación mínima.

Ejemplo de flujo de optimización de PrestaShop 9

Un proyecto práctico de optimización podría ser así:

Fase 1 — Medir

Captura:

TTFB de la página de inicio: 900 ms
TTFB de categoría: 1.8 s
TTFB de producto: 1.2 s
TTFB del checkout: 800 ms

Fase 2 — Perfilar

Detecta:

Consulta de categoría: 900 ms
Llamada API del módulo: 350 ms
Procesamiento PHP: 300 ms

Fase 3 — Corregir el mayor cuello de botella

Añade un índice de base de datos basado en datos objetivos.

Nuevo TTFB de categoría:

650 ms

Fase 4 — Corregir la llamada remota del módulo

Almacena en caché los datos remotos durante cinco minutos.

Nuevo TTFB de categoría:

320 ms

Fase 5 — Optimizar las imágenes

Reduce en un 40 % los bytes iniciales de imágenes transferidas.

Ahora el trabajo cuenta con pruebas medibles.

Ejemplo de arquitectura para un catálogo grande

Para una tienda grande automatizada:

                        ┌──────────────┐
Clientes ─────────────▶│ Nginx / CDN  │
                        └──────┬───────┘
                               │
                        ┌──────▼───────┐
                        │ PHP-FPM      │
                        │ PrestaShop 9 │
                        └──────┬───────┘
                               │
                     ┌─────────▼─────────┐
                     │ MySQL / MariaDB   │
                     └───────────────────┘

Segundo plano:
Flujo del proveedor → Cola → Procesos de productos
                         ├─ proceso de stock
                         ├─ proceso de precios
                         └─ proceso de imágenes

Esto separa las peticiones interactivas del trabajo pesado en segundo plano.

Lista de comprobación de rendimiento

PHP

• Versión PHP compatible
• OPcache habilitado
• OPcache con tamaño suficiente
• Procesos PHP-FPM medidos
• Modo producción activado
• Versiones PHP web y CLI comprobadas

Base de datos

• Registro de consultas lentas revisado
• Consultas costosas analizadas con EXPLAIN
• Índices basados en la carga real
• Tablas históricas sobredimensionadas revisadas
• Actualizaciones grandes procesadas por lotes

Módulos

• Hooks globales analizados
• Llamadas remotas eliminadas de las rutas críticas
• Módulos sin uso eliminados
• Paneles costosos almacenados en caché

Imágenes

• WebP/AVIF habilitado cuando convenga
• Tipos de imagen sin uso eliminados
• Dimensiones adaptables utilizadas
• Carga diferida de imágenes fuera de pantalla
• Regeneración mediante tareas controladas

Servidor

• SSD/NVMe
• Suficiente RAM libre
• Sin uso de swap con carga normal
• Compresión habilitada
• Cabeceras de caché del navegador configuradas
• CDN para recursos estáticos considerado

Automatización

• Las tareas cron utilizan bloqueos
• Las tareas pesadas se procesan por lotes
• Se supervisa el estado de las colas
• Los reintentos están limitados
• El trabajo pesado está separado del tráfico de clientes

Monitorización

• Latencia HTTP supervisada
• Saturación de procesos PHP supervisada
• Base de datos supervisada
• Uso de disco e inodos supervisado
• Duración de las tareas cron supervisada
• Alertas configuradas

Preguntas frecuentes

¿Cuál es la forma más rápida de acelerar PrestaShop 9?

Mide primero. La mejora de más valor suele ser el mayor cuello de botella real: SQL, un módulo, imágenes, saturación de PHP-FPM o una tarea en segundo plano.

¿Admite PrestaShop 9 WebP y AVIF?

Sí. La compatibilidad nativa con WebP y AVIF se introdujo en PrestaShop 9.

¿Qué versión de PHP es mejor para PrestaShop 9?

La tabla oficial de compatibilidad actual recomienda PHP 8.4 para PrestaShop 9.0 y PHP 8.5 para PrestaShop 9.1.

¿Redis hará que PrestaShop 9 sea más rápido?

Puede ayudar en ciertos usos de caché, sesiones, colas o bloqueos. No corrige automáticamente PHP o SQL lentos.

¿Debería añadir más núcleos de CPU?

Solo si la CPU es el cuello de botella. Si la base de datos espera a un almacenamiento lento o PHP a una API remota, más núcleos pueden aportar poco.

¿Por qué la tienda solo va lenta durante las importaciones?

La importación probablemente compite con el tráfico web por CPU, RAM, base de datos o E/S de disco. Reduce la concurrencia, procesa por lotes, cambia la programación o separa procesos.

¿Cómo acelerar una tienda de 100.000 productos?

Céntrate en importaciones incrementales, hashes de origen, consultas indexadas, colas limitadas, procesamiento de imágenes, optimización de base de datos y eliminación de escrituras innecesarias de productos.

¿Es Nginx más rápido que Apache?

Ambos pueden funcionar bien. La configuración y el comportamiento de la aplicación suelen importar más que la marca del servidor.

¿Debería vaciar la caché cada hora?

No. Invalidar constantemente cachés útiles puede reducir el rendimiento. Invalídalas solo cuando sea necesario.

¿Con qué frecuencia debo revisar el rendimiento?

Supervisa continuamente las métricas clave y realiza auditorías profundas tras grandes versiones, cambios de módulos o infraestructura o crecimientos importantes del catálogo.

Guías y recursos relacionados con PrestaShop 9

• 10 formas prácticas de acelerar PrestaShop 9
• guía SEO para PrestaShop 9
• requisitos del sistema de PrestaShop 9

Cuando los síntomas de lentitud son en realidad fallos de la aplicación

Si las peticiones lentas o inestables terminan en errores 500 intermitentes, utiliza el procedimiento seguro para diagnosticar errores HTTP 500 en producción. Crash Snapshot Lite puede capturar incidentes compatibles de la aplicación sin dejar activado el modo de depuración completo.