De Luma a Hyvä: lo que gana de verdad, y lo que cuesta

Luma se diseñó en torno a supuestos de 2015: carga de módulos con RequireJS, Knockout para cualquier cosa interactiva, jQuery debajo de todo ello, LESS encima. Funciona. También ha sido la mayor razón individual por la que las tiendas Magento puntúan mal en Core Web Vitals, y ninguna cantidad de minificación cambia eso: no se puede afinar hasta salir de un stack que envía un megabyte de JavaScript antes de que el comprador haya hecho nada.

Hyvä sustituye esa capa por Tailwind CSS y Alpine.js y borra la mayor parte del resto. Los resultados de rendimiento son realmente drásticos, y por eso la migración se recomienda tan a la ligera. Lo que se menciona menos es que está reconstruyendo toda su tienda, pagando una licencia para hacerlo y heredando un problema de compatibilidad con cada extensión que tiene.

Las dos mitades son ciertas. Esta es la versión honesta de cada una.

Qué sustituye Hyvä en realidad

Ayuda ser preciso con el alcance, porque «cambiar de tema» se queda corto y «cambiar de plataforma» se pasa.

Hyvä es un tema de Magento más un conjunto de módulos. Corre sobre el mismo backend de Magento, la misma capa de PHP, la misma base de datos, el mismo admin. Su catálogo, pedidos, clientes, indexers, tareas de cron, integraciones y conexión con el ERP quedan intactos. En ese sentido es mucho menos arriesgado que pasar a Shopware o a Medusa.

Lo que elimina es todo el stack del lado del cliente:

Esa última fila es la que decide el tamaño de su proyecto. Las plantillas siguen siendo PHTML, así que el modelo mental resulta familiar, pero cada plantilla que ha personalizado en Luma está escrita contra un stack que ya no existe. No hay conversión automática, y no debería haberla. Está reescribiendo la tienda.

Las ganancias, en concreto

Carga de JavaScript. Es el titular y se lo merece. Una página de categoría de Luma estándar suele enviar más de un megabyte de JavaScript repartido en una larga cola de peticiones. Su equivalente en Hyvä suele quedar por debajo de 100 KB en total, a menudo bastante por debajo. Esa diferencia aparece en cada métrica que importa y en todas las páginas del sitio a la vez.

LCP e INP. Menos JavaScript significa menos trabajo en el hilo principal, lo que significa que el navegador pinta antes y responde a los toques antes. El INP en particular tiende a mejorar más de lo que los equipos esperan, porque el coste de interacción de Luma está repartido entre decenas de bindings de Knockout que se inicializan todos antes de que la página se asiente. Las tiendas Hyvä suelen estar en verde en las pruebas de laboratorio donde la versión Luma estaba en naranja.

Menos peticiones, cascada más simple. RequireJS resuelve las dependencias en tiempo de ejecución, lo que produce una cascada de peticiones realmente difícil de optimizar porque es dinámica. Eliminarlo elimina toda una clase de problema de rendimiento en lugar de afinarlo.

Velocidad de desarrollo. Es la ganancia que los equipos cuentan con más entusiasmo después, y está infravalorada en el caso de negocio. Depurar un binding de Knockout a través del árbol de layout JSON de los UI components es una habilidad especializada que lleva meses adquirir. Depurar Alpine es leer el HTML. Cambios de frontend que llevaban dos días en Luma a menudo llevan dos horas.

Contratación. Tailwind y Alpine son habilidades web corrientes. Knockout y RequireJS no lo son, y la bolsa de desarrolladores que los conocen bien se reduce cada año. Está cambiando una dependencia de nicho por una común.

Una base más limpia para todo lo demás. Una vez que el frontend es delgado, el trabajo de rendimiento que queda —la galería y el LCP de la PDP, las colecciones hinchadas de las páginas de categoría— es más fácil de ver y de arreglar, porque ya no está enterrado bajo tiempo de ejecución de JavaScript.

Los inconvenientes que nadie pone en la presentación

Es una reconstrucción, no un cambio de piel. Presupueste en consecuencia. Para una tienda mediana con un tema Luma moderadamente personalizado, un proyecto en Hyvä suele ser cuestión de varios meses, no de un sprint. Quien le presupueste dos semanas o está describiendo una instalación de Hyvä estándar con su logo encima, o no ha mirado su código.

Sus personalizaciones de Luma no vienen con usted. Cada plantilla a medida, cada sobreescritura de layout XML que apunte a un bloque de Luma, cada archivo LESS, cada componente de Knockout que escribió su última agencia: nada de eso se porta. En la práctica, esto suele ser sano: mucha de la personalización acumulada de Luma existe para rodear a Luma. Pero es trabajo que paga dos veces.

El impuesto de las extensiones. Es lo que descarrila los calendarios. Cualquier módulo de terceros que renderice marcado en el frontend o envíe JavaScript necesita una versión compatible con Hyvä. Hay tres resultados por extensión:

• El proveedor o la comunidad de Hyvä mantiene un módulo de compatibilidad. El mejor caso, y cada vez más habitual en las extensiones populares, pero compruebe la versión, no solo el nombre.
• El proveedor no tiene nada, y usted reconstruye el frontend de esa extensión.
• La extensión es en el fondo un widget de Luma con un backend pegado, y la respuesta honesta es sustituirla.

Audite esto antes de comprometerse con una fecha. Una tienda con cuarenta extensiones puede encontrarse fácilmente con que seis de ellas suponen la mitad del proyecto.

El checkout es una decisión aparte y un coste aparte. Por defecto, Hyvä deja en su sitio el checkout de Magento, lo que significa que la página más pesada y más dependiente de JavaScript de su sitio sigue corriendo el stack antiguo detrás de una carcasa con estilo Hyvä. Si el rendimiento del checkout es parte de su caso de negocio, necesita un checkout Hyvä dedicado, y esos son productos con licencia aparte y con sus propios requisitos de compatibilidad con los módulos de pago y envío. Lea nuestro desglose del rendimiento del checkout en Magento antes de dar por hecho que la migración del tema lo arregla.

Cuesta dinero, y no es código abierto. Hyvä tiene licencia comercial: una tarifa única por dominio para el tema, con licencias aparte para el checkout y la biblioteca de componentes de UI. Consulte sus precios actuales directamente en lugar de fiarse de una cifra en un artículo, y tenga en cuenta que es una licencia de código disponible, no abierta. Si «todo lo de nuestro stack tiene que ser libremente redistribuible» es una restricción dura para usted, aquí termina la conversación.

Page Builder y el flujo de trabajo de marketing. El contenido de Page Builder funciona con Hyvä a través de una capa de compatibilidad, pero cualquier contenido que su equipo construyera apoyándose en widgets de Luma o en el JavaScript de un slider necesita revisión. Averigüe pronto si las páginas existentes de su equipo de marketing sobreviven, porque descubrirlo en el lanzamiento es caro.

Un upstream más que seguir. Ahora sigue las versiones de Hyvä junto con las versiones y los niveles de parche de Magento. Es un coste continuo modesto, pero no es cero, y se suma a la disciplina de parcheo que ya le debe a Magento.

Hyvä no arreglará un backend lento

Es la decepción más habitual, y es completamente predecible.

Hyvä es un cambio de frontend. Facilita muchísimo el trabajo del navegador. No hace nada con el TTFB, y el TTFB es un número del backend: el hit rate de Varnish, la configuración de Redis, la versión de PHP, OpenSearch, los índices de base de datos, una llamada lenta al ERP que bloquea el renderizado de una página.

Si sus páginas sin cachear tardan 2,5 segundos en producir el HTML, seguirán tardando 2,5 segundos en producir el HTML después de la migración. El comprador verá un pintado más rápido una vez que llegue ese HTML, lo que es valor real, pero la historia de «nuestro sitio se volvió 4 veces más rápido» que le vendieron no se materializará.

Haga primero el diagnóstico. Si su TTFB es malo, trabaje los cimientos de rendimiento a nivel de sitio antes o junto con la reconstrucción del frontend, no después.

Quién debería moverse, y quién no

Argumentos fuertes a favor de Hyvä:

• Sus Core Web Vitals están suspendiendo con datos de campo y el profiling apunta a la ejecución de JavaScript y al bloqueo del hilo principal, no al tiempo de servidor.
• Ya estaba planeando un rediseño. El coste marginal de hacerlo en Hyvä en lugar de en Luma es pequeño, y es con diferencia el momento más barato para cambiar.
• Su equipo de frontend es lento por culpa de Luma, y puede ponerle un número a eso.
• El móvil es una parte significativa de sus ingresos y sus puntuaciones en móvil son malas.

Argumentos débiles, al menos por ahora:

• Su tienda funciona, sus Vitals aprueban y no tiene rediseño planeado. Hay sitios con más retorno donde gastar el presupuesto.
• Tiene un tema Luma muy personalizado, una lista larga de extensiones y ningún apetito por una reconstrucción. Espere a un ciclo natural de rediseño.
• Su problema real está en el servidor. Arregle eso primero; la respuesta puede ser que nunca necesitó la migración del tema.
• Está evaluando seriamente dejar Magento del todo. No invierta en una reconstrucción del frontend para una plataforma de la que puede salir: resuelva esa cuestión primero.

Llevar el proyecto sin sorpresas

La secuencia que evita la mayor parte del dolor:

1. Audite las extensiones antes de definir nada. Liste cada módulo que toca el frontend, clasifique cada uno como compatible / necesita trabajo / sustituir, y póngalo delante de quien apruebe el presupuesto. Este único paso es la diferencia entre una estimación precisa y una mala.
2. Tome la línea base de sus números actuales. Datos de campo de CrUX, no una ejecución de laboratorio. Querrá demostrar la ganancia después, y las comparaciones solo de laboratorio son demasiado ruidosas para discutir con ellas.
3. Decida el checkout pronto. Checkout de Magento estándar bajo Hyvä, o un checkout Hyvä dedicado, con las implicaciones de licencia y de módulos de pago que siguen. Esto da forma al calendario más que cualquier otra decisión.
4. Reconstruya en lugar de portar. Los equipos que intentan recrear su tema Luma píxel a píxel en Hyvä gastan la mayor parte del presupuesto reproduciendo decisiones que nadie recuerda haber tomado. Trátelo como un rediseño con una estructura de contenido conocida.
5. Use una vista de tienda o un dominio de staging para ejecutar los dos. Puede tener Hyvä en una vista de tienda mientras Luma sirve otra, lo que hace realista, y no teórico, un despliegue por fases y la comparación.
6. Proteja las ganancias. Una tienda Hyvä con cuatro contenedores de tag manager, un widget de chat y un script de personalización vuelve a ser una tienda lenta. El frontend delgado es un activo que tiene que proteger activamente después del lanzamiento.

El resumen honesto

Hyvä es la mejor respuesta disponible para el rendimiento de la tienda en Magento, y la mejora en la experiencia de desarrollo es lo bastante real como para que los equipos que han dado el paso rara vez quieran volver atrás.

También es una reconstrucción completa de la tienda con una tarifa de licencia, una auditoría de extensiones, una decisión aparte sobre el checkout y ningún efecto en absoluto sobre el tiempo de respuesta de su servidor. Es un buen intercambio para muchas tiendas. Es un mal uso del presupuesto para una tienda cuyos Vitals ya aprueban, y es el primer movimiento equivocado para una tienda cuyo problema es un TTFB de 2 segundos.

Decida cuál de esas es usted antes de decidir sobre Hyvä.

Emyrix hace trabajo de frontend y rendimiento en Magento para comerciantes y agencias, incluida la auditoría de extensiones y la definición honesta que decide si una migración a Hyvä merece la pena en su caso. Si está sopesando el paso, hablemos.