¿Por qué es lenta tu tienda Magento 2? La respuesta casi siempre se reduce a la falta de caché Varnish, a consultas MySQL lentas y a un motor de búsqueda Elasticsearch u OpenSearch mal configurado, que juntos son las fuentes más habituales de problemas de rendimiento. Según nuestra experiencia, la mayoría de los directivos se enfrentan al problema de velocidad cuando los datos de conversión ya empiezan a empeorar, aunque las causas técnicas aparecen mucho antes, de forma medible, en las métricas del servidor. En buena parte de los casos, la lentitud no se debe a un único fallo, sino a varios problemas de servidor y de código que se refuerzan entre sí y que, por separado, ya generan una carga considerable. Este artículo repasa los 7 errores de servidor y de código más habituales que vuelven lenta una tienda Magento 2 y muestra qué síntomas concretos provoca cada uno.
Falta de caché Varnish: el descuido más caro
La falta de caché Varnish es el error más habitual, y a la vez el más caro, que encontramos al auditar una tienda Magento 2 lenta, porque este único ajuste de configuración marca por sí solo una diferencia drástica en el tiempo de carga. Según nuestra experiencia, usar la full page cache integrada, basada en el sistema de archivos, en lugar de Varnish hace que el sistema ejecute PHP y consulte la base de datos en cada petición, mientras que con Varnish las páginas en caché pueden servirse directamente desde la memoria, sin ejecutar PHP ni acceder a la base de datos. La documentación oficial de Adobe Commerce también confirma claramente que la caché integrada es bastante más lenta que Varnish, diseñado específicamente para acelerar el tráfico HTTP.
¿Qué síntomas tiene una caché Varnish ausente o mal configurada?
El síntoma más típico de una caché Varnish ausente o mal configurada es que las páginas de producto y de categoría tardan segundos en cargar sin caché, mientras que con una configuración de Varnish adecuada ese tiempo baja al rango de los milisegundos. Cuándo no basta con activar Varnish: cuando aunque sea un solo bloque del layout tiene el atributo cacheable=”false”, porque eso desactiva la caché de toda la página, y el problema suele remontarse a un único módulo a medida mal programado.
Consultas MySQL lentas: el cuello de botella oculto de la base de datos
Las consultas MySQL lentas son la segunda causa más habitual de que una tienda Magento 2 se vuelva lenta, y este problema es especialmente traicionero porque sus síntomas solo se notan de forma gradual, a medida que crecen el catálogo de productos y el volumen de pedidos. En los casos que hemos analizado, entre las causas más habituales están una indexación ausente o mal configurada, un exceso de atributos EAV y módulos a medida sin optimizar que generan consultas repetidas con frecuencia. Hemos observado esta relación en varios proyectos: cuanto mayor es el maestro de productos y la estructura de grupos de clientes de una tienda online B2B, más se nota una capa de base de datos mal optimizada en la velocidad de todo el sistema.
¿Cómo se reconoce un problema de rendimiento en la base de datos?
Un problema de rendimiento en la base de datos suele manifestarse en un panel de administración lento, tiempos de indexación largos y una carga de CPU alta en el servidor MySQL, incluso cuando la caché del frontend funciona correctamente. Para quién no es adecuado aplazar la optimización de consultas: para las empresas cuyo catálogo crece con regularidad o que hacen importaciones frecuentes, porque en su caso la carga de la base de datos crece exponencialmente con el tamaño del catálogo.
| Error | Síntoma típico | Solución prioritaria |
| Falta de caché Varnish | Tiempos de carga de segundos | Activar Varnish, revisar los bloques cacheables |
| Consultas MySQL lentas | Admin lento, carga de CPU alta | Indexación y optimización de consultas |
| OpenSearch mal configurado | Búsqueda lenta o imprecisa | Revisar la estructura del índice y la configuración de shards |
| Imágenes sin optimizar | Carga lenta de las páginas de categoría | Optimizar el formato y la compresión de imágenes |
Elasticsearch u OpenSearch mal configurado
Un Elasticsearch u OpenSearch mal configurado es el tercer error crítico, y en un sistema Magento 2 afecta directamente no solo a la velocidad de búsqueda, sino también al rendimiento de las páginas de catálogo y de los filtros. Según nuestra experiencia, la mayoría de los clientes se topan con este problema cuando la indexación del motor de búsqueda no está en consonancia con el tamaño real del catálogo, y la configuración de shards o la asignación de memoria se ha quedado corta frente al crecimiento desde el lanzamiento.
¿Cuándo supone la configuración de OpenSearch un riesgo inmediato?
La configuración de OpenSearch supone un riesgo inmediato cuando el tiempo de respuesta de las búsquedas ya llega al rango de los segundos, o cuando la sincronización del catálogo falla con regularidad, porque eso perjudica directamente la experiencia de compra y la conversión. Cuándo no conviene ignorar la configuración del motor de búsqueda en el rescate de un proyecto: cuando la tienda se prepara para una campaña de temporada con un gran aumento de tráfico, porque un índice de búsqueda infradimensionado puede colapsar en plena carga máxima.
Los 7 errores de servidor y de código más habituales que ralentizan las tiendas Magento 2:
- Caché Varnish ausente o mal configurada.
- Consultas MySQL sin optimizar y sin indexación.
- Índice de Elasticsearch/OpenSearch infradimensionado o mal configurado.
- Imágenes demasiado pesadas, sin compresión ni formato adecuado.
- Uso incorrecto o inexistente de Redis en la gestión de sesiones y caché.
- Demasiados módulos de terceros que entran en conflicto entre sí.
- Versión de PHP obsoleta o infraestructura de servidor infradimensionada.
En una auditoría de rendimiento de Magento 2 siempre hay que revisar estos elementos:
- El tipo de backend de la Full Page Cache y su cobertura cacheable real.
- La identificación de las consultas MySQL más lentas a partir del slow query log.
- El tamaño del índice de OpenSearch, el número de shards y el tiempo de respuesta.
- El estado del hardware y del software de la infraestructura de servidores y su mantenimiento.
- El número de módulos instalados y su impacto real en la carga de la página.
Imágenes sin optimizar: el asesino invisible de la velocidad
Las imágenes sin optimizar son el cuarto error más habitual que ralentiza las tiendas Magento 2, y este problema es especialmente traicionero porque visualmente nada lo delata: la tienda se ve bien, solo que carga despacio. Según nuestra experiencia, la mayoría de las páginas de catálogo son lentas porque las fotos de producto se suben al servidor en su tamaño original, sin comprimir, y el sistema no usa un formato de imagen moderno y más ligero en lugar de los antiguos JPEG o PNG. En los casos que hemos analizado, la optimización de imágenes por sí sola, sin ninguna otra intervención, mejoró el tiempo de carga entre un 20 y un 40 % en las páginas de categoría que muestran muchas imágenes de producto a la vez.
¿Qué ajustes concretos mejoran más la velocidad de carga de las imágenes?
La mayor mejora llega con el paso a un formato de imagen moderno y más ligero, la activación de la carga diferida (lazy loading) y el uso de una CDN, porque juntos reducen notablemente la carga sobre el servidor y la red. Cuándo no conviene aplazar la optimización de imágenes: cuando el catálogo de la tienda se compone de categorías muy visuales con muchas fotos, porque en ese caso el tamaño de las imágenes es, proporcionalmente, el factor que más pesa en el tiempo total de carga de la página.
Uso incorrecto o inexistente de Redis en la gestión de sesiones y caché
El uso incorrecto o inexistente de Redis es el quinto error crítico, que provoca ralentizaciones notables sobre todo en tiendas Magento 2 con mucho tráfico, porque sin él la gestión de sesiones y el almacenamiento de fragmentos de caché generan una carga considerable en la base de datos. En buena parte de los casos hemos visto que se mantiene el almacenamiento de sesiones en el sistema de archivos incluso en tiendas cuyo tráfico justificaría desde hace tiempo implantar Redis, y este descuido se vuelve realmente crítico en los periodos de máximo tráfico.
¿Por qué es un problema que la configuración de Redis no esté separada?
Es un problema que el almacenamiento de sesiones y el de caché funcionen en la misma base de datos Redis, sin separación, porque entonces una operación grande de limpieza de caché puede ralentizar temporalmente o incluso interrumpir las sesiones activas de los usuarios. Para quién es especialmente adecuada una configuración de Redis dedicada y separada: para toda tienda con muchos usuarios conectados a la vez e invalidaciones de caché frecuentes, porque en su caso la falta de separación supone un riesgo directo para la experiencia de usuario.
Demasiados módulos de terceros que entran en conflicto entre sí
El sexto error habitual es un número excesivo de módulos de terceros que entran en conflicto entre sí, lo que en una tienda Magento 2 perjudica no solo el rendimiento, sino también la estabilidad y la mantenibilidad del sistema. Según nuestra experiencia, en la mayoría de los rescates de proyectos vemos que buena parte de los módulos se ha ido acumulando con los años, y que nadie usa desde hace tiempo muchas de sus funciones, mientras siguen cargando el sistema en segundo plano en cada carga de página.
¿Cómo se detectan los módulos que generan carga innecesaria?
Los módulos que generan carga innecesaria suelen identificarse con herramientas de profiling, como el profiler integrado de Magento o una solución APM externa, que muestran con precisión qué módulos generan más consultas o el mayor tiempo de ejecución en una carga de página concreta. ¿Conviene eliminar todos los módulos a la vez para mejorar el rendimiento? No, porque eso conlleva un riesgo funcional serio: el enfoque correcto son las pruebas graduales, módulo a módulo, y la retirada sistemática de los que realmente se han vuelto innecesarios.
Versión de PHP obsoleta e infraestructura de servidor infradimensionada
El séptimo error, a menudo subestimado, es una versión de PHP obsoleta y una infraestructura de servidor infradimensionada, que limitan de base la eficacia de cualquiera de las optimizaciones mencionadas. Según nuestra experiencia, los sistemas Magento 2 que funcionan con versiones antiguas de PHP no solo son más lentos que con versiones modernas, sino que también suponen un riesgo de seguridad, porque el soporte del fabricante para esas versiones termina tarde o temprano.
¿Qué recursos de servidor suelen estar infradimensionados?
Los recursos que con más frecuencia se quedan cortos son la memoria, que se convierte en un cuello de botella durante las operaciones de indexación e importación, y la capacidad de CPU, que limita el número de peticiones que pueden atenderse a la vez en los picos de tráfico. Cuándo no basta con actualizar la versión de PHP: cuando la infraestructura de servidor subyacente (procesador, memoria, velocidad de almacenamiento) no se ha dimensionado en proporción al tráfico real y al tamaño del catálogo de la tienda, porque en ese caso la actualización solo aporta una mejora parcial.
Qué orden de corrección es realmente la mejor opción para una tienda lenta
La mejor opción nunca es que el directivo intente corregir todos los errores a la vez, sino abordar los 7 errores de servidor y de código más habituales en un orden ponderado, empezando por los factores con mayor impacto en el negocio y avanzando hacia los menores. Según nuestra experiencia, la mayoría de las mejoras de rendimiento exitosas empiezan por configurar correctamente la caché Varnish, porque ese único paso ya marca una diferencia drástica en el tiempo de carga; después viene la revisión de las consultas MySQL lentas y de la configuración de OpenSearch, que suponen una carga cada vez mayor a medida que crece el catálogo. En buena parte de los casos, la optimización de imágenes, una implantación correcta de Redis y la retirada de módulos innecesarios son pasos complementarios que por separado tienen un impacto menor, pero que sumados influyen de forma notable en la experiencia de usuario final. Es importante tener en cuenta que una versión de PHP obsoleta y una infraestructura de servidor infradimensionada limitan de base la eficacia de todas las demás optimizaciones, por lo que una mejora de rendimiento realmente integral tampoco puede ignorar esta capa, aunque sus síntomas sean menos llamativos que la falta de caché o una búsqueda lenta.
Según nuestra experiencia, la mayoría de los clientes logran una mejora duradera cuando no tratan estos errores como una intervención puntual, sino que mantienen el sistema dentro de una monitorización continua y basada en métricas. Para quién no es adecuada una mejora de rendimiento puntual y ocasional: para las empresas que amplían su catálogo con regularidad o se preparan para picos de tráfico de temporada, porque en su caso incluso una configuración de Varnish, MySQL y OpenSearch bien ajustada en su momento puede ir quedándose corta a medida que crecen. La mejor opción, por tanto, no es un único truco técnico, sino un orden de corrección estructurado y priorizado, que empiece por los errores de servidor y de código de mayor impacto y que, con una monitorización continua, garantice que la tienda Magento 2 siga siendo rápida y fiable a largo plazo.
