Guardar un producto tarda 20 segundos: hooks y reindexación

En octubre de 2026 un compañero de la comunidad contó que guardar un producto le costaba 21-22 segundos y que a veces pasaba de 60 y aparecía el error Maximum execution time of 60 seconds exceeded. Respuesta corta: casi siempre es algo enganchado al guardado del producto: un conector con un sistema externo, miles de combinaciones o la reindexación del módulo de filtros. Subir el tiempo máximo de PHP solo esconde el problema.

Los hooks que hay que mirar

Al guardar un producto, PrestaShop ejecuta, entre otros, estos hooks:

• actionProductUpdate
• actionObjectProductUpdateBefore
• actionObjectProductUpdateAfter

Todo módulo enganchado a ellos se ejecuta dentro de la misma petición, y tú esperas a que acaben todos. Puedes verlos en Diseño → Posiciones, filtrando por cada hook.

Gustavo lo resumía con su experiencia: la mayoría de las veces es un conector que envía los datos a otro sistema (un ERP, un marketplace, un feed) en el mismo momento del guardado, o un producto con miles de combinaciones.

Cómo encontrar al culpable

1. Trabaja en una copia de la tienda, no en producción.
2. Apunta qué módulos hay en esos tres hooks.
3. Desengancha o desactiva uno cada vez y mide cuánto tarda el guardado. El que hace bajar el tiempo es el que buscas.
4. Para medir con detalle, activa el modo de depuración: en PrestaShop 8 y 9 la página de producto es Symfony y la barra de depuración muestra el tiempo de la petición y las consultas.

El caso de ps_facetedsearch

El módulo de filtros de PrestaShop es uno de los sospechosos habituales. Al guardar productos o reglas de precio, reindexa precios y atributos dentro de la propia petición del back-office, y en catálogos grandes eso son segundos de espera en cada guardado.

Unos días después del hilo, Gustavo publicó un cambio para ps_facetedsearch 5.1.0 que lo resuelve con una cola:

• Al guardar, el back-office solo apunta qué productos hay que reindexar, sin repetir los que ya estén en la cola.
• Una tarea programada (cron) procesa la cola después, por lotes, con bloqueo para que no se pisen dos ejecuciones y con recuperación si algo falla.
• La caché se invalida una sola vez al final.
• Si la cola no se puede escribir, vuelve a la indexación de siempre, así que no se pierde nada.

En su tienda, el hook del back-office pasó a tardar unos 0,33 milisegundos; la indexación se hace luego, fuera de la petición. Lo propuso a PrestaShop en una pull request, que se cerró sin integrarse tras la revisión (el autor anunció un nuevo diseño); el código sigue en su fork con la versión v5.1.0-ecom1.

Lo que no conviene hacer

• Subir max_execution_time para que «no salga el error». El producto seguirá tardando lo mismo y el problema crecerá con el catálogo.
• Sincronizar con sistemas externos en el momento del guardado. Lo sano es dejar el cambio en una cola y que una tarea lo envíe después.

Si quieres ver de un vistazo qué módulo y qué consulta se comen el tiempo en cada página, el módulo RKR Diagnoses de Rekire hace de profiler dentro de PrestaShop.

Esto salió en @PrestashopEsp, la mayor comunidad PrestaShop de España en Telegram. Ver la conversación