AGTI

PrestaShop lento: cómo saber si el cuello de botella está en el servidor, la base de datos, los módulos o el frontend

Amauri Gabriel
Diagnóstico de rendimiento de una tienda PrestaShop lenta

PrestaShop lento: cómo saber si el cuello de botella está en el servidor, la base de datos, los módulos o el frontend

Cuando una tienda PrestaShop se vuelve lenta, el servidor suele ser el primer sospechoso. Aumentar CPU y memoria puede ayudar si el origen está realmente saturado, pero también puede ocultar un cuello de botella sin eliminarlo. Una consulta sin índice, un hook costoso, un módulo que espera una API durante la generación de la página o demasiado JavaScript de terceros seguirá limitando la experiencia incluso en una infraestructura mayor.

Un diagnóstico útil empieza por dividir la palabra “lento” en síntomas observables. La tienda puede tardar en enviar el primer byte y funcionar bien después; puede entregar el HTML rápidamente, pero bloquearse cuando el comprador interactúa; puede ser rápida para visitantes y lenta para usuarios autenticados; o degradarse solamente durante picos de tráfico y tareas programadas.

Cada escenario apunta a una capa diferente. Esta guía propone un método reproducible para descubrir dónde se consume el tiempo antes de decidir la corrección.

Primero, defina qué está lento

Decir que una página tarda cinco segundos todavía no es un diagnóstico. La espera puede ocurrir antes de que el servidor responda o después de que el navegador reciba el HTML.

Separe al menos cuatro señales:

  • Time to First Byte (TTFB): incluye red, procesamiento del origen y la espera hasta el primer byte. Un TTFB alto orienta la investigación hacia red, servidor web, PHP, base de datos, módulos o servicios externos.
  • Largest Contentful Paint (LCP): indica cuándo se renderiza el principal contenido visible. Imágenes grandes, CSS bloqueante, fuentes y prioridad de recursos influyen en esta métrica.
  • Interaction to Next Paint (INP): mide la respuesta a las interacciones. JavaScript pesado y tareas largas pueden hacer que una página parezca lista, pero reaccione con retraso.
  • Cumulative Layout Shift (CLS): registra movimientos inesperados del diseño, frecuentes cuando banners, imágenes y vitrinas se cargan sin reservar espacio.

Google utiliza como referencias de buena experiencia un LCP de hasta 2,5 segundos, INP inferior a 200 milisegundos y CLS máximo de 0,1. No sustituyen el análisis comercial, pero ayudan a diferenciar carga, capacidad de respuesta y estabilidad. Consulte la documentación de Core Web Vitals de Google.

Pruebe rutas diferentes. Inicio, categoría, producto, búsqueda, carrito, checkout y back office ejecutan controladores, hooks, consultas e integraciones distintas. Un promedio del dominio puede ocultar una página de producto lenta o una pantalla de pedidos que empeora a medida que crece la base.

Cree una línea de base reproducible

Registre una línea de base antes de cambiar módulos, caché o infraestructura. De lo contrario, una mejora aparente puede deberse a cachés calientes, menor tráfico o una ruta de red distinta.

Una línea de base práctica incluye:

  1. URL y tipo de página;
  2. fecha, hora y nivel aproximado de tráfico;
  3. sesión anónima o autenticada;
  4. pruebas con caché fría y caliente;
  5. TTFB, duración total y tamaño de respuesta;
  6. LCP, INP y CLS reales cuando haya datos suficientes;
  7. CPU, memoria, swap y E/S de disco durante la solicitud;
  8. cantidad y tiempo total de consultas SQL;
  9. versiones de PrestaShop, PHP, tema y módulos relevantes.

Repita el mismo escenario. La mediana representa la experiencia habitual; los percentiles altos revelan la cola lenta. Una mediana de 800 ms con p95 de ocho segundos no describe un sistema sano: solo uno que funciona rápido la mayor parte del tiempo.

Capa 1: DNS, conexión, TLS y CDN

Si el navegador tarda en establecer la conexión, el retraso puede aparecer antes de ejecutar PrestaShop. En un entorno controlado, compare el dominio público con el origen y revise resolución DNS, conexión TCP, negociación TLS, redirecciones y distancia geográfica.

Señales frecuentes:

  • múltiples redirecciones antes de la URL final;
  • origen muy alejado de los principales clientes;
  • fallos intermitentes limitados a una operadora o región;
  • archivos estáticos solicitados siempre al origen;
  • encabezados de caché poco eficaces para imágenes, CSS y JavaScript;
  • configuración inconsistente de DNS, IPv6 o certificados.

Una CDN puede acercar contenido estático y reducir carga en el origen, pero no repara automáticamente PHP lento ni SQL ineficiente. Las reglas de caché también deben preservar la personalización: cuenta, carrito y checkout no pueden tratarse como páginas públicas iguales para todos.

Capa 2: servidor, PHP-FPM y almacenamiento

Si el TTFB crece junto con el uso de CPU, las colas de PHP-FPM, el swap o la espera de disco, investigue la infraestructura. La cantidad total de memoria no es suficiente; debe descubrir qué recurso se satura cuando aumenta la latencia.

CPU y procesos PHP

CPU alta puede provenir de tráfico real, bots, tareas programadas, regeneración de imágenes, indexación o código costoso ejecutado en cada solicitud. Compruebe si todos los workers de PHP-FPM están ocupados y si existen solicitudes esperando un proceso libre.

No aumente pm.max_children sin estimar el consumo real de memoria por proceso. Demasiados procesos pueden convertir una cola en falta de memoria. Cuando el servidor empieza a usar swap, la latencia suele crecer bruscamente.

OPcache

OPcache guarda bytecode PHP precompilado en memoria para evitar cargar y compilar scripts en cada solicitud. Confirme que esté habilitado en el SAPI que atiende la tienda, que su memoria no esté agotada y que admita la cantidad de archivos de la aplicación. Consulte el manual oficial de OPcache.

No copie valores de otro servidor sin medir. Memoria insuficiente, reinicios frecuentes o una política inadecuada de validación pueden reducir su utilidad.

Disco y E/S

Copias de seguridad, logs verbosos, sesiones en archivos, plantillas compiladas y base de datos en el mismo volumen pueden competir por E/S. CPU baja no significa servidor libre: los procesos pueden estar esperando almacenamiento. Observe latencia y cola del disco durante el problema.

Capa 3: configuración de producción de PrestaShop

Antes de buscar una causa compleja, confirme que la tienda no esté ejecutando opciones de desarrollo en producción.

Revise:

  • modo de producción y visualización de errores;
  • compilación y caché de Smarty;
  • invalidación controlada después de despliegues;
  • combinación y minificación de CSS/JavaScript probadas con tema y módulos;
  • barras y módulos de diagnóstico deshabilitados;
  • nivel de logs apropiado para producción.

La documentación de PrestaShop recomienda mantener _PS_MODE_DEV_ y _PS_DEBUG_PROFILING_ desactivados en producción y evitar la compilación forzada de Smarty. Consulte las recomendaciones oficiales de rendimiento.

Vaciar toda la caché continuamente tampoco es una estrategia. Las primeras solicitudes después de cada limpieza pagan nuevamente el coste de compilación y reconstrucción. La invalidación debe corresponder a cambios reales de código, tema, configuración o contenido.

Modo debug y profiling nativo: dos herramientas diferentes

Debug y profiling son útiles, pero responden preguntas distintas.

_PS_MODE_DEV_ expone errores e información de desarrollo. Ayuda a localizar excepciones, avisos, incompatibilidades y fallos ocultos por una página genérica. Es, ante todo, una herramienta de diagnóstico funcional.

_PS_DEBUG_PROFILING_ agrega información de profiling al procesamiento de la página. Según la versión de PrestaShop y la ruta ejecutada, permite observar indicadores como tiempo total, memoria, consultas SQL, archivos cargados y ejecución de hooks. Resulta especialmente útil al comparar páginas similares o detectar que una ruta genera muchas más consultas que otra.

En instalaciones que utilizan config/defines.inc.php, suele activarse temporalmente así:

if (!defined('_PS_DEBUG_PROFILING_')) {
    define('_PS_DEBUG_PROFILING_', true);
}

Al finalizar la captura, restáurelo obligatoriamente:

if (!defined('_PS_DEBUG_PROFILING_')) {
    define('_PS_DEBUG_PROFILING_', false);
}

Un flujo de profiling controlado

El profiling añade trabajo a la solicitud. Sus tiempos no equivalen a la experiencia normal del comprador. Utilice la salida para comparar proporciones y diferencias: qué grupo de consultas domina el tiempo, qué hook cuesta más, qué página carga más archivos y qué cambio elimina trabajo repetido.

Flujo recomendado:

  1. reproducir el problema sin profiler y guardar la línea de base;
  2. utilizar homologación con datos representativos siempre que sea posible;
  3. si producción es imprescindible, restringir el acceso y elegir una ventana corta;
  4. perfilar una solicitud representativa y guardar el resultado;
  5. desactivar profiling inmediatamente;
  6. formular una hipótesis, cambiar una sola causa y repetir la prueba normal.

No deje debug ni profiling activos en una tienda pública. Además de aumentar el coste, la salida puede revelar rutas, consultas y detalles técnicos. PrestaShop recomienda expresamente desactivar ambas constantes en producción.

Cómo interpretar el resultado

  • Muchas consultas pequeñas: busque patrones N+1, lecturas repetidas de configuración, loops y hooks ejecutados varias veces.
  • Pocas consultas muy lentas: revise índices, filtros poco selectivos, ordenaciones y tablas grandes.
  • Tiempo concentrado en hooks: relacione cada hook con los módulos registrados y pruebe candidatos en homologación.
  • Memoria inusualmente alta: investigue colecciones grandes, hidratación excesiva de objetos, exportaciones o imágenes procesadas dentro de la solicitud web.
  • Diferencias grandes entre rutas: compare módulos, bloques, combinaciones de producto y servicios remotos presentes en cada página.

El profiler señala dónde investigar, pero no siempre prueba la causa raíz. Una consulta puede estar lenta porque el disco está saturado, y un hook puede estar esperando una API externa.

Capa 4: base de datos

Con el tiempo, las tiendas acumulan pedidos, carritos, conexiones, búsquedas, logs y tablas de módulos. Una consulta aceptable con un catálogo pequeño puede convertirse en crítica años después.

Active el slow query log durante una ventana controlada y clasifique los resultados por frecuencia, duración y filas examinadas. La documentación de MySQL sobre el slow query log explica su funcionamiento. No analice únicamente la consulta más larga: una consulta de 100 ms ejecutada miles de veces puede consumir más capacidad que otra aislada de dos segundos.

Para cada candidata, revise:

  • plan de ejecución con EXPLAIN;
  • índices utilizados y filas estimadas;
  • filtros por tienda, idioma, grupo y estado;
  • JOIN, ORDER BY y GROUP BY sobre conjuntos grandes;
  • consultas repetidas con parámetros idénticos;
  • tablas de logs o módulos sin retención;
  • esperas por bloqueos y transacciones largas.

No cree índices por ensayo y error. Cada índice consume espacio y encarece las escrituras. Debe responder a una consulta real, frecuente y medida.

Capa 5: módulos, hooks, overrides y servicios externos

Los módulos amplían PrestaShop en puntos específicos de ejecución. Uno puede ser barato en la página inicial y costoso en producto. Otro puede solicitar inventario o transporte remoto durante el checkout. Algunos ejecutan lógica incluso cuando su bloque visual no aparece.

En homologación, relacione los hooks costosos con los módulos registrados. Deshabilite un candidato por vez, repita la misma solicitud y compare. Cambiar varios componentes simultáneamente impide saber cuál produjo el resultado.

Preste especial atención a:

  • solicitudes HTTP síncronas sin timeouts estrictos;
  • APIs de transporte, pago, recomendaciones, analítica o ERP en el camino de renderizado;
  • consultas dentro de loops de productos y combinaciones;
  • carga repetida de configuración;
  • overrides antiguos que duplican trabajo del core;
  • módulos abandonados o incompatibles;
  • tareas pesadas que deberían ejecutarse mediante cron o cola.

Un sistema externo no debe bloquear indefinidamente la tienda. Defina timeout, comportamiento de contingencia y caché cuando el dato lo permita. Los procesos que no necesitan finalizar antes de responder al navegador deben ejecutarse de forma asíncrona.

Capa 6: tema, imágenes y JavaScript

Cuando el TTFB es saludable, pero LCP o INP siguen mal, investigue el navegador.

Una imagen principal demasiado pesada puede dominar el LCP. CSS bloqueante retrasa la primera renderización útil. Etiquetas de marketing, chats, píxeles, pruebas A/B y widgets pueden ocupar el hilo principal después de recibir el HTML.

Revise:

  • bytes y formatos de imágenes entregados a cada dispositivo;
  • imágenes adaptables y srcset;
  • prioridad de la imagen principal y lazy loading fuera del primer viewport;
  • CSS crítico y recursos bloqueantes;
  • volumen de JavaScript y tareas largas;
  • scripts de terceros según coste y valor comercial;
  • dimensiones reservadas para bloques dinámicos;
  • cantidad de módulos visuales en la página inicial.

No optimice solo una puntuación. Lea los hallazgos concretos y valide en sesiones reales. Una modificación que mejora el laboratorio, pero rompe personalización, medición o checkout, no es una mejora.

Relación entre síntomas y capas

| Síntoma | Primeras verificaciones |
|—|—|
| TTFB alto en todas las rutas | PHP-FPM, OPcache, base de datos, configuración y servicios externos |
| Solo producto o categoría es lento | hooks, módulos, combinaciones, consultas e imágenes específicas |
| Back office lento al abrir pedidos | volumen, módulos administrativos, integraciones y SQL |
| Rápido fuera de horas pico | saturación de workers, CPU, base, disco o concurrencia |
| HTML rápido, renderizado lento | imágenes, CSS, JavaScript y terceros |
| Página visible, pero interacciones lentas | INP, tareas largas y listeners |
| Latencia intermitente | APIs, cron, bots, bloqueos, E/S o red |
| Reiniciar PHP ayuda temporalmente | pool saturado, crecimiento de memoria, OPcache o procesos persistentes |

Secuencia de diagnóstico para evitar desperdicio

  1. Medir rutas representativas y separar latencia del origen de trabajo en el navegador.
  2. Correlacionar los periodos lentos con CPU, memoria, swap, disco y workers.
  3. Confirmar configuración de producción, caché y OPcache.
  4. Usar debug y profiling de forma controlada para localizar consultas y hooks sospechosos.
  5. Analizar slow query log y planes de ejecución.
  6. Probar módulos e integraciones individualmente en homologación.
  7. Revisar imágenes, CSS, JavaScript y terceros.
  8. Cambiar una causa por vez y repetir la línea de base.
  9. Monitorizar después del despliegue para detectar picos y regresiones.

Esta secuencia evita dos errores costosos: aumentar infraestructura sin evidencia y aplicar muchas “optimizaciones” al mismo tiempo. Ambos aumentan el coste y conservan la incertidumbre.

Conclusión

El rendimiento de PrestaShop no depende de una única opción. Es el resultado combinado de red, servidor de origen, PHP, acceso a la base, módulos, integraciones remotas y ejecución en el navegador.

El modo debug y el profiling nativo son componentes valiosos de la investigación cuando se usan brevemente, preferiblemente en homologación, y se desactivan inmediatamente. Transforman “la tienda está lenta” en hipótesis comprobables: demasiadas consultas, un hook costoso, memoria excesiva, un servicio externo bloqueante o un cuello de botella que solo aparece en el frontend.

Mida antes de comprar más infraestructura. Compare antes de deshabilitar módulos al azar. Repita el mismo escenario antes de declarar que una optimización funcionó.

AGTI diagnostica y optimiza tiendas PrestaShop considerando código, base de datos, módulos e infraestructura como un único sistema operativo. Si su tienda está lenta, inestable o se degrada durante picos de tráfico, contacte con nuestro equipo para realizar un análisis basado en evidencias.

Referencias