Hay tantos generadores de sitios estáticos (SSG). Es abrumador intentar decidir por dónde empezar. Si bien una gran cantidad de artículos útiles pueden ayudar a recorrer las opciones (populares), no facilitan mágicamente la decisión.
He estado en una búsqueda para ayudar a que esa decisión sea más fácil. Un colega construyó una hoja de trucos de evaluación del generador de sitios estáticos. Proporciona una instantánea realmente agradable a través de numerosas opciones populares de SSG. Lo que falta es cómo se comportan realmente en acción.
Una característica que todos los generadores de sitios estáticos tienen en común es que toma datos de entrada, los ejecuta a través de un motor de plantillas y genera archivos HTML. Normalmente nos referimos a este proceso como The Build.
Se necesitan demasiados matices, contexto y variabilidad para comparar cómo funcionan varios SSG durante el proceso de compilación para mostrarlos en una hoja de cálculo, y por lo tanto, comienza nuestra prueba para comparar los tiempos de compilación con los generadores de sitios estáticos populares.
Esto no es solo para determinar qué SSG es más rápido. Hugo ya tiene esa reputación. Quiero decir, lo dicen en su sitio web, el marco más rápido del mundo para crear sitios web, ¡así que debe ser cierto!
Esta es una comparación en profundidad de los tiempos de compilación en varios SSG populares y, lo que es más importante, para analizar por qué esos tiempos de compilación tienen el aspecto que tienen. Elegir a ciegas el más rápido o desacreditar al más lento sería un error. Averigüemos por qué.
Los exámenes
El proceso de prueba está diseñado para comenzar de manera simple, con solo unos pocos SSG populares y un formato de datos simple. Una base sobre la cual expandirse a más SSG y datos más matizados. Por hoy, la prueba incluye seis opciones populares de SSG:
- Once
- Gatsby
- Hugo
- Jekyll
- próximo
- Nuxt
Cada prueba utilizó el siguiente enfoque y condiciones:
- La fuente de datos para cada compilación son archivos Markdown con un título generado aleatoriamente (como portada) y un cuerpo (que contiene tres párrafos de contenido).
- El contenido no contiene imágenes.
- Las pruebas se ejecutan en serie en una sola máquina, lo que hace que los valores reales sean menos relevantes que la comparación relativa entre el lote.
- El resultado es texto sin formato en una página HTML, ejecutado a través del iniciador predeterminado, siguiendo la guía respectiva de cada SSG para comenzar.
- Cada prueba es una ejecución en frío. Los cachés se borran y los archivos de Markdown se regeneran para cada prueba.
Estas pruebas se consideran pruebas de referencia. Están usando archivos Markdown básicos y generando HTML sin estilo en la salida integrada.
En otras palabras, la salida es técnicamente un sitio web que podría implementarse en producción, aunque en realidad no es un escenario del mundo real. En cambio, esto proporciona una comparación de referencia entre estos marcos. Las elecciones que haga como desarrollador utilizando uno de estos marcos ajustarán los tiempos de compilación de varias maneras (generalmente ralentizándolo).
Por ejemplo, una forma en la que esto no representa el mundo real es que estamos probando compilaciones en frío. En el mundo real, si tiene 10,000 archivos Markdown como fuente de datos y está usando Gatsby, va a hacer uso de la caché de Gatsby, lo que reducirá en gran medida los tiempos de compilación (hasta la mitad).
Lo mismo puede decirse de las compilaciones incrementales, que están relacionadas con ejecuciones en caliente o en frío, ya que solo compilan el archivo que cambió. No estamos probando el enfoque incremental en estas pruebas (en este momento).
Los dos niveles de generadores de sitios estáticos
Antes de hacer eso, consideremos primero que en realidad hay dos niveles de generadores de sitios estáticos. Llamémoslos básicos y avanzados.
- Los generadores básicos (que no son básicos bajo el capó) son esencialmente una interfaz de línea de comandos (CLI) que toma datos y genera HTML y, a menudo, puede extenderse para procesar activos (lo que no estamos haciendo aquí).
- Los generadores avanzados ofrecen algo además de generar un sitio estático, como la representación del lado del servidor, las funciones sin servidor y la integración del marco. Suelen configurarse para ser más dinámicos desde el primer momento.
Elegí intencionalmente tres de cada tipo de generador en esta prueba. En el cubo básico caerían Eleventy, Hugo y Jekyll. Los otros tres se basan en un marco frontal y se envían con varias cantidades de herramientas. Gatsby y Next se basan en React, mientras que Nuxt se basa en Vue.
| Generadores básicos | Generadores avanzados |
|---|---|
| Once | Gatsby |
| Hugo | próximo |
| Jekyll | Nuxt |
Mi hipotesis
¡Apliquemos el método científico a este enfoque porque la ciencia es divertida (y útil)!
Mi hipótesis es que si un SSG es avanzado, funcionará más lento que un SSG básico. Creo que los resultados reflejarán eso porque los SSG avanzados tienen más gastos generales que los SSG básicos. Por lo tanto, es probable que veamos ambos grupos de generadores, básico y avanzado, agrupados en los resultados con generadores básicos moviéndose significativamente más rápido.
Permítanme ampliar un poco esa hipótesis.
Lineal (ish) y rápido
Hugo y Eleventy volarán con conjuntos de datos más pequeños. Son procesos (relativamente) simples en Go y Node.js, respectivamente, y su salida de compilación lo reflejará. Si bien ambos SSG se ralentizarán a medida que aumente la cantidad de archivos, espero que permanezcan en la parte superior de la clase, aunque Eleventy puede ser un poco menos lineal a escala, simplemente porque Go tiende a ser más eficiente que Node.
Lento, luego rápido, pero aún lento
Los SSG avanzados o vinculados al marco de trabajo comenzarán y parecerán lentos. Sospecho que una prueba de un solo archivo contiene una diferencia significativa: milisegundos para las básicas, en comparación con varios segundos para Gatsby, Next y Nuxt.
Cada uno de los SSG basados en marcos se crea con un paquete web, lo que conlleva una gran cantidad de gastos generales, independientemente de la cantidad de contenido que estén procesando. Ese es el equipaje al que nos inscribimos al usar esas herramientas (más sobre esto más adelante).
Pero, a medida que agreguemos miles de archivos, sospecho que veremos que se cierra la brecha entre los depósitos, aunque el grupo SSG avanzado se quedará más atrás en una cantidad significativa.
En el grupo de SSG avanzado, espero que Gatsby sea el más rápido, solo porque no tiene un componente del lado del servidor del que preocuparse, pero eso es solo una intuición. Next y Nuxt pueden haber optimizado esto hasta el punto en que, si no estamos usando esa función, no afectará los tiempos de compilación. Y sospecho que Nuxt superará a Next, solo porque hay un poco menos de sobrecarga con Vue, en comparación con React.
Jekyll: el niño extraño
Ruby es infamemente lento. Se ha vuelto más eficiente con el tiempo, pero no espero que escale con Node, y ciertamente no con Go. Y, sin embargo, al mismo tiempo, no tiene el bagaje de un marco.
Al principio, creo que veremos a Jekyll como bastante veloz, tal vez incluso indistinguible de Eleventy. Pero a medida que lleguemos a los miles de archivos, el rendimiento se verá afectado. Mi intuición es que puede haber un punto en el que Jekyll se convierta en el más lento de los seis. Llegaremos hasta la marca de 100.000 para estar seguro.
¡Ya tenemos los resultados!
El código que impulsa estas pruebas está en GitHub. También hay un sitio que muestra los resultados relativos.
Después de muchas iteraciones de construir una base sobre la cual se pudieran ejecutar estas pruebas, terminé con una serie de 10 ejecuciones en tres conjuntos de datos diferentes:
- Base: Un solo archivo, para comparar los tiempos de construcción base
- Pequeños sitios: De 1 a 1024 archivos, duplicando cada vez (para que sea más fácil determinar si los SSG escalaron linealmente)
- Sitios grandes: De 1.000 a 64.000 archivos, el doble en cada ejecución. Originalmente quería subir a 128,000 archivos, pero encontré algunos cuellos de botella con algunos de los marcos. 64,000 terminaron siendo suficientes para producir una idea de cómo los jugadores escalarían con sitios aún más grandes.
Haga clic o toque las imágenes para verlas más grandes.
Resumiendo los resultados
Algunos resultados me sorprendieron, mientras que se esperaban otros. Aquí están los puntos de alto nivel:
- Como se esperaba, Hugo fue el mas rapido, independientemente del tamaño. Lo que no esperaba es que ni siquiera estuviera cerca de ningún otro generador, incluso en las construcciones base.
- Los grupos básicos y avanzados de SSG son bastante obvios cuando se observan los resultados para sitios pequeños. Eso era lo esperado, pero fue sorprendente ver Next y Eleventy acercándose a 64.000 archivos. También es sorprendente que Jekyll rindiera más rápido que Once en cada carrera.
- Pensé que Gatsby sería el más rápido entre los marcos avanzados, y sospeché que sería el que se acercaría más a lo básico. Pero Gatsby resultó ser el más lento, produciendo la curva más dramática.
- Si bien no se mencionó específicamente en la hipótesis, la escala de diferencias fue mayor de lo que hubiera imaginado. En una fila, Hugo era aproximadamente 250 veces más rápido que Gatsby. Pero con 64.000 archivos, estaba más cerca, unas 40 veces más rápido. Eso significa que, aunque Hugo sigue siendo el más rápido (significativamente), sus tiempos están más cerca de los de otros generadores a medida que aumenta el tamaño de los sitios.
Que significa todo esto?
Cuando compartí mis resultados con los creadores y mantenedores de estos SSG, generalmente recibí el mismo mensaje. Parafrasear:
Los generadores que necesitan más tiempo para construir lo hacen porque están haciendo más. Están aportando más a la mesa para que los desarrolladores trabajen, mientras que los sitios más rápidos (es decir, las herramientas “básicas”) centran sus esfuerzos en gran medida en convertir plantillas en archivos HTML.
Estoy de acuerdo.
En resumen: escalar sitios Jamstack es difícil.
Los desafíos que se le presentarán, Desarrollador, a medida que escale un sitio variarán según el sitio que esté tratando de construir. Esos datos no se capturan aquí porque no pueden serlo: cada proyecto es único de alguna manera.
Lo que realmente se reduce es su nivel de tolerancia a la espera a cambio de la experiencia del desarrollador.
Por ejemplo, si vas a construir un sitio grande y con muchas imágenes con Gatsby, lo pagarás con tiempos de compilación, pero también tienes una inmensa red de complementos y una base sobre la cual construir. un sitio web sólido, organizado y basado en componentes. Haga lo mismo con Jekyll, y será necesario mucho más esfuerzo para mantenerse organizado y eficiente durante todo el proceso, aunque sus compilaciones pueden ejecutarse más rápido.
En el trabajo, normalmente construyo sitios con Gatsby (o Next, según el nivel de interactividad dinámica requerido). Hemos trabajado con el marco de trabajo de Gatsby para construir un núcleo en el que podamos construir rápidamente sitios web ricos en imágenes y altamente personalizados, repletos de una gran cantidad de componentes. Nuestras compilaciones se vuelven más lentas a medida que los sitios escalan, pero ahí es cuando nos volvemos creativos al implementar micro front-end, descargar el procesamiento de imágenes, implementar vistas previas de contenido, junto con muchas otras optimizaciones.
Por otro lado, tiendo a preferir trabajar con Eleventy. Por lo general, soy solo yo escribiendo código, y mis necesidades son mucho más simples. (Me gusta pensar en mí mismo como un buen cliente para mí). Siento que tengo más control sobre los archivos de salida, lo que me facilita obtener 💯s en el rendimiento del lado del cliente, y eso es importante para mí.
Al final, no se trata solo de lo que es rápido o lento. Se trata de lo que funciona mejor para usted y cuánto tiempo está dispuesto a esperar.
Terminando
¡Este es solo el comienzo! El objetivo de este esfuerzo fue crear una base sobre la cual podamos, juntos, comparar tiempos de construcción relativos en generadores de sitios estáticos populares.
¿Qué ideas tienes? ¿Qué agujeros puedes hacer en el proceso? ¿Qué podemos hacer para endurecer estas pruebas? ¿Cómo podemos hacer que se parezcan más a escenarios del mundo real? ¿Deberíamos descargar el procesamiento a una máquina dedicada?
Estas son las preguntas que me encantaría que me ayudaras a responder. Hablemos de eso.