Cuándo pasar a headless en Adobe Commerce

La mayoría de los comercios que me preguntan por headless en realidad preguntan otra cosa: ¿por qué mi tienda es lenta y por qué cada cambio en el frontend tarda tres semanas? Headless puede resolver las dos cosas. Un buen tema 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 con ScandiPWA para un comercio con un GMV de 8 cifras, y trabajo con Hyvä y PWA Studio. Las dos opciones funcionan. Ninguna es la opción por defecto correcta para todos.

Qué significa headless en Adobe Commerce

En una instalación clásica, Adobe Commerce genera cada página en PHP: layout XML, bloques, 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: los drop-ins necesitan una licencia de Commerce que los cubra.
• Un frontend propio en Next.js, Nuxt o similar, escrito por tu equipo contra las mismas APIs.

Todas sacan el renderizado de Magento. Todas te dejan con dos aplicaciones que construir, desplegar, monitorizar y actualizar 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 difícil de trabajar. RequireJS, Knockout y mucho JavaScript en cada página. Headless era la salida.

Hyvä eliminó la mayor parte de 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 poco, el trabajo de frontend es rápido, y cada función del backend, cada extensión y cada ajuste del admin sigue funcionando como el negocio ya 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 la comparación honesta hoy no es «headless frente a Luma lento». 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. La experiencia es el producto. Mucha interactividad, configuradores, contenido personalizado contra el que un tema renderizado en servidor tendría que pelear.
4. Tienes un equipo de frontend. Ingenieros de JavaScript internos que se harán cargo del storefront a largo plazo, no una agencia que lo entrega en el lanzamiento.
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 lo posea envejece mal. Las actualizaciones del framework se acumulan, el esquema GraphQL se desvía y la tienda acaba 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:

• Tus extensiones son tu negocio. 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. Tus desarrolladores conocen Magento. Hyvä los mantiene productivos. 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ä más el trabajo de backend de mi checklist de rendimiento te lleva ahí por una fracción del coste.
• Tu equipo de merchandising vive en el 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

Tres puntos sorprenden a los equipos más a menudo.

Rendimiento de GraphQL. La caché de página completa no te protege como en una tienda con tema. Las consultas GraphQL sin caché con datos de producto profundos llegan a PHP en cada petición. Necesitas diseño de consultas, caché en el edge y perfilado de resolvers desde el primer día.

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.

Paridad SEO. Reescrituras de URL, etiquetas canonical, datos estructurados, hreflang y redirecciones vivían en Magento. En headless, el storefront tiene que reproducir cada uno, 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? Sin un equipo con nombre, 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ä para catálogo y checkout, y una aplicación separada solo para la parte del sitio que la necesita, como un configurador o un hub de contenidos, que llama a las mismas APIs de Commerce.

Lo que yo haría

Para la mayoría de las tiendas Adobe Commerce medianas en 2026, recomiendo Hyvä con un buen trabajo de rendimiento en el backend. Ofrece casi toda 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, el servicio de storefronts headless empieza con una evaluación de dos semanas que responde por escrito a las cuatro preguntas de arriba para tu tienda.