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.Next.js front end, and their page load times were slower than the Shopify theme they'd replaced. Their development team had grown from one contractor to four. Content editors needed a developer present just to push a blog post live.
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.Go headless when you genuinely need multiple front ends or performance a monolith cannot hit; one WordPress site with a good theme beats three developers maintaining a stack you did not need.
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.WordPress, Squarespace, whatever, couples the content management back end to the front-end presentation layer. They talk to each other natively. Headless decouples them. Your CMS (Contentful, Sanity, Strapi, WordPress in headless mode) becomes a pure content API. Your front end, Next.js, Nuxt, Astro, SvelteKit, whatever you fancy, fetches that content and renders it however it wants.
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 as the CMS, serving JSON over REST or GraphQL
- Next.js en el front end, ya sea generado estáticamente (SSG) o renderizado del lado del servidor (SSR) on the front end, either statically generated (SSG) or server-side rendered (SSR)
- Vercel o Netlify para deployment y edge functions for deployment and edge functions
- Shopify Storefront API o BigCommerce si hay comercio electrónico de por medio or BigCommerce if there's commerce involved
- Alguna versión de Algolia para búsqueda, porque las opciones de búsqueda nativa suelen ser basuraAlgolia for search, because the native search options are usually rubbish
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. is the strongest argument. If the same content needs to appear on a website, a mobile app, a kiosk display, and a smart TV interface, a coupled CMS becomes genuinely painful. One content API that all four surfaces query? That actually makes sense. Seahawk had a hospitality client in Dubai, one of those resort groups with a public-facing site, an internal staff app, and digital signage across the property. Single Sanity instance feeding all of it. That was the right call, full stop.
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. is the second legitimate argument. Statically generated pages served from a CDN edge are fast in a way that PHP-rendered WordPress pages simply aren't, regardless of how well you've optimised your server. When you're talking about millions of page views per month, those milliseconds compound into meaningful revenue differences. Google's research has documented the correlation between load speed and conversion rate repeatedly, it's not theoretical.
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. matters too, though only for organisations big enough to have separate front-end and back-end teams. If your content team is a 20-person marketing department that wants to move independently of your engineering team, a clean API contract between CMS and front end lets both sides work without blocking each other.
¿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., if one or two people manage all the content, the editorial DX of a proper coupled CMS like WordPress is genuinely better than a headless CMS. Preview environments are harder. Inline editing is gone. WYSIWYG is neutered.
- 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., a proper headless build costs 2-3x a comparable WordPress build to develop, and the ongoing maintenance is higher. If budget is a constraint, that money almost always does more good elsewhere.
- 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.), static generation means build times. A news publisher pushing 50 articles a day doesn't want to wait 8 minutes for a full site rebuild every time. (Yes, incremental static regeneration helps. It also adds its own complexity.)
- 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., someone has to own the deployment pipeline, the CDN config, the environment variables, the preview URLs. On a small team, that someone is usually the developer who's also doing everything else.
---
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.WP REST API or WPGraphQL, gives you the content management experience your clients already know (and honestly, most clients know WordPress), combined with the flexibility of a modern front end. You're not paying for Contentful. You're not retraining anyone. The editorial team keeps Gutenberg. The front end gets to be whatever framework suits the project.
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.GROQ query language is expressive once you've spent a day with it, Sanity Studio is customisable in ways Contentful isn't, and the real-time collaboration is excellent. Pricing is more reasonable. The downside is that the learning curve for non-technical content editors is steeper, the Studio looks different enough from WordPress that there's always a training period.
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.Astro with local content collections is worth considering. No CMS at all. Content lives as Markdown or MDX files in the repo. Developers love it. Non-technical editors usually hate it. Know your audience before going this route.
---
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.Web Almanac's data on CMS performance shows that the performance gap between headless-oriented frameworks and traditional coupled CMSes is real but not automatic. A badly implemented Next.js site can absolutely underperform a well-configured WordPress site. Architecture alone doesn't save you.
---
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. If yes, headless gets a serious look. If no, it loses a major justification.
- ¿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. Non-technical editors on a tight deadline in an unfamiliar CMS is a bad combination.
- ¿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. Sub-50,000 monthly visitors on a reasonable host? WordPress handles it fine.
- ¿Hay un desarrollador dedicado para el mantenimiento continuo? Si la respuesta es "llamaremos a alguien cuando se rompa", la infraestructura headless es un pasivo. If the answer is "we'll call someone when it breaks," headless infrastructure is a liability.
- ¿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. Not just the build. Hosting, CMS subscriptions, developer time for updates. Total cost of ownership.
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.by default, but a poorly configured headless build with unoptimised images, waterfall API requests, and no proper caching can absolutely underperform a well-tuned WordPress site. Performance is about execution, not just architecture.
¿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.