Cuándo pasar a headless en Adobe Commerce

La mayoría de los comercios que me preguntan por headless quieren saber por qué su tienda es lenta y por qué cada cambio en el frontend tarda tres semanas. Headless puede resolver ambos problemas. Un tema bien construido también. La diferencia está en el coste y en quién lo paga durante los próximos cinco años.

He mantenido en producción un storefront headless ScandiPWA para un comercio con un GMV de 8 cifras, y trabajo con Hyvä y PWA Studio. Los dos funcionan, y ninguno es la opción por defecto adecuada para todo el mundo.

Qué significa headless en Adobe Commerce

En una instalación clásica, Adobe Commerce genera cada página en PHP a partir de layout XML, bloques y plantillas. En una instalación headless, Adobe Commerce pasa a ser solo el backend. Una aplicación separada genera el storefront y habla con Commerce mediante GraphQL o REST.

Esa aplicación separada puede ser:

• PWA Studio. El kit de React de Adobe para construir un storefront sobre la API GraphQL de Commerce.
• ScandiPWA. Un storefront en React mantenido por una agencia de Magento, también sobre GraphQL.
• El storefront de Adobe sobre Edge Delivery Services. Bloques de Commerce y componentes drop-in, que Adobe promueve ahora para los storefronts nuevos. Revisa antes las licencias, porque los drop-ins necesitan una licencia de Commerce que los cubra.
• Un frontend propio. Desarrollado por tu equipo en Next.js, Nuxt o similar, sobre las mismas APIs.

Con cualquiera de ellas, Magento deja de renderizar el storefront y pasas a construir, desplegar, monitorizar y actualizar dos aplicaciones en lugar de una.

Qué cambió con Hyvä

Durante años, el argumento real a favor de headless era que Luma, el tema por defecto, es lento y cuesta trabajar con él. Carga RequireJS, Knockout y mucho JavaScript en cada página, y headless era la salida.

Hyvä le quitó casi toda la fuerza a ese argumento. Sustituye el frontend de Luma por Alpine.js y Tailwind CSS y mantiene el renderizado en servidor dentro de Magento. Las páginas pesan menos y el trabajo de frontend va más rápido. El backend, las extensiones y los ajustes del admin siguen funcionando como el negocio ya los conoce. Desde noviembre de 2025, el propio Hyvä Theme es gratuito y de código abierto bajo OSL 3.0 y AFL 3.0; Hyvä Checkout y los productos enterprise siguen siendo comerciales.

Así que hoy la comparación que merece la pena es headless frente a Hyvä.

Cuándo merece la pena headless

Recomiendo un storefront separado cuando se cumplen al menos dos de estos puntos:

1. Commerce es uno de varios backends. El storefront también lee de un CMS, un PIM, un motor de reservas o una plataforma de contenidos, y Magento no debería ser el punto donde todo se junta.
2. Necesitas más de un frontend. Una tienda web más una app nativa, quioscos o un canal de marketplace que usan las mismas APIs de carrito y catálogo.
3. El storefront es muy interactivo. Los configuradores de producto, mucha interacción en el navegador o el contenido personalizado chocarían con un tema renderizado en servidor.
4. Tienes un equipo de frontend. Ingenieros de JavaScript internos que se harán cargo del storefront a largo plazo. Una agencia que lo entrega en el lanzamiento no cuenta.
5. El presupuesto cubre dos aplicaciones. El coste de construirlas y también el de mantener dos bases de código, dos pipelines de despliegue y dos sistemas de monitorización, cada año.

El punto 4 es el que más pesa. Un storefront headless sin un equipo que se haga cargo de él envejece mal. Las actualizaciones del framework se acumulan y el frontend deja de coincidir con el esquema GraphQL. Al final la tienda se queda congelada en versiones antiguas porque nadie puede pagar la actualización.

Cuándo no

Quédate con un tema renderizado en servidor, en la práctica Hyvä, cuando:

• Dependes de muchas extensiones de frontend. Cada módulo de terceros que toca el frontend necesita un equivalente headless. Métodos de pago, reseñas, fidelización, pedido rápido B2B: cada uno es un pequeño proyecto de integración, y algunos proveedores no ofrecen ninguna cobertura GraphQL.
• Tu equipo es de PHP. Hyvä mantiene productivos a los desarrolladores de Magento. Un storefront en React los hace depender de quien escriba el JavaScript.
• El objetivo es la velocidad. Si el encargo es «páginas más rápidas y mejores Core Web Vitals», Hyvä y el trabajo de backend de mi checklist de rendimiento lo consiguen por una fracción del coste.
• Tu equipo de merchandising depende del admin. Page Builder, widgets, bloques CMS y actualizaciones de layout funcionan de forma nativa con un tema de Magento. En un storefront headless, cada uno necesita soporte explícito o un sustituto.

Los costes que se subestiman

Área	Tema Hyvä	Storefront headless
Aplicaciones en marcha	Una	Dos, más caché de API
Módulos de terceros	Módulo de compatibilidad Hyvä, a menudo disponible	Reconstruidos o integrados uno a uno
Herramientas de contenido del admin	Nativas	Parciales, requieren trabajo por función
Actualizaciones	Actualización de Magento	Actualización de Magento más del framework de frontend
Perfiles necesarios	Magento, Tailwind, Alpine.js	Magento, GraphQL, React o similar, hosting de Node

Hay tres puntos que suelen sorprender a los equipos.

El primero es el rendimiento de GraphQL. La caché de página completa no protege las peticiones GraphQL como protege las páginas de una tienda renderizada con un tema. Las consultas GraphQL sin caché que piden muchos datos de producto llegan a PHP en cada petición. El diseño de consultas, la caché en el edge y el perfilado de resolvers tienen que formar parte del desarrollo desde el primer sprint.

Después viene el checkout. Es la parte más personalizada de cualquier tienda y la más cara de reconstruir. Proveedores de pago, impuestos, reglas de envío y controles de fraude tienen que funcionar a través de la API.

Y luego está la paridad SEO. Magento se encargaba de las reescrituras de URL, las etiquetas canonical, los datos estructurados, hreflang y las redirecciones. En headless, el storefront tiene que reproducir cada uno de ellos, o el tráfico cae tras el lanzamiento.

Una decisión en cuatro preguntas

Cuando un comercio me pregunta si pasar a headless, hago estas preguntas, en este orden:

1. ¿Qué problema estás resolviendo? Si la respuesta es velocidad o productividad del equipo, empieza con Hyvä y para aquí.
2. ¿Quién se hará cargo del storefront dentro de tres años? Si no hay un equipo concreto que se haga cargo, no hay headless.
3. ¿Cuántas extensiones con frontend usas? Haz la lista. Comprueba el soporte de API de cada una. Esta lista suele cerrar la discusión.
4. ¿Tienes un canal o una fuente de datos que Magento no debería renderizar? Si la respuesta es sí, headless empieza a amortizarse.

Un camino intermedio útil es el híbrido. Hyvä sirve el catálogo y el checkout. Una aplicación separada, que llama a las mismas APIs de Commerce, se encarga solo de la parte del sitio que la necesita, como un configurador o un hub de contenidos.

Lo que yo haría

Para la mayoría de las tiendas Adobe Commerce medianas en 2026, recomiendo Hyvä más las correcciones de backend de mi checklist de rendimiento. Esa combinación da la mayor parte de la velocidad de headless con un coste a largo plazo mucho menor. Recomiendo headless a comercios con varios canales, varias fuentes de datos y un equipo de frontend que se va a quedar. En ese caso, prefiero que lo construyas bien a que lo hagas a medias.

Si estás valorando esta decisión ahora, mi servicio de estrategia de storefront empieza con una evaluación de dos semanas. Al terminar tienes por escrito la respuesta a las cuatro preguntas de arriba para tu tienda.