CMS monolítico vs headless vs composable

“WordPress ya está viejo, hagámoslo headless.”

Es probable que hayas escuchado esa frase, o que la hayas dicho. El problema no es que sea falsa, es que responde a una pregunta que nadie hizo.

La pregunta que decide este asunto no aparece en ninguna comparación de tecnologías: quién va a publicar el contenido, con qué frecuencia, y qué necesita ver antes de darle a guardar. De ahí se deriva casi todo lo demás.

Este artículo compara las tres formas de repartir contenido y presentación desde ese ángulo, que es el que se paga después.

Qué se está separando en realidad

Las tres opciones responden a lo mismo: cuánto se separa el lugar donde vive el contenido del lugar donde se muestra.

Eso último es la clave que casi nunca aparece en la comparación. Separar no elimina trabajo: lo transfiere de un sistema que ya lo resolvía a un equipo que ahora tiene que resolverlo.

Quién edita, quién mantiene y qué cuesta cada opción

Las dos filas que más pesan en la práctica son la de previsualización y la de quién arregla una integración rota. Ninguna de las dos aparece en las comparativas de los proveedores, por motivos evidentes.

Lo que un CMS tradicional resolvía gratis

Al salir de un sistema acoplado se hereda una lista de tareas que antes nadie veía porque venían hechas. Esto es lo que pasa a ser código tuyo:

// Todo esto lo daba el CMS. Ahora lo generas tú, por página.
$meta = [
    'title'       => $post->seoTitle ?: $post->title,
    'description' => $post->excerpt,
    'canonical'   => $site . $post->url,     // y decidir qué es canónico
    'og:image'    => $post->image ?: $site . '/og-default.jpg',
    'robots'      => $post->published ? 'index, follow' : 'noindex',
];

// Y además: sitemap.xml al publicar, redirecciones cuando cambia
// un slug, y una previsualización de lo no publicado.

Ninguna de esas piezas es difícil por separado. El problema es que son ocho o diez, hay que acordarse de todas, y las que se olvidan no fallan de forma visible: simplemente el contenido deja de posicionar, o una URL antigua empieza a devolver un error que nadie nota durante meses.

La redirección al cambiar un slug es el caso más típico. En un CMS tradicional suele estar resuelta; en un sistema propio, si nadie la programó, cada corrección de un título rompe los enlaces existentes.

Cuándo headless sí compensa

El punto de la previsualización es el que más fricción genera después. Un editor acostumbrado a ver la página antes de publicar no acepta bien escribir a ciegas en un formulario, y construir una previsualización fiel en un sistema propio cuesta bastante más de lo que parece.

El argumento del rendimiento, con matices

La razón más repetida para dejar un CMS tradicional es la velocidad. Es un argumento real, pero rara vez se plantea con precisión, y eso lleva a proyectos que se rehacen enteros para resolver algo que tenía una solución mucho más barata.

Un CMS acoplado es lento por un motivo concreto: cada visita ejecuta código y consulta la base de datos para producir una página que casi siempre es idéntica a la anterior. Ese trabajo se repite miles de veces al día para devolver lo mismo.

Pero eso no se arregla necesariamente separando el contenido de la presentación. Se arregla no repitiendo el trabajo, y hay tres formas de conseguirlo, en orden de costo:

• Caché de página en el propio CMS. Una extensión que guarda el HTML ya generado y lo sirve tal cual. Es lo más barato y suele bastar.
• Un CDN por delante. Las páginas se sirven desde un punto cercano al visitante sin tocar tu servidor. Tampoco requiere cambiar la arquitectura.
• Generación estática. El HTML se produce una vez al publicar y el servidor solo entrega archivos. Es lo más rápido posible y es lo que hace este sitio.

La tercera es la que a veces se confunde con headless, y no son lo mismo. Puedes generar un sitio estático a partir de un CMS tradicional, y puedes tener un headless que renderiza en cada petición y va lento igual.

La pregunta útil no es si el CMS es lento, es dónde se está repitiendo trabajo que podría hacerse una sola vez. Si la respuesta se resuelve con caché, cambiar de arquitectura es una obra mayor para un problema menor.

Si ya tienes un CMS y estás pensando en cambiar

Este es el punto de partida de casi todo el mundo, y el que menos se cubre en las comparativas, porque el escenario habitual no es elegir desde cero sino decidir si vale la pena moverse.

Antes de migrar conviene medir tres cosas del sistema actual, porque las tres determinan el costo real del cambio y ninguna se ve a simple vista.

Con esos tres números la decisión deja de ser una preferencia técnica y pasa a ser una estimación. Un sitio de doscientas páginas con dos extensiones y un editor ocasional es una migración de semanas; uno de veinte mil URLs con tienda y tres idiomas es un proyecto que conviene no empezar sin estar seguro.

Y si decides migrar, hay un orden que reduce el riesgo: mantener el CMS actual como panel de edición y empezar consumiendo su API para generar el sitio. Así compruebas que el contenido sale bien y que el frontend nuevo se sostiene, antes de cambiar también la herramienta con la que trabaja quien publica.

El problema específico de composable

Composable lleva la idea un paso más allá: un servicio para el contenido, otro para la búsqueda, otro para la tienda, otro para las imágenes, cada uno el mejor en lo suyo.

Sobre el papel es atractivo. En la práctica cambia la naturaleza del trabajo: dejas de construir funcionalidad y pasas a mantener integraciones.

Composable se justifica cuando hay equipos distintos que gestionan áreas distintas del negocio y necesitan herramientas especializadas. Para un proyecto que lleva una o dos personas, es la forma más rápida de convertir el mantenimiento en un trabajo de tiempo completo.