Actualizado el 18/04/2026: WordPress headless pasó de experimental a estándar de producción en 2026: WPGraphQL 2.x es ahora el plugin canónico para GraphQL, la REST API de WordPress 7.0 mejoró su latencia un 40% respecto a 2024, y la nueva Abilities API facilita arquitecturas desacopladas con control granular de permisos.
En 30 segundos
- Trew Knowledge publicó el 15/04/2026 un marco de decisión headless vs híbrido que prioriza métricas operacionales sobre tendencias de mercado.
- WordPress 7.0 introduce la Abilities API: declaración de capacidades en formato machine-readable, con validación en cadena (input → permission → execute → output).
- WPGraphQL 2.x incorpora persisted queries y federación; es plugin canónico de la comunidad con sponsoreo de Automattic desde octubre 2024.
- La latencia de respuesta nativa de WordPress 7.0 mejoró un 40% respecto a 2024, con TTFB pasando de 3,5s a 0,8s en entornos de producción documentados.
- Headless se justifica con equipos multiplataforma (web + apps + kioscos) o redacciones de alto volumen; híbrido gana en la mayoría de los sitios de contenido.
- El error más común: adoptar headless por moda y subestimar el costo de mantener dos stacks técnicos en paralelo.
Trew Knowledge es una agencia especializada en análisis y consultoría sobre WordPress y arquitecturas web. Produce marcos de decisión y estudios comparativos sobre estrategias de desarrollo en el ecosistema WordPress, incluyendo análisis de headless CMS, híbridos y tecnologías relacionadas.
¿Qué es WordPress Headless? El cambio de paradigma en 2026
Hace tres años, «headless WordPress» era un experimento de equipos avanzados. Hoy es el enfoque estándar para organizaciones que necesitan velocidad, seguridad y presencia multicanal. La diferencia técnica es clara: WordPress opera exclusivamente como backend de gestión de contenido. No controla la presentación pública. El frontend es un framework moderno separado que consume la API de WordPress.
El cambio de mercado no fue solo técnico. Fue operacional. Las organizaciones que en 2023 pusieron en producción arquitecturas headless con Next.js o Astro empezaron a reportar resultados concretos: menor tiempo de carga, mejor posicionamiento orgánico y la capacidad de reutilizar el mismo CMS en web, apps y otros canales digitales sin duplicar el trabajo editorial.
Lo que cambió en 2026 es que WordPress dejó de ser el cuello de botella. WordPress 7.0 trajo mejoras sustanciales a la REST API nativa y la Abilities API para arquitecturas desacopladas. WPGraphQL 2.x maduró hasta convertirse en el plugin canónico para GraphQL. El ecosistema de frameworks frontend (Next.js, Astro, SvelteKit) estabilizó sus integraciones. El conjunto hace que montar un setup headless hoy sea considerablemente menos doloroso que en 2023 o 2024.
Eso sí: que sea más accesible no significa que sea la respuesta correcta para todos. El marco de decisión headless vs híbrido sigue siendo necesario.
Headless vs Híbrido: La verdadera pregunta no es si desacoplarse
Según el análisis de Trew Knowledge, la narrativa de «headless es siempre mejor» se aflojó bastante. La pregunta ya no es si desacoplarse, sino cuánto desacoplamiento tiene sentido para tu caso concreto.
En una arquitectura headless, WordPress pasa a ser exclusivamente un sistema de gestión de contenido en el backend. Todo lo que el usuario ve viene de otro frontend, generalmente un framework JavaScript como Next.js o Astro, que consume la API de WordPress. En una arquitectura híbrida, WordPress sigue renderizando la mayor parte del sitio pero expone su API para casos puntuales: una app mobile, un widget externo, una integración específica.
La decisión no vive en diagramas de arquitectura. Vive en los workflows editoriales, en la consistencia del analytics, en el presupuesto de ingeniería y en el ritmo de releases del equipo. Un setup headless puede verse elegante en papel y convertirse en un ancla operacional en la práctica.
WordPress Headless 2026: producción estándar, latencia -40% y WPGraphQL 2.x como eje central
La novedad concreta de 2026 no es que headless WordPress exista, sino que dejó de ser experimental. Tres factores convergen para explicarlo. Relacionado: crear landing pages con GraphQL.
El primero es la mejora de rendimiento de WordPress 7.0. Según análisis publicados sobre la arquitectura headless en 2026, la latencia de respuesta nativa de la REST API mejoró un 40% respecto a 2024. En números concretos: un TTFB que en setups sin optimizar rondaba los 3,5 segundos bajó a 0,8 segundos. Eso cambia el cálculo de rendimiento para sitios que antes consideraban que headless no valía la pena por la complejidad añadida.
El segundo factor es WPGraphQL 2.x. La versión anterior era buena; la actual es madura. Persisted queries, soporte de federación, smart cache integrado, y una cobertura completa del modelo de datos de WordPress (posts, taxonomías, ACF, menús, usuarios). Lo que antes requería varios plugins o workarounds ahora está resuelto en un solo plugin con mantenimiento activo y respaldo de Automattic. Para wordpress headless 2026, esto significa que el setup estándar tiene un camino claro y documentado.
El tercer factor es la estabilización del ecosistema frontend. Next.js 16, Astro 6 y SvelteKit 2 tienen integraciones maduras con WordPress. Hay patrones documentados, librerías de soporte y comunidad activa. El costo de arrancar un proyecto headless bajó porque el punto de partida ya no es una hoja en blanco.
Ahora bien, habría que ver si estos números de latencia se mantienen en todos los contextos. Los benchmarks publicados corresponden a entornos con configuración óptima (CDN, caché de página completa, ISR). Un WordPress mal configurado en un servidor compartido no va a dar esos resultados por arte de magia.
WordPress 7.0: La Abilities API para control de permisos granular
WordPress 7.0 trajo la Abilities API, y es uno de esos cambios que parece técnico pero tiene implicancias directas en cómo diseñás una arquitectura desacoplada. Según el post oficial de Make WordPress del 24 de marzo, la API permite que plugins, themes y el propio core declaren sus capacidades en un formato machine-readable.
La diferencia con el sistema de roles tradicional es estructural. El sistema de roles de WordPress (administrador, editor, autor, etc.) define qué usuario puede hacer qué acción. La Abilities API define qué capacidades expone el sistema, independientemente del rol. Un frontend desacoplado puede descubrir programáticamente qué hay disponible en el backend sin depender de documentación manual.
La validación funciona en cadena: input → permission → execute → output. Cada capacidad tiene un namespace con el formato plugin-slug/ability-name, lo que evita colisiones entre plugins. Para arquitecturas headless, esto resuelve un problema real: antes, cuando WordPress agregaba una funcionalidad nueva en el backend, el frontend desacoplado se enteraba cuando algo dejaba de funcionar. Con la Abilities API, el frontend puede consultar qué hay disponible y adaptarse antes de que algo rompa.
El impacto en seguridad también es relevante. En arquitecturas desacopladas, los tokens de autenticación tienen que viajar entre el frontend y el backend. Con la Abilities API, es posible emitir tokens con scopes específicos: un token que solo puede leer posts publicados, otro que puede crear borradores, otro que puede gestionar medios. Eso reduce la superficie de ataque en caso de que un token quede expuesto.
WPGraphQL 2.x: El estándar de facto para APIs GraphQL
Si vas a desacoplar, tarde o temprano tenés que elegir cómo el frontend consume el contenido de WordPress. Hay dos caminos principales.
La REST API de WordPress es la opción built-in: no requiere plugins adicionales, está documentada, y para casos simples zafa perfectamente. El problema clásico es el overfetching: cada endpoint tira campos que no necesitás, y para armar una página compleja terminás haciendo múltiples requests.
WPGraphQL 2.x resuelve eso con un schema fuertemente tipado donde pedís exactamente lo que necesitás, podés anidar relaciones en una sola query y evitás los viajes de ida y vuelta. La versión 2.x agrega persisted queries (queries pre-registradas en el servidor, más seguras y cacheables) y soporte de federación para arquitecturas con múltiples fuentes de datos.
El smart cache integrado en WPGraphQL 2.x es otro cambio con impacto directo. Las queries de GraphQL son dinámicas por naturaleza, lo que históricamente dificultaba el caching a nivel de red. La implementación de smart cache en 2.x resuelve esto con invalidación granular: cuando un post específico se actualiza, solo se invalida el caché de las queries que incluían ese post, no todo el caché global. Eso mejora la eficiencia de la caché en sitios con alto volumen de actualizaciones.
REST API vs GraphQL: Análisis de rendimiento y latencia
¿Y cuándo conviene cada uno? La comparativa tiene matices que los benchmarks simples no capturan.
| Criterio | REST API (WP 7.0) | WPGraphQL 2.x |
|---|---|---|
| Instalación | Built-in en WP core | Plugin canónico (Automattic) |
| Latencia en queries simples | Baja (sin overhead) | Levemente mayor (parsing GraphQL) |
| Latencia en queries complejas | Alta (múltiples requests) | Baja (una sola query) |
| Overfetching | Sí, por diseño | No, pedís solo lo que necesitás |
| Relaciones anidadas | Múltiples requests | Una sola query |
| Persisted queries | No nativo | Sí, desde 2.x |
| Smart cache | Cache HTTP estándar | Invalidación granular por entidad |
| Curva de aprendizaje | Baja | Media (requiere conocer GraphQL) |
| Ideal para | Integraciones simples, híbrido | Headless complejo, multiplataforma |
El tema es que «más rápido» depende del caso. Para una query que trae un solo post con tres campos, REST API sin overfetching es perfectamente competitiva. Donde GraphQL gana con claridad es en páginas complejas: una home que necesita posts recientes + categorías + menús + datos del autor. En REST, eso son cuatro o cinco requests encadenados. En WPGraphQL, una sola query con todos los datos. Ya lo cubrimos antes en probar cambios en un ambiente staging.
Otro factor: las persisted queries de WPGraphQL 2.x cambian la ecuación de seguridad. En lugar de aceptar queries arbitrarias del cliente (que podrían ser maliciosas o ineficientes), el servidor solo ejecuta queries pre-registradas. Eso también mejora el rendimiento porque el servidor puede optimizar y cachear esas queries conocidas.
Frameworks recomendados para frontend: Next.js, Astro y SvelteKit
La elección del framework frontend es tan importante como la elección entre REST y GraphQL. Cada opción tiene un perfil de proyecto donde brilla.
Next.js 16 sigue siendo la opción más completa para proyectos full-stack. App Router estabilizado, Server Components, Incremental Static Regeneration (ISR) con revalidación por webhook desde WordPress. El trade-off: bundle de JavaScript más pesado y una curva de aprendizaje real para equipos que no tienen experiencia con React.
Astro 6 es la opción más interesante para blogs y sitios de contenido. Genera HTML estático con cero JavaScript por defecto, lo que se traduce en Core Web Vitals excelentes sin configuración adicional. Cuando necesitás interactividad puntual, Astro permite cargar componentes React, Vue o Svelte solo donde hacen falta. Para un blog WordPress headless con SEO como prioridad, Astro 6 es difícil de superar en términos de performance pura.
SvelteKit 2 es la opción para equipos que priorizan bundles mínimos y prefieren Svelte sobre React. Buena integración con WordPress vía REST o GraphQL, y un output compilado considerablemente más liviano que Next.js. Menos ecosistema, pero más que suficiente para la mayoría de los proyectos.
El criterio de selección más honesto: usá Next.js si tu equipo ya sabe React y el proyecto necesita componentes interactivos complejos. Usá Astro si el foco es contenido editorial y querés los mejores Core Web Vitals con el menor esfuerzo. Usá SvelteKit si ya conocés Svelte y no necesitás el ecosistema de React.
Mejora de latencia 2024-2026: 40% más rápido y casos de estudio
Los números concretos de la mejora de latencia en WordPress 7.0 vienen de varios frentes simultáneos.
La REST API incorporó optimizaciones en el procesamiento de respuestas: menos serialización innecesaria, mejor manejo de caché HTTP nativo y reducción del tiempo de bootstrap de WordPress en requests de API pura (donde no se necesita el stack completo de temas y plugins de presentación). Eso solo explica una parte de la mejora del 40%.
La otra parte viene de WPGraphQL 2.x y de cómo los frameworks frontend aprovechan ISR. La Incremental Static Regeneration permite generar páginas estáticas que se revalidan en background cuando el contenido cambia en WordPress, sin rebuilds completos del sitio. El resultado: el usuario recibe HTML estático desde una CDN (latencia de milisegundos), y WordPress solo recibe requests de revalidación, no de cada visita.
Los casos de estudio documentados muestran: TTFB reducido de 3,5s a 0,8s en entornos de producción bien configurados, costos de servidor reducidos hasta un 75% (porque WordPress no está renderizando cada pageview), tráfico orgánico con mejoras del 22% atribuidas a mejor posicionamiento por Core Web Vitals, y bounce rate reducido un 35% por tiempos de carga menores. Cubrimos ese tema en detalle en gestionar enlaces en arquitectura headless.
Tomalo con pinzas: esos números corresponden a migraciones de sitios mal optimizados en hosting compartido hacia arquitecturas headless en infraestructura dedicada. La comparación no es headless vs monolítico bien configurado. Si comparás headless con un WordPress monolítico en un servidor dedicado con caché de página completa, la diferencia de rendimiento se achica bastante.
Implementación paso a paso: del WordPress monolítico a headless
La implementación tiene decisiones secuenciales que conviene tomar en orden.
El primer paso es elegir la capa de API. La recomendación para proyectos nuevos en 2026 es WPGraphQL 2.x si el proyecto tiene páginas complejas o múltiples fuentes de datos. REST API si es un proyecto simple con equipo sin experiencia en GraphQL. Una vez que el frontend está construido sobre una de las dos, migrar es costoso.
Instalación de WPGraphQL: desde el repositorio oficial en wordpress.org/plugins/wp-graphql. Después de activarlo, el endpoint GraphQL queda disponible en /graphql. Conviene instalar también WPGraphiQL (el IDE integrado) para explorar el schema antes de escribir queries en el frontend.
El setup básico de Next.js o Astro con WordPress implica configurar las variables de entorno con la URL del CMS, instalar la librería de cliente GraphQL (Apollo o similar para Next.js, la integración nativa de Astro para contenido), y armar las queries que el frontend va a necesitar. Lo más tedioso es mapear el modelo de datos de WordPress al modelo que espera el frontend.
El webhook-triggered revalidation es el eslabón que conecta ambas capas. Cuando un editor publica o actualiza un artículo en WordPress, un webhook dispara una revalidación en el frontend. Next.js tiene soporte nativo para esto vía revalidatePath y revalidateTag. Astro requiere un endpoint custom que ejecute el rebuild o revalidación.
Para el hosting, WordPress puede vivir en un hosting WordPress de Donweb con su carga habitual de gestión de contenido, que baja considerablemente cuando no está renderizando páginas públicas. El frontend se despliega en cualquier servicio que soporte Node.js o sitios estáticos.
Troubleshooting más común: errores de CORS entre el dominio del frontend y el de WordPress (se resuelve en wp-config.php o con el plugin CORS Headers), problemas con autenticación para contenido privado (usar la Abilities API con tokens de scope limitado), y timeouts en builds de sitios grandes con muchos posts (solución: builds incrementales con ISR en lugar de rebuilds completos).
WordPress 7.0 Abilities API: cómo cambia las decisiones de arquitectura
WordPress 7.0 trajo la Abilities API, y es uno de esos cambios que parece técnico pero tiene implicancias directas en cómo diseñás una arquitectura desacoplada. Según el post oficial de Make WordPress del 24 de marzo, la API permite que plugins, themes y el propio core declaren sus capacidades en un formato machine-readable.
En la práctica: un frontend desacoplado puede descubrir programáticamente qué puede hacer el backend sin depender de documentación manual ni de prueba y error. La validación funciona en cadena: input → permission → execute → output. Cada capacidad tiene un namespace con el formato plugin-slug/ability-name, lo que evita colisiones entre plugins.
Para arquitecturas headless, esto es un cambio real. Antes, cuando WordPress agregaba una funcionalidad nueva en el backend, el frontend desacoplado se enteraba cuando algo dejaba de funcionar. Con la Abilities API, el frontend puede consultar qué hay disponible y adaptarse. Cobertura relacionada: interfaces dinámicas generadas con IA.
WPGraphQL 2.x vs REST API: qué está confirmado y qué todavía no
Confirmado
- WPGraphQL 2.x como plugin canónico: Automattic lo esponsorea activamente desde octubre 2024. El repositorio tiene mantenimiento activo y contribuciones del equipo de WordPress.com.
- Persisted queries en WPGraphQL 2.x: disponibles en producción, documentadas, con casos de uso reales en sitios de alto tráfico.
- Abilities API en WordPress 7.0: incluida en el core, documentada en developer.wordpress.org, con repositorio de referencia en GitHub.
- Mejora de latencia del 40%: documentada en benchmarks de entornos de producción con configuración estándar recomendada.
- Soporte de federación en WPGraphQL 2.x: disponible para arquitecturas con múltiples fuentes de datos GraphQL.
Todavía no está confirmado o requiere más contexto
- Adopción masiva de la Abilities API: la API existe, pero el ecosistema de plugins todavía está adoptándola. No todos los plugins populares la implementan todavía.
- Latencia del 40% en todos los setups: el número aplica a entornos bien configurados. Migraciones desde hosting compartido mal optimizado pueden mostrar mejoras mayores, pero comparativas más justas (WP optimizado vs headless) muestran diferencias menores.
- WPGraphQL como única opción: para proyectos simples con equipo sin experiencia en GraphQL, la REST API sigue siendo completamente válida. No hay motivo para migrar forzosamente a GraphQL.
Costos reales: inversión, hosting e infraestructura
Acá viene lo que muchos análisis de arquitectura omiten convenientemente: los números.
Una arquitectura headless tiene dos capas de costo. La primera es la inversión inicial: necesitás un equipo con experiencia en el framework frontend elegido (Next.js, Astro, Nuxt), en la API de WordPress, y en el pipeline de build y despliegue. Para un proyecto nuevo, ese overhead puede representar entre un 30% y un 60% más de tiempo de desarrollo inicial respecto a un tema tradicional bien hecho.
La segunda capa es el hosting e infraestructura. El CMS de WordPress puede vivir en un hosting WordPress estándar, como el hosting WordPress de Donweb, ya que su carga baja considerablemente cuando no renderiza páginas públicas. El frontend necesita su propia infraestructura: un servicio de hosting para aplicaciones Node.js o sitios estáticos, una CDN configurada, y un sistema de invalidación de caché cuando el contenido cambia en WordPress.
Para una pequeña editorial con un desarrollador, headless es difícil de justificar. Para una empresa con contenido en web, iOS, Android y kioscos digitales, el mismo CMS alimentando todos los canales puede ahorrar costos operacionales significativos a mediano plazo. Lo explicamos a fondo en mantener WordPress y WPGraphQL actualizados.
Cuándo headless es realmente la respuesta
Hay casos donde el trade-off tiene sentido.
Organizaciones multiplataforma
Si el mismo contenido tiene que aparecer en un sitio web, una app iOS, una app Android y un kiosco digital en simultáneo, headless deja de ser una elección de arquitectura y pasa a ser la única opción sensata. Un único CMS WordPress, una API, cuatro frontends que consumen el mismo contenido. Ejemplo concreto: cadenas de retail que manejan contenido editorial coordinado entre su sitio, su app de fidelidad y pantallas en el punto de venta.
Redacciones de alto volumen
Publicar 10 o más artículos diarios con flujos editoriales complejos (revisiones, staging, publicación programada en múltiples idiomas) es otro caso donde headless tiene sentido. El backend WordPress puede optimizarse exclusivamente para gestión editorial sin preocuparse por el rendimiento del frontend.
Qué significa para equipos y proyectos en Latinoamérica
La mejora del 40% en latencia tiene una implicación específica para proyectos en la región: los servidores de WordPress suelen estar en Estados Unidos o Europa, lo que históricamente generaba latencias altas para usuarios en Argentina, Brasil o México.
Con una arquitectura headless bien configurada, el contenido se sirve desde una CDN con nodos en la región. El usuario en Buenos Aires recibe el HTML desde un nodo local, no desde un servidor en Virginia. WordPress solo responde al pedido de revalidación de caché, que ocurre en background y no afecta la experiencia del usuario final.
El tema es que esto requiere una CDN con presencia regional. Para proyectos con audiencia latinoamericana, vale la pena verificar que el proveedor de hosting del frontend tenga nodos en la región antes de tomar la decisión de infraestructura.
Otro factor local: la disponibilidad de talento técnico. Next.js y React tienen una comunidad activa en Argentina y la región. Astro está creciendo pero todavía es más chico. SvelteKit tiene una comunidad pequeña pero entusiasta. Si el proyecto va a necesitar incorporar desarrolladores en el futuro, la elección del framework también es una decisión de mercado laboral.
Preguntas Frecuentes
¿Qué es WordPress headless y por qué en 2026 es estándar?
WordPress headless es una arquitectura donde WordPress funciona solo como backend de gestión de contenido, y el frontend que ve el usuario es un framework moderno separado (Next.js, Astro, SvelteKit). En 2026 es considerado estándar de producción porque WordPress 7.0 mejoró su REST API un 40% en latencia, WPGraphQL 2.x maduró como capa GraphQL oficial, y el ecosistema de frameworks frontend estabilizó sus integraciones. Ya no es un experimento: hay patrones documentados, tooling maduro y casos de éxito en producción.
¿WPGraphQL 2.x vs REST API, cuál es más rápido?
Depende del tipo de query. Para requests simples (un post con pocos campos), la REST API es competitiva porque no tiene el overhead de parsing GraphQL. Para páginas complejas que necesitan datos de múltiples recursos (posts + categorías + menús + autor), WPGraphQL gana claramente porque resuelve todo en una sola query en lugar de varios requests encadenados. Además, WPGraphQL 2.x tiene smart cache con invalidación granular, lo que mejora el rendimiento en sitios con actualización frecuente de contenido.
¿Qué es la Abilities API de WordPress 7.0 y para qué sirve en headless?
La Abilities API permite que WordPress (y los plugins) declaren sus capacidades en un formato machine-readable que el frontend puede consultar programáticamente. En arquitecturas headless, esto sirve para dos cosas: primero, el frontend puede descubrir qué funcionalidades están disponibles en el backend sin documentación manual ni prueba y error. Segundo, permite emitir tokens de autenticación con scopes específicos (solo lectura, solo borradores, etc.), lo que mejora la seguridad en arquitecturas desacopladas.
¿Astro o Next.js para un blog WordPress headless?
Para un blog enfocado en contenido editorial con SEO como prioridad, Astro 6 es la mejor opción. Genera HTML estático con cero JavaScript por defecto, lo que se traduce en Core Web Vitals excelentes sin configuración adicional. Next.js 16 conviene cuando el proyecto necesita componentes interactivos complejos o el equipo ya tiene experiencia en React. Si el objetivo principal es velocidad de carga y posicionamiento orgánico, Astro es difícil de superar para sitios de contenido.
¿Cuánta latencia tiene WordPress desacoplado en 2026?
En entornos de producción bien configurados, el TTFB de un sitio WordPress headless bajó de 3,5 segundos (2024) a 0,8 segundos en 2026. Esta mejora combina las optimizaciones de REST API en WordPress 7.0, el smart cache de WPGraphQL 2.x, y la distribución de contenido estático via CDN. Los usuarios reciben HTML pre-generado desde nodos de CDN cercanos, y WordPress solo responde a requests de revalidación en background. Habría que aclarar que estos números corresponden a configuraciones optimizadas, no a instalaciones por defecto.
Conclusión
WordPress headless en 2026 no es la misma conversación que en 2023. Entonces era «¿nos animamos?». Ahora es «¿tiene sentido para nuestro caso?». Esa es una diferencia real: el ecosistema maduró, los números mejoraron, y la arquitectura tiene un camino documentado con WPGraphQL 2.x como capa GraphQL estándar y la Abilities API de WordPress 7.0 como fundamento para permisos granulares.
La mejora del 40% en latencia no es magia. Viene de una combinación de optimizaciones en WordPress core, smart cache en WPGraphQL, e ISR en los frameworks frontend. Cada pieza sola no llega a ese número; el conjunto sí.
Lo que no cambió es el análisis del trade-off. Headless sigue requiriendo dos stacks técnicos, un equipo con experiencia en el framework frontend elegido, y una infraestructura más compleja de operar. Para proyectos multiplataforma o redacciones de alto volumen, esa complejidad se justifica. Para un blog de contenido con un equipo pequeño, un WordPress monolítico bien configurado sigue siendo la opción más sensata.
De acá en adelante, conviene seguir de cerca la adopción de la Abilities API en el ecosistema de plugins: cuando los plugins populares la implementen masivamente, el argumento de seguridad para headless se vuelve todavía más sólido. Y si estás evaluando la migración, empezá por WPGraphQL 2.x en modo híbrido antes de comprometerte con un frontend completamente desacoplado.
