Qué es un CMS headless y cuándo conviene

Conviene que sepas de dónde viene este artículo antes de seguir. Estudi Zeta desarrolla sitios con Nuxt y Strapi, así que tenemos interés comercial en que esta arquitectura te parezca buena idea. Por eso el texto dedica una sección entera a los casos en los que no compensa, y otra a lo que exige de tu equipo. Si después de leerlas la respuesta para tu proyecto es WordPress, el artículo habrá hecho su trabajo.

La arquitectura rinde cuando se cumple al menos una de estas condiciones:

• El contenido alimenta más de un canal. Web pública, aplicación, catálogo interno, pantallas, integración con un ERP o con un configurador de producto.
• El catálogo es grande y estructurado. Cientos de fichas con campos comunes, filtrables y relacionadas entre sí, donde cada campo tiene que poder consultarse por separado.
• El sitio funciona en varios idiomas con contenido propio de cada mercado, más allá de la traducción del mismo texto.
• La interfaz tiene requisitos que un tema no cubre. Animación sincronizada con el desplazamiento, modelos tridimensionales, configuradores, cualquier pieza donde la experiencia sea parte del producto.
• El proyecto va a crecer durante años y el coste de rehacerlo cada tres se ha vuelto un problema conocido.
• El rendimiento es un requisito de negocio, no una aspiración. Un sitio generado en tiempo de construcción parte de una ventaja difícil de igualar con un gestor que compone cada página en cada visita.

Una señal fiable: si al describir el proyecto aparecen las palabras "y también debería aparecer en…", la arquitectura headless probablemente tenga sentido.

Esta sección importa más que la anterior, porque es la que casi nadie escribe. Antes de entrar conviene separar dos cosas que suelen ir mezcladas: las limitaciones que son propias de la arquitectura y las que dependen de cómo se planteó el proyecto. Las segundas son reales, se encuentran a menudo, y se evitan con decisiones que se toman antes de escribir la primera línea de código.

Empecemos por dos criterios que se citan como propios de la arquitectura y no lo son.

El primero es el tamaño. Un sitio de diez páginas con cinco idiomas, datos estructurados por tipo de entidad y un catálogo que va a crecer es mejor candidato que doscientas entradas de blog sin estructura. El número de páginas no dice nada sobre la arquitectura que necesita.

El segundo es publicar contenido de forma habitual. Los gestores headless actuales incluyen vista previa del sitio real, no una aproximación dentro del editor, y quien publica entradas en un gestor tradicional publica en uno headless con una formación breve. A cambio, el sitio no arrastra extensiones que actualizar, incompatibilidades entre ellas ni la superficie de ataque de un sistema que ejecuta código en cada visita.

El tercero es el condicional, y merece detalle. Se dice que en headless el equipo no puede montar páginas nuevas sin ayuda. Ocurre, y con frecuencia, pero no por la arquitectura: ocurre cuando el proyecto se construyó como un conjunto de plantillas fijas. Si en cambio se define desde el principio un catálogo de componentes con sus variantes de diseño y se colocan en zonas dinámicas, el editor compone páginas completas eligiendo bloques y orden. La diferencia entre las dos situaciones es una decisión de diseño de sistema tomada antes de empezar, no una propiedad del gestor.

Lo que sí requiere desarrollo en cualquier caso es ampliar ese catálogo. Una calculadora de presupuesto, un configurador, un buscador con filtros que antes no existían: eso es funcionalidad nueva y hay que construirla. La diferencia con un gestor tradicional no está en la maquetación, está en que allí una parte de esa funcionalidad a veces se compra ya hecha.

De ahí salen tres preguntas que conviene hacer a cualquier proveedor antes de firmar, y cuyas respuestas predicen bastante bien cómo será el año siguiente al lanzamiento:

• Qué páginas voy a poder montar sin llamaros, y con qué bloques.
• Qué pasa cuando necesite algo que hoy no está previsto, y cómo se presupuesta.
• Quién puede continuar este proyecto si dejamos de trabajar juntos.

Los casos donde la respuesta correcta sí es un gestor tradicional:

• No hay ni va a haber acceso continuado a alguien que toque código. Es el criterio decisivo. Sin desarrollador (interno, agencia o tercero), un proyecto headless se queda congelado en cuanto el negocio necesite algo que no estaba previsto.
• El negocio depende de funcionalidad de terceros, presente o futura. Reservas, membresías, formación, comercio con configuraciones específicas, herramientas de cálculo. Si la operativa se apoya en varias extensiones, o si es previsible que las necesidades futuras se resuelvan comprando en lugar de construyendo, el ecosistema pesa más que la arquitectura.
• El presupuesto o el plazo no absorben el arranque. La capa visible hay que construirla, y el trabajo de definir el modelo de contenido y el catálogo de componentes va por delante de la primera pantalla visible. Si el proyecto sale en tres semanas con recursos ajustados, la decisión es otra, y no es una decisión mala.
• Un comercio electrónico estándar sin necesidades particulares de interfaz ni integraciones fuera de lo común, donde una plataforma especializada resuelve el conjunto.

Ese primer punto es el que más pesa y el que menos se pregunta al decidir. Los otros tres tienen solución con presupuesto; ese no.

Y conviene decir que el error va en las dos direcciones. Un catálogo de mil referencias con integraciones montado sobre un gestor tradicional acaba sostenido por una acumulación de extensiones que ya no se puede actualizar sin miedo. Elegir mal no se manifiesta en el lanzamiento: se manifiesta dos años después, cuando el sistema deja de acompañar lo que el negocio necesita.

Es la objeción que más aparece, y viene de una confusión: la mala fama de las aplicaciones que se construyen enteras en el navegador, donde el buscador recibe una página vacía y tiene que ejecutar código para ver el contenido.

Un proyecto headless bien planteado no funciona así. El contenido se genera en el servidor o en el momento de construir el sitio, y llega al buscador como HTML completo. Desde el punto de vista del rastreo, es indistinguible de un sitio tradicional.

Lo que sí cambia es de quién es la responsabilidad. En un gestor tradicional, las etiquetas, el mapa del sitio, las URL canónicas y los datos estructurados los resuelve una extensión que alguien instala. En headless no hay extensión: cada una de esas piezas se construye, y si no se construye, no existe. No es una desventaja de la arquitectura, es un requisito del proyecto que hay que presupuestar desde el principio.

La ventaja está en el control. Cuando los datos estructurados se generan a partir de campos definidos en el modelo de contenido, dejan de depender de que alguien rellene bien una caja de texto.

Un proyecto headless arranca más caro. Hay que construir la capa visible que un tema resolvería, configurar los tipos de contenido, montar la vista previa y resolver todo lo que en un gestor tradicional viene puesto.

La comparación honesta no es la factura inicial: es el coste a tres o cuatro años, incluyendo mantenimiento, licencias, incidencias y la probabilidad de tener que rehacer el sitio. Un proyecto tradicional que hay que reconstruir a los tres años puede resultar más caro que uno headless que se mantiene siete. Y al revés: un proyecto headless en un sitio que nunca necesitó esa arquitectura es dinero gastado en complejidad que nadie usa.

Para editar, poco: los paneles de los gestores headless son sencillos y la formación se mide en horas. Quien publica una entrada en un gestor tradicional publica una en Strapi sin dificultad.

Para mantener, más. Estas son las diferencias reales del día a día:

• Componer páginas sí, ampliar el catálogo de bloques no, siempre que el proyecto se definiera así. Si se construyó con plantillas fijas, cualquier página nueva pasa por desarrollo. Conviene preguntarlo antes de firmar, porque después es caro de cambiar.
• Las actualizaciones son de código, no de un botón. Se planifican, se prueban y se despliegan.
• Hace falta acceso a un desarrollador, ya sea interno, la agencia que lo construyó o cualquier otra. Aquí conviene preguntar por el stack: si está construido sobre tecnologías estándar y con documentación, cualquier desarrollador senior puede continuarlo. Si está construido sobre una solución propietaria, no.
• La vista previa se configura, no viene puesta. Los gestores headless actuales la traen como funcionalidad, y muestra el sitio real en lugar de una aproximación dentro del editor. Conviene dejarla lista antes de que el equipo empiece a publicar, no después.

Si tu empresa no tiene ni va a tener acceso continuado a alguien que pueda tocar el código, esa es una razón suficiente para quedarse en un gestor tradicional, aunque el resto de criterios apunten en la otra dirección.