Probamos diez plataformas frente a los flujos que un equipo React vive de verdad, desde un sitio Next.js de marketing con tres editores hasta una aplicación multi-tenant con decenas de modelos de contenido, esquemas con ramas y previsualización al vuelo a través de middleware. Cada plataforma queda ordenada por aquello en lo que es mejor para los ingenieros que tienen que llevarla a producción.
De un vistazo
Compara las mejores herramientas lado a lado
Cada plataforma se evaluó frente a escenarios representativos: ergonomía del SDK tipado en un repositorio TypeScript estricto, patrones de consulta GraphQL y REST bajo carga real de página, viajes de ida y vuelta de previsualización a través del modo borrador de Next.js, comportamiento del CDN de imágenes en activos hero y la manguera de webhooks que cualquier equipo editorial no trivial acaba generando. Ningún proveedor pagó por su posición y ninguna relación de afiliación influyó en el ranking. Esta guía cubre los factores de compra que importan, después explora las preguntas más difíciles y al final revisa cada plataforma una a una.
Lo esencial
¿El SDK de TypeScript es realmente de primera?
Los equipos React se preocupan más por modelos de contenido tipados que por listas de características. Tipos generados desde tu esquema, un SDK mantenido y ejemplos limpios de Next.js o Remix son la diferencia entre un CMS que se vuelve invisible y uno con el que tus ingenieros pelean cada sprint.
¿GraphQL o REST, y encaja con tu stack?
GraphQL se siente nativo si tu app ya usa Apollo o urql, REST está bien si estás cosiendo contenido en server components. Elige la forma de API que case con tu capa de datos, no la que enamoró a la demo del proveedor.
¿Los editores tendrán previsualización real, no una captura?
La previsualización en vivo es la función que los editores deciden y la que más fines de semana cuesta a los ingenieros. Soporte nativo del modo borrador de Next.js, tokens de previsualización firmados y latencia de ida y vuelta por debajo de un segundo separan las plataformas que envían de las que hay que cuidar.
¿Las ramas de contenido y los roles vienen de serie o atornillados?
Las migraciones de esquema sobre un CMS en vivo dan miedo sin entornos. Ramas de contenido, control de acceso por rol y un ecosistema de webhooks que aguante pipelines paralelos deciden si tu equipo puede ir rápido sin romperle la mañana a marketing.
Cómo elegir el mejor CMS headless para tu stack React
El mercado de CMS headless está hoy lo bastante poblado como para que cualquier demo de proveedor parezca creíble durante los primeros treinta minutos. Las diferencias aparecen después, cuando tu editor quiere previsualizar un borrador en una URL en vivo, tu CTO pregunta cómo funcionan las migraciones de esquema y tu ingeniero de DevOps nota que la cola de webhooks es el cuello de botella en cada despliegue. Considera las siguientes preguntas antes de comprometerte.
¿GraphQL o REST sirve mejor a tu stack React?
Si tu app ya corre Apollo Client o urql, un CMS GraphQL nativo como Hygraph, Sanity o DatoCMS encaja casi sin pegamento. Consultas el contenido igual que el resto de tu grafo de datos, lo cacheas igual y tus ingenieros dejan de reinventar el SDK. Si estás muy metido en server components de Next.js o en una arquitectura basada en fetch, REST es genuinamente más simple, y Contentful o Strapi te darán menos trabajo. Elegir GraphQL cuando tu equipo nunca lo ha usado añade un impuesto mental que ningún beneficio del modelado de contenidos va a devolver. Adapta la forma de la API a la capa de datos que ya tienes.
¿Cuán importante es la previsualización al vuelo para tus editores?
La previsualización en vivo es la función que se demuestra una vez y luego persigue a ingeniería durante un año. Las plataformas que la resuelven bien, como Storyblok, DatoCMS y Sanity, dan a los editores una previsualización lado a lado o en línea con un viaje de ida y vuelta por debajo del segundo en una URL de borrador. Las que no, te obligan a cablear el modo borrador de Next.js, los tokens firmados y un hook de revalidación a medida para cada tipo de contenido. Si tu equipo editorial es pequeño y publica una vez por semana, una previsualización básica es suficiente. Si tienes diez editores publicando a diario en un sitio de marketing, pondera mucho la previsualización en vivo, porque la alternativa es un canal de Slack lleno de capturas.
¿Necesitas ramas de contenido para cambios de esquema seguros?
Añadir un campo obligatorio a un modelo de contenido que ya está en producción es el momento en el que la mayoría de equipos descubre si su CMS tiene entornos. Contentful tiene space environments, Sanity tiene datasets, Hygraph y DatoCMS tienen content stages. Strapi y Directus te empujan a flujos basados en Git que tú mismo construyes. Si tu esquema es estable y tu equipo editorial es pequeño, las ramas son un nice-to-have. Si marketing está iterando esquemas de landing cada semana, las ramas son la diferencia entre un martes y un rollback.
¿Cuán pulida tiene que ser la experiencia del editor?
Los ingenieros lo subestiman y luego acaban arrastrados a una reunión un viernes sobre por qué el editor tiene que hacer scroll por cuarenta campos para encontrar el botón de publicar. Storyblok y Prismic invierten mucho en la UI editorial, con construcción visual de páginas y composición basada en slices. Sanity Studio es personalizable hasta el exceso, lo cual es una virtud para ingeniería y una frustración para editores que solo querían un formulario limpio. Strapi y Directus dan un admin usable de serie pero se sienten como paneles de control más que como entornos editoriales. Adapta el pulido a quien va a usarlo de verdad, no a quien eligió la herramienta.
¿Autoalojado, en cloud o ambos?
Strapi y Directus corren en cualquier sitio donde puedas correr Node y una base Postgres, que es exactamente la respuesta para industrias reguladas, clientes on-premise y equipos que se niegan a meter su contenido en el cloud de un proveedor. Contentful, Sanity, Hygraph, DatoCMS, Prismic y Storyblok son solo cloud, que es la respuesta correcta para la mayoría de equipos que no quieren operar un CMS. Ghost y ButterCMS quedan en medio, con Ghost contento de autoalojarse y ButterCMS pegado al modelo API como servicio. Decide dónde vive el dato antes de enamorarte del editor.
¿Vas a quedarte corto en el CDN de imágenes y en el techo de webhooks?
El CDN de imágenes es la función que no notas hasta que el tráfico se dispara, y entonces la notas para siempre. Sanity, Contentful, DatoCMS y Storyblok llevan un CDN real con transformaciones al vuelo, URLs firmadas y techos de ancho de banda razonables. Strapi y Directus esperan que cablees el tuyo, lo cual está bien si ya corres Cloudinary o imgix y es un problema si no. Los techos de webhooks importan más de lo que admite la documentación. Una plataforma que estrangula webhooks bajo carga te tirará silenciosamente el pipeline de revalidación el día que arranque una campaña. Lee los rate limits antes de leer la web de marketing.
¿Cuánto vendor lock-in estás dispuesto a aceptar?
Cada CMS headless presume de portabilidad porque el contenido vive detrás de una API. La realidad vivida es que las definiciones de esquema, el formato de texto enriquecido, las referencias de activos y el modelo de roles se vuelven específicos del proveedor en seis meses. Sanity exporta su dataset limpiamente, Strapi y Directus te dan una base de datos que controlas, y Contentful tiene herramientas de migración sólidas. Prismic, Storyblok y DatoCMS son más pegajosos de lo que parecen. Elige el nivel de lock-in con el que puedas vivir en un horizonte de tres años, no la plataforma que gana la demo.
Mejor para entrega de API empresarial
Contentful
Top Pick
Contentful combina una Content Delivery API REST y GraphQL probada en batalla con SDKs de TypeScript de primera, space environments para cambios de esquema seguros y el historial operativo que los compradores aversos al riesgo realmente valoran.
Visitar la webA quién va dirigido: Equipos React mid-market y empresariales que corren sitios en producción que no toleran caídas del CMS, quieren tipos generados de TypeScript sobre un esquema estable y necesitan separación limpia entre las APIs de contenido, entrega y gestión para que ingeniería, redacción y operaciones no choquen.
Por qué nos gusta: La Content Delivery API es la más predecible de la categoría, con cabeceras de caché razonables, cobertura regional de CDN y una superficie REST que cualquier capa de datos React consume sin ceremonia. El SDK de TypeScript es genuinamente de primera: los tipos generados desde tu esquema fluyen por hooks, server components e ISR sin tener que pelearte con ellos. Los space environments dan a los ingenieros un sitio donde aterrizar cambios de esquema, correr migraciones contra un space alias y promocionar sin asustar a marketing. Los webhooks son lo bastante fiables para alimentar la revalidación de Next.js a volumen de producción, y la management API está documentada lo suficiente para que los equipos de plataforma codifiquen el esquema como configuración. El control de acceso por rol es granular sin convertirse en un problema de RR. HH.
Defectos pero no decisivos: El precio escala con dureza en cuanto superas las localizaciones, tipos de contenido o llamadas a la API incluidos, lo que pega más fuerte a equipos que no modelaron su crecimiento. La UI del editor es funcional pero se siente más antigua que Storyblok o Sanity Studio. El soporte GraphQL es sólido pero secundario, con REST recibiendo la mayor parte de la inversión de plataforma, así que los stacks GraphQL-first pueden notar bordes ásperos. Las herramientas de migración para esquema como código existen pero exigen disciplina para usarse bien. La plataforma es opinionada sobre el modelado de contenidos, una virtud cuando el equipo está de acuerdo y un punto de fricción cuando no lo está.
Mejor para grafo de contenido estructurado
Sanity
Top Pick
Sanity trata el contenido como un grafo consultable, viene con un Studio basado en React que tu equipo puede extender y entrega a los ingenieros datasets, listeners en tiempo real y Portable Text que encajan con un stack React moderno de serie.
Visitar la webA quién va dirigido: Equipos liderados por ingeniería que construyen aplicaciones React donde el contenido es estructurado, relacional y reutilizado en varias superficies, que quieren un CMS que se comporte como una base de datos con un editor bonito encima y que están cómodos personalizando Studio en TypeScript para que case con su flujo.
Por qué nos gusta: GROQ es genuinamente potente una vez que el equipo supera la sintaxis, permitiéndote unir, filtrar y proyectar contenido como consultarías un grafo de datos en lugar de un endpoint de CMS. El SDK de TypeScript y el pipeline de codegen producen clientes tipados que funcionan en Next.js, Remix y React Router con poco pegamento. Portable Text es la respuesta más limpia al texto enriquecido en React, dándote una estructura serializable que puedes renderizar con componentes a medida en lugar de pelearte con HTML embebido. Los datasets ofrecen un modelo de ramas de contenido que escala, y la API de listeners en tiempo real alimenta una previsualización en vivo que de verdad se siente viva. Studio es una app React que envías en el mismo repo, lo que significa que los ingenieros pueden extenderla sin salir de su stack.
Defectos pero no decisivos: La curva de aprendizaje de GROQ y la personalización de Studio es real, y los equipos que esperan un editor llave en mano basado en formularios sentirán la fricción. El nivel gratuito es generoso pero el precio por documento y por ancho de banda puede sorprender a equipos que almacenan medios grandes inline. La UX editorial requiere inversión para sentirse pulida; de serie es funcional más que deliciosa. Portable Text es opinionado, y migrarse fuera de él más adelante es más trabajo que cambiar un blob de markdown.
Mejor para extensibilidad open source
Strapi
Top Pick
Strapi entrega a los equipos React un backend open source de Node y TypeScript autoalojado, con REST y GraphQL de serie, una arquitectura de plugins extensible y control total sobre la base de datos, la infraestructura y la hoja de ruta.
Visitar la webA quién va dirigido: Equipos de ingeniería que necesitan autoalojarse por cumplimiento, soberanía o coste, que quieren extender el CMS con plugins o middleware a medida y que ya operan servicios Node.js y una base Postgres o MySQL sin pestañear.
Por qué nos gusta: Strapi corre en infraestructura que ya conoces, lo que significa que los despliegues encajan en tu CI, tu gestión de secretos y tu observabilidad existentes en lugar de los de otra persona. El soporte TypeScript ha madurado mucho, y la v5 trae un SDK tipado que los equipos React consumen limpiamente desde Next.js, Remix o una app Vite plana. REST y GraphQL son de primera mano, no atornillados, así que los patrones de consulta pueden casar con el resto de tu capa de datos. La arquitectura de plugins es middleware genuino, dejándote añadir endpoints a medida, modificar lifecycles e integrar flujos sin forkear el core. El control de acceso por rol y el versionado de contenidos vienen en la edición open source. Alojarlo tú mismo pone un techo al coste total de propiedad de un modo que ninguna página de precios SaaS puede igualar.
Defectos pero no decisivos: Estás operando un CMS, lo que significa que las actualizaciones, los backups y los parches de seguridad son tu problema. El admin editorial es funcional pero se siente como un panel de control más que como un entorno editorial pulido. El pipeline de imágenes espera que traigas tu CDN. La migración entre versiones mayores ha sido históricamente dolorosa, y la transición de v4 a v5 recordó a los equipos que los cambios de esquema disruptivos cuestan caros. Funciones empresariales como SSO y registros de auditoría viven detrás del nivel cloud o enterprise.
Mejor para edición visual
Storyblok
Top Pick
Storyblok combina un editor visual lado a lado con un modelo de contenido basado en componentes que mapea limpiamente sobre componentes React, dando a los editores un WYSIWYG real y a los ingenieros un esquema estructurado en lugar de un volcado de texto enriquecido.
Visitar la webA quién va dirigido: Equipos React con peso de marketing donde los editores esperan componer páginas visualmente, que quieren que los componentes en el CMS reflejen los componentes del repositorio y que están dispuestos a invertir en la configuración del editor visual para dar al equipo editorial una superficie de autoservicio genuina.
Por qué nos gusta: El editor visual es el mejor de la categoría para editores que piensan en páginas en lugar de en campos, con una previsualización en vivo que se actualiza según escriben y un árbol de componentes pinchable que mapea por nombre a tus componentes React. El patrón bloks es una abstracción limpia: cada bloque del editor corresponde a un componente React, los esquemas son estructurados en lugar de libres, y los ingenieros conservan el control sobre cómo se renderiza el contenido. El SDK de TypeScript y el paquete @storyblok/react resuelven el sync en tiempo real con el editor, los tokens de borrador y la resolución de componentes con poco pegamento. El servicio de imágenes lleva transformaciones al vuelo de serie, y la superficie de webhooks alimenta la revalidación al volumen que generan los equipos de marketing.
Defectos pero no decisivos: El editor visual solo funciona si tu sitio se despliega en una URL que Storyblok pueda meter en un iframe, lo que significa que las previsualizaciones solo en local necesitan configuración extra. El modelo de precios basado en tráfico y asientos puede subir rápido en sitios de marketing con mucho tráfico. El modelo mental de bloks dentro de bloks dentro de bloks crea árboles de contenido potentes pero a veces difíciles de depurar. El soporte GraphQL es funcional pero la plataforma es REST primero. Migrarse fuera de Storyblok cuesta más que dejar a casi cualquier competidor porque la composición visual de páginas está fuertemente acoplada al editor.
Mejor para construir páginas en Next.js
Prismic
Top Pick
Prismic trae Slice Machine, un toolkit de desarrollador que convierte componentes React en slices del editor y al revés, dando a los equipos Next.js un flujo pragmático de construcción de páginas sin salir del repositorio.
Visitar la webA quién va dirigido: Equipos Next.js que construyen sitios de marketing y aplicaciones impulsadas por contenido que quieren un modelo de página basado en slices, prefieren definir sus esquemas en código en lugar de en una UI y aceptan vivir dentro de las opiniones de Prismic a cambio de una integración estrecha con Next.js.
Por qué nos gusta: Slice Machine es genuinamente una buena idea bien ejecutada: defines slices como componentes React en tu repo, los empujas a Prismic y los editores componen páginas a partir de esos slices en una previsualización lado a lado. El patrón de esquema como código mantiene los modelos de contenido en control de versiones junto a los componentes que renderizan, lo que elimina toda una clase de divergencias entre editor y código. La integración con Next.js gestiona el modo borrador, la revalidación bajo demanda y la optimización de imágenes con poco pegamento a medida. El SDK de TypeScript es sólido, y el endpoint GraphQL de Prismic resuelve las consultas que las páginas de marketing suelen necesitar. La fiabilidad de los webhooks es lo bastante buena para alimentar ISR a escala de producción.
Defectos pero no decisivos: Prismic es opinionado sobre Next.js, y los equipos React que usan Remix, Vite o un framework no React se sentirán ciudadanos de segunda. El modelo de slices es excelente para páginas de marketing pero incómodo para contenido muy relacional donde las uniones importan más que la composición. El editor de Custom Types para contenido fuera de slices es funcional pero se siente más antiguo que el tooling de slices. El precio escala por llamadas a la API y localizaciones de formas que sorprenden a los equipos bajo tráfico. Migrar slices a otro CMS es un proyecto, no un script.
Mejor para federación GraphQL
Hygraph
Top Pick
Hygraph trata GraphQL como API de primera, no como añadido, con federación de contenido que te deja coser datos de producto, APIs de comercio y servicios externos en un único esquema que tu app React puede consultar.
Visitar la webA quién va dirigido: Equipos React que ya corren Apollo, urql o Relay y quieren que su CMS se comporte como otro nodo del grafo, que necesitan combinar contenido del CMS con comercio, búsqueda o datos de producto detrás de una sola consulta y que valoran el desarrollo schema-first por encima de una UI de editor pulida.
Por qué nos gusta: El endpoint GraphQL es la plataforma, no una capa sobre REST, lo que significa que filtros, paginación, ordenación y relaciones anidadas funcionan como los clientes GraphQL esperan. La federación de contenido es el diferenciador: puedes registrar APIs GraphQL externas como tipos remotos y unirlos con contenido nativo en una única consulta, lo que elimina toda una clase de código de costura en tu app Next.js o Remix. El SDK de TypeScript junto con GraphQL Code Generator te da consultas tipadas de extremo a extremo. Los content stages cubren los flujos de ramas que los ingenieros necesitan para cambios de esquema seguros. La entrega de webhooks es fiable, y el modelo de roles es lo bastante granular para equipos distribuidos.
Defectos pero no decisivos: La UI editorial es funcional más que deliciosa, y los editores acostumbrados a Storyblok o Prismic notarán la diferencia. La previsualización en vivo funciona pero requiere más configuración que en los competidores liderados por editor visual. El nivel gratuito cubre proyectos pequeños pero llega rápido a sus límites a medida que crecen los modelos de contenido, y los planes saltan en lugar de escalar suavemente. GraphQL primero significa que los equipos no familiarizados con el lenguaje heredan una curva de aprendizaje. La documentación ha mejorado pero todavía va por detrás de Contentful y Sanity en casos extremos.
Mejor para blogs llave en mano
ButterCMS
Top Pick
ButterCMS es la opción sin complicaciones: una API REST alojada para blogs, páginas y colecciones que entra en una app React o Next.js en una tarde y se aparta del camino una vez enviada.
Visitar la webA quién va dirigido: Equipos pequeños de producto que necesitan añadir un blog, una página de empleo o una superficie de marketing a una app React existente sin adoptar una plataforma de contenido entera, que valoran el time-to-shipped por encima de la profundidad del modelado de contenidos y que no quieren negociar con un proveedor sobre content stages.
Por qué nos gusta: La API es deliberadamente simple: endpoints REST para posts, páginas y colecciones, un SDK de Node y JavaScript que se integra con cualquier app React y un motor de blog llave en mano que cubre el 80% de lo que marketing necesita. El editor alojado es limpio, opinionado y amigable para editores sin reuniones de configuración. El alojamiento de imágenes está incluido y es lo bastante bueno para la mayoría de cargas de marketing de contenidos. La documentación es concisa, los ejemplos de integración para Next.js y Gatsby son precisos y el equipo de soporte responde. El precio es transparente y predecible, lo que importa para proyectos donde la línea del CMS nunca debe convertirse en una conversación de comité.
Defectos pero no decisivos: ButterCMS es superficial por diseño, y los equipos que necesitan ramas, roles granulares, federación de contenido o consultas GraphQL ricas se le quedarán pequeños. El SDK de TypeScript es funcional pero la generación de tipos a partir de colecciones a medida es manual. La previsualización en vivo es básica comparada con Storyblok o DatoCMS. Las transformaciones de activos son limitadas frente a competidores con CDNs de imagen completos. La plataforma es la respuesta correcta para un blog y la equivocada para un grafo de contenido empresarial, así que sé honesto sobre en qué lado estás.
Mejor para creadores de newsletters
Ghost
Top Pick
Ghost es plataforma de publicación primero y CMS headless después, pero su Content API es lo bastante limpia como para que los equipos React que llevan una newsletter, una marca de medios o un sitio de creador la usen como backend de un frontend Next.js a medida.
Visitar la webA quién va dirigido: Equipos liderados por publicación que llevan una newsletter, blog o sitio de medios que quieren suscripciones, gestión de miembros y entrega de email integradas con el contenido y que están dispuestos a aceptar las opiniones editoriales de Ghost a cambio de un stack de audiencia y monetización integrado.
Por qué nos gusta: Ghost se queda con todo el stack de publicación: escritura, alta de miembros, suscripciones de pago, newsletters por email y analítica, que es exactamente lo que un equipo creador necesita y exactamente lo que la mayoría de CMS headless te dejan ensamblar. La Content API es REST, está bien documentada y se consume fácil desde un frontend Next.js o Remix cuando quieres un sitio totalmente a medida en lugar del tema por defecto. El editor es agradable para escritores de formato largo, y el sistema de membresía y niveles gestiona newsletters de pago sin atornillar Memberstack. Autoalojarse en una VPS pequeña es genuinamente barato, y Ghost(Pro) gestiona la operación para los equipos que no quieren.
Defectos pero no decisivos: Ghost no es un CMS generalista. Modelos de contenido a medida, relaciones complejas y datos estructurados más allá de posts y páginas no son la fuerza de la plataforma, y forzarlos suele significar trabajar a contracorriente. El SDK de TypeScript es liderado por la comunidad en lugar de ser de primera mano. La cobertura de webhooks es más estrecha que en Contentful o Sanity. El flujo editorial está enfocado a un autor; las publicaciones multiautor funcionan pero les faltan los roles granulares que los equipos empresariales esperan. Usa Ghost cuando las newsletters y los miembros sean el producto, no cuando lo sea el modelado de contenidos.
Mejor para envolver bases SQL
Directus
Top Pick
Directus convierte cualquier base SQL en un CMS headless con APIs REST y GraphQL autogeneradas, una app de admin limpia y la rara propiedad de que tu contenido vive en una base de datos que controlas y consultas directamente.
Visitar la webA quién va dirigido: Equipos de ingeniería que ya tienen una base relacional o quieren que su contenido viva en una, que necesitan exponer tablas existentes a editores sin reescribirlas como modelos de contenido propietarios y que valoran la propiedad del dato y la portabilidad SQL por encima de una UI editorial curada.
Por qué nos gusta: La arquitectura es la función estrella: apunta Directus a una base Postgres, MySQL o SQLite y te genera un CMS más APIs REST y GraphQL a partir de tu esquema existente, sin obligarte a migrar tus datos a un formato propietario. Eso lo convierte en el mejor encaje para productos donde el contenido y los datos operativos viven en la misma base, y para equipos que quieren mantener herramientas de BI, jobs de ETL y analítica apuntando a SQL en lugar de a una exportación del CMS. El SDK de TypeScript es sólido, la app de admin es React y extensible y los permisos granulares son ABAC real en lugar de roles atornillados. Autoalojarse es directo, y Directus Cloud está ahí cuando no quieres.
Defectos pero no decisivos: El modelo schema-first es potente pero implacable para editores acostumbrados a una experiencia curada de modelado de contenido; tienes que invertir en configuración de campos para que las tablas se sientan como contenido. La previsualización en vivo existe pero requiere cablearse contra tu frontend. El pipeline de imágenes es funcional pero espera que traigas o configures un CDN para producción. La documentación ha mejorado pero sigue teniendo esquinas desiguales en torno al desarrollo de plugins. Las actualizaciones de versión mayor exigen cuidado, sobre todo en equipos que corren extensiones a medida.
Mejor para previsualización en tiempo real
DatoCMS
Top Pick
DatoCMS combina una API GraphQL primero, un editor pulido y la integración más fiable de previsualización en vivo con el modo borrador de Next.js de cualquier plataforma que probamos, razón por la que los equipos editoriales dejan de quejarse en un sprint.
Visitar la webA quién va dirigido: Equipos React y Next.js cuyos editores cuidan intensamente la previsualización en vivo, que quieren GraphQL como API principal de contenido y que están dispuestos a pagar por una experiencia editorial curada en lugar de autoalojarse y ensamblar la previsualización ellos mismos.
Por qué nos gusta: La Content Delivery API GraphQL es la más limpia de su clase, con filtros, fragmentos y paginación predecibles que encajan con Apollo o urql sin ceremonia. La API de actualizaciones en tiempo real alimenta una previsualización en vivo que se siente realmente viva: las ediciones aparecen en la página Next.js renderizada en un latido, sin gimnasia manual de revalidación. El CDN de imágenes resuelve transformaciones, focal points, placeholders LQIP y URLs firmadas a escala de producción. La localización, los entornos y los roles son de primera, no añadidos. El SDK de TypeScript junto con codegen produce clientes tipados de extremo a extremo. La documentación es genuinamente buena, con ejemplos de Next.js que sobreviven al contacto con la realidad.
Defectos pero no decisivos: El precio es el más opinionado de la categoría, con dimensiones por registro, por activo y por entorno que pueden sorprender a equipos en crecimiento; modela tu uso antes de firmar. Las extensiones de campos a medida requieren trabajo React, lo que es virtud para ingeniería y carga para marketing. El editor es pulido pero ligeramente menos visual que Storyblok para los marketers que quieren composición a nivel de página. Los webhooks son fiables pero los techos de tasa son reales, así que los pipelines de revalidación de muy alto volumen necesitan diseño en lugar de buenos deseos.