Magento 2: optimización de rendimiento para catálogos grandes

El rendimiento es el talón de Aquiles de Magento

Magento 2 (Adobe Commerce) es una plataforma extremadamente potente, pero su complejidad arquitectónica tiene un coste en rendimiento. Con catálogos de más de 50.000 productos, las páginas de categoría, la búsqueda y el proceso de indexación pueden volverse lentas si no se optimizan correctamente.

Actualización — julio 2026: hemos revisado esta guía a fondo. Desde su publicación original, Magento ha dado un salto importante: la versión actual es la 2.4.9 (mayo de 2026), que exige PHP 8.4 u 8.5, requiere OpenSearch 3.x en instalaciones nuevas (Elasticsearch ya no está soportado) y adopta Valkey como backend oficial de caché y sesiones en sustitución de Redis. Todas las recomendaciones siguientes están puestas al día con estos cambios.

Indexación: la base de todo

El sistema de indexadores de Magento transforma los datos del catálogo en tablas planas optimizadas para consultas rápidas. Configura los indexadores en modo «Update by Schedule» en lugar de «Update on Save» para evitar que cada cambio de producto dispare una reindexación completa. Para catálogos muy grandes, programa la reindexación completa en horarios de bajo tráfico.

Varnish Cache: imprescindible

Varnish es el acelerador HTTP recomendado oficialmente para Magento 2. Cachea las páginas completas y las sirve sin ejecutar PHP, reduciendo los tiempos de respuesta de segundos a milisegundos. Configura correctamente las reglas de purga para que los cambios de stock, precios y contenido se reflejen inmediatamente.

Redis para sesiones y caché

Usa Redis para la caché de aplicación (config, layout, block HTML) y para las sesiones de usuario. Redis es significativamente más rápido que el sistema de archivos por defecto y escala mejor bajo carga. Separa las instancias de Redis para caché y sesiones para evitar que un flush de caché cierre las sesiones de los usuarios.

Desde Magento 2.4.9, el backend oficial de caché y sesiones es Valkey 8.x, el fork de código abierto de Redis surgido tras su cambio de licencia. La migración es prácticamente transparente (protocolo compatible), pero conviene planificarla en la próxima actualización de versión: el soporte de las herramientas y parches de Adobe ya asume Valkey como opción por defecto.

Elasticsearch / OpenSearch

Para catálogos grandes, el motor de búsqueda es crítico. Elasticsearch (o OpenSearch) no solo mejora la relevancia de los resultados de búsqueda, sino que reduce la carga en la base de datos MySQL. Asegúrate de configurar correctamente los analyzers para tu idioma y los sinónimos de producto.

Ojo si sigues en Elasticsearch: desde Magento 2.4.9 ya no está soportado y las instalaciones nuevas exigen OpenSearch 3.x. El cambio de formato de índice entre OpenSearch 2.x y 3.x obliga a reindexar por completo, algo que en catálogos de cientos de miles de SKUs hay que presupuestar en tiempo y ventana de mantenimiento. A cambio, la 3.x indexa de forma más estable y resuelve más rápido la búsqueda facetada en catálogos grandes.

Optimización de base de datos

MySQL es otro punto crítico. Ajusta los parámetros de innodb_buffer_pool_size (debería ser el 70-80% de la RAM disponible), ten presente que la query cache desapareció en MySQL 8 (el mínimo que exige Magento 2.4), así que el ajuste fino pasa por el buffer pool y los índices, y limpia periódicamente las tablas de logs y reportes que Magento genera. Para catálogos muy grandes, considera Percona Server o MariaDB como alternativa a MySQL estándar.

CDN e imágenes

Configura un CDN para servir assets estáticos (CSS, JS, imágenes) y usa el redimensionado de imágenes nativo de Magento para generar los tamaños exactos que necesita cada vista. Habilita la conversión a WebP y lazy loading para las imágenes de catálogo.

El frontend también cuenta: Luma, Hyvä y Core Web Vitals

Todo lo anterior optimiza el lado servidor, pero en 2026 buena parte de la percepción de velocidad se juega en el navegador. El frontend clásico de Magento (Luma) arrastra un peso de JavaScript considerable que penaliza el INP, la métrica de interactividad que Google consolidó como Core Web Vital en sustitución del FID. Para catálogos grandes con mucho tráfico orgánico, la migración a Hyvä se ha convertido en la optimización de frontend con mejor retorno: reduce drásticamente el JavaScript y el CSS servidos, y es habitual pasar de puntuaciones mediocres a verdes en PageSpeed sin tocar la infraestructura. La alternativa headless (PWA Studio, frontends propios sobre GraphQL) sigue teniendo sentido en proyectos con equipo frontend fuerte, aunque su coste de mantenimiento es mayor. Si quieres profundizar en cómo las métricas de experiencia afectan al posicionamiento de tu tienda, tenemos una guía completa de SEO técnico para ecommerce que complementa esta.

Operaciones masivas: importaciones, cron y colas

En catálogos grandes, el rendimiento no se degrada solo en la navegación: se degrada de madrugada, cuando corren las importaciones. Tres recomendaciones concretas. Primera: usa la API asíncrona o importaciones por lotes en lugar de guardar producto a producto; cada save individual dispara eventos, invalidaciones de caché e indexaciones parciales que multiplican el coste. Segunda: revisa el crontab de Magento con lupa, porque los grupos de cron mal dimensionados (index, consumers, default) compiten entre sí y un cron solapado puede tumbar la base de datos en hora punta. Tercera: activa los consumers de RabbitMQ para operaciones diferibles (actualización de stock, reglas de catálogo, emails transaccionales); mover trabajo a colas es la diferencia entre una importación de 100.000 SKUs que pasa desapercibida y una que tira la tienda.

Dimensionar la infraestructura (y cuándo plantearse la nube de Adobe)

Ninguna caché salva a un servidor infradimensionado. Como referencia para un catálogo de más de 50.000 productos: PHP-FPM con workers suficientes para el tráfico sin caché (el peor caso tras un flush), memoria dedicada para Valkey separada de la de MySQL, y el buffer pool de InnoDB dimensionado para que el working set del catálogo quepa en RAM. Separar la base de datos en su propia máquina es el primer paso de escalado vertical que recomendamos; los frontales web escalan después en horizontal detrás del balanceador. Si estás valorando delegar toda esta capa, en nuestra comparativa de Adobe Commerce Cloud frente a on-premise analizamos costes y arquitectura de cada opción, y en el análisis del futuro de Adobe Commerce repasamos hacia dónde va la plataforma.

Errores comunes que vemos en auditorías

Tras años auditando tiendas Magento lentas, los patrones se repiten. El flush de caché completo como rutina diaria (basta con purgas selectivas por tag). Módulos de terceros que desactivan el full page cache en categorías enteras por un bloque dinámico que podría cargarse por AJAX. Indexadores en «Update on Save» en producción porque alguien lo cambió para una prueba y nadie lo revirtió. Logs de Magento y tablas de reportes sin limpiar que ocupan más que el propio catálogo. Imágenes originales de 8 MB servidas sin redimensionar porque el CDN «ya lo comprime». Y el más caro de todos: escalar hardware sin haber perfilado antes, pagando el doble de servidor para tapar una query N+1 que un desarrollador resolvería en una tarde. Casi todos estos problemas los destapa una auditoría técnica de un par de días.

Monitorización y presupuesto de rendimiento

La optimización no es un proyecto de una vez: es un proceso. Instrumenta la tienda con un APM (New Relic, Blackfire o equivalente) para ver el tiempo real por transacción, no medias que esconden los picos. Define un presupuesto de rendimiento: tiempo de respuesta de servidor bajo 300 ms en páginas cacheadas, INP bajo 200 ms, hit rate de Varnish por encima del 90%. Y revisa las métricas tras cada deploy, porque la mayoría de las regresiones de rendimiento entran con código nuevo, no con crecimiento del catálogo. Este enfoque de mejora continua encaja de lleno con los sistemas de gestión que pide una certificación como ISO 27001: medir, fijar umbrales, corregir y volver a medir. Y no olvides el otro lado de la moneda: un catálogo rápido pero sin parchear es una bomba de relojería, como contamos en nuestra guía de seguridad y hardening en Magento 2.

Diagnóstico: qué mirar antes de tocar nada

La mitad de las optimizaciones fallidas que heredamos empezaron sin diagnóstico. Antes de cambiar configuración alguna, dedica una sesión a responder tres preguntas con datos. ¿Dónde se va el tiempo de cada petición? Un perfilado con Blackfire o los profiles de New Relic descompone la petición en bloques: si el 70% es PHP de módulos de terceros, ninguna caché de MySQL te va a salvar. ¿Qué peticiones se saltan la caché? Revisa la cabecera X-Magento-Cache-Debug y el hit rate de Varnish: es habitual descubrir que la mitad del tráfico llega con cookies o parámetros de campaña que fragmentan la caché y la vuelven inútil. ¿Qué hace sufrir a la base de datos? El slow query log con umbral de un segundo durante 48 horas dice más que cualquier intuición: las consultas de navegación por capas sobre atributos mal indexados y los COUNT sobre tablas de millones de filas suelen encabezar la lista.

Con esas tres respuestas, el plan de trabajo se prioriza solo: se ataca primero lo que más tiempo roba por petición multiplicado por las veces que ocurre. Parece obvio, pero evita el clásico proyecto de tres meses optimizando algo que representaba el 4% del problema.

Atributos y navegación por capas: el coste oculto de los catálogos grandes

Hay un factor de rendimiento específico de los catálogos grandes que casi nadie vigila: el diseño de atributos. Cada atributo marcado como filtrable en la navegación por capas multiplica el trabajo de indexación y el tamaño de los índices de OpenSearch. Tiendas con 80 atributos filtrables donde los clientes usan seis son más comunes de lo que parece, y cada uno de esos filtros de más encarece cada página de categoría. Audita qué filtros se usan de verdad (los datos están en tu analítica) y desmarca el resto como filtrables; el impacto en tiempos de indexación puede ser espectacular.

Lo mismo aplica a los atributos con scope de tienda en instalaciones multi-tienda: cada scope adicional multiplica filas en las tablas EAV y en los índices planos. Y cuidado con las reglas de catálogo (catalog price rules) aplicadas a decenas de miles de productos: su reindexación es de las más caras de la plataforma y conviene agruparlas y programarlas, no dejar que cada cambio comercial dispare una en horario de tienda abierta. En general, en un catálogo grande cada decisión de modelado de datos es una decisión de rendimiento, aunque quien la toma no lo sepa.

Contenido personalizado sin romper la caché: private content y hole punching

Una duda recurrente: «si cacheo toda la página, ¿cómo muestro el minicarrito, los precios de grupo o el nombre del usuario?». Magento resuelve esto con el patrón de private content: la página se sirve entera desde Varnish, idéntica para todos, y las piezas personales se cargan aparte en el navegador (customer-data en localStorage más llamadas a secciones). El error clásico es de módulos o personalizaciones que insertan datos del cliente directamente en el HTML de la página: en el momento en que eso ocurre, la página deja de ser cacheable, Varnish la marca como privada y toda la categoría pasa a ejecutar PHP en cada visita. En una tienda con tráfico, un solo bloque mal hecho puede costar más rendimiento que todo lo que ganes afinando MySQL.

La revisión es sencilla y muy rentable: recorre las plantillas y módulos que tocan páginas de categoría y producto buscando accesos a la sesión del cliente o al carrito en tiempo de renderizado. Todo lo que dependa del usuario debe llegar por customer sections o por AJAX tras la carga, y los bloques marcados como no cacheables (cacheable=»false» en el layout XML) deben limitarse a páginas privadas como el checkout o el área de cliente, nunca aparecer en layouts que hereden las páginas públicas. Es una de las primeras comprobaciones que hacemos en cualquier auditoría de rendimiento, precisamente porque es invisible desde fuera y carísima por dentro.

Checklist exprés antes de una campaña fuerte

Si tienes Black Friday o rebajas a la vista, este es el repaso mínimo con dos semanas de antelación: test de carga sobre las páginas críticas simulando el pico esperado por tres; verificación del hit rate de Varnish y de que las páginas de campaña son cacheables; reindexación completa y cron limpio la noche anterior; congelación de deploys desde una semana antes salvo hotfixes; revisión de que los consumers de colas están corriendo y al día; y un plan de contingencia escrito (a quién llamar, cómo activar la página de espera, cómo escalar frontales). Ningún punto es sofisticado; lo que marca la diferencia es hacerlos todos, cada vez.

Preguntas frecuentes

¿Cuántos productos aguanta Magento 2 sin problemas?

Bien configurado, Magento 2 gestiona catálogos de cientos de miles de SKUs sin despeinarse; hay instalaciones con más de un millón. El límite práctico no lo pone la plataforma sino la infraestructura y la disciplina: indexación programada, colas activas y una capa de caché bien afinada.

¿Merece la pena actualizar a Magento 2.4.9 solo por rendimiento?

Si vienes de 2.4.6 o anterior, sí: PHP 8.4/8.5 y OpenSearch 3.x rinden notablemente mejor, y las versiones antiguas van quedando sin soporte y sin parches de seguridad. Planifica la reindexación completa que exige el salto de OpenSearch y prueba los módulos de terceros en staging antes.

¿Varnish o el full page cache integrado?

Varnish, siempre que el hosting lo permita. El FPC integrado (que ya funciona sobre Valkey) ejecuta PHP en cada hit y no compite en latencia ni en capacidad de absorber picos. El integrado solo es razonable en tiendas pequeñas o entornos de desarrollo.

¿Cada cuánto conviene auditar el rendimiento?

Una revisión a fondo anual como mínimo, y siempre antes de campañas fuertes (Black Friday, rebajas). Entre medias, la monitorización continua con alertas debería avisarte de las regresiones en cuanto entran, no cuando las nota el cliente.

¿Sirven estas recomendaciones para Adobe Commerce en la nube?

La mayoría sí: indexación programada, diseño de atributos, private content y disciplina de colas aplican igual. Cambia quién gestiona la infraestructura: en Cloud, Fastly sustituye a Varnish y el dimensionamiento lo gobierna Adobe, así que tu margen de mejora está sobre todo en el código, los módulos y el modelado del catálogo.

Conclusión

Optimizar un Magento con catálogo grande no es magia: es aplicar orden. Medir primero, cachear bien, indexar de forma programada, mantener el motor de búsqueda y la base de datos al día, y vigilar que nada se degrade con cada deploy. La plataforma ha mejorado mucho —PHP 8.4, OpenSearch 3, Valkey, y un frontend moderno con Hyvä— pero ninguna versión sustituye al trabajo de afinado sobre tu catálogo y tu tráfico concretos. Si tu tienda va lenta y no sabes por dónde empezar, o quieres llegar a la próxima campaña con garantías, nuestro equipo de mantenimiento ecommerce trabaja exactamente en esto todos los días.