Auditoría de módulos PrestaShop: comprobando lo que cada módulo carga en cada página

Por qué el exceso de módulos es el asesino silencioso del rendimiento de PrestaShop

Toda tienda PrestaShop empieza siendo rápida. Luego instalas cinco módulos, diez módulos, treinta módulos, y de repente tu página de inicio tarda cuatro segundos en cargar. El culpable rara vez es un solo módulo masivo. En cambio, son docenas de pequeños módulos, cada uno añadiendo su propio archivo CSS, su propio archivo JavaScript y sus propias consultas a la base de datos en cada carga de página. Este peso acumulativo es lo que llamamos exceso de módulos (module bloat), y es la razón número uno por la que las tiendas PrestaShop se vuelven lentas con el tiempo.

El problema es que la mayoría de los propietarios de tiendas nunca auditan lo que sus módulos realmente cargan. Instalan un módulo para etiquetas de producto, otro para botones de compartir en redes sociales, otro para un popup de newsletter, otro para analítica, y cada uno se registra silenciosamente en hooks como displayHeader y actionFrontControllerSetMedia. Incluso si un módulo solo muestra contenido en las páginas de producto, puede seguir cargando sus archivos CSS y JavaScript en la página de inicio, páginas de categoría, carrito y checkout. Esto significa que tus clientes están descargando recursos que nunca usarán en esa página en particular.

Una auditoría de módulos adecuada revela exactamente lo que cada módulo aporta al peso de tu página. Te dice qué módulos son los que más sobrecargan, cuáles cargan recursos innecesariamente y cuáles puedes optimizar o eliminar por completo. Este artículo te guía a través del proceso completo de auditar tus módulos PrestaShop para rendimiento, usando las DevTools del navegador, el modo de depuración de PrestaShop y un análisis sistemático.

Paso 1: Activar el modo de depuración y el perfilado de rendimiento de PrestaShop

Antes de abrir las herramientas del navegador, necesitas activar las capacidades de perfilado integradas de PrestaShop. PrestaShop tiene un modo de depuración que revela información detallada sobre la ejecución de hooks, los tiempos de carga de módulos y las consultas a la base de datos. Para activarlo, necesitas modificar dos ajustes.

Primero, ve a Parámetros Avanzados y luego a Rendimiento en tu back office. Establece el Modo de Depuración en Sí. Esto activa el reporte de errores y el registro adicional que ayuda a identificar módulos problemáticos. Sin embargo, el verdadero poder proviene de la función de perfilado.

Para activar el perfilado completo, necesitas editar el archivo defines.inc.php ubicado en el directorio config de tu PrestaShop. Busca la línea que define _PS_DEBUG_PROFILING_ y establécela en true. En PrestaShop 1.7 y 8.x, esta constante controla si la barra de perfilado aparece en la parte inferior de cada página del front office. Una vez activada, recarga cualquier página de tu tienda y verás un panel de perfilado detallado mostrando los tiempos de ejecución de cada hook, cada módulo y cada consulta SQL.

El panel de perfilado se divide en varias secciones. La sección de hooks te muestra cada hook que se ejecutó en la página actual, qué módulos están vinculados a cada hook y cuánto tiempo tardó cada módulo en ejecutarse. La sección SQL muestra cada consulta a la base de datos, su tiempo de ejecución y qué módulo o función del núcleo la disparó. La sección de módulos te da un resumen del tiempo total de ejecución por módulo a través de todos los hooks.

Presta especial atención a la columna de tiempo total de ejecución. Un módulo bien optimizado debería contribuir menos de 10 milisegundos a la carga de una página. Si ves un módulo tardando 50, 100 o incluso 500 milisegundos, eso es un problema de rendimiento serio que necesita investigación.

Paso 2: Usar las DevTools del navegador para mapear los recursos de los módulos

El perfilado integrado de PrestaShop te informa sobre el rendimiento del lado del servidor, pero no te muestra la imagen completa de lo que sucede en el navegador. Para eso, necesitas las Herramientas de Desarrollo de tu navegador. Abre Chrome o Firefox, pulsa F12 y navega a la pestaña Red (Network).

Recarga tu página de inicio con la pestaña Red abierta. Verás cada petición que hace el navegador: HTML, archivos CSS, archivos JavaScript, imágenes, fuentes y llamadas AJAX. El objetivo es identificar cuáles de estas peticiones provienen de módulos.

En PrestaShop, los recursos de módulos siguen un patrón de URL predecible. Los archivos CSS de módulos se sirven típicamente desde rutas como /modules/nombremodulo/views/css/archivo.css o /modules/nombremodulo/css/archivo.css. Los archivos JavaScript siguen el mismo patrón con js en lugar de css. Usa la barra de filtro en la pestaña Red para filtrar por "modules/" y verás instantáneamente cada recurso cargado desde tus módulos instalados.

Para cada recurso de módulo que encuentres, anota la siguiente información: el nombre del archivo, su tamaño (tanto transferido como sin comprimir) y si se carga en el tipo de página actual. Quieres construir una hoja de cálculo o lista simple que mapee cada módulo a sus recursos. Una auditoría típica podría revelar algo como esto: el módulo A carga dos archivos CSS que suman 45 KB y un archivo JavaScript de 120 KB en cada página, pero solo muestra contenido en las páginas de producto. Eso significa que las páginas de categoría, la página de inicio y el carrito están cargando 165 KB de recursos innecesarios.

La pestaña Red también te muestra la vista de cascada (waterfall), que revela cuándo empieza a cargar cada recurso y cuánto tarda. Los recursos que bloquean el renderizado (CSS que bloquea el renderizado y JavaScript síncrono) son particularmente dañinos porque impiden que el navegador muestre cualquier contenido hasta que terminan de cargarse. Busca archivos JavaScript de módulos que se cargan en el head sin atributos async o defer, ya que estos son los peores infractores en cuanto al tiempo de carga percibido.

Paso 3: Analizando la cascada de red por módulo

La vista de cascada en DevTools merece su propia sección porque revela problemas de rendimiento que los tamaños de archivo por sí solos no muestran. Cuando miras la cascada, quieres identificar tres tipos de problemas.

Primero, busca recursos que bloquean el renderizado provenientes de módulos. Estos aparecen como barras que comienzan temprano en la cascada y retrasan el evento de primer pintado (la línea vertical verde o azul). En PrestaShop, los archivos CSS añadidos a través del hook displayHeader o mediante addCSS en setMedia son típicamente bloqueantes del renderizado. Si un módulo añade un archivo CSS grande que solo se necesita en páginas específicas, bloquea el renderizado en todas las páginas sin razón.

Segundo, busca cadenas de carga secuencial. Algunos módulos cargan un archivo JavaScript que luego dispara la carga de recursos adicionales: más archivos JavaScript, archivos CSS, fuentes web o llamadas a APIs externas. Cada eslabón en esta cadena añade latencia. Un módulo que carga jQuery UI, luego un CSS de tema jQuery UI, luego un JavaScript de widget personalizado y luego el CSS del widget crea una cadena de cuatro peticiones secuenciales que podrían tardar de 200 a 400 milisegundos incluso en una conexión rápida.

Tercero, busca peticiones externas. Algunos módulos hacen llamadas a servidores externos para analítica, seguimiento, carga de fuentes, widgets de redes sociales o datos de API. Estas peticiones son particularmente peligrosas porque no tienes control sobre el tiempo de respuesta del servidor externo. Un módulo de compartir en redes sociales que llama a las APIs de Facebook, Twitter y Pinterest en cada carga de página puede añadir 500 milisegundos o más de latencia, y si alguno de esos servidores está lento o inaccesible, puede bloquear toda tu página impidiendo que termine de cargar.

Para cuantificar el impacto por módulo, usa la función de bloqueo de Chrome DevTools. Haz clic derecho en una petición de un módulo específico y elige "Bloquear dominio de solicitud" o "Bloquear URL de solicitud". Luego recarga la página y compara el tiempo de carga. Esto te da una medición directa de cuánto contribuyen los recursos de ese módulo a tu tiempo total de carga de página. Repite esto para cada módulo para construir un ranking de más pesados a más ligeros.

Paso 4: Análisis de ejecución de hooks

Entender qué hooks usa cada módulo es crítico para identificar cargas innecesarias. El sistema de hooks de PrestaShop es el mecanismo mediante el cual los módulos inyectan su contenido, recursos y lógica en las páginas. Los hooks más relevantes para el rendimiento en las páginas del front office son displayHeader, actionFrontControllerSetMedia, displayTop, displayHome, displayFooter, displayProductAdditionalInfo y displayProductListFunctionalButtons.

El hook displayHeader es el hook más comúnmente abusado en el ecosistema PrestaShop. Los módulos se registran en este hook para añadir su CSS y JavaScript al head de la página. El problema es que displayHeader se ejecuta en absolutamente todas las páginas del front office. Si un módulo se registra en displayHeader sin verificar qué página está viendo el cliente actualmente, carga sus recursos en todas partes.

Para ver qué módulos están registrados en cada hook, ve a Diseño y luego a Posiciones en tu back office. Esta página muestra cada hook y cada módulo vinculado a él. Mira específicamente displayHeader y actionFrontControllerSetMedia. Cuenta cuántos módulos están registrados ahí. En una tienda típica con 30 o más módulos instalados, podrías encontrar de 15 a 20 módulos solo en displayHeader. Cada uno está añadiendo al menos un archivo CSS o JavaScript a cada página.

Ahora cruza esta información con tus hallazgos de DevTools. Para cada módulo en displayHeader, verifica si ese módulo realmente necesita cargarse en la página actual. Un módulo de reseñas de productos solo necesita sus recursos en las páginas de producto. Un módulo de lista de deseos solo necesita sus recursos en las páginas de producto y de cuenta. Un módulo de guía de tallas solo necesita sus recursos en las páginas de producto. Sin embargo, todos ellos están cargando en tu página de inicio, tus páginas de categoría, tus páginas CMS y tu checkout.

Los datos de perfilado del Paso 1 añaden otra dimensión a este análisis. Algunos módulos no solo cargan recursos innecesarios sino que también ejecutan código PHP costoso en cada llamada de hook. Un módulo que ejecuta consultas a la base de datos en su método hookDisplayHeader para verificar valores de configuración o recuperar datos está desperdiciando recursos del servidor en cada página, incluso cuando su salida no es necesaria.

Paso 5: Identificando los módulos más pesados

Con los datos del perfilado, DevTools y el análisis de hooks, ahora puedes clasificar tus módulos por su impacto en el rendimiento. Crea una lista con las siguientes columnas: nombre del módulo, número de archivos CSS cargados, tamaño total de CSS, número de archivos JavaScript cargados, tamaño total de JavaScript, tiempo de ejecución del servidor según el perfilado, número de consultas a la base de datos y páginas donde el módulo realmente muestra contenido.

Los módulos que puntúan más alto en estas métricas son los que más sobrecargan tu tienda. Según nuestra experiencia auditando cientos de tiendas PrestaShop, las siguientes categorías de módulos son consistentemente las de peor rendimiento.

Los módulos constructores de páginas (page builders) suelen ser los más pesados. Cargan grandes frameworks CSS, múltiples bibliotecas JavaScript para su editor visual, y a veces incluso cargan recursos del editor en el front office. Un constructor de páginas que carga 300 KB de CSS y 500 KB de JavaScript en cada página no es inusual.

Los módulos de redes sociales que incrustan widgets de Facebook, Instagram o Twitter cargan archivos externos que son tanto grandes como impredecibles en su tiempo de carga. Un único widget de feed de Instagram puede añadir 1 MB o más de JavaScript a tu página.

Los módulos de analítica y seguimiento que usan múltiples píxeles de seguimiento cargan archivos desde dominios externos. Cada píxel de seguimiento típicamente añade de 20 a 50 KB de JavaScript más peticiones de red adicionales para imágenes de píxel y llamadas a APIs.

Los módulos de sliders y carruseles cargan grandes bibliotecas JavaScript como Slick, Owl Carousel o Swiper junto con su CSS. Incluso si el slider solo aparece en la página de inicio, los recursos a menudo se cargan en todas las páginas.

Los módulos de chat en vivo cargan paquetes JavaScript sustanciales para la interfaz del widget de chat, típicamente de 100 a 300 KB, además de establecer conexiones WebSocket que consumen recursos durante toda la sesión de navegación.

Paso 6: Medir el rendimiento antes y después

Antes de empezar a desactivar hooks o eliminar módulos, establece una medición de referencia. Usa múltiples herramientas para obtener una imagen completa.

En Chrome DevTools, ve a la pestaña Lighthouse y ejecuta una auditoría de rendimiento. Registra la Puntuación de Rendimiento, First Contentful Paint (FCP), Largest Contentful Paint (LCP), Total Blocking Time (TBT) y Cumulative Layout Shift (CLS). Ejecuta la auditoría tres veces y promedia los resultados para compensar la variabilidad.

Usa la pestaña Performance en DevTools para grabar una traza de carga de página. Esto te da un gráfico de llama (flame chart) que muestra exactamente lo que el navegador está haciendo en cada milisegundo. Busca tareas largas (bloques de más de 50 milisegundos) e identifica qué archivos de módulos las causan.

También mide el peso de tu página. En la pestaña Red, mira el número total de peticiones y el tamaño total transferido en la parte inferior del panel. Filtra por CSS y JS por separado para obtener totales específicos de módulos.

Registra todos estos números antes de hacer cualquier cambio. Luego, a medida que optimices módulos desvinculando hooks innecesarios o desactivándolos por completo, vuelve a ejecutar las mismas mediciones. La diferencia te dice exactamente cuánto rendimiento ganaste con cada cambio.

Una auditoría de módulos bien ejecutada típicamente reduce el peso de la página entre un 30 y un 50 por ciento y mejora los tiempos de carga de uno a dos segundos. En tiendas con muchos módulos mal optimizados, la mejora puede ser aún más dramática.

Paso 7: Desactivar hooks innecesarios

Una vez que hayas identificado qué módulos cargan recursos en páginas donde no son necesarios, tienes varias opciones de optimización. El enfoque más sencillo es desvincular módulos de hooks donde no necesitan estar.

Ve a Diseño y luego a Posiciones en tu back office. Encuentra el módulo en el hook del que quieres eliminarlo. Haz clic en el icono de papelera o el botón de desvincular para eliminar el módulo de ese hook específico. Esto evita que el módulo se ejecute en ese hook por completo.

Sin embargo, ten cuidado con este enfoque. Algunos módulos usan displayHeader no solo para cargar CSS y JavaScript sino también para realizar tareas de inicialización esenciales. Desvincular un módulo así de displayHeader podría romper su funcionalidad en las páginas donde realmente se necesita. Siempre prueba en un entorno de staging o como mínimo prueba las páginas específicas donde el módulo debería seguir funcionando después de desvincularlo.

Un mejor enfoque a largo plazo es contactar al desarrollador del módulo y solicitar carga condicional de recursos. Un módulo bien codificado debería verificar el controlador o tipo de página actual antes de cargar sus recursos. Por ejemplo, un módulo de reseñas de productos debería solo cargar su CSS y JavaScript cuando el controlador actual es ProductController. De esta forma, el módulo permanece vinculado a displayHeader por compatibilidad pero solo carga recursos cuando realmente se necesitan.

Si te sientes cómodo editando código de módulos, puedes añadir verificaciones condicionales tú mismo. En el método hookDisplayHeader o hookActionFrontControllerSetMedia del módulo, añade una verificación del nombre del controlador actual. Si el controlador no es uno donde el módulo muestra contenido, retorna tempranamente sin añadir ningún recurso. Esta es la optimización más precisa y efectiva que puedes hacer.

Lista de verificación práctica para tu auditoría de módulos

Para resumir todo el proceso de auditoría, aquí tienes una lista de verificación práctica que puedes seguir. Comienza activando el perfilado de depuración de PrestaShop. Abre la pestaña Red de DevTools y recarga tu página de inicio. Filtra las peticiones por la ruta de módulos y lista cada recurso de módulo. Anota el tamaño y tipo de cada recurso. Revisa Diseño y luego Posiciones para ver los módulos en displayHeader. Cruza los registros de hooks con dónde los módulos realmente muestran contenido. Usa el bloqueo de peticiones de DevTools para medir el impacto por módulo. Registra las puntuaciones base de Lighthouse. Desvincula los módulos de hooks donde no son necesarios. Añade carga condicional a los módulos que cargan globalmente. Vuelve a medir las puntuaciones de Lighthouse después de cada cambio. Documenta tus hallazgos y cambios para referencia futura.

Este enfoque sistemático asegura que no pierdas ninguna oportunidad de rendimiento y te da datos concretos para justificar cada cambio que hagas. El exceso de módulos no es un misterio. Es un problema medible y solucionable, y toda tienda PrestaShop se beneficia de una auditoría exhaustiva de módulos al menos una vez al año.