Magento tiene fama de lento, pero en la mayoría de los casos que he auditado el problema no es el framework: es una configuración de producción a medio hacer. Este checklist va de lo más impactante a lo más fino.
1. Modo de aplicación y caché de página completa
- Confirma el modo de producción:
bin/magento deploy:mode:showdebe devolverproduction. Endeveloperel rendimiento cae drásticamente porque se desactiva la compilación de código estático. - Full Page Cache activo y con hits reales: revisa las cabeceras
X-Magento-Cache-Debugen las páginas de catálogo. Si vesMISSde forma constante en páginas que deberían estar cacheadas, algo (un bloque no cacheable, una cookie mal gestionada) está rompiendo el caché. - Redis para caché y sesiones, no el backend de archivos. Con Redis para
cache,page_cachey sesiones, se elimina buena parte del I/O a disco que lastra Magento bajo carga concurrente.
2. Indexadores en modo "Update on Schedule"
Compruébalo con bin/magento indexer:status. Si algún indexador (catálogo de productos, precios, categorías) está en modo Update on Save, cada guardado desde el admin puede disparar una reindexación síncrona que bloquea la petición. En catálogos grandes esto se nota muchísimo. Cambia a Update on Schedule y asegúrate de que el cron de Magento corre con la frecuencia adecuada:
bin/magento indexer:set-mode schedule
bin/magento indexer:status
3. Cron: el sospechoso habitual cuando "todo va lento a ratos"
Si el rendimiento es intermitente en vez de constante, sospecha del cron. Revisa que cron_schedule no tenga miles de tareas atascadas en pending y que no haya varios crons de Magento compitiendo por los mismos recursos a la misma hora (reindexación, generación de sitemap y limpieza de logs solapados en el mismo minuto es un clásico).
4. Catálogo: atributos y colecciones
- Atributos usados en listados (
used_in_product_listing) deben tenerused_for_sort_bye indexación EAV coherente — atributos innecesarios en el listado multiplican losJOINde la colección de productos. - Evita
->load()en bucles en código custom. Cada llamada es una consulta separada; usa colecciones con los filtros aplicados de una vez. - Flat catalog ya no es necesario en Magento 2 moderno con MySQL bien indexado, pero si sigues en Magento < 2.3 con catálogos grandes, sigue siendo una palanca real.
5. Imágenes y assets estáticos
- Sirve imágenes en WebP o al menos con compresión agresiva; el catálogo suele ser el mayor contribuyente al peso de página en e-commerce.
- Usa un CDN delante de
pub/staticypub/media. Magento no necesita servir esos assets directamente en producción. - Confirma que el merge y minify de CSS/JS (o el build de Vite/Webpack si usas un tema headless) está activo, y que
static content deployse ejecutó tras el último despliegue — es fácil olvidarlo y servir assets sin optimizar sin que salte ningún error visible.
6. Consultas lentas en MySQL
Activa el slow query log temporalmente en un pico de tráfico real y revisa qué consultas superan el segundo. En mi experiencia, la mayoría de las consultas lentas en Magento vienen de:
- Módulos de terceros que hacen
SELECT *sobre tablas EAV sin índices adecuados. - Reportes de admin ejecutados directamente contra la base de producción sin réplica de lectura.
- Colecciones con
addAttributeToFilterencadenados sin revisar elEXPLAINresultante.
7. PHP-FPM y OPcache
Confirma que opcache.validate_timestamps=0 en producción (con invalidación explícita en el despliegue) y que opcache.memory_consumption es suficiente para no estar recompilando código constantemente. Revisa también el número de workers de PHP-FPM frente a la concurrencia real — ni tan pocos que se forme cola, ni tantos que agoten la memoria del servidor.
La regla general
Antes de tocar código, mide. New Relic, Blackfire o incluso el profiler nativo de Magento (?profile=1 en desarrollo) casi siempre señalan uno de los siete puntos de arriba como causa raíz. Optimizar a ciegas sin perfilar primero es la forma más rápida de perder una tarde entera sin mover la aguja.