Cómo elegir entre arquitecturas de CMS headless, acopladas e híbridas

Un CMS tradicional, o acoplado, almacena el contenido y genera las páginas que lo muestran. Los editores trabajan en un sistema que sabe cómo se ve la página; los desarrolladores crean plantillas dentro de ese sistema. Un CMS headless almacena y gestiona el contenido y lo expone a través de una API, y la “cabeza” (el sitio web, la aplicación móvil, la pantalla del quiosco) es una aplicación independiente que obtiene el contenido y lo presenta por su cuenta.

Esa separación explica toda la diferencia. Todas las ventajas que se atribuyen a la arquitectura headless (velocidad, flexibilidad, frameworks de front-end modernos, publicación multicanal) se derivan de ella, y también todos sus inconvenientes. El contenido pasa a ser datos estructurados en lugar de páginas, lo que aporta flexibilidad y también obliga a que alguien diseñe esa estructura. La presentación pasa a ser una aplicación propia de la organización, lo que significa que su equipo es responsable del rendimiento, la accesibilidad y la disponibilidad.

El argumento más sólido a favor de headless es el contenido que debe aparecer en más de un lugar. Por ejemplo, un grupo con una docena de sitios de marca que comparten información de productos, textos legales y comunicados de prensa; una empresa que publica el mismo contenido en un sitio web, una aplicación móvil y pantallas en tienda; o una organización que trabaja en tres idiomas y necesita que las traducciones se mantengan al día con el original. En todos estos casos, almacenar el contenido una sola vez como entradas estructuradas y con información de idioma, y distribuirlo a través de una API, elimina gran parte de las copias y de las incoherencias que conllevan.

Headless también conviene a las organizaciones con un equipo sólido de ingeniería de front-end que ya desarrolla en React o frameworks similares y que quiere tratar el sitio web como un producto, con los mismos pipelines y las mismas prácticas de pruebas y despliegue que sus demás aplicaciones. Si ese equipo existe, una API de contenido encaja de forma más natural que un sistema de plantillas.

Los desarrolladores suelen preferir headless: una API limpia, un front-end bajo su control y ningún lenguaje de plantillas heredado. Los editores suelen mostrarse menos entusiastas, y de su experiencia depende que el contenido llegue a publicarse. En un CMS acoplado, el editor ve la página tal como aparecerá, arrastra un componente a su lugar y pulsa Publicar. En una configuración headless pura, los editores rellenan campos en un formulario y confían en que el front-end los presente correctamente. La vista previa de la página real con contenido no publicado debe desarrollarse, al igual que la programación, el flujo de trabajo y las aprobaciones si el CMS no los ofrece.

Antes de elegir headless, entreviste a los editores. Averigüe cuántas páginas publican por semana, si crean ellos mismos las landing pages o se las piden a un desarrollador, y si necesitan ver la página mientras la editan. Si el equipo de marketing necesita crear y modificar páginas sin ayuda de ingeniería, la organización necesita un CMS con una edición visual real sobre su API o bien un modelo híbrido, y en ambos casos debe presupuestar herramientas de vista previa y composición.

El comercio electrónico es donde la elección tiene más consecuencias. Una arquitectura headless combina una plataforma de contenido con un motor de comercio, un servicio de búsqueda y un proveedor de pagos independientes, lo que se conoce como stack componible. Para un minorista con requisitos particulares y un equipo capacitado, esto aporta lo mejor de cada categoría y la libertad de cambiar cualquier pieza. Para la mayoría de las organizaciones, también implica hacerse cargo de la integración entre catálogo, contenido, carrito, proceso de pago y promociones, y mantener alineadas las hojas de ruta de varios proveedores.

Una plataforma integrada, en la que el contenido y el comercio comparten un modelo de datos y una interfaz de administración, elimina ese costo de integración y suele ofrecer a los responsables de comercialización una mejor experiencia en el día a día. La decisión depende de si los requisitos de comercio son lo bastante particulares como para justificar ensamblar el stack internamente. En muchas organizaciones no lo son.

Los sitios headless suelen ser rápidos, pero la velocidad proviene de cómo está construido el front-end, no de la arquitectura en sí. Son rápidos cuando las páginas se generan de antemano o en el edge, se almacenan en caché de forma intensiva y el contenido se obtiene en el momento de la compilación o de la solicitud, no en el navegador en cada visita. Un sitio headless que llama a la API de contenido desde el navegador para cada componente puede ser más lento que el CMS acoplado al que sustituyó. Un CMS acoplado bien configurado detrás de una CDN también sirve las páginas con gran rapidez.

Trate el rendimiento como un requisito con un presupuesto (tiempo hasta el primer contenido, elemento de contenido más grande, disponibilidad para la interacción) y exija a cada arquitectura candidata que demuestre cómo cumple ese presupuesto, también en redes móviles y no solo con la conexión de la oficina.

Elija un CMS acoplado o híbrido cuando el contenido se encuentre en un solo sitio web, los editores necesiten componer las páginas por sí mismos, el equipo de ingeniería sea pequeño o se comparta con otros sistemas, y el plazo de lanzamiento importe más que la flexibilidad de la arquitectura. Esto describe a una gran cantidad de sitios de marketing corporativos, intranets y portales de servicio. Un CMS híbrido, que genera las páginas y además lo expone todo a través de una API, cubre hoy el sitio web y deja margen para una aplicación o un segundo canal en el futuro.

Elija headless cuando el contenido tenga varios destinos, cuando las traducciones y los sitios de marca deban mantenerse coherentes en muchas propiedades, cuando un equipo sólido de front-end quiera hacerse cargo de la experiencia, o cuando los requisitos de comercio exijan un stack componible y la organización esté preparada para operarlo. La decisión depende de la organización, no de la reputación de la tecnología.