Hyvä vs Luma: qué cambia realmente bajo carga

Hay una trampa muy común con el tema de performance, y es medir donde no duele. Abres tu sitio en la oficina, en una máquina decente, con buena conexión, y todo se siente rápido. Lighthouse te regala un número verde y te vas a dormir tranquilo. El problema es que ninguno de tus clientes está en esas condiciones.

Tus clientes están en la calle, en el metro, con un celular que ya tiene dos años y una señal que va y viene. Y muchos de ellos están entrando justo cuando lanzaste la campaña, todos al mismo tiempo. Ahí, bajo presión real, es donde Luma y Hyvä dejan de parecerse.

El problema de Luma no es Luma: es el peso

Luma, el theme que viene de fábrica con Magento, arrastra una arquitectura de hace una década. RequireJS, Knockout, jQuery, un montón de JavaScript que el navegador tiene que descargar, parsear y ejecutar antes de que la página se sienta usable. En tu laptop eso son milisegundos que ni notas. En un celular modesto, ese mismo JavaScript se traduce en segundos de pantalla congelada.

Y aquí va el detalle que mucha gente no conecta: el celular no sólo tiene que bajar el JavaScript, tiene que ejecutarlo. El procesador de un teléfono de gama media es una fracción del de tu computadora. Cada kilobyte de JS que le mandas es trabajo que ese procesadorcito tiene que hacer mientras el usuario mira una pantalla en blanco, decidiendo si se queda o se va.

El JavaScript que no mandas es el más rápido del mundo. No se descarga, no se parsea, no se ejecuta. No existe.

Qué hace Hyvä distinto

Hyvä reescribe el frontend con una idea simple y casi radical para el ecosistema Magento: mandar lo mínimo. Tailwind para los estilos, Alpine.js —que pesa unos pocos kilobytes— para la interactividad, y fuera todo el andamiaje pesado de RequireJS y Knockout. El resultado no es una mejora marginal. Es un orden de magnitud menos de JavaScript llegando al dispositivo.

¿Qué significa eso en la práctica? Que el navegador tiene muchísimo menos que procesar antes de pintar algo útil. El LCP —el momento en que el usuario ve el contenido principal— baja de forma notoria. El INP, que mide qué tan rápido responde la página cuando tocas un botón, mejora porque el hilo principal no está ahogado ejecutando scripts. Y el CLS, esos saltos molestos de la maquetación, se controla mejor cuando hay menos piezas moviéndose tarde.

"Bajo carga" es donde se decide todo

Una página individual rápida está bien. Pero el escenario que de verdad importa es la concurrencia: cientos o miles de usuarios pegándole a la tienda al mismo tiempo. Ahí el backend también cuenta —Varnish, Redis, la base de datos afinada— pero el frontend ligero ayuda de una forma que se subestima: menos peticiones, menos render del lado del cliente, menos todo. La tienda aguanta más gente con la misma infraestructura.

Esto es lo que medimos cuando hacemos un benchmark serio. No el Lighthouse de una corrida feliz, sino el tiempo de respuesta bajo carga sostenida, simulando usuarios concurrentes reales. Es ahí donde la diferencia entre el stack moderno y Luma deja de ser un debate de gustos y se vuelve un número que cualquiera entiende.

El asterisco honesto

Hyvä no es magia gratis. Migrar de Luma a Hyvä implica trabajo de frontend real, y las extensiones que dependían de Luma necesitan una capa de compatibilidad o un reemplazo. No es "instalar y listo". Por eso lo primero que hacemos es una auditoría que mide tu punto de partida —campo y laboratorio— para que la mejora sea demostrable, no una corazonada.

Tampoco prometemos números mágicos antes de medir. Prometemos método: medimos antes, optimizamos, y medimos después con las mismas reglas. Si la mejora no se ve en los datos, no cuenta.

Si tus Core Web Vitals están en ámbar o rojo, o si tu tienda sufre cada vez que lanzas una campaña, empieza por una auditoría de performance. Te decimos qué mover primero —y muchas veces los quick wins de backend dan resultado antes de tocar una sola línea del theme.