Cuándo headless no es la respuesta

Headless no es un error. Es una arquitectura concreta que resuelve muy bien un conjunto concreto de problemas, y se le vende a un grupo de tiendas mucho más grande que el grupo que tiene esos problemas. La pregunta útil nunca es "¿headless es bueno?". Es si el problema real de esta tienda está del lado de la frontera que irse headless mueve.

La mayoría de las veces no lo está. La factura llega igual, en cuotas, desde la primera vez que marketing quiere probar una app.

Qué compra headless de verdad

Cuatro cosas, y vale ser preciso con ellas, porque el material de venta no lo es.

Libertad de renderizado. Eres dueño del camino de render de punta a punta: framework, routing, caché, obtención de datos, modelo de interacción. Si la experiencia que necesitas se parece más a una aplicación que a un conjunto de páginas, esta es la que importa, y ninguna otra cosa te la da.

Un solo front end sobre varios back ends. Si el storefront tiene que componer comercio con algo que no es comercio — un sistema editorial grande, un motor de reservas, un configurador con su propia lógica de precios — un front end propio deja de ser una preferencia y pasa a ser la única forma que encaja. Un storefront cuyo modelo de contenido principal vive en otro lado pelea con la capa de plantillas en cada página.

Un front end que sobrevive al back end. Varios motores de comercio detrás de una experiencia, o un negocio que de verdad espera cambiar de plataforma. Raro, y real.

Interacción que se niega a ser páginas. No "nuestro diseño es a medida" — el diseño de toda tienda es a medida. A medida en el sentido de un configurador largo, una herramienta de diseño, una experiencia tipo marketplace donde la búsqueda es la navegación principal.

La razón que más se da, y que menos veces es cierta, es el rendimiento. Un tema no es lento por ser un tema. Es lento porque carga una pila de scripts de terceros, una imagen de portada sin optimizar, tipografías desde tres orígenes y una sección que recorre la colección entera. Irse headless no elimina ninguna; las reubica en un código donde son tu problema en lugar del de la plataforma. Hacer rápido un tema es trabajo de rendimiento, por una fracción del costo de un cambio de arquitectura.

La factura que nadie cotiza

El checkout no se viene contigo

Esta es la que sostiene todo. En Shopify, el checkout sigue siendo de Shopify. Un storefront headless le entrega el control, lo que significa que el tramo del embudo con más ingreso por píxel es justo el que no reconstruiste.

Ahora tienes una costura: tu stack de un lado, el de ellos del otro, encontrándose en el momento del pago. Es manejable — la extensibilidad de checkout personaliza lo que hay del otro lado, y las Functions cambian su lógica — pero fíjate en lo que pasó. La decisión headless no te dio control del checkout. Te dio control de todo excepto el checkout, y el checkout es donde está el dinero. La mayor parte de lo que puedes hacer ahí requiere Plus sin importar cómo esté construido el storefront.

El ecosistema de apps deja de ser instalar y listo

La mayoría de las apps de Shopify entregan una theme app extension: un bloque que el comerciante arrastra a una sección y configura. Ese mecanismo no existe en tu front end propio. Reseñas, upsells, guías de tallas, listas de deseos, widgets de fidelidad, avisos de reposición, selectores de moneda — cada uno se convierte en un proyecto de integración contra la API que el proveedor exponga, si es que expone alguna.

El efecto es un cambio en quién hace el trabajo. Con un tema, alguien de marketing instala una app el martes y el miércoles está viva. Con headless, abre un ticket y espera un sprint. Multiplícalo por las herramientas que un equipo de marketing quiere probar en un año y convertiste un presupuesto de experimentación en un backlog de ingeniería.

El editor de temas desaparece, y se lleva un flujo de trabajo

Este es el costo que sorprende a los seis meses y no el primer día. El editor de temas es la razón por la que alguien de merchandising puede armar una landing de campaña el jueves para lanzarla el viernes sin pedirle permiso a nadie: secciones, bloques, ajustes por plantilla, vista previa en vivo de un cambio sin publicar.

Headless reemplaza eso con algo, normalmente un CMS headless — una buena herramienta y un flujo de trabajo completamente distinto. Contenido modelado por un desarrollador, editado en un sistema que no sabe cómo se ve la página, previsualizado por un mecanismo que alguien tiene que construir y mantener funcionando. La vista previa es la pieza que se subestima siempre: contenido en borrador, en la URL correcta, en el idioma correcto, en un despliegue que no es producción, es un proyecto pequeño en sí mismo y se pudre en cuanto nadie lo cuida. Presupuéstalo, o marketing dejará de pedir y sacará las campañas por landings pagadas.

Hosting, despliegues y observabilidad pasan a ser tuyos

Un tema se despliega sobre infraestructura en la que nunca piensas. Con headless eres dueño: una factura de hosting, una estrategia de CDN y caché — incluida la invalidación cuando cambia un precio — pipelines de build, entornos de preview, seguimiento de errores, alertas, y una persona a la que le suena el teléfono. Nada de eso es difícil. Todo es real, y es costo de operación y no de construcción. Construimos este tipo de front end y nos gusta hacerlo, así que esto no es una advertencia contra el trabajo. Es una advertencia contra cotizar una suscripción como si fuera un proyecto.

También cambia quién puede mantener la tienda. Un storefront con tema sobrevive con un buen desarrollador de temas o un retainer de agencia. Uno headless necesita un ingeniero de front end con experiencia real de framework y una historia de despliegue que lo sobreviva.

La prueba honesta

Cuatro preguntas. Las dos primeras deciden; las dos últimas te dicen si puedes pagar la respuesta.

1. ¿El modelo de contenido principal del storefront está fuera del comercio? Si el sitio es en el fondo una publicación, un catálogo maestro, un flujo de reservas o un configurador que además vende al final, headless es la forma que encaja. Si es una tienda con páginas, no lo es.
2. ¿La interacción que necesitas se niega a ser páginas? Pregunta qué se rompe de verdad si la experiencia son plantillas y secciones. Si la respuesta es "nada, sería menos elegante", la respuesta es no.
3. ¿Puedes nombrar a la persona dueña del pipeline de despliegue dentro de dieciocho meses? No la agencia — la responsabilidad. Si no hay nadie, estás comprando una arquitectura sin mantenedor.
4. ¿Agotaste el tema? No "¿probaste uno?" — ¿alguien quitó los scripts, arregló el material, reestructuró el contenido en metafields y metaobjects, y midió el resultado? Si no, estás comparando una construcción descuidada contra una hipotética.

Cuando una tienda responde que no a las dos primeras y aun así se va headless, el motor real suele ser una mala experiencia con un tema que escribió otro, un número de rendimiento con una causa más simple, o una preferencia por el stack que el equipo ya conoce. La tercera es honesta y merece decirse en voz alta en vez de disfrazarse de argumento arquitectónico. Es una decisión de contratación y de moral del equipo, que es legítima — solo que no es la misma conversación.

Qué hacer en su lugar, casi siempre

Reconstruir el tema bien, una vez, con la seriedad que ibas a gastar en la reescritura. Casi toda queja que lleva a un comerciante hacia headless es una queja sobre un tema concreto y no sobre los temas.

• Corta los scripts de terceros. Cuéntalos, ponle un dueño a cada uno, borra los que no tienen dueño.
• Arregla el material y las tipografías. Tamaños correctos, formatos correctos, un solo origen, sin desplazamiento de layout.
• Modela el contenido en metafields y metaobjects en vez de en HTML duplicado por página, para que un cambio sea una edición y una plantilla lo renderice en todos lados.
• Mide en dispositivos y redes reales, antes y después — no un puntaje de una herramienta corrida una vez desde un portátil.

Un desarrollo de tema hecho así te da un storefront que el equipo de merchandising puede operar, en el que las apps se instalan, y que entrega al checkout sin costura. Cuando un tema reconstruido pierde una comparación de velocidad contra un build headless, casi nunca es la capa de plantillas la que perdió.

La versión de este argumento que no está en contra de headless

Vete headless cuando el storefront de verdad no es un storefront: cuando el comercio es una fuente de datos entre varias, cuando la interacción es una aplicación, cuando el front end tiene que sobrevivir a la plataforma que hay detrás. Ahí los costos de arriba no son costos — son el precio de la única arquitectura que funciona, y la construimos con gusto. Buena parte de lo que hacemos en React tiene exactamente esa forma.

No te vayas headless para arreglar una página lenta, para escapar de un tema que heredaste, o porque el equipo de front end prefiere escribir React antes que Liquid. Las tres se arreglan por una fracción del precio, y ninguna es un problema de arquitectura.