Profiling de PrestaShop solo para tu IP: qué módulo va lento
Gustavo compartió cómo activar el profiler de PrestaShop solo para tu IP, sin ralentizar ni enseñar nada a los clientes. Explicamos el cambio en defines.inc.php, qué mirar en el resultado y un caso del grupo: un buscador por filtros que se comía la CPU de un servidor de ocho núcleos.
Cuando una tienda va lenta, la pregunta es qué va lento: un módulo, un hook, una consulta. PrestaShop trae un profiler que lo dice, pero activarlo para todo el mundo es mala idea. En abril de 2025 Gustavo compartió cómo activarlo solo para tu IP, y pidió que se fijara el mensaje en el grupo.
Dónde se activa
En config/defines.inc.php hay un bloque como este:
if (!defined('_PS_DEBUG_PROFILING_')) {
define('_PS_DEBUG_PROFILING_', false);
}Cambiarlo a true lo activa para todos los visitantes: la tienda va más lenta y muestra información interna. La idea de Gustavo es condicionarlo a tu IP (esta es su condición, escrita en una línea):
if (!defined('_PS_DEBUG_PROFILING_')) {
define('_PS_DEBUG_PROFILING_', ($_SERVER['REMOTE_ADDR'] ?? '') === '203.0.113.10');
}Cambia 203.0.113.10 por tu IP pública. El mismo truco sirve para el modo de depuración, _PS_MODE_DEV_, que está en el mismo fichero. Gustavo lo dejó claro: nunca hay que activar depuración ni profiling para todo el mundo.
REMOTE_ADDR es la IP del proxy, no la tuya: la condición no funcionará o la cumplirá todo el que pase por ese proxy. En ese caso, haz el diagnóstico en una copia de la tienda.Qué mirar en el resultado
Al recargar cualquier página desde tu IP, el profiler aparece al final con sus tablas de tiempos. Lo útil, por orden:
- Hooks y módulos que más tardan. Suele salir un culpable claro: un módulo que tarda más que todo lo demás junto.
- Consultas SQL lentas y, sobre todo, las repetidas. La misma consulta lanzada cientos de veces en una página es un problema de código, no del servidor.
- Memoria y tiempo total de cada fase de la carga.
Un caso: los filtros que se comían la CPU
En julio un compañero tenía un cliente con 3.300 productos activos, 100 marcas, 1.000 colores, 300 tallas y cinco temporadas. El buscador por filtros dejaba al límite un servidor de ocho núcleos y el cliente pedía cambiar de módulo de filtros. Gustavo le recomendó antes:
- Revisar el profiling para ver dónde se va el tiempo.
- Añadir los índices que falten y optimizar la base de datos.
- Ajustar la caché de MariaDB.
Según su experiencia, solo con eso debería notarse, y mucho. Cambiar de módulo sin saber dónde está el cuello de botella es cambiar el problema de sitio.
Para la parte del navegador
El profiler mide el servidor. Para lo que pasa en el navegador (scripts, imágenes, llamadas a terceros), Gustavo prefiere WebPageTest a PageSpeed porque da más detalle, y la pestaña Performance de las herramientas del navegador, en una ventana de incógnito, para ver qué dispara el INP.
Al terminar
Deja el fichero como estaba. Un profiler olvidado ralentiza cada visita desde tu IP y, si la condición falla, la de todos. Con el modo de depuración, más todavía: si se queda activo para todo el mundo, cualquier error enseña rutas del servidor y trozos de código a quien pase por ahí.
Si prefieres no tocar ficheros del núcleo, en Rekire tenemos RKR Diagnoses, un módulo de diagnóstico y profiler de rendimiento para PrestaShop.
Esto salió en @PrestashopEsp, la mayor comunidad PrestaShop de España en Telegram. Ver la conversación