La reunión duraba veinte minutos y ya había dos bandos. El director de marketing quería un rediseño para septiembre. El CTO, que llevaba tres meses leyendo sobre arquitecturas desacopladas, había traído una diapositiva con una sola palabra: headless. Debajo, un gráfico de barras verdes.

Nos tocaba el papel incómodo. Antes de responder, pedimos abrir el móvil y cargar su ficha de producto más vendida. Tardó lo que tarda un café en enfriarse. Miramos la cascada de red: veintitrés scripts de terceros, una imagen de cabecera de 1,8 MB sin redimensionar, un carrusel que arrancaba con una librería de 300 KB y un chat de soporte que se cargaba antes que el precio. Ninguno de esos problemas se arregla cambiando de arquitectura. Se arreglan borrando cosas.

Qué gana de verdad una tienda al pasarse a Hydrogen

Hydrogen es el framework de Shopify sobre React Router, desplegado normalmente en Oxygen, su red de servidores. Renderiza en servidor, consume la Storefront API por GraphQL y te deja controlar cada byte que llega al navegador. En el papel es una maravilla. Y en manos de un equipo que sabe lo que hace, la mejora en la métrica de carga del contenido principal es real: controlas el orden de las peticiones, decides qué se hidrata y qué no, cacheas respuestas de la API con precisión quirúrgica.

El matiz está en contra qué lo comparas. Si la referencia es un tema Online Store 2.0 comprado en el marketplace, cargado de secciones que nadie usa y con ocho apps inyectando JavaScript en el head, headless parecerá magia. Si la referencia es un tema bien construido —imágenes servidas por el CDN de Shopify en el tamaño correcto, fuentes locales, apps auditadas una a una, JavaScript diferido, secciones que solo cargan lo suyo— la diferencia se estrecha muchísimo. Hemos visto tiendas con Liquid entrar en verde en las tres métricas de Core Web Vitals sin tocar la arquitectura.

Dicho de otra forma: en la mayoría de proyectos que nos llegan, el cuello de botella no es el motor de plantillas. Es la acumulación de años de decisiones de marketing que nadie ha retirado.

Lo que se pierde y casi nunca aparece en la primera reunión

Aquí es donde la conversación se pone honesta. Con Hydrogen se va el editor de temas. Y con él, la autonomía del equipo de marketing.

• Las secciones y los bloques desaparecen tal y como los conoces. Cambiar el orden de la home, meter un banner de rebajas o programar una landing de Black Friday deja de ser arrastrar y soltar y pasa a ser una tarea en el sprint. Se puede montar un sistema de contenido con metaobjetos para recuperar parte de esa flexibilidad, pero eso es desarrollo a medida, con su coste y su mantenimiento.
• Media biblioteca de apps deja de servirte. Todo lo que se instala como bloque de aplicación en el escaparate —reseñas, buscadores, quizzes, upsells, tallas, wishlists— asume que hay un tema Liquid debajo. En headless o reconstruyes esa funcionalidad contra su API, o te quedas sin ella. El checkout es la excepción tranquilizadora: sigue siendo el de Shopify, así que las extensiones de checkout y los métodos de pago funcionan igual.
• El mantenimiento nunca termina. Un tema Liquid puede pasar dos años sin que lo toques y sigue funcionando. Una aplicación Hydrogen tiene dependencias que envejecen, versiones de la Storefront API que se retiran, migraciones de framework que llegan cuando llegan. Súmale monitorización de errores, pipeline de despliegue y un entorno de pruebas que hay que mantener vivo.

Ese último punto es el que más presupuestos ha reventado de los que hemos visto. Nadie firma un proyecto headless contando el año dos.

Los perfiles donde sí sale a cuenta

No estamos en contra de Hydrogen. Está en nuestra caja de herramientas y lo proponemos cuando el caso lo pide. Los casos que lo piden se parecen bastante entre sí:

• Varios frontales sobre un mismo backend. Una web pública, un portal B2B con precios negociados y una aplicación para la fuerza de ventas, todos tirando del mismo catálogo. Aquí la Storefront API deja de ser un capricho y pasa a ser la única forma sensata de hacerlo.
• Lógica de producto que Liquid no aguanta. Configuradores con miles de combinaciones, presupuestos que se calculan al vuelo, productos que dependen de datos de un ERP en tiempo real. Cuando el frontal necesita pensar, conviene que sepa pensar.
• Catálogos enormes con navegación exigente. Decenas de miles de referencias, filtros combinados, búsqueda con un motor externo. Controlar el renderizado y la caché deja de ser una optimización y pasa a ser el proyecto.
• Equipo técnico interno de verdad. Si hay dos o tres personas que ya viven en React y van a seguir ahí dentro de dos años, el coste de mantenimiento se absorbe. Si el mantenimiento depende de contratar a alguien que aún no existe, mejor no empezar.

Y los perfiles donde es quemar presupuesto

Trescientas referencias, un equipo de marketing de dos personas que publica campañas cada semana y una tienda que va lenta por acumulación de apps. Aquí headless resuelve el problema equivocado y crea uno nuevo: el equipo que antes montaba una landing en una tarde ahora abre un ticket y espera.

Con el cliente de la diapositiva hicimos otra cosa. Auditamos las apps y quitamos cinco que nadie usaba, movimos el chat a cargarse tras la interacción del usuario, reconstruimos la plantilla de producto con secciones propias y pusimos las imágenes en el tamaño que tocaba. Tres semanas. La ficha de producto pasó a cargar en una fracción del tiempo anterior y marketing conservó su editor. La conversación sobre Hydrogen sigue abierta, pero ahora es una decisión de producto, no una reacción al informe de velocidad.

Cuando alguien nos pregunta por headless, lo primero que hacemos es medir el tema actual con datos de campo y separar cuánto de la lentitud viene del motor y cuánto de lo que le hemos colgado encima. Suele bastar para saber de qué lado cae el proyecto. Si estás en esa duda y quieres el cálculo aplicado a tu tienda, escríbenos y lo miramos con tus números.