Optimización de rendimiento en Magento 2: lo que mueve la aguja de verdad

La mayoría de los proyectos de rendimiento en Magento empiezan por el sitio equivocado. Alguien ejecuta Lighthouse, ve una puntuación en rojo y se pasa tres semanas minificando CSS, mientras el servidor sigue tardando 1,4 segundos en devolver el primer byte de HTML. El CSS nunca fue el problema.

Esta es la capa de todo el sitio: la infraestructura y la configuración que marcan el techo de cada página de su tienda. Si está mal, ningún trabajo de frontend le salvará. Si está bien, sus páginas de producto y de categoría parten de una posición en la que la optimización del frontend rinde de verdad.

Las particularidades de cada tipo de página las cubrimos aparte: páginas de categoría y navegación por capas, páginas de producto y checkout. Empiece aquí.

Sepa qué número intenta mover

Los umbrales de Core Web Vitals llevan un tiempo estables, y son los que Google usa de verdad:

• LCP ≤ 2,5 s: cuánto tarda en renderizarse el elemento visible más grande
• INP ≤ 200 ms: cuánto tarda la página en responder a las interacciones (sustituyó al FID en marzo de 2024, y es una métrica mucho más dura porque mide todas las interacciones, no solo la primera)
• CLS ≤ 0,1: cuánto salta el layout mientras carga
• TTFB ≤ 800 ms: no es un Core Web Vital, pero es la base de todos ellos

La distinción que importa: Lighthouse le da datos de laboratorio de un dispositivo simulado, mientras que Google posiciona con datos de campo de usuarios reales de Chrome (CrUX). Una tienda puede sacar 95 en Lighthouse y aun así suspender Core Web Vitals en el campo, normalmente porque los usuarios reales llegan a páginas sin cachear, con redes más lentas y con sesión iniciada, cosas que la prueba de laboratorio nunca toca.

Use Lighthouse para diagnosticar. Use los datos de campo de CrUX y PageSpeed Insights para decidir si ha ganado de verdad.

Primero el TTFB: todo lo demás viene después

Si su TTFB está por encima de 800 ms, su LCP no puede ser bueno. El navegador ni siquiera ha recibido el HTML. Esto es lo que suele causarlo.

Full-page cache con Varnish

La full-page cache integrada de Magento funciona, pero guarda las páginas cacheadas en un almacenamiento accesible desde PHP y sigue arrancando la aplicación para servirlas. Varnish se coloca por completo delante de PHP y sirve el HTML cacheado en milisegundos de un solo dígito. En una tienda en producción esto no es opcional.

El problema real no es instalar Varnish: es el hit rate de la caché. Auditamos con regularidad tiendas con Varnish y hit rates por debajo del 40 %, lo que significa que la mayoría de los visitantes reciben el camino lento de todos modos. Causas habituales:

• Parámetros de marketing en la URL (?utm_source=...) que crean entradas de caché únicas. Normalícelos o elimínelos en el VCL.
• Extensiones que llaman a setNoCacheHeaders() o marcan bloques como no cacheables sin necesidad.
• Invalidación agresiva de la caché: un vaciado completo con cada guardado de producto mantendrá la tienda permanentemente en frío durante el horario comercial.

Compruebe su hit rate con varnishstat antes de dar por sana esta capa.

Contenido privado y el impuesto del hole-punching

Magento usa el «contenido privado» para inyectar datos por cliente (contenido del carrito, nombre del cliente, lista de deseos) en páginas cacheadas, a través de una petición separada a /customer/section/load. Es la arquitectura correcta, pero se degrada mucho cuando las extensiones se van acumulando.

Cada extensión que registra una sección personalizada añade carga a esa petición, y se dispara en casi todas las páginas. Hemos visto respuestas de section/load de más de 200 KB que tardan 800 ms, encima de una página cacheada que por lo demás era rápida. Audite etc/frontend/sections.xml en todo el código y averigüe qué hay ahí de verdad.

Redis, configurado como es debido

Use instancias de Redis separadas (o, como mínimo, bases de datos separadas) para la caché por defecto, la caché de página y las sesiones. Compartir una sola instancia significa que un pico de tráfico con muchas sesiones puede expulsar sus entradas de caché.

Active la compresión de Redis para la caché de página si guarda documentos HTML grandes, y asegúrese de que maxmemory-policy está en allkeys-lru en las instancias de caché: el noeviction por defecto provocará fallos duros cuando Redis se llene, en lugar de descartar entradas antiguas con elegancia.

Versión de PHP y OPcache

Magento 2.4.8 soporta PHP 8.3 y 8.4, con 8.4 recomendado para producción. Magento 2.4.9, publicado en mayo de 2026, requiere PHP 8.4 u 8.5 y abandona por completo 8.2.

Si todavía está en una rama antigua de PHP, actualizar es una de las mejoras de rendimiento más baratas que existen: normalmente entre un 15 y un 25 % en tiempo de ejecución de PHP sin cambiar código. Acompáñela de un OPcache bien dimensionado (opcache.memory_consumption en 512 MB o más para Magento, opcache.max_accelerated_files en 60000 o más) y active la caché de realpath con generosidad.

Indexers, cron y la ralentización invisible

Un indexer en «Update on Save» en una tienda con un catálogo grande bloqueará tablas en horario comercial y hará que tanto el admin como la tienda se arrastren. Ponga todos los indexers en Update by Schedule y deje que el sistema MView agrupe los cambios a través del cron.

Luego verifique de verdad que el cron está corriendo. Un cron roto en silencio en Magento significa índices desactualizados, una cola de mensajes sin procesar y una degradación a cámara lenta difícil de atribuir. bin/magento cron:status y la monitorización de la tabla cron_schedule deberían formar parte de su observabilidad estándar, no ser algo que se mira después de una queja.

Búsqueda: OpenSearch, y deje de usar Flat Catalog

Magento 2.4.8 apunta a OpenSearch 2.19. El soporte de Elasticsearch se eliminó en 2.4.8, así que si está actualizando desde una rama anterior, esto es un punto de migración, no una nota al pie.

Ya que está ahí: desactive Flat Catalog si sigue activado. Quedó obsoleto hace años y en un Magento moderno perjudica activamente: añade una sobrecarga de indexación enorme y el beneficio en el rendimiento de las consultas ya no existe, ahora que la búsqueda pasa por OpenSearch. Sobrevive en muchas tiendas solo porque los artículos antiguos siguen recomendándolo.

El mito del bundling de JS

Este merece su propia sección, porque sigue circulando y es directamente perjudicial.

El bundling nativo de JS de Magento concatena el JavaScript en archivos muy grandes, a menudo de varios megabytes. En HTTP/1.1 ese intercambio tenía sentido: menos peticiones ganaban a cargas más pequeñas. En HTTP/2 y HTTP/3, que soporta cualquier host moderno, las peticiones se multiplexan y son baratas. Lo que le queda es un bloque enorme que el navegador tiene que descargar, parsear y ejecutar antes de que la página sea interactiva.

Ese coste de parseo y ejecución cae directamente sobre su puntuación de INP. Deje desactivado el bundling nativo de JS. Si necesita reducir la sobrecarga de peticiones, use un pipeline de build como es debido, con code splitting, no el bundler integrado de Magento.

Lo mismo vale para la minificación de JS con el minificador propio de Magento, que es lento y da problemas en el deploy; hágala en su paso de build o en el borde de la CDN.

Imágenes: la carga más grande que controla

El manejo de imágenes por defecto de Magento es generoso con el tamaño de archivo. Las soluciones se conocen bien:

• Sirva WebP o AVIF. El soporte de los navegadores ya es universal. Una CDN con negociación automática de formato (Cloudflare, Fastly, CloudFront con Lambda@Edge) lo resuelve sin tocar su código.
• Defina ancho y alto explícitos en cada imagen. Esto por sí solo corrige la mayoría de los problemas de CLS.
• Precargue la imagen del LCP y dele fetchpriority="high". No la cargue en diferido: cargar en diferido la imagen principal o la primera imagen de producto es una de las heridas de LCP autoinfligidas más habituales que encontramos.
• Cargue en diferido todo lo que queda por debajo del pliegue, incluidas las partes de la página que la mayoría de los temas renderiza con avidez.

El tema: la conversación honesta sobre Luma

En algún momento de un proyecto de rendimiento solemos tener que decirlo sin rodeos: Luma tiene un techo, y no es alto.

El frontend de Luma está construido sobre RequireJS y Knockout.js, y carga un grafo de dependencias enorme en cada página. Se puede optimizar alrededor —lo hacemos, con regularidad, y a menudo es la decisión correcta—, pero una tienda Magento estándar en Luma suele quedarse en algún punto entre 4 y 6 segundos de LCP en móvil y le cuesta controlar el INP, porque el coste de arranque del JavaScript es estructural, no accidental.

Hyvä sustituye ese stack por Tailwind y Alpine.js y envía una fracción del JavaScript. Las tiendas que migran suelen pasar de suspender dos de los tres Core Web Vitals a aprobar los tres, antes de cualquier ajuste a medida.

La pega es real: Hyvä es una licencia de pago, es una reconstrucción del frontend y no un cambio de configuración, y cada extensión con un frontend basado en Luma necesita un módulo de compatibilidad o una reescritura. Eso es un proyecto, no un sprint.

La regla honesta: si ya está planeando un rediseño o un cambio de plataforma, vaya a Hyvä y no mire atrás. Si su tema Luma funciona comercialmente y solo necesita que sea más rápido, la optimización dirigida le dará mejoras significativas por mucho menos dinero. Lo que no funciona es pasar seis meses intentando que Luma se comporte como Hyvä.

Por dónde empezar el lunes

Si no hace nada más este trimestre:

1. Mida el TTFB y el hit rate de Varnish. Arréglelos antes de tocar código de frontend.
2. Confirme PHP 8.4, indexers por programación, cron sano, Flat Catalog desactivado, bundling de JS desactivado.
3. Audite sections.xml y averigüe qué está hinchando su petición de contenido privado.
4. Precargue la imagen del LCP, ponga dimensiones a todo, sirva WebP.
5. Tome la línea base en CrUX para poder demostrar que el cambio funcionó.

Una cosa más que conviene señalar si está en una rama antigua: Magento 2.4.6 llega al fin de soporte el 11 de agosto de 2026. Después de eso no hay más parches de seguridad ni correcciones. Si es su caso, la actualización es ahora una fecha límite de seguridad además de una oportunidad de rendimiento, y Adobe soporta pasar directamente de 2.4.6 a 2.4.8 sin el paso intermedio.

Emyrix lleva proyectos de rendimiento en Magento y Adobe Commerce: profiling, arquitectura de caché, trabajo de Core Web Vitals y las actualizaciones de versión que vienen con ellos. Si su tienda es lenta y prefiere saber por qué antes que adivinarlo, escríbanos.