De archivos HTML a JAMStack: treinta años intentando separar el contenido de la presentación

Roger Mohino -

Los inicios de la web

Los primeros sitios web eran, literalmente, documentos. Archivos HTML escritos a mano, subidos por FTP a un servidor, y devueltos al navegador tal cual. No había bases de datos. No había paneles de administración. No había lógica de negocio. Si querías cambiar una palabra, abrías el archivo, la editabas y volvías a subirlo.

Funcionó durante unos años. Dejó de funcionar cuando internet creció.

A finales de los 90, las empresas empezaron a necesitar actualizar contenido todos los días, y depender de un desarrollador para cambiar un titular se volvió insostenible. La industria respondió con los primeros gestores de contenido: sistemas que separaban el contenido de la plantilla para que alguien sin conocimientos técnicos pudiera publicar sin tocar código.

En los 2000, WordPress, Joomla y Drupal llevaron esa idea hasta el extremo, cualquier persona, en cuestión de minutos, podia tener un sitio publicado, con panel visual, plugins para todo y una comunidad inmensa resolviendo dudas. WordPress ganó esa década con tanta contundencia que, más de veinte años después, sigue alimentando alrededor del 40% de la web.

Pero internet no paró. Las aplicaciones se volvieron más complejas, los equipos empezaron a construir frontends con React y Vue, y esos frameworks modernos chocaban de frente con la forma en que los CMS tradicionales habían sido diseñados. El modelo monolítico: un único sistema que almacena, procesa y sirve el HTML, empezó a crujir.

Treinta años después de aquellos primeros archivos estáticos, la industria se hizo una pregunta que había evitado durante demasiado tiempo: ¿y si el contenido no tuviera que saber cómo se muestra?

El modelo monolítico y por qué dejó de ser suficiente

Para entender qué significa desacoplar un CMS, hay que entender primero qué está acoplado.

En un sistema monolítico, el mismo proceso hace tres cosas a la vez: guarda el contenido, lo procesa, y lo sirve como HTML al navegador. Todo en el mismo sitio, todo en el mismo momento. WordPress y Drupal son el ejemplo canónico: cuando un usuario visita una página, el servidor consulta la base de datos, aplica una plantilla escrita en PHP (Twig en Drupal, los theme files en WordPress) y devuelve HTML ya renderizado.

Durante años, esto fue más que suficiente. El ecosistema de WordPress resolvía casi cualquier necesidad funcional sin escribir una línea de código, el panel era familiar y todo el mundo sabía cómo utilizarlo.

El problema no es que el modelo monolítico sea malo. El problema es que el contexto ha cambiado.

Los sitios web modernos reciben miles de visitas simultáneas, tienen que cargar en menos de dos segundos, y deben funcionar igual en un móvil de 200€ que en un televisor inteligente. Un servidor que genera HTML en tiempo real para cada petición, con una cadena de plugins ejecutándose en cada carga, tiene cada vez más dificultades para cumplir esas expectativas.

Y luego está la seguridad, WordPress es el CMS más atacado del mundo, en parte porque es el más usado, y en parte porque cada plugin desactualizado es una puerta de entrada. Cuando tu arquitectura depende de veinte plugins, tu superficie de ataque también.

Headless y decoupled no son lo mismo

Alrededor de 2015, el vocabulario cambió. Empezaron a aparecer dos palabras que todo el mundo usaba como sinónimos y que en realidad no lo son.

  • Decoupled describe la separación entre frontend y backend. El CMS sigue existiendo, sigue teniendo su panel, pero el frontend ya no depende de él para renderizar las páginas. Hay una frontera limpia y clara entre ambos.
  • Headless va un paso más allá: el CMS ni siquiera tiene capa de presentación propia. Solo expone datos a través de una API. 

Todo headless es decoupled, pero no todo decoupled es headless. Drupal es el ejemplo perfecto: puedes usarlo con su sistema de plantillas de toda la vida, o activar su JSON:API y consumirlo desde un frontend completamente separado. Si desactivas su frontend, se convierte en 100% headless.

La implicación práctica es concreta: el CMS deja de generar HTML, es decir en lugar de renderizar páginas, expone endpoints con JSON. Y ese JSON puede consumirlo en un sitio web, una app móvil, una pantalla digital, o cualquier cosa capaz de hacer una petición HTTP. WordPress añadió su REST API en 2016. El CMS más tradicional del mundo reconoció, oficialmente, que el futuro pasaba por poder usarlo sin su frontend.

JAMStack: lo que sucede cuando desacoplas

Desacoplar el CMS resuelve un problema y abre otro inmediatamente. Si el CMS ya no genera el HTML, alguien tiene que hacerlo. ¿Quién, cuándo, y cómo?

La respuesta llegó en 2015, de la mano de Mathias Biilmann, cofundador de Netlify, bajo un nombre que se volvió estándar: JAMStack. No es un framework, ni una tecnología. Es una forma de pensar la arquitectura web cuando los datos, la lógica y la presentación viven en sitios distintos.

Se apoya en tres ideas, y cada una responde a un problema que el monolito no sabía resolver bien:

  • Pre-rendering. En lugar de generar el HTML cada vez que alguien visita una página, se genera una sola vez durante el build. El resultado es un conjunto de archivos estáticos listos para servir, sin procesamiento en tiempo real. Lo que antes hacía el servidor en cada petición, ahora lo hace una vez y se reutiliza.
  • CDN-first. Esos archivos estáticos se distribuyen por una red global de servidores. Cuando alguien visita el sitio desde Barcelona, recibe los archivos desde el nodo más cercano, no desde un servidor centralizado en Virginia. La diferencia en velocidad es enorme y la resiliencia ante picos de tráfico es algo que un servidor tradicional difícilmente puede igualar.
  • APIs para lo dinámico. Formularios, autenticación, pagos, datos en tiempo real. Todo se resuelve con APIs externas o funciones serverless. El frontend las consume desde el navegador, y la arquitectura se mantiene desacoplada de principio a fin.

Next.js, Nuxt y Astro son los frameworks que hicieron esto viable en producción. Permiten combinar páginas pre-renderizadas en build time con contenido dinámico bajo demanda, sin tener que elegir entre velocidad y flexibilidad.

Tres filosofías sobre dónde debe alojarse el contenido

Una vez que el CMS es headless, la siguiente pregunta es inevitable: ¿cuál uso? El mercado ha crecido tanto en los últimos años que la respuesta depende menos de features concretas y más de una decisión filosófica: ¿dónde quieres que viva tu contenido?

Hay tres respuestas posibles, y cada una resuelve una pregunta distinta.

En el repositorio, junto al código (Git Based)

Es la respuesta más radical. El contenido no vive en una base de datos, ni en un servidor externo. Vive como archivos .md, .json o .yaml dentro del propio repositorio Git. El panel de administración es una interfaz visual que lee y escribe esos archivos, haciendo commits automáticos cuando el editor publica.

Esto permite no disponer de infraestructura adicional que mantener, el historial de versiones viene gratis con Git, y el developer tiene control absoluto. La contrapartida es que no escala bien con grandes volúmenes de contenido, el soporte multi-idioma suele ser limitado o inexistente, y no es el modelo adecuado para contenido estructurado complejo.

Los tres nombres a conocer aquí son Keystatic, Tina CMS y Nuxt Studio. 

Keystatic tiene integración oficial con Next.js y TypeScript nativo, con dos modos de funcionamiento: local para desarrollo y GitHub para equipos en producción. 

Tina es el más cercano al modelo de edición visual sobre la página, con preview en tiempo real. 

Nuxt Studio hace lo mismo pero para el ecosistema Vue.

Este modelo encaja bien en blogs, documentación y sitios editoriales ligeros. No encaja en un e-commerce multi-idioma con diez mil referencias.

En tu propio servidor (Self-hosted)

Es el modelo más equilibrado entre control y funcionalidad. El CMS se instala en una infraestructura que tú gestionas, guarda el contenido en su propia base de datos y expone una API REST o GraphQL que el frontend consume.

Esto proporciona una serie de ventajas muy claras:

  • Control total sobre los datos
  • Sin coste por uso más allá del servidor
  • Código abierto en todos los casos

Pero contiene una serie de limitaciones:

  • Mantenimiento, actualizaciones, seguridad y backups son responsabilidad del desarrollador.

En este caso, hay tres opciones dominantes, y cada una representa una filosofía distinta:

  • Strapi es el más veterano. Nació en 2015, tiene la comunidad más grande de los tres, y su propuesta es sencilla: defines tipos de contenido desde el panel, y Strapi genera automáticamente los endpoints REST y GraphQL. El panel es intuitivo para perfiles no técnicos: crear un artículo se parece a rellenar un formulario. El multi-idioma funciona bien, pero requiere instalar el plugin i18n oficial. Podriamos decir que es el WordPress del mundo headless.
  • Directus es el más distinto de los tres. Mientras Strapi y Payload crean su propio esquema en base de datos, Directus hace algo que ningún otro hace: lee y replica la estructura de una base de datos ya existente. Si ya cuentas con una base de datos con su propia estructura, Directus se adapta a ella. El panel es el mejor diseñado para perfiles no técnicos: visual, limpio, con gestión de assets integrada, flujos de trabajo y permisos granulares. El multi-idioma es nativo y sólido. 
  • Payload es el más novedoso y el más técnico. Su propuesta rompe con la lógica de los otros dos: no se instala junto a tu aplicación Next.js, se instala dentro. El CMS y el frontend comparten el mismo codebase, los mismos tipos de TypeScript, la misma conexión a la base de datos. Defines una colección en Payload y tienes acceso tipado a esos datos directamente en tus Server Components, sin llamadas API, sin capa de autenticación separada, sin sincronizar schemas entre dos proyectos. 

Este modelo encaja cuando el control sobre los datos es innegociable, hay volumen de contenido, y conviven dos perfiles de usuario (técnico y no técnico) que necesitan herramientas distintas.

En la nube de un tercero (Cloud-hosted)

El CMS lo gestiona otra empresa en su infraestructura, es decir tu equipo accede al panel por web, el contenido vive en los servidores del proveedor y tu frontend consume su API.

La ventaja es que no hay infraestructura que mantener, las actualizaciones y la seguridad son problema del proveedor, y la escalabilidad viene incluida. La contrapartida son tres cosas que conviene mirar de cerca: 

  • Coste recurrente escala con el uso
  • Dependen del proveedor
  • Los datos no están en tus servidores.

Encontramos tres alternativas, las más demandadas en el mercado:

  • Ghost nació directamente como headless, con el Content API en el núcleo. Está especializado en contenido digital: blogs, newsletters, publicaciones editoriales. El panel es limpio y amigable, pero no está pensado para contenido estructurado complejo como servicios o portfolio.
  • Prismic se posiciona en el terreno de los sitios web construidos con JavaScript moderno. Su carta fuerte es el Slice Machine: bloques de contenido reutilizables que el editor combina visualmente para construir páginas sin tocar código. El multi-idioma es nativo, la integración con Next.js es de las mejores del mercado, y los planes van desde gratis hasta 675€/mes en el tier Platinum.
  • Storyblok hizo algo que ningún otro CMS headless se atrevió a hacer: devolverle al editor la sensación de estar tocando la página. Su Visual Editor permite editar el sitio mientras se navega, con preview en tiempo real antes de publicar. Para un perfil no técnico es lo más cercano a editar directamente sobre el diseño, sin abstracciones. El contenido se organiza en bloks (componentes reutilizables que el editor combina), el multi-idioma es nativo en todos los planes, y la integración con Next.js es completa.

Este modelo encaja cuando la velocidad de implementación pesa más que el control, el equipo no quiere gestionar infraestructura, y el coste mensual es asumible.

Tabla comparativa de CMS

El problema de el multi-idioma en headless

Hay una cosa que conviene decir antes de cerrar, y es que desacoplar el CMS no lo resolvió todo. Algunos problemas se volvieron más sencillos, otros todo lo contrario. El multi-idioma es un caso paradigmático.

En un monolito como WordPress, el multi-idioma se resolvía instalando un plugin. WPML, Polylang, y listo. En una arquitectura headless hay que coordinar dos piezas: el CMS y el frontend. Y hay dos formas de hacerlo, cada una con sus implicaciones.

  • Traducciones en el CMS. El editor gestiona las traducciones campo a campo desde el panel. Cuando el frontend pide contenido, especifica el idioma en la query y recibe los datos ya traducidos. Es el modelo de Directus, Storyblok, Prismic y Sanity.
  • Traducciones en el frontend. El CMS guarda el contenido en un solo idioma, y la capa de internacionalización vive en Next.js mediante librerías como next-intl o i18next. Más flexible, pero pone más peso en el lado del desarrollo. Tina CMS funciona así.

Y luego está el tema de las URLs, que para SEO es muy importante. Hay tres estrategias posibles:

  • /es/servicios/desarrollo-web: subcarpetas por idioma. La opción más recomendada por Google y la más sencilla de implementar.
  • es.itdo.com/servicios/desarrollo-web: subdominios. Es válido, pero más complejo de mantener.
  • itdo.es/servicios/desarrollo-web: dominios separados. Máximo control SEO y máxima infraestructura.

Las subcarpetas son la opción por defecto en Next.js esto quiere decir que el enrutado internacional se configura en next.config.js y permite redirigir automáticamente según el navegador del visitante. Lo único que no puede faltar es la etiqueta hreflang en el <head> de cada página, ya que es lo que le dice a Google qué versión del contenido corresponde a cada idioma.

Aquí hay una ventaja real del modelo headless sobre el monolito, y merece la pena nombrarla: el schema markup y los metadatos se pueden construir programáticamente desde los mismos datos que alimentan el contenido. En WordPress esto requiere tres plugins distintos y rezar para que no choquen entre ellos. En Next.js es una función que recibe datos y devuelve JSON-LD.

El círculo se cierra

La industria empezó con archivos HTML estáticos porque era lo único que había. Inventó los CMS monolíticos porque lo otro no escalaba, construyó WordPress y Drupal durante veinte años hasta que se quedaron cortos (en según qué caso, no hay que menos tenerlos), y acabó desacoplando el contenido de la presentación para volver a donde empezó: sirviendo archivos estáticos desde un CDN, solo que esta vez generados automáticamente a partir de un CMS que vive en otro sitio.

No es casualidad. Es lo que pasa cuando una industria madura, descubre que los problemas viejos no se resuelven con más capas, sino separando bien las capas que ya tiene.

¿Y tú, qué CMS crees que es el más óptimo para tu sitio web?

Referencias