Magento Visual Editor: la capa para marketers que Hyvä no cubre

Hyvä acelera la forma en que los desarrolladores construyen storefronts de Magento 2. No le da a los marketers una manera de componer o editar páginas sin abrir un ticket de ingeniería. Ese hueco, una capa de edición visual basada en componentes, es justo lo que un Magento visual editor añade sobre el mismo backend de Magento, sin sustituir a Hyvä donde ya funciona.

Qué es Hyvä realmente (y qué no es)

Hyvä sustituyó el theme por defecto Luma de Magento por un stack más ligero: TailwindCSS para los estilos, AlpineJS para la interactividad y plantillas PHTML en lugar del paquete RequireJS/KnockoutJS con el que venía Luma. El resultado es real. Las tiendas construidas sobre Hyvä suelen lanzar entre un 30 y un 50 por ciento más rápido que builds comparables sobre Luma, y el ecosistema se ha puesto al día, con más de 1.000 extensiones de Magento que ya ofrecen compatibilidad oficial con Hyvä. A principios de 2026, Hyvä ya no es una alternativa emergente. Es la opción por defecto para los comerciantes de Magento serios que se preocupan por el rendimiento del frontend.

Nada de eso cambia lo que Hyvä es: un framework de themes para desarrolladores. Cada plantilla, cada sección, cada nuevo bloque de contenido es un archivo PHTML que un desarrollador escribe, prueba y despliega. Hyvä nunca se diseñó para entregar la composición de páginas a un equipo de marketing, y su propia documentación no dice lo contrario. Eso no es una carencia de ejecución. Es una decisión de alcance, y razonable para un proyecto centrado en el rendimiento de renderizado más que en la experiencia de edición.

El hueco: marketing sigue abriendo un ticket por cada página

Hable con un comerciante de Magento que haya migrado a Hyvä por rendimiento, y las cifras del frontend suelen haber mejorado. Pregunte al equipo de marketing qué ha cambiado en la forma de publicar una landing page nueva, una campaña de temporada o una historia de producto, y la respuesta suele ser: nada. Siguen escribiendo un brief, se lo entregan a un desarrollador, esperan un hueco en el sprint y revisan un enlace de staging antes de que nada salga a producción.

Ese es el patrón del que trata este post. Hyvä arregló el problema de rendimiento. No tocó el problema de composición: quién puede construir y cambiar una página, y a qué velocidad. Para un Product Owner o Marketing Owner que gestiona un calendario de contenidos, una campaña de Black Friday o una nueva landing de producto, "frontend de Magento rápido" y "tiempo de publicación rápido" son dos problemas distintos, y Hyvä solo resuelve el primero.

Por qué "simplemente añade un módulo de page builder" no cierra el hueco

Adobe Commerce, la edición de pago de Magento, incluye su propio Page Builder, pero eso es una función de Adobe Commerce, no algo que Magento Open Source o un storefront con Hyvä tengan por defecto. Incluso donde existe un módulo tipo page builder, normalmente edita bloques CMS y áreas de contenido estático dentro de la estructura de plantillas existente. No le da a marketing control sobre la composición completa de la página, secciones reutilizables ni una vista previa en vivo que coincida con lo que el desarrollador construyó en PHTML. La superficie de edición y la superficie de renderizado siguen siendo dos sistemas separados que hay que mantener sincronizados a mano.

Ese es el patrón de fallo recurrente con los editores añadidos a posteriori. Suman una interfaz sin tocar el modelo de componentes subyacente. Las plantillas del desarrollador y los bloques del marketer se separan, y al final alguien tiene que reconciliarlos, normalmente otra vez un desarrollador.

La capa que falta: un editor visual basado en componentes para marketing

Lo que los comerciantes de Magento buscan realmente cuando escriben "Magento frontend sin código" no es cero código en todas partes. Es una forma de dejar de enrutar cada cambio de página por una cola de ingeniería. Eso requiere tres cosas a la vez: un editor visual con vista previa en vivo, una librería de componentes compartida que los desarrolladores poseen y marketing compone a partir de ella, y una conexión directa a los mismos datos de producto, precio y stock que Magento ya tiene.

Esta es la capa que añade Laioutr FMP. Studio, nuestro composable visual page builder, es un editor visual con vista previa en vivo: un Product Owner o Marketing Owner arrastra y configura secciones desde una librería de componentes compartida y publica sin necesidad de un pull request. Los desarrolladores siguen siendo dueños de los componentes, los design tokens y las conexiones de datos. Nada de esto es "sin código para todo el mundo". Es low-code para marketing y totalmente abierto a nivel de código para desarrollo, que es la separación real que importa en un storefront de Magento. Un Magento visual editor que funciona así cambia el cálculo para el equipo de marketing, no para el backlog de ingeniería.

Cómo convive con Magento y Hyvä, no en lugar de ellos

Laioutr FMP se conecta a Magento igual que cualquier frontend moderno: a través de la API GraphQL de Magento, sin conector a medida. Eso significa que los equipos no tienen que arrancar un theme de Hyvä existente para conseguir una capa de edición orientada a marketing. Un patrón habitual: ingeniería mantiene un theme construido en Hyvä, o uno construido en Laioutr, para las plantillas que necesitan lógica a medida profunda, como los pasos del checkout o los flujos de configurador, mientras marketing gestiona páginas de campaña, landing pages y secciones de contenido a través de Studio de Laioutr, pensado para marketing managers, ambos leyendo y escribiendo contra el mismo backend de Magento.

Hyvä optimiza el build del desarrollador. Laioutr FMP optimiza la publicación del marketer. Responden a preguntas distintas, y una tienda Magento puede ejecutar ambas a la vez durante una transición, o apoyarse por completo en Studio de Laioutr para todo lo de cara al cliente cuando el equipo esté listo.

Lo que trae esa capa, en concreto:

• Un editor visual con vista previa en vivo en lugar de un ciclo de revisión por enlace de staging
• Una librería de componentes compartida y consistente con la marca, de modo que una nueva página de campaña reutiliza secciones aprobadas en lugar de un build hecho una sola vez
• Componentes WCAG Ready listos de fábrica, que cierran la brecha de accesibilidad que los themes basados en Luma suelen arrastrar sin auditar
• Hosting en la UE y una capa de entrega optimizada para Core Web Vitals, con nuevas landing pages que suelen lanzar alrededor de un 65 por ciento más rápido que en una configuración headless clásica con un ticket de desarrollo por página, mientras que la capa de gestión de contenido mantiene sincronizado el contenido multi-idioma

Cómo se ve esto en la práctica

Los equipos que añaden esta capa a una configuración de Magento existente suelen pasar por los mismos cuatro pasos: conectar la API GraphQL de Magento, sin middleware a medida; mapear las secciones del theme existente sobre la librería de componentes de Laioutr; decidir qué páginas siguen siendo propiedad de desarrollo y cuáles pasan a Studio; y lanzar primero las páginas orientadas a marketing mientras el resto de la migración, si la hay, avanza en paralelo. Nada de esto requiere reconstruir Hyvä ni cambiar de versión de Magento. El backend se queda exactamente donde está. Este patrón forma parte de para qué está construida la Agentic Frontend Management Platform: marketing e ingeniería trabajando desde la misma base de componentes en lugar de dos sistemas desconectados.

El alcance honesto

Si el problema de una tienda Magento es puramente rendimiento de renderizado y el equipo no tiene quejas sobre la velocidad de publicación, Hyvä por sí solo puede ser la respuesta correcta, y añadir otra capa de frontend encima sería resolver un problema que todavía no existe. La capa descrita aquí importa específicamente cuando un Product Owner o Marketing Owner es quien espera a un desarrollador para cada página nueva. Ese es un coste distinto, habitual y normalmente subestimado en los storefronts de Magento, y es el que un editor visual basado en componentes está construido para eliminar.

Lectura relacionada: Los costes ocultos de las integraciones de terceros en un frontend monolítico de Magento y Más allá del theme: los Core Web Vitals de Magento son un problema de la capa de frontend.