He estado construyendo para la web lo suficiente como para recordar cuando "Jamstack" era solo una charla de conferencia que Mathias dio en Smashing Conf. ¿Ahora? Nike, Spotify y Twilio ejecutan partes de su presencia web de esta manera.

Aquí está lo que necesitas saber: Jamstack no es un framework. Es un enfoque arquitectónico que cambia cómo construyes, despliegas y sirves sitios web. Y ha madurado mucho más allá de la fase "solo para blogs".

Esta guía funciona para ambos lados de la mesa. Ingenieros: profundizaremos en invalidación ISR, patrones de funciones edge, configuraciones de compilación reales. Especialistas en marketing y producto: mostraremos por qué esto se traduce en páginas más rápidas, mejores clasificaciones SEO, menos interrupciones a las 3 AM.

Tabla de contenidos

La idea central: qué significa realmente Jamstack

El nombre significaba JavaScript, APIs y Markup. Mathias Biilmann (cofundador de Netlify) lo acuñó alrededor de 2015-2016 porque no había una abreviatura adecuada para el patrón que su equipo seguía viendo. El "JAM" en mayúsculas se ha suavizado a "Jamstack" -- y honestamente, el acrónimo importa menos que dos principios centrales:

  1. Pre-renderizado -- Genera la mayor parte posible de tu sitio con anticipación, no en cada solicitud.
  2. Desacoplamiento -- Separa tu frontend de los servicios backend, bases de datos y gestión de contenido.

Eso es. Todo lo demás fluye de esas dos ideas.

Por qué los especialistas en marketing deben preocuparse

Velocidad. Disponibilidad. SEO.

Las Métricas principales de la web de Google influyen directamente en los rankings de búsqueda. Las páginas pre-renderizadas servidas desde un CDN constantemente superan a las páginas renderizadas en servidor en métricas de LCP (Largest Contentful Paint) e FID (First Input Delay). Un estudio de 2025 del Informe de UX de Chrome de Google mostró que los sitios que utilizan arquitecturas estáticas prioritarias pasaron los umbrales de métricas principales web casi el doble de veces que los sitios tradicionales renderizados en servidor.

Traducción: páginas más rápidas → mejores rankings → más tráfico.

Por qué los ingenieros deben preocuparse

Complejidad operacional reducida. Sin servidores de origen que parchear a las 2 AM. Sin grupos de conexión de base de datos para ajustar. Tu superficie de ataque se reduce drásticamente cuando estás sirviendo activos estáticos desde un CDN con llamadas API manejadas por servicios gestionados.

Envías más rápido porque tu pipeline de CI/CD es un git push que desencadena una compilación y se despliega globalmente en minutos.

Pre-renderizado: compilar una vez, servir en todas partes

El pre-renderizado es la base. En lugar de que un servidor genere HTML en cada solicitud (el modelo WordPress/PHP), un sitio Jamstack genera todas sus páginas HTML durante un paso de compilación antes del despliegue.

Modelo mental simplificado:

Tradicional: Solicitud del usuario → Servidor → Consulta a base de datos → Renderizado de plantilla → HTML → Usuario
Jamstack:    Paso de compilación → HTML/CSS/JS estático → CDN → Solicitud del usuario → Respuesta instantánea

El paso de compilación se ejecuta en CI/CD (Vercel, Netlify, GitHub Actions, lo que sea). Extrae contenido de tu CMS a través de API, lo ejecuta a través del proceso de compilación de tu framework y genera una carpeta de archivos estáticos. Esos archivos se envían a un CDN.

Generación de sitios estáticos (SSG)

El enfoque Jamstack original. Cada página se genera en tiempo de compilación. Los frameworks que manejan esto bien:

  • Astro -- Envía cero JavaScript por defecto. Excelente para sitios con mucho contenido. Lo usamos mucho para sitios de marketing en Social Animal (ve nuestro trabajo con Astro).
  • Next.js -- Soporta SSG a través de getStaticProps y getStaticPaths, más modos de renderizado híbrido.
  • Hugo -- Compilaciones extremadamente rápidas en Go. Un sitio de 10,000 páginas se compila en segundos.
  • Eleventy (11ty) -- Minimal, flexible, sin vinculación de framework.

Aquí está SSG en Next.js:

// pages/blog/[slug].js
export async function getStaticPaths() {
  const posts = await fetchAllPostSlugs(); // desde CMS sin cabeza
  return {
    paths: posts.map((slug) => ({ params: { slug } })),
    fallback: 'blocking', // fallback ISR -- más sobre esto después
  };
}

export async function getStaticProps({ params }) {
  const post = await fetchPostBySlug(params.slug);
  return {
    props: { post },
    revalidate: 60, // ISR: regenerar cada 60 segundos
  };
}

Enfoque comparable en Astro:

---
// src/pages/blog/[slug].astro
import { getCollection } from 'astro:content';

export async function getStaticPaths() {
  const posts = await getCollection('blog');
  return posts.map((post) => ({
    params: { slug: post.slug },
    props: { post },
  }));
}

const { post } = Astro.props;
---
<article>
  <h1>{post.data.title}</h1>
  <Content />
</article>

El problema del tiempo de compilación

SSG tiene una limitación bien conocida: los tiempos de compilación escalan con el número de páginas. Un catálogo de e-commerce de 50,000 páginas puede tomar 30+ minutos para compilar. Este fue un punto de dolor real en 2020-2022.

¿La respuesta de la industria? ISR y compiladores bajo demanda (más sobre esto en la sección ISR).

Entrega por CDN: por qué la geografía importa

Un CDN cachea tus archivos estáticos en nodos edge en todo el mundo. Cuando un usuario en Tokio solicita tu página, la obtiene de un nodo edge en Tokio -- no de tu servidor de origen en Virginia.

La diferencia de rendimiento es dramática. Una página renderizada típica en servidor podría tener un TTFB (Time to First Byte) de 200-800ms dependiendo de la carga del servidor y la distancia del usuario. ¿Una página estática servida por CDN? Generalmente 10-50ms.

Proveedores de CDN para Jamstack

Proveedor Nivel gratuito Ubicaciones Edge Características notables
Vercel 100GB ancho de banda/mes 110+ Construido para Next.js, cacheo de edge automático
Netlify 100GB ancho de banda/mes 150+ Despliegues previos, manejo de formularios, identidad
Cloudflare Pages Ancho de banda ilimitado 330+ Integración con Workers, cero arranques en frío
AWS CloudFront 1TB/mes (12 meses) 450+ Control fino de caché, Lambda@Edge
Fastly Basado en uso 80+ Purga instantánea, lógica edge basada en VCL

Para la mayoría de proyectos Jamstack en 2026, Vercel y Netlify manejan despliegue y CDN en un paquete. Empujas código, ellos compilan y distribuyen. Si necesitas más control sobre reglas de caché o estás ejecutando a escala masiva, Cloudflare o Fastly te dan esa granularidad.

Invalidación de caché

La parte difícil no es servir contenido cacheado -- es saber cuándo romper ese caché. Cuando un editor de contenido publica una nueva publicación de blog, ¿con qué rapidez entra en funcionamiento?

Con SSG puro, desencadenas una compilación completa. Con ISR, invalidas rutas específicas. Con funciones edge, puedes hacerlo por solicitud. Cada enfoque tiene compensaciones entre frescura y complejidad de compilación.

Desacoplamiento de API: el backend se convierte en un servicio

En una configuración tradicional de WordPress o Drupal, el CMS es el servidor. Almacena contenido, renderiza plantillas, maneja autenticación, procesa formularios y sirve páginas. Si el CMS se cae, todo se cae.

Jamstack desacopla todo esto. Tu frontend son solo archivos en un CDN. Tu backend es una colección de APIs -- cada una manejando una preocupación:

  • Contenido → API de CMS sin cabeza (Sanity, Contentful, Storyblok)
  • Autenticación → Auth0, Clerk, Supabase Auth
  • Pagos → API de Stripe
  • Búsqueda → Algolia, Meilisearch, Typesense
  • Formularios → Formspree, Netlify Forms, Basin
  • E-commerce → API de Shopify Storefront, Saleor, Medusa

Esto a menudo se llama una "arquitectura componible". Eliges servicios de clase mundial para cada función en lugar de aceptar lo que tu CMS monolítico agrupa.

La compensación de ingeniería

No pretenderé que esto sea completamente positivo. El desacoplamiento introduce complejidad de integración. Ahora estás gestionando claves de API, configuraciones de webhook y flujos de datos entre múltiples servicios. Un monolito es más simple de razonar.

La compensación vale la pena cuando necesitas rendimiento a escala, cuando diferentes equipos necesitan trabajar independientemente, o cuando quieres cambiar servicios sin reescribir todo tu sitio.

En Social Animal, ayudamos a los equipos a pensar a través de exactamente este tipo de decisión de arquitectura. Nuestro trabajo de desarrollo de CMS sin cabeza está específicamente construido alrededor de encontrar la composición correcta de servicios para cada proyecto.

CMS sin cabeza: contenido sin el monolito

Un CMS sin cabeza almacena y gestiona contenido pero no tiene opinión sobre cómo se muestra. En lugar de renderizar páginas (como hace WordPress), expone contenido a través de una API. Tu frontend consume esa API en tiempo de compilación, en tiempo de solicitud, o ambos.

Comparación de CMS sin cabeza (2026)

CMS Tipo Estilo de API Nivel gratuito Mejor para
Sanity Basado en API GROQ + GraphQL Generoso (gratis hasta 200K solicitudes de API/mes) Modelado de contenido flexible, colaboración en tiempo real
Contentful Basado en API REST + GraphQL Plan comunitario (5 usuarios) Equipos empresariales, localización
Storyblok Basado en API REST + GraphQL Plan comunitario (1 usuario) Edición visual, contenido impulsado por componentes
Strapi Auto-alojado / Cloud REST + GraphQL Gratis (auto-alojado) Control total, backends personalizados
Payload CMS Auto-alojado REST + GraphQL Gratis (código abierto) TypeScript nativo, configuración de código primero
WordPress (sin cabeza) Auto-alojado REST + WPGraphQL Gratis (código abierto) Equipos con experiencia existente en WordPress
Keystatic Basado en Git Sistema de archivos Gratis (código abierto) Sitios con mucho markdown, contenido liderado por desarrolladores

La elección depende de tu equipo. Si tus editores necesitan una experiencia de edición visual pulida, Storyblok o Sanity's Studio son difíciles de superar. Si quieres contenido almacenado en tu repositorio de Git como archivos markdown, Keystatic o incluso colecciones de contenido integradas de Astro funcionan bien.

Cómo fluye el contenido en Jamstack

1. Editor publica contenido en CMS sin cabeza
2. CMS envía webhook a plataforma de compilación (Vercel/Netlify)
3. Plataforma de compilación desencadena nueva compilación o revalidación ISR
4. Framework obtiene contenido más reciente a través de API de CMS
5. Páginas estáticas se generan y despliegan en CDN
6. Usuario ve contenido actualizado (segundos a minutos, dependiendo de la estrategia)

Para sitios de marketing con mucho contenido, este flujo de trabajo es transformador. Los editores obtienen una interfaz de contenido dedicada. Los desarrolladores obtienen control total sobre el frontend. Ninguno bloquea al otro.

Vemos este patrón constantemente en nuestros proyectos Next.js.

Funciones Edge: computación en la capa CDN

Las funciones edge son la evolución más grande en Jamstack desde ISR. Te permiten ejecutar pequeños fragmentos de código del lado del servidor en nodos edge de CDN -- cerca del usuario, con tiempos de arranque en frío medidos en milisegundos de un solo dígito.

Piensa en ellas como funciones serverless ligeras que se ejecutan antes de que la respuesta llegue al usuario. Son perfectas para:

  • Pruebas A/B -- Enruta usuarios a diferentes variantes de página sin parpadeo del lado del cliente
  • Personalización -- Sirve contenido diferente basado en geolocalización, cookies o encabezados
  • Verificaciones de autenticación -- Verifica tokens JWT antes de servir contenido protegido
  • Reescrituras y redirecciones de URL -- Maneja lógica de enrutamiento compleja en el edge
  • Feature flags -- Alterna características sin redesplegar

Ejemplo de función Edge (Vercel)

// middleware.ts (se ejecuta en el edge en cada solicitud)
import { NextResponse } from 'next/server';
import type { NextRequest } from 'next/server';

export function middleware(request: NextRequest) {
  const country = request.geo?.country || 'US';
  
  // Redirige usuarios de UE a versión compatible con GDPR
  if (['DE', 'FR', 'IT', 'ES', 'NL'].includes(country)) {
    return NextResponse.rewrite(new URL(`/eu${request.nextUrl.pathname}`, request.url));
  }
  
  // Prueba A/B: división 50/50 basada en cookie
  const bucket = request.cookies.get('ab-bucket')?.value;
  if (!bucket) {
    const response = NextResponse.next();
    response.cookies.set('ab-bucket', Math.random() > 0.5 ? 'a' : 'b');
    return response;
  }
  
  return NextResponse.next();
}

export const config = {
  matcher: ['/((?!api|_next/static|favicon.ico).*)'],
};

Proveedores de funciones Edge

  • Vercel Edge Middleware -- Se ejecuta antes de cada ruta, integración ajustada con Next.js
  • Netlify Edge Functions -- Basado en Deno, se ejecuta en la red de Deno Deploy
  • Cloudflare Workers -- Red de edge más grande, aislados V8, sin arranques en frío
  • Deno Deploy -- Despliegue global sin configuración, construido en tiempo de ejecución Deno

Las funciones edge difuminan la línea entre estático y dinámico. Obtienes los beneficios de latencia de entrega de CDN con solo suficiente lógica del lado del servidor para manejar personalización.

Aquí es donde Jamstack en 2026 realmente brilla -- ya no es "solo sitios estáticos".

ISR: lo mejor de lo estático y dinámico

Enfrentamos este problema duramente en 2020. El cliente tenía un catálogo de e-commerce de 50,000 páginas. Las compilaciones completas tomaron 30+ minutos. Los editores de contenido publicarían actualizaciones y esperarían. Y esperarían.

La Regeneración Estática Incremental (ISR) lo resolvió. Next.js la introdujo en 2020. Las páginas se generan estáticamente en tiempo de compilación pero pueden regenerarse en segundo plano después de un intervalo de tiempo especificado o bajo demanda a través de llamadas a API.

Cómo funciona ISR

  1. La primera solicitud golpea el CDN y sirve la página estática cacheada
  2. Si la página es más antigua que el intervalo revalidate, Next.js desencadena una regeneración en segundo plano
  3. La siguiente solicitud obtiene la página generada recientemente
  4. Los usuarios nunca ven un estado de carga -- siempre obtienen una versión cacheada
// ISR de Next.js con revalidación bajo demanda
// pages/api/revalidate.js
export default async function handler(req, res) {
  // Verifica secreto de webhook desde CMS
  if (req.query.secret !== process.env.REVALIDATION_SECRET) {
    return res.status(401).json({ message: 'Token inválido' });
  }

  try {
    const { slug } = req.body;
    await res.revalidate(`/blog/${slug}`);
    return res.json({ revalidated: true });
  } catch (err) {
    return res.status(500).send('Error revalidando');
  }
}

Esto significa que un editor de contenido publica un cambio en Sanity, un webhook se dispara a tu endpoint de revalidación, y solo esa página específica se regenera. El resto de tus 50,000 páginas se queda sin tocar.

Los tiempos de compilación bajan de 30 minutos a milisegundos para actualizaciones de contenido.

ISR vs SSG vs SSR

Estrategia Cuándo se genera HTML Frescura Rendimiento Mejor para
SSG Solo tiempo de compilación Obsoleto hasta la siguiente compilación Más rápido (CDN puro) Sitios con cambios infrecuentes
ISR Tiempo de compilación + regeneración en segundo plano Obsoleto de segundos a minutos Rápido (CDN con actualizaciones en segundo plano) Sitios de contenido con actualizaciones regulares
SSR Cada solicitud Siempre fresco Más lento (dependencia del servidor) Páginas altamente dinámicas, personalizadas
SSR de Edge Cada solicitud en edge Siempre fresco Rápido (computación de edge) Dinámico + baja latencia

En la práctica, la mayoría de sitios Jamstack de producción en 2026 usan un enfoque híbrido. Las páginas de marketing son SSG. Las publicaciones de blog usan ISR con revalidación de 60 segundos. Las páginas del dashboard usan SSR o renderizado del lado del cliente.

Tanto Next.js como Astro soportan este tipo de estrategia de renderizado por ruta.

Jamstack vs arquitectura tradicional

Aspecto Tradicional (WordPress/Drupal) Jamstack
Renderizado Del lado del servidor, por solicitud Pre-renderizado + cacheado por CDN
Alojamiento Requiere servidor web + base de datos Archivos estáticos en CDN
Escalado Vertical (servidor más grande) o capas de caché Horizontal por defecto (CDN lo maneja)
Seguridad Gran superficie de ataque (servidor, BD, plugins) Mínima (archivos estáticos, claves de API del lado del servidor)
TTFB 200-800ms típico 10-50ms típico
Edición de contenido Interfaz CMS integrada CMS sin cabeza separado
Despliegue FTP/SSH, reinicios de servidor Git push → compilación automática + despliegue
Costo a escala Aumenta con tráfico (recursos del servidor) Frecuentemente plano o mínimo (ancho de banda de CDN)
Experiencia del desarrollador Vinculada al lenguaje de plantillas de CMS Cualquier framework de frontend

Quiero ser honesto aquí: la arquitectura tradicional no es mala. WordPress alimenta más del 40% de la web por buenas razones -- es madura, bien entendida y tiene un ecosistema enorme.

El enfoque Jamstack gana cuando el rendimiento es crítico, cuando necesitas escalar impredeciblemente, o cuando tu equipo de desarrollo quiere trabajar con herramientas frontend modernas.

Ejemplos reales de producción

Déjame compartir algunos ejemplos concretos -- no escenarios hipotéticos, sino arquitecturas de producción reales.

Ejemplo 1: Catálogo de productos de e-commerce

Stack: Next.js + Shopify Storefront API + Sanity (para contenido editorial) + Vercel

Una marca de moda DTC con la que trabajamos tenía ~8,000 páginas de producto. Usando ISR con revalidación de 5 minutos, las páginas de producto se mantenían frescas sin compilaciones completas. El contenido editorial (lookbooks, guías de estilo) vivía en Sanity. Shopify manejaba inventario y pago.

El resultado: el promedio TTFB bajó de 680ms a 35ms después de la migración desde su tema Shopify Liquid.

Ejemplo 2: Sitio de marketing de múltiples marcas

Stack: Astro + Storyblok + Cloudflare Pages

Una empresa SaaS ejecutando cuatro marcas de producto bajo un dominio. Cada marca tenía diseño visual diferente pero compartía componentes de navegación y pie. La arquitectura de isla de Astro significaba que la mayoría de páginas se enviaban con cero JavaScript del lado del cliente. El editor visual de Storyblok permitía al equipo de marketing reorganizar secciones de página sin participación del desarrollador.

Tiempos de compilación para todo el sitio de 400 páginas: ~45 segundos.

Ejemplo 3: Portal de documentación

Stack: Next.js App Router + contenido MDX en Git + Búsqueda de Algolia + Vercel

Una empresa de herramientas para desarrolladores con 2,000+ páginas de documentación. El contenido vivía como archivos MDX en el repositorio -- sin CMS externo necesario. Algolia indexaba contenido en tiempo de compilación para búsqueda instantánea. ISR manejaba las pocas páginas dinámicas (changelog, estado).

El equipo usó despliegues previos de Vercel para que los redactores técnicos revisaran cambios de docs antes de fusionar.

Ejemplo 4: Sitio de noticias/medios

Stack: Next.js + Contentful + CDN Fastly + AWS Lambda

Un editor de medios digitales necesitaba cargas de página subsegundas para SEO y optimización de ingresos por anuncios. Las páginas de noticias de última hora usaban ISR bajo demanda desencadenado por webhooks de Contentful -- los nuevos artículos entraban en línea en menos de 10 segundos después de publicar. Las funciones edge manejaban inserción de anuncios dirigida por geografía.

Su tasa de aprobación de métricas principales web fue del 45% al 92% después de la migración.

Cuándo Jamstack es la opción incorrecta

Creo en ser directo sobre las limitaciones. Jamstack no es ideal para:

  • Aplicaciones altamente interactivas en tiempo real (piensa Google Docs, Figma) -- estas necesitan conexiones persistentes del servidor, no páginas pre-renderizadas.
  • Sitios donde cada página es única por usuario -- si nada puede ser cacheado, pierdes la ventaja del CDN. Aunque SSR de edge ayuda a cerrar esta brecha.
  • Equipos sin capacidad de ingeniería de frontend -- la DX es excelente si tienes desarrolladores cómodos con React/Vue/Svelte e integración de API. Un especialista en marketing en solitario a menudo está mejor servido por Squarespace o WordPress.
  • Prototipado rápido donde la arquitectura aún no importa -- si estás validando una idea la próxima semana, no sobre-ingenierices el stack.

Si no estás seguro de si Jamstack se ajusta a tu proyecto, nos encantaría hablar sobre las compensaciones. Ponte en contacto con nosotros o revisa nuestro presupuesto para proyectos web sin cabeza.

Preguntas frecuentes

¿Es Jamstack solo para sitios estáticos?

No -- y esta es la idea errónea más común. Aunque Jamstack se originó con sitios estáticos, el Jamstack moderno incluye ISR, funciones edge y renderizado del lado del servidor en el edge. Puedes construir experiencias completamente dinámicas y personalizadas.

La parte "estática" se refiere a cómo las páginas se entregan (archivos pre-construidos desde un CDN), no a lo que pueden hacer.

¿Cómo maneja Jamstack contenido dinámico como comentarios de usuarios o carritos de compras?

A través de JavaScript del lado del cliente y APIs. Los comentarios podrían usar un servicio como Disqus o un endpoint de API personalizado. Los carritos de compras típicamente usan estado del lado del cliente sincronizado con una API de e-commerce (Shopify, Snipcart, Medusa).

La página estática carga instantáneamente, luego JavaScript hidrata las partes dinámicas.

¿Cuál es la diferencia entre un CMS sin cabeza y un CMS tradicional?

Un CMS tradicional (como WordPress en su modo predeterminado) gestiona contenido y renderiza el frontend. Un CMS sin cabeza solo gestiona contenido y lo entrega a través de API.

Tu frontend -- construido con Next.js, Astro, o cualquier framework -- consume esa API. Este desacoplamiento te permite usar el mismo contenido en sitios web, aplicaciones móviles y otros canales.

¿Cuánto cuesta alojar un sitio Jamstack?

Significativamente menos que el alojamiento tradicional para la mayoría de sitios. Vercel, Netlify y Cloudflare Pages todos tienen niveles gratuitos generosos que manejan tráfico moderado.

Incluso a escala, estás pagando por ancho de banda de CDN (barato) en lugar de computación del servidor (caro). Un sitio que recibe 500K visitantes mensuales podría costar $0-$20/mes en el plan Pro de Vercel. El mismo tráfico en un host WordPress gestionado podría ejecutarse $50-$300/mes.

¿Funciona Jamstack para SEO?

Excepcionalmente bien. Los motores de búsqueda reciben HTML completamente renderizado en la primera solicitud -- sin esperar a que se ejecute JavaScript. Las mejoras de velocidad de página impactan directamente los puntajes de métricas principales web.

Las meta etiquetas pre-renderizadas y datos estructurados están integrados en el HTML en tiempo de compilación. Muchos profesionales de SEO específicamente recomiendan arquitecturas Jamstack para sitios de contenido.

¿Qué sucede si mi CMS sin cabeza se cae?

Esto es realmente una de las fortalezas de Jamstack. Porque tu sitio es pre-renderizado y servido desde un CDN, permanece en línea incluso si tu CMS está temporalmente no disponible.

Los editores no pueden publicar contenido nuevo durante la interrupción, pero tu sitio continúa sirviendo la última versión construida a todos los visitantes. Compara esto con WordPress tradicional, donde una interrupción de base de datos significa que todo tu sitio se cae.

¿Cuánto tiempo tarda migrar un sitio WordPress a Jamstack?

Depende de la complejidad. Un sitio de marketing directo con 50-100 páginas podría tomar 4-8 semanas. Un sitio de contenido grande con miles de publicaciones, plugins personalizados y flujos de trabajo complejos podría tomar 3-6 meses.

La migración de contenido en sí (WordPress a CMS sin cabeza) suele ser la parte más fácil -- herramientas como wp-graphql e importadores específicos de CMS manejan el trabajo pesado. La reconstrucción de frontend es donde va la mayor parte del tiempo.

¿Pueden las personas no técnicas gestionar contenido en un sitio Jamstack?

Absolutamente. Ese es el punto completo de un CMS sin cabeza.

Plataformas como Storyblok ofrecen edición visual de arrastrar y soltar. Sanity's Studio proporciona una interfaz de edición personalizable. Desde la perspectiva de un editor, la experiencia a menudo es mejor que WordPress porque el CMS está construido específicamente para gestión de contenido sin el desorden de configuraciones de tema, configuraciones de plugin y gestión de servidor.