Mi PrestaShop va lento: cómo saber qué módulo tiene la culpa
Cuando una tienda tarda demasiado en responder, casi siempre sospechamos de los módulos. Te explicamos cómo medir los tiempos y encontrar al culpable sin romper nada.
Entras a tu catálogo, abres una ficha de producto y la página tarda varios segundos en responder. Cuando notas tu PrestaShop lento, la primera tentación suele ser borrar la caché o culpar de inmediato al servidor, pero en el día a día de una tienda el culpable casi siempre tiene otro nombre: un módulo que hace más trabajo del que debería en cada petición.
En nuestra joyería online nos ha tocado lidiar con esto más de una vez. A base de probar añadidos para promociones, transportistas o integraciones externas, el tiempo de carga se resiente si no vigilas qué hace cada pieza. La buena noticia es que no necesitas intuición para dar con el problema: PrestaShop incluye herramientas para medir exactamente qué proceso está consumiendo los recursos de tu servidor.
Por qué se vuelve lenta una tienda: causas de más a menos probable
Antes de cambiar ajustes a lo loco, conviene entender el orden habitual en el que aparecen los atascos de rendimiento. En una tienda basada en PrestaShop, estas son las causas más frecuentes ordenadas por probabilidad:
- Módulos enganchados a hooks globales: cuando un módulo se ancla a posiciones que se cargan en absolutamente todas las páginas (como la cabecera o el final de la página), su código PHP se ejecuta en cada visita de cada cliente. Si hace consultas pesadas a la base de datos, el impacto se multiplica.
- Overrides mal resueltos o sobrecargados: si varios módulos modifican el comportamiento de clases centrales de la tienda (como el carrito o el despachador de rutas), pueden generar comprobaciones repetidas o conflictos que alargan el procesamiento antes de devolver el contenido.
- Scripts externos y llamadas remotas: herramientas de chat, píxeles de seguimiento o módulos que comprueban datos conectándose a servidores externos en tiempo real pueden dejar la carga en pausa si ese servidor remoto responde con retraso.
- Ajustes de caché y compilación incorrectos: tener activada la recompilación de plantillas en cada visita obliga a la tienda a rehacer el trabajo una y otra vez.
- Imágenes sin optimizar en el catálogo: pesan mucho al viajar por la red hacia el navegador del cliente, aunque esto afecta más a la descarga visual que al tiempo de respuesta del servidor.
El modo de perfilado: cómo medir en lugar de adivinar
Para acelerar PrestaShop sin dar palos de ciego, el método más directo que ofrece el sistema es el perfilado de rendimiento. PrestaShop cuenta con una constante interna llamada _PS_DEBUG_PROFILING_ pensada para desglosar el tiempo exacto que consume la página.
Cuando este modo está activo, al cargar cualquier página de la tienda verás al pie un panel detallado con métricas técnicas. Entre ellas, destacan dos apartados fundamentales para dar con un módulo lento de PrestaShop:
- Tiempo de ejecución por hook: muestra cuántos milisegundos se lleva cada zona de la página. Si ves que un hook secundario tarda más que la propia consulta de productos, ya tienes una pista clara.
- Módulos y consultas a la base de datos: detalla qué módulos han actuado durante esa carga concreta y cuántas llamadas han hecho a las tablas de la tienda.
Con esa tabla delante, dar con el causante deja de ser una sospecha. Si un módulo de reseñas o un recomendador de productos gasta la mitad del tiempo total de la visita, queda retratado en los datos.
Los hooks que más peligro tienen en el rendimiento
No todos los lugares de la tienda pesan lo mismo. Hay puntos específicos donde conviene vigilar con lupa qué tenemos instalado. Si quieres repasar cómo funcionan estas posiciones, puedes ver nuestra guía sobre qué son los hooks de PrestaShop.
En el rendimiento diario, los puntos más sensibles suelen ser:
displayBeforeBodyClosingTag: está justo antes de cerrar la página. Se suele usar para etiquetas de seguimiento y herramientas externas. Si varias de ellas intentan cargar recursos síncronos, la página tardará en quedar lista para el cliente.displayTopydisplayNav: forman la cabecera. Todo lo que coloques ahí se evalúa en la portada, en las categorías, en el producto y en el proceso de compra. Si tienes cinco módulos distintos buscando datos en cada visita, la cabecera será una losa.actionCartSave: este hook no muestra nada en pantalla, sino que salta cada vez que cambia el carrito. Si tienes varios módulos escuchando ese evento para recalcular condiciones, cupones o regalos, el botón de añadir a la cesta responderá despacio.
En el panel de administración, dentro de Diseño > Posiciones, puedes revisar qué módulos están enganchados a cada hook y desenganchar los que no estés utilizando realmente.
Overrides que chocan entre sí
Cuando instalas un módulo, a veces copia archivos dentro del directorio /override/ de tu tienda para alterar el núcleo del sistema. Esto permite funciones avanzadas, pero tiene una contrapartida importante.
Si dos módulos intentan sobreescribir la misma clase de PrestaShop, pueden pisarse. En nuestra tienda hemos tenido overrides compartidos en clases principales como el carrito o las URLs, y cuando algo no encaja, el sistema puede ralentizarse antes de fallar o generar un bloqueo mayor. Si te has encontrado alguna vez con una pantalla en blanco tras instalar un módulo, la raíz del problema suele estar en estos conflictos.
Además, PrestaShop mantiene un índice de clases en su caché. Cuando se tocan o limpian overrides, siempre es necesario vaciar la caché para que la tienda reconozca los cambios limpios y deje de arrastrar llamadas innecesarias.
Comparativa de métodos para localizar el fallo
Dependiendo de si tienes acceso a los archivos o prefieres trabajar solo desde el panel de administración, puedes seguir diferentes caminos para dar con el módulo problemático:
| Método | Dónde se hace | Qué te dice | Dificultad |
|---|---|---|---|
Modo perfilado (_PS_DEBUG_PROFILING_) |
Fichero de configuración | Milisegundos exactos por módulo, hook y consultas a base de datos | Media |
| Desactivación selectiva | Copia de pruebas | Confirma si la lentitud desaparece al apagar un módulo concreto | Baja |
| Revisión de posiciones | Diseño > Posiciones | Detecta módulos innecesarios anclados en zonas globales | Baja |
Siempre que sea posible, el camino más seguro para aislar al culpable consiste en clonar la tienda en un entorno de pruebas, desactivar los módulos sospechosos de uno en uno desde Módulos > Gestor de módulos y cronometrar la respuesta del catálogo.
La caché: qué resuelve y qué no
Existe la creencia extendida de que vaciar la caché lo soluciona todo. En Parámetros avanzados > Rendimiento tienes el botón de borrar caché, que resulta muy útil cuando has editado una plantilla o has cambiado traducciones y la tienda sigue mostrando la versión antigua.
Sin embargo, la caché no arregla un error de código. Si un módulo hace una consulta lenta a la base de datos o consulta una API externa que tarda en responder, borrar la caché solo conseguirá que la primera visita tras el borrado sea todavía más lenta, ya que el sistema tendrá que recompilar todo desde cero.
En el día a día de una tienda en producción, la compilación de plantillas nunca debe estar forzada en cada visita. Debe mantenerse en recompilar solo si hay cambios, permitiendo que la caché haga su trabajo habitual.
Por dónde empezar hoy mismo en tu tienda
Si notas la tienda pesada ahora mismo, este es el orden práctico con el que te recomendamos actuar para resolverlo sin correr riesgos:
- Comprueba los ajustes básicos: entra en Parámetros avanzados > Rendimiento y asegúrate de que la compilación de plantillas no esté forzada en cada recarga de página.
- Revisa las posiciones globales: ve a Diseño > Posiciones y echa un vistazo a hooks como
displayTop,displayNavodisplayBeforeBodyClosingTag. Si ves módulos antiguos de promociones que ya no usas o herramientas que dejaste de utilizar, desengánchalos de esa posición. - Activa el perfilado o haz pruebas en local: si la lentitud continúa, activa
_PS_DEBUG_PROFILING_o lleva una copia a tu entorno de pruebas para desactivar sospechosos uno a uno. - Decide qué hacer con el módulo: una vez localizado el causante, comprueba si tiene alguna actualización pendiente compatible con tu versión de PrestaShop o si sus funciones se pueden resolver con una alternativa más ligera que no dependa de overrides pesados.