JAMstack vs headless: diferencias reales

JAMstack (JavaScript, APIs, Markup) es un enfoque de desarrollo web que genera páginas estáticas en tiempo de build y las sirve desde CDN. La interactividad se añade con JavaScript en el cliente, y la lógica de negocio se delega a APIs externas (pagos, autenticación, formularios, bases de datos).

La ventaja principal es el rendimiento: las páginas pre-renderizadas se sirven instantáneamente desde el edge, sin necesidad de servidor generando HTML en cada request. Frameworks como Astro, Next.js (modo SSG), Gatsby y Hugo implementan este enfoque. El ecosistema de plataformas de deploy (Vercel, Netlify, Cloudflare Pages) está optimizado para JAMstack.

Headless se refiere a la separación entre la capa de contenido/lógica (backend) y la capa de presentación (frontend). El backend expone datos a través de APIs y no impone ninguna interfaz visual. El frontend puede ser una web, una app móvil, un quiosco o cualquier otro canal.

Headless no prescribe cómo se renderiza el frontend. Puede ser SSG (pre-renderizado), SSR (renderizado en servidor), CSR (renderizado en cliente) o una combinación. Es un concepto de arquitectura más amplio que JAMstack, centrado en el desacoplamiento de capas.

La confusión surge porque muchas implementaciones JAMstack son headless: usan un CMS headless como fuente de datos (Contentful, Strapi, Sanity) que se consume en build time para generar las páginas estáticas. En este caso, el proyecto es simultáneamente JAMstack (por cómo se renderiza) y headless (por cómo se gestiona el contenido).

Sin embargo, un proyecto puede ser headless sin ser JAMstack (un frontend React con SSR que consume un CMS headless) y JAMstack sin ser headless (un sitio estático con archivos Markdown locales, sin backend externo).

JAMstack es ideal para sitios con contenido que cambia con poca frecuencia: blogs, documentación, sitios corporativos, landings de marketing. El pre-renderizado garantiza tiempos de carga excelentes, seguridad inherente (no hay servidor expuesto) y costes de hosting muy bajos (CDN).

Los límites de JAMstack puro aparecen con contenido dinámico frecuente (feeds en tiempo real, dashboards personalizados) o catálogos de producto muy grandes donde el build time se vuelve prohibitivo. En estos casos, SSR o un enfoque híbrido es más adecuado.

Headless con SSR es más adecuado cuando el contenido cambia con alta frecuencia, cuando hay personalización por usuario, o cuando el catálogo es demasiado grande para pre-renderizar en cada build. Ecommerce con miles de SKUs, plataformas SaaS con dashboards y aplicaciones con contenido en tiempo real son escenarios típicos.

También es la opción cuando necesitas multicanalidad real: el mismo backend headless sirve datos a una web (SSR o SSG), una app móvil y otros canales sin duplicar la lógica de contenido.

Los frameworks modernos permiten combinar SSG y SSR en el mismo proyecto. Astro, Next.js y Nuxt soportan que algunas páginas se pre-rendericen en build time (JAMstack) mientras otras se generan en servidor por request (SSR). Esto permite usar SSG para las páginas estáticas y SSR para las dinámicas, optimizando rendimiento y frescura del contenido.

Incremental Static Regeneration (ISR) de Next.js y funcionalidades similares en otros frameworks añaden otra capa: las páginas estáticas se regeneran automáticamente en segundo plano cada cierto tiempo, combinando la velocidad del SSG con la actualización del SSR.