Un cliente me llamó en 2021 — una marca de comercio electrónico de tamaño medio en Manchester, alrededor de 40,000 SKUs, múltiples tiendas regionales — furioso. Habían gastado £180,000 durante 18 meses en una compilación headless de Shopify con un front end 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 publicación de blog.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.
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 u supervisado compilaciones en bien más de 12,000 sitios en Seahawk Media. Headless ha sido la opción correcta en quizás 8–10% de ellos. ¿El otro 90%? Habría sido un desastre — costoso, lento de lanzar y miserable de mantener. Este artículo trata 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
Sacamos rápido la definición del camino. Un CMS tradicional —WordPress, Squarespace, lo que sea— acopla el backend de gestión de contenido a la capa de presentación del front end. Se comunican entre sí nativamente. Headless desacopla eso. Tu CMS (Contentful, Sanity, Strapi, WordPress en modo headless) se convierte en una API de contenido puro. 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 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
Mira, hay razones reales y legítimas para hacer esto. No estoy descartando la arquitectura. Solo estoy cansado de que se aplique sin discriminación.
La entrega de contenido multicanal es el argumento más sólido. Si el mismo contenido necesita aparecer en un sitio web, una aplicación móvil, una pantalla de quiosco y una interfaz de TV inteligente, un CMS acoplado se vuelve genuinamente problemático. ¿Una API de contenido única que las cuatro superficies consulten? Eso tiene sentido. Seahawk tenía un cliente de hotelería 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 única instancia de Sanity alimentando todo. Esa fue la decisión correcta, sin lugar a dudas. 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 rendimiento 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 lo son, sin importar cuán bien hayas optimizado tu servidor. Cuando estamos hablando de millones de visualizaciones de página por mes, esos milisegundos se suman en diferencias de ingresos significativas. La investigación de Google ha documentado repetidamente la correlación entre la velocidad de carga y la tasa de conversión — 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 en desarrolladores que acaban de descubrir Next.js y quieren usarlo en todo. (Yo mismo fui culpable en 2019 — construí un blog headless para un cliente pequeño de una organización sin fines de lucro, pasé tres días configurando webhooks para disparar reconstrucciones en Netlify cuando había nuevos posts, les cobré por eso, y aún me llaman cuando algo se rompe.) El problema es que headless traslada 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 pequeños de contenido — si una o dos personas manejan todo el contenido, la experiencia 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 queda castrado. — 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 de lo que cuesta desarrollar un WordPress comparable, y el mantenimiento continuo es más alto. Si el presupuesto es una restricción, ese dinero casi siempre hace más bien en otro lugar. — 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.
- Cambios de contenido frecuentes — la generación estática significa tiempos de compilació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 suma 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 ser responsable del pipeline de despliegue, la configuración del CDN, las variables de entorno, las URLs de vista previa. En un equipo pequeño, ese alguien generalmente es 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 backend 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 frontend moderno. No estás pagando a Contentful. No estás reentrenando a nadie. El equipo editorial mantiene Gutenberg. El frontend puede ser cualquier framework que se ajuste 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 particularmente bien para sitios de marketing que tienen una biblioteca de contenido sustancial en WordPress y no quieren migrar, pero sí quieren un front end en React por razones de rendimiento o interactividad. El compromiso 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 nivel gratuito es genuinamente útil para proyectos pequeños, pero una vez que alcanzas los límites, estás mirando $300+/mes antes de haber hecho algo interesante. Optaría por Contentful en proyectos con presupuestos reales y organizaciones que necesitan flujos de trabajo adecuados de roles y permisos.
Sanity
Mi favorita personal para la mayoría de proyectos headless de nivel medio. El lenguaje de consulta GROQ es expresivo una vez que has pasado un día con él, Sanity Studio es personalizable de formas en que Contentful no lo es, y la colaboración en tiempo real es excelente. El precio es más razonable. 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 tomar este camino.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 — migró de una instalación de WordPress administrada a Next.js con Sanity, implementada en Vercel. Antes de la migración, las puntuaciones de Lighthouse rondaban 62–68 en móvil. Después, consistentemente 91–96. El tiempo hasta el primer byte cayó de aproximadamente 420ms a menos de 80ms. No es una mejora marginal. 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 en Sanity, y un presupuesto que absorbió una construcción de ocho semanas. Las ganancias de rendimiento fueron reales porque las condiciones para 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 qué significa "mejor" para tu proyecto específico. Para distribución multicanal, separación de equipos o rendimiento con alto volumen de tráfico, WordPress headless —o reemplazar WordPress con un CMS headless dedicado— puede mejorar significativamente las cosas. Para un sitio web empresarial 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 económico de operar y más simple de transferir 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 puede darte una configuración headless funcional por muy poco costo mensual. Pagarás en tiempo de desarrollador. 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?
En 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 gana familiaridad con el stack. Factoriza esto en los plazos y presupuestos honestamente —clientes a quienes se les dijo "solo unas pocas semanas" para una compilació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 reduciendo en el extremo inferior. Gutenberg se ha comido algunos escenarios donde headless solía estar justificado —las experiencias de contenido interactivo y orientadas a componentes son más alcanzables en WordPress ahora sin desacoplamiento. En el extremo superior, para publicación multicanal a gran escala y comercio electrónico, headless es tan relevante como siempre ha sido.
---
Headless no es un símbolo de estatus. Es un compromiso: 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 de front-end personalizados. Redujeron su sobrecarga de desarrollo en un 60% y finalmente mejoraron sus tiempos de carga. A veces la forma antigua es la forma correcta. No hay nada de malo en eso.