Jamstack o WordPress es una decisión de restricciones
El prerenderizado no hace rápido un sitio por sí solo. En el Web Almanac de 2020, Next.js logró buen LCP en el 23 % de las cargas móviles y WordPress en el 25 %. Decide el modelo de edición.
Contenido
- Puntos clave
- Qué es realmente cada arquitectura
- El prerenderizado no garantiza una página rápida
- Quién edita, y con qué frecuencia
- Todo lo que debe ser cierto en tiempo de petición
- El coste está en el mantenimiento, no en el hosting
- Cuatro preguntas que lo resuelven
- Preguntas frecuentes
- Decide primero el modelo de edición
Ninguna de las dos arquitecturas es mejor en abstracto. Jamstack encaja en sitios cuyo contenido cambia con una cadencia previsible y cuyo equipo puede llevar un pipeline de build. WordPress encaja cuando publica gente no técnica a diario y espera ver el cambio ya publicado. Deciden el modelo de edición, la petición y el mantenimiento.
Puntos clave
- El Web Almanac de 2020 encontró más del 42 % de las páginas sobre un CMS. WordPress tenía un 31 % de cuota de uso y un 74,2 % de las páginas con CMS.
- Jamstack se detectó en el 0,84 % de las páginas móviles y el 0,91 % de las de escritorio, frente al 0,34 % y el 0,50 % de 2019.
- El prerenderizado no garantiza velocidad. El buen LCP en móvil llegó al 74 % en Jekyll, pero al 23 % en Next.js y al 18 % en Nuxt.js, frente al 25 % de WordPress.
- WordPress incluye endpoints de contenido de la REST API desde la versión 4.7, de diciembre de 2016, así que usarlo headless es configuración y no migración.
Qué es realmente cada arquitectura
Jamstack construye el front end como páginas y assets estáticos por adelantado y los sirve desde un CDN. Los servicios de backend se consultan por API, en el build o desde el navegador. Las dos ideas de fondo son el prerenderizado y el desacoplamiento.
WordPress genera las páginas desde una base de datos en cada petición, con PHP y normalmente con caché delante. Los dos modelos pueden servir un documento rápido. Se diferencian en cuándo se produce el HTML y en quién puede cambiarlo sin un desarrollador.
El prerenderizado no garantiza una página rápida
Aquí fallan casi todas las comparativas. El Web Almanac de 2020 midió Core Web Vitals por framework, y la dispersión dentro de Jamstack es mayor que la distancia entre Jamstack y WordPress.
En el Web Almanac de 2020, las cargas móviles con buen Largest Contentful Paint fueron el 74 % en Jekyll y el 69 % en Hugo. En Gatsby fueron el 36 %, en Next.js el 23 % y en Nuxt.js el 18 % (HTTP Archive, 9 de diciembre de 2020). WordPress quedó en el 25 % (capítulo de CMS).
Los generadores que apenas envían JavaScript conservan su ventaja. Los que hidratan una aplicación devuelven el coste al cliente, y el umbral de 2,5 segundos de LCP no distingue de dónde viene el retraso. Elegir Jamstack por velocidad y añadir después un runtime pesado devuelve el sitio al punto de partida. Ese patrón también aparece en lo que una empresa compra cuando compra una web.
Quién edita, y con qué frecuencia
Conviene empezar aquí: descarta una opción más rápido que cualquier benchmark. WordPress trae editor, biblioteca de medios, roles, previsualización y publicación programada. Un equipo de marketing lo maneja sin desarrollador, y WordPress 5.0, en diciembre de 2018, convirtió la edición por bloques en el comportamiento por defecto.
Un sitio Jamstack no tiene nada de eso hasta que se añade un CMS headless: otro proveedor, otro juego de cuentas, otra integración que mantener. Si el sitio publica dos veces al año, ese coste da igual. Si publica a diario y el build tarda seis minutos, los editores esperan seis minutos por una errata.
Todo lo que debe ser cierto en tiempo de petición
Prerenderizar significa que el HTML era correcto en el build. El stock, los precios, un panel personalizado y los resultados de búsqueda no lo son, así que se desplazan a llamadas en cliente o a funciones serverless.
Es una contrapartida razonable en unos pocos componentes. Deja de serlo en el contenido principal de las páginas con más tráfico. Ahí se ha reconstruido un sitio dinámico con más piezas móviles que el anterior.
El coste está en el mantenimiento, no en el hosting
El hosting es la línea más barata en los dos modelos y la que más se discute. El coste recurrente está en otra parte.
WordPress acumula una superficie de plugins que hay que parchear, y cada plugin sin parchear es una puerta abierta. Jamstack acumula dependencias de build que se rompen por su cuenta, además de un build que debe seguir funcionando para que alguien publique. Ninguno desaparece en el handover, y por eso cotizamos alcance y no horas.
Cuatro preguntas que lo resuelven
- ¿Con qué frecuencia cambia el contenido y quien lo cambia sabe leer un pull request?
- ¿Alguna página con tráfico alto debe ser correcta en tiempo de petición y no de build?
- ¿Quién responde del pipeline de build dentro de dieciocho meses, con nombre y rol?
- ¿Qué pasa con la publicación si el build falla un viernes a las 18:00?
Responderlas antes del debate de arquitectura suele terminar el debate. Son del mismo tipo que las tres preguntas que deciden si un proyecto fracasa.
WordPress expone endpoints de contenido de la REST API para posts, comentarios, términos, usuarios y ajustes desde la versión 4.7, del 6 de diciembre de 2016 (WordPress.org). Un backend WordPress con front end prerenderizado es una tercera opción válida.
Preguntas frecuentes
¿Jamstack siempre es más rápido que WordPress?
No. En el Web Almanac de 2020, Jekyll alcanzó buen LCP móvil en el 74 % de las cargas y Hugo en el 69 %. Next.js llegó al 23 % y Nuxt.js al 18 %, mientras WordPress alcanzaba el 25 %. El prerenderizado quita tiempo de servidor; un runtime grande en cliente lo devuelve.
¿Se puede usar WordPress en modo headless?
Sí. Los endpoints de contenido de la REST API están en el core desde WordPress 4.7, de diciembre de 2016. Los editores conservan su interfaz y el front end se construye aparte. La contrapartida son dos sistemas que operar.
¿Cuándo es Jamstack una mala elección?
Con publicación diaria por editores no técnicos, builds largos y páginas que deben ser correctas en tiempo de petición. Cualquiera de las tres por separado es llevadera. Juntas convierten el pipeline en un cuello de botella entre marketing y su web.
¿Qué parte de la web usa cada modelo?
El Web Almanac de 2020 encontró más del 42 % de las páginas sobre algún CMS, con WordPress en un 31 %. Jamstack se detectó en el 0,84 % de las móviles, frente al 0,34 % de 2019. La distancia es grande; el crecimiento, no.
Decide primero el modelo de edición
Escribe quién publica, con qué frecuencia y qué tiene que ser cierto en tiempo de petición. Después elige la arquitectura que encaje con esas tres respuestas. Dentro de doce meses la prueba honesta será si alguien de fuera de desarrollo publicó sin pedir ayuda. La segunda, si el móvil sigue cumpliendo los umbrales de Core Web Vitals en el percentil 75.
