Dibuja el customer journey de automoción y casi siempre obtienes la misma diapositiva: descubrimient…
FaaS vs. CMS headless: por qué un CMS solo sigue sin ser un frontend
FaaS vs. CMS headless: por qué un CMS solo sigue sin ser un frontend
El equipo eligió un CMS headless. El modelo de contenido está definido, la API de entrega devuelve contenido limpio y estructurado. La energía del kickoff está alta. Entonces llega la pregunta que debería haberse hecho primero: ¿quién renderiza esto, quién lo opera y quién mantiene el storefront rápido y actualizado dentro de seis meses? Un CMS headless no responde a esa pregunta, porque nunca se construyó para eso. Es un backend de contenido, no un frontend.
Esa confusión no es un detalle de diseño, es un error de categoría. Un CMS y un Frontend as a Service (FaaS) resuelven problemas distintos, aunque ambos aparezcan en la misma frase en el momento en que "composable" entra en la conversación. Este post traza la línea con claridad: qué le da realmente un CMS headless, qué falta después de eso, y cómo hacer que ambos funcionen juntos sin construir ninguna de las dos capas dos veces.
Qué entrega realmente un CMS headless
Un CMS headless, ya sea Contentful, Storyblok, Sulu o Kontent.ai, entrega de forma fiable tres cosas: un modelo de contenido para contenido estructurado, una interfaz de edición para los equipos de marketing y editorial, y una API de entrega a través de la cual se extrae el contenido. Ese es el núcleo de la promesa "headless": el contenido se desacopla del canal de salida, de modo que el mismo modelo de contenido puede servir a web, app y otros puntos de contacto.
Lo que deliberadamente falta es la "cabeza". Sin renderizado, sin librería de componentes, sin routing, sin capa de hosting, sin garantía de rendimiento. Eso no es una carencia del producto, es la decisión de diseño que hace que un CMS headless sea rápido y flexible en primer lugar. Solo significa que el trabajo real empieza una vez que el contenido está modelado, no termina ahí.
Lo que falta después: la capa operativa del storefront
Entre "la API de contenido devuelve datos" y "un cliente ve una página rápida, accesible y consistente con la marca" hay toda una capa operativa que los talleres de kickoff adoran saltarse:
- Renderizado y componentes. ¿Quién construye los componentes que muestran el contenido, y quién los mantiene entre campañas, idiomas y marcas?
- Rendimiento y Core Web Vitals. Una respuesta de API no es una puntuación de LCP. La entrega en el edge, el cacheo y la optimización de imágenes no ocurren automáticamente solo porque el CMS sea headless.
- Accesibilidad. WCAG y los estándares de accesibilidad equivalentes son propiedades del frontend, no del modelo de contenido.
- Vista previa en vivo en contexto real. Muchos editores de CMS muestran una vista previa del contenido, no la página real del storefront renderizada, con el layout real y los componentes vecinos reales.
- Operaciones. Hosting, CI/CD, monitorización, rollback, todo lo que convierte un build puntual en un servicio en funcionamiento.
Esa capa es exactamente el trabajo de un Frontend as a Service. Hemos escrito por separado sobre cómo es la edición visual directamente en un storefront en vivo, en lugar de una vista previa de CMS aislada: Edición visual en un storefront en vivo: por qué la vista previa de un CMS no es un frontend.
FaaS: la capa operativa sobre el CMS
Frontend as a Service es exactamente el modelo operativo que cierra el hueco entre la API de contenido y el storefront en vivo, como servicio en lugar de como proyecto puntual. En vez de que su equipo construya la capa de renderizado, rendimiento y operaciones una vez y luego la mantenga viva por su cuenta, un FaaS ejecuta esa capa de forma continua: librería de componentes, editor en vivo, hosting, monitorización de rendimiento, sincronización multi-idioma. El CMS sigue siendo la fuente de verdad para el contenido, el FaaS se convierte en la fuente de verdad para la experiencia del storefront.
La diferencia con una capa de frontend construida internamente no es que existan componentes, los equipos internos también los construyen. La diferencia es que la propia capa operativa se convierte en una propiedad de la plataforma, en lugar de tener que traer de vuelta capacidad de ingeniería cada vez que el CMS se actualiza, el tráfico se dispara o se añade un nuevo idioma. Esbozamos este mismo principio, complementar un CMS con un frontend visual en lugar de sustituirlo, usando ejemplos concretos de migración de CMS aquí: CMS headless con un visual page builder: la capa de frontend que falta.
CMS y FaaS no son una disyuntiva
Las últimas semanas han traído toda una ola de comparativas de "opciones de frontend para [CMS]", cubriendo Contentful, Storyblok, Sulu, Kontent.ai y otros. El hilo común en todas ellas es el mismo: el CMS es bueno en aquello para lo que se construyó, el modelado de contenido, los flujos editoriales, la entrega vía API. Ninguno de ellos se diseñó para ser el frontend de un storefront, y eso no es una crítica a los proveedores, es simplemente arquitectura.
Por eso Laioutr no se posiciona como un sustituto de CMS, sino como la capa de frontend que se sitúa sobre un CMS headless existente. Su CMS sigue siendo el backend de contenido, Content Management en Laioutr gestiona la composición, la edición en contexto y la consistencia de marca entre páginas, idiomas y campañas. Los equipos editoriales siguen trabajando en su CMS, o directamente en Studio según la configuración, pero la página que realmente sale a producción es un storefront operado, no la salida en bruto renderizada de una API de contenido.
Cómo separar la pregunta del CMS de la pregunta del frontend en la práctica
Cuatro preguntas ayudan a mantener las dos capas separadas antes de que un proyecto tropiece por mezclarlas:
- ¿Quién renderiza la página que realmente ve el cliente? Si la respuesta es "el CMS se encarga de eso de alguna manera", la pregunta del frontend sigue abierta.
- ¿Dónde viven el rendimiento, la accesibilidad y el SEO? Los tres pertenecen a la capa de frontend, no al modelo de contenido.
- ¿El equipo editorial ve una vista previa real en vivo, o solo una vista previa de contenido? Esa diferencia decide si una página de campaña sale en horas o en sprints.
- ¿Qué pasa con una segunda marca o un segundo mercado? Una buena respuesta necesita su propia capa operativa, no una segunda configuración de CMS.
Si no puede responder con claridad estas cuatro preguntas para su configuración actual, probablemente tiene un CMS, pero todavía no un frontend.
Próximos pasos
Elegir un CMS headless es una buena decisión. Asumir que resuelve automáticamente la pregunta del frontend es el error que ralentiza los proyectos justo después del kickoff. Si quiere ver cómo es un Frontend as a Service en concreto sobre su CMS actual, eche un vistazo a Frontend as a Service o reserve una demo en la que lo repasamos contra su modelo de contenido real, no una página de ejemplo genérica.
Más de la plataforma Laioutr
Sobre el autor: Marcel Thiesies es cofundador de Laioutr. Trabaja con equipos del mid-market en la región DACH y más allá para mantener separadas las decisiones de CMS y las decisiones de frontend, mientras las opera juntas en la práctica.