Un cliente me llamó en 2021, una marca de e-commerce mediana en Manchester, con alrededor de 40,000 SKUs, múltiples tiendas regionales, furioso. Habían gastado £180,000 durante 18 meses en una construcción headless de Shopify con un front end en Next.js, y sus tiempos de carga de página eran más lentos que el tema de Shopify que habían reemplazado. Su equipo de desarrollo había crecido de un contratista a cuatro. Los editores de contenido necesitaban un desarrollador presente solo para publicar una entrada de blog en vivo.
Punto clave: Usa una arquitectura headless cuando realmente necesites múltiples interfaces o cuando una arquitectura monolítica no pueda alcanzar el rendimiento requerido; un sitio WordPress con un buen tema supera a tres desarrolladores manteniendo una pila tecnológica que no necesitabas.
Headless les había sido vendida como el futuro. Y técnicamente, lo es. Pero nadie les dijo cuál sería el costo real de operarla.
He construido o supervisado construcciones en bien más de 12,000 sitios en Seahawk Media. Headless ha sido la opción correcta en quizá 8-10% de ellos. ¿El otro 90%? Habría sido un desastre, costoso, lento de entregar, y miserable de mantener. Este post es sobre saber en qué categoría cae tu proyecto antes de que ya hayas firmado los cheques.
---
Qué "Headless" Realmente Significa en la Práctica
Aclaremos la definición rápido. Un CMS tradicional, WordPress, Squarespace, lo que sea, acopla el back end de gestión de contenidos a la capa de presentación del front end. Se comunican entre sí de forma nativa. Headless los desacopla. Tu CMS (Contentful, Sanity, Strapi, WordPress en modo headless) se convierte en una API pura de contenido. Tu front end, Next.js, Nuxt, Astro, SvelteKit, lo que prefieras, obtiene ese contenido y lo renderiza como quiera.
Idea simple. La complejidad se cuela en todos lados.
El stack que realmente aparece en los proyectos
En la práctica, cuando alguien dice "headless", generalmente se refiere a una de estas combinaciones:
- Contentful o Sanity como CMS, sirviendo JSON sobre REST o GraphQL
- Next.js en el front end, ya sea generado estáticamente (SSG) o renderizado del lado del servidor (SSR)
- Vercel o Netlify para deployment y edge functions
- Shopify Storefront API o BigCommerce si hay comercio electrónico de por medio
- Alguna versión de Algolia para búsqueda, porque las opciones de búsqueda nativa suelen ser basura
Cada una de esas es una relación de proveedor separada, una línea de facturación separada, y algo separado que puede fallar a las 2am un viernes.
---
El Caso Genuino Para Ir Headless
Aquí está la cosa: hay razones reales y legítimas para hacer esto. No estoy descartando la arquitectura. Solo estoy cansado de que se aplique indiscriminadamente.
La entrega de contenido multicanal es el argumento más fuerte. Si el mismo contenido necesita aparecer en un sitio web, una aplicación móvil, una pantalla en quiosco y una interfaz de TV inteligente, un CMS acoplado se vuelve genuinamente problemático. ¿Una API de contenido única que las cuatro superficies consultan? Eso tiene sentido real. Seahawk tenía un cliente de hospitalidad en Dubai, uno de esos grupos de resorts con un sitio público, una aplicación interna para el personal y señalización digital en toda la propiedad. Una instancia única de Sanity alimentando todo. Esa fue la opción correcta, punto.
El desempeño a escala real es el segundo argumento legítimo. Las páginas generadas estáticamente servidas desde un edge de CDN son rápidas de una manera que las páginas WordPress renderizadas en PHP simplemente no son, sin importar qué tan bien hayas optimizado tu servidor. Cuando hablas de millones de visualizaciones de página por mes, esos milisegundos se acumulan en diferencias de ingresos significativas. La investigación de Google ha documentado la correlación entre la velocidad de carga y la tasa de conversión repetidamente, no es teórico.
La separación de equipos también importa, aunque solo para organizaciones lo suficientemente grandes como para tener equipos separados de front-end y back-end. Si tu equipo de contenido es un departamento de marketing de 20 personas que quiere funcionar independientemente de tu equipo de ingeniería, un contrato de API limpio entre CMS y front-end permite que ambos lados trabajen sin bloquearse mutuamente.
¿Esos tres casos? Genuinamente vale la pena el costo de complejidad. Todo lo demás es generalmente pensamiento ilusorio disfrazado de arquitectura.
---
Cuando Headless Es Solo Sobre-ingeniería Cara
Un sitio de folleto de cinco páginas para una firma de contabilidad de Londres no necesita una arquitectura headless. Tampoco lo necesita una tienda WooCommerce de 200 productos con un desarrollador en retención.
Veo este error constantemente, especialmente de desarrolladores que acaban de descubrir Next.js y quieren usarlo en todo. (Yo fui culpable de esto mismo en 2019, construí un blog headless para un cliente pequeño de caridad, pasé tres días configurando webhooks para activar reconstrucciones de Netlify en nuevas publicaciones, les cobré por ello, y aún me llaman cuando algo se rompe.) El problema es que headless desplaza la complejidad operacional del CMS a la infraestructura. WordPress se actualiza a sí mismo. Tu pipeline personalizado de Next.js + Contentful no.
Escenarios específicos donde headless generalmente cuesta más de lo que devuelve:
- Equipos de contenido pequeños: si una o dos personas gestionan todo el contenido, la DX editorial de un CMS acoplado adecuado como WordPress es genuinamente mejor que un CMS headless. Los entornos de vista previa son más difíciles. La edición inline desaparece. WYSIWYG está mutilado.
- Presupuestos ajustados: una construcción headless adecuada cuesta 2-3x más que una construcción WordPress comparable para desarrollar, y el mantenimiento continuo es mayor. Si el presupuesto es una restricción, ese dinero casi siempre hace más bien en otro lado.
- Los cambios frecuentes de contenido y la generación estática significan tiempos de construcción. Un editor de noticias que publica 50 artículos al día no quiere esperar 8 minutos para una reconstrucción completa del sitio cada vez. (Sí, la regeneración estática incremental ayuda. También añade su propia complejidad.)
- Sin DevOps dedicado, alguien tiene que hacerse cargo del pipeline de despliegue, la configuración de CDN, las variables de entorno, las URLs de vista previa. En un equipo pequeño, ese alguien suele ser el desarrollador que también está haciendo todo lo demás.
---
El Punto Medio Headless de WordPress
Lo que cuestionaría es la falsa dicotomía entre "WordPress tradicional" y "completamente headless con un CMS separado." Hay un camino intermedio que funciona muy bien para cierta clase de proyecto.
WordPress como back end headless, usando WP REST API o WPGraphQL, te da la experiencia de gestión de contenido que tus clientes ya conocen (y honestamente, la mayoría de clientes conocen WordPress), combinada con la flexibilidad de un front end moderno. No estás pagando por Contentful. No estás reentrenando a nadie. El equipo editorial mantiene Gutenberg. El front end puede ser el framework que se adapte al proyecto.
He usado este patrón en probablemente 30-40 proyectos en los últimos cuatro años. Funciona bien especialmente para sitios de marketing que tienen una biblioteca de contenido sustancial existente en WordPress y no quieren migrar, pero sí quieren un front end React por razones de rendimiento o interactividad. El trade-off es que el mantenimiento del plugin WPGraphQL puede volverse complicado, y sigues ejecutando un servidor PHP, no has escapado completamente del hosting de WordPress.
---
Elige tu CMS Headless: Una Comparación Práctica
No todos los CMSes headless son iguales, y la elección importa más de lo que la gente admite cuando está entusiasmada por el framework del front end.
Contentful
La opción de nivel empresarial. API sólida, buenos SDKs, UI editorial razonable. El precio es el punto débil, el tier gratuito es genuinamente útil para proyectos pequeños, pero una vez que alcanzas los límites, estás viendo $300+/mes antes de haber hecho nada interesante. Elegiría Contentful para proyectos con presupuestos reales y organizaciones que necesitan workflows adecuados de roles y permisos.
Sanity
Mi favorita personal para la mayoría de proyectos headless de mercado medio. El lenguaje de consulta GROQ es expresivo una vez que le dedicas un día, Sanity Studio es personalizable de formas en que Contentful no lo es, y la colaboración en tiempo real es excelente. Los precios son más razonables. La desventaja es que la curva de aprendizaje para editores de contenido no técnicos es más pronunciada, el Studio se ve lo suficientemente diferente de WordPress que siempre hay un período de capacitación.
Strapi
Código abierto, auto-hospedado, gratuito de ejecutar. Si tienes un cliente que no pagará cuotas de CMS SaaS y tiene un servidor, vale la pena considerar Strapi. El panel de administración es decente. Pero estás asumiendo el hosting, actualizaciones y parches de seguridad tú mismo. No es poco.
Astro con colecciones de contenido
Para sitios con mucho contenido que son mayormente estáticos, documentación, blogs, sitios de marketing, Astro con colecciones de contenido local vale la pena considerar. Sin CMS en absoluto. El contenido vive como archivos Markdown o MDX en el repositorio. A los desarrolladores les encanta. A los editores no técnicos generalmente les odia. Conoce a tu audiencia antes de ir por esta ruta.
---
El Argumento de Rendimiento: Lo Que Los Números Realmente Dicen
Déjame darte un benchmark real en lugar de una afirmación vaga sobre velocidad.
Un cliente de Seahawk, una empresa SaaS, alrededor de 80 páginas, tráfico moderado, se trasladó de una instalación WordPress administrada a Next.js con Sanity, desplegado en Vercel. Antes de la migración, las puntuaciones de Lighthouse estaban alrededor de 62-68 en móvil. Después, consistentemente 91-96. El tiempo hasta el primer byte bajó de aproximadamente 420ms a menos de 80ms. Eso no es una mejora marginal. Eso es un producto diferente.
Pero, y esto importa, tenían un desarrollador front-end dedicado, un equipo de contenido de cuatro personas que pasaron por capacitación de Sanity, y un presupuesto que absorbió ocho semanas de construcción. Las ganancias de rendimiento fueron reales porque las condiciones para hacer que headless funcionara estaban en su lugar.
Los datos del Web Almanac sobre rendimiento de CMS muestran que la brecha de rendimiento entre frameworks orientados a headless y CMS acoplados tradicionales es real pero no automática. Un sitio de Next.js mal implementado puede absolutamente tener un rendimiento inferior al de un sitio WordPress bien configurado. La arquitectura sola no te salva.
---
Tomar la Decisión: Un Marco Que Realmente Uso
Cuando llega un brief de cliente a mi escritorio y hay alguna duda sobre si headless es lo apropiado, repaso cinco preguntas antes de comprometerme con una recomendación.
- ¿El contenido necesita aparecer en más de una superficie? Si es sí, headless recibe una consideración seria. Si es no, pierde una justificación importante.
- ¿Cuál es el nivel de comodidad técnica del equipo de contenidos? Editores no técnicos bajo presión de tiempo en un CMS desconocido es una mala combinación.
- ¿Cuál es el tráfico esperado y el requisito de rendimiento? ¿Menos de 50,000 visitantes mensuales en un host razonable? WordPress lo maneja bien.
- ¿Hay un desarrollador dedicado para el mantenimiento continuo? Si la respuesta es "llamaremos a alguien cuando se rompa", la infraestructura headless es un pasivo.
- ¿Cuál es el presupuesto real, incluyendo el primer año de operación? No solo la construcción. Hosting, suscripciones de CMS, tiempo de desarrollador para actualizaciones. Costo total de propiedad.
Si las preguntas 1, 4 y 5 no se alinean, recomendaré un enfoque tradicional o híbrido y dormiré bien.
---
FAQ
¿Es headless WordPress mejor que una configuración WordPress tradicional?
Depende completamente de lo que "mejor" signifique para tu proyecto específico. Para entrega multicanal, separación de equipos, o rendimiento con volúmenes de tráfico alto, WordPress headless, o reemplazar WordPress con un CMS headless dedicado, pueden mejorar las cosas significativamente. Para un sitio web comercial estándar con un equipo pequeño y tráfico moderado, WordPress tradicional con un buen tema y caché adecuado es más fácil de construir, más barato de ejecutar, y más simple de entregar a un cliente.
¿Headless siempre significa mejor rendimiento?
No. Y este mito está causando daño real a los presupuestos de proyectos. Las páginas generadas estáticamente servidas desde un CDN son más rápidas por defecto, pero una compilación headless mal configurada con imágenes sin optimizar, solicitudes API en cascada y sin caché adecuado puede absolutamente tener peor rendimiento que un sitio WordPress bien ajustado. El rendimiento se trata de ejecución, no solo de arquitectura.
¿Cuál es la forma más económica de ir headless?
Strapi en un VPS de £5/mes combinado con Astro o Next.js desplegado en el nivel gratuito de Vercel te puede dar una configuración headless funcional por muy poco costo mensual. Pagarás en tiempo de desarrollador en su lugar. Nada es realmente gratis, solo estás eligiendo dónde cae el costo.
¿Cuánto tiempo típicamente toma una compilación headless comparado con una compilación CMS tradicional?
Por mi experiencia: un proyecto comparable toma aproximadamente 1.5x a 2.5x más tiempo en una configuración headless que en WordPress, especialmente si es el primer proyecto headless del equipo. Esa brecha se reduce conforme el equipo se familiariza con el stack. Factoriza esto en los plazos y cotizaciones honestamente; los clientes a quienes se les dijo "solo algunas semanas" para una construcción headless, cuando termina tomando cuatro meses, no vuelven.
¿Se está muriendo headless ahora que WordPress tiene el Block Editor?
No, pero los casos de uso se están estrechando en la parte inferior. Gutenberg se ha comido algunos escenarios donde headless solía estar justificado; las experiencias de contenido interactivas impulsadas por componentes son más alcanzables en WordPress ahora sin desacoplamiento. En la parte superior, para publicaciones multicanal a gran escala y comercio, headless es tan relevante como siempre ha sido.
---
Headless no es un símbolo de estatus. Es un trade-off, más flexibilidad, más complejidad, más costo, a cambio de ganancias genuinas en situaciones específicas. Conoce la situación antes de comprometerte. El cliente de comercio electrónico de Manchester que mencioné al principio eventualmente migró de vuelta a un tema de Shopify con algunos componentes frontend personalizados. Redujeron su sobrecarga de desarrollo en un 60% y sus tiempos de carga finalmente mejoraron. A veces la forma antigua es la correcta. No hay nada de malo en eso.