Medimos el tiempo de build de proyectos Gatsby en los planes de pago de las plataformas de hosting estático más populares
Jamstack está creciendo a toda velocidad. Casi cada mes aparecen nuevas herramientas y frameworks, y eso le está dando una segunda vida a la generación de sitios estáticos.
Nuestro framework de referencia para crear webs siempre ha sido Gatsby. Hace tres años, cuando empezamos a usarlo, no había muchas opciones para desplegar un sitio: Netlify o Vercel. Hoy el panorama es otro: también tienes Gatsby Cloud, Cloudflare Pages, AWS Amplify, e incluso puedes montar herramientas de build parecidas en tu propia infraestructura con proyectos como Waypoint.
Un sitio generado de forma estática tiene un inconveniente importante: el tiempo de build. Si tienes un blog pequeño o una web de una sola página, cualquier hosting o framework te dará resultados muy parecidos y no notarás la diferencia. Pero la cosa se complica cuando pasas de 100 páginas. A esa escala, la plataforma puede marcar una diferencia enorme en el rendimiento del build para desarrolladores, diseñadores y equipos de marketing, porque nadie quiere esperar horas para ver los cambios publicados.
Así que decidí hacer pruebas en las plataformas más populares con sus planes de pago.
Índice
Plataformas
Netlify
Plan Pro: 20 $/mes por miembro.
Vercel
Plan Pro: 20 $/mes por miembro.
Gatsby Cloud
Plan Pro: 50 $/mes con 2 plazas incluidas y 20 $ por cada miembro adicional.
Cloudflare Pages
Plan Pro: 20 $/mes, plazas ilimitadas.
AWS Amplify
Los primeros 1000 minutos son gratis; después, 0,01 $ por minuto de build.
Self-hosted
50 $/mes: un servidor propio con Drone CI y estas especificaciones: AMD Ryzen 5 3600 Hexa-Core "Matisse" (Zen2), 64 GB de RAM y SSD NVMe de 512 GB en RAID. Plazas ilimitadas. Despliegue en Netlify con netlify-cli.
Casos de prueba
Empecé midiendo el tiempo de build con la cache vacía. Aunque normalmente tendrás una cache que funciona bien y reduce el tiempo de build, hay casos en los que toca vaciarla a mano, o Gatsby la vacía por ti cuando cambias gatsby-node.js, gatsby-config.js o package.json.
Hice cinco ejecuciones por prueba y anoté la media. También usé un cronómetro para comprobar que no hubiera una diferencia significativa entre el aviso real de finalización y la cifra que muestra la interfaz. El cronómetro no pretendía medir con precisión, sino averiguar si las plataformas dicen la verdad y no descuentan del tiempo de build fases como la inicialización del entorno o la publicación.
Web basada en Markdown
Tiempo de build con la cache vacía
La primera prueba fue con una web basada en Markdown. Los resultados me sorprendieron bastante. Gatsby Cloud terminó en dos minutos, ocho veces más rápido que Netlify, que tardó 16. Los tiempos de Gatsby Cloud son muy parecidos a los que obtengo lanzando builds en local con chips Apple M1, lo cual es una locura. Estoy seguro de que hacen algo de magia entre bastidores, como mínimo optimización de imágenes en paralelo.
Vercel fue algo más rápido que Cloudflare Pages: 10:30 frente a 11:23. Subestimé claramente a AWS Amplify: pensaba que lanzarían los builds en instancias EC2 de la capa gratuita, pero usan una máquina con 4 vCPU y 7 GB de memoria (se agradece esa transparencia en la interfaz), así que terminó en 9:47.
La solución self-hosted fue bastante rápida y se quedó muy cerca de Gatsby Cloud en tiempo de build, pero subir los resultados a Netlify se lleva más o menos la mitad de ese tiempo, así que acabó en segundo lugar.
Lo curioso es que Gatsby Cloud pudo completar todo el build en el tiempo que Cloudflare tardó en inicializar el entorno.
Tiempo de build de un Deploy Preview
Aquí empecé a intuir que iba a ser una carrera a muerte, porque los competidores empezaron a mostrar sus problemas y lo distinto que gestionan cada escenario. Para la prueba de Deploy Preview creé una rama a partir de master e hice dos cambios: uno en un archivo jsx y otro en un archivo md.
Netlify (16:16), Cloudflare (11:16) y AWS Amplify (9:14) dieron los peores resultados, y te explico por qué. Netlify tiene un plugin muy útil que conserva la cache entre builds, PERO no funciona si el build dura más de 15 minutos.
Cloudflare Pages no ofrece ninguna opción para conservar la cache entre builds, así que siempre da resultados lentos.
AWS Amplify sí permite conservar la cache, pero ninguna de sus guías oficiales explica cómo hacerlo funcionar. Añadir sin más las carpetas necesarias a su archivo yaml de build no sirve. Después de dedicarle un tiempo razonable a investigarlo, lo dejé, porque estoy bastante seguro de que sus usuarios tampoco se van a meter en ese berenjenal. Sin esa configuración, lo único que se conserva entre builds es node_modules.
Vercel lo hizo muy bien y terminó en 3:32. Me impresionó, porque toda la magia de la cache ocurre entre bastidores y no hace falta instalar plugins adicionales de Gatsby ni en la plataforma ni en el código para que funcione correctamente.
Gatsby Cloud volvió a ganar con 0:49, y la versión self-hosted quedó a solo 25 segundos.
Tiempo de build con la cache caliente
Por tiempo de build con la cache caliente me refiero a un build posterior que se lanza desde la misma rama en la que ya se hizo un build antes. Es lo que ocurre cada vez que vuelves a desplegar una web tras un cambio de contenido o añades commits a tu Pull Request.
Vercel (1:08) y la versión self-hosted (1:06) quedaron muy igualados, pero Gatsby Cloud fue más rápido con 0:27.
Cloudflare Pages, Netlify y AWS Amplify, en cambio, tienen margen de mejora, sin duda.
Web con WordPress headless
Después pasé a probar Gatsby v4 conectado a una web en WordPress. El sitio tiene dos idiomas, un buen puñado de plugins habituales de WP y unas 1000 páginas en total. Aquí es donde la cosa se pone difícil.
Tiempo de build con la cache vacía
Netlify ni siquiera terminó el build: se detuvo a los 22 minutos. Vercel y Cloudflare Pages lo completaron en 24 minutos. Gatsby Cloud fue rápido, pero incluso para él fue duro: 17:47. AWS Amplify fue la mayor sorpresa, con tiempos constantes de unos 15 minutos. El CI self-hosted logró el mejor resultado: 11:30. Probablemente el servidor utilizado estaba más cerca del hosting de WP y tardó menos en descargar los assets iniciales.
Tiempo de build de un Deploy Preview
Creo que podemos dar por suspendidos en esta ronda a Cloudflare, Netlify y AWS Amplify, así que vamos directos a Vercel. Tardó 2:39 en el Deploy Preview, un resultado muy bueno. Gatsby Cloud hizo lo mismo en 1:45, y la versión self-hosted lo resolvió en 1:23.
Tiempo de build con la cache caliente
En Vercel no hubo ninguna diferencia respecto al Deploy Preview. En Gatsby Cloud, en cambio, tardó 20 segundos menos. La versión self-hosted mantuvo sus excelentes resultados. Eso sí, tengo que mencionar que en una ocasión la subida de archivos con Netlify CLI desde la versión self-hosted tardó más de 6 minutos. Decidí no incluirlo porque solo pasó una vez.
Extra
El análisis no estaría completo sin enseñarte una cosa más. Todas las pruebas anteriores se hicieron cambiando un archivo jsx y un post del blog. Pero mira lo que puede hacer Gatsby Cloud cuando haces un cambio de contenido (desde un CMS como WP, Contentful, Prismic, etc.), que es lo más habitual.
Desde el punto de vista de la arquitectura, y a juzgar por los logs de build, da la impresión de que Gatsby Cloud mantiene la última instancia de tu versión de producción en reposo, de modo que puede despertarla rápidamente, saltarse algunos pasos del build y, conociendo el diff de contenido, generar un nuevo build en muy poco tiempo.
¡Pasaron solo 20 segundos desde el cambio en el CMS hasta verlo publicado en producción! Es muy impresionante. Hace unos años, la promesa de Gatsby de reconstruir un sitio en cuestión de segundos sonaba difícil de creer, pero ahora parece que podría ser verdad. ¡Buen trabajo!
Nota: este resultado solo se consigue si cambias un post o una página. Si cambias datos compartidos, como los menús, tendrá que reconstruir todas las páginas y al final tardará unos 50 segundos.
Ganadores
Gatsby Cloud ganó la carrera con el mejor tiempo de build de su categoría. Estoy seguro de que usa las máquinas más potentes de todas las plataformas y hace algo de magia en segundo plano. Vercel se mostró como un competidor sólido: no brilló en las ejecuciones en frío, pero la cache lo cambia todo. En la práctica, a nadie le preocupa que un build tarde menos de 10 minutos, pero en cuanto se supera ese umbral empiezan las preguntas sobre cómo hacerlo más rápido. Teniendo esto en cuenta, puedo recomendar sin problema tanto Gatsby Cloud como Vercel.
A pesar de todo lo que me gustan los productos de Cloudflare, Pages parece el más flojo de su catálogo. El desarrollo ha sido muy lento y no he notado cambios significativos entre la primera beta y la versión actual. En mi opinión, Cloudflare tiene el plan de precios más asequible y razonable, sin límite de plazas ni de ancho de banda. Así que habrá que seguirle la pista.
AWS Amplify... ¿Qué quieres que te diga? Es AWS. Si te encantan sus servicios y su UX no te parece la peor del mundo, puede seguir siendo una opción. Configuración del build en archivos YAML, ajustes separados para activar los Deploy Previews y los builds de otras ramas, ausencia de políticas Cache-Control de serie... Nada de esto juega a su favor.
Netlify es, supongo, la solución más popular y muy asequible del mercado. Interfaz estupenda y un conjunto de funcionalidades increíble, pero el tiempo de build puede convertirse en un cuello de botella serio si tu sitio crece rápido.
Una alternativa self-hosted es rápida, no tiene límites y cuesta solo 50 $/mes por una máquina muy potente; eso sí, ten en cuenta que probablemente tendrás que dedicarle horas de configuración de vez en cuando.
