Decidí ayudar a quienes están ocupados eligiendo SSG. Un colega mío ha compilado una lista de preguntas para ayudarlo a encontrar un generador de sitios estáticos. Se adjunta a esta lista un resumen de los SSG populares. Solo carece de una evaluación de cómo funcionan los diferentes GSS en acción.
Lo que todos los GSS tienen en común es cómo funcionan. Es decir, aceptan algunos datos como entrada y los pasan a través del motor de plantillas. La salida son archivos HTML. Este proceso se conoce comúnmente como construcción del proyecto.
Para obtener datos de rendimiento comparables para diferentes SSG, hay muchos matices a considerar. Debe prestar atención a las características de los proyectos, a los factores que ralentizan o aceleran el montaje. Aquí es donde comienza nuestra exploración del desempeño de los SSG populares.
Dicho esto, nuestro objetivo no es solo encontrar el SSG más rápido. La reputación de ser "el más rápido" ya se ha apoderado de Hugo . Quiero decir, el sitio web del proyecto dice que Hugo es el marco de construcción de sitios web más rápido del mundo. Y eso significa - la forma en que es.
Este artículo compara el rendimiento de los SSG populares. Es decir, estamos hablando del tiempo de construcción de los proyectos. Pero lo más importante aquí es un análisis profundo de por qué ciertas herramientas muestran ciertos resultados. Será un error, independientemente del momento del montaje del proyecto, elegir el "SSG más rápido" o abandonar inmediatamente el "más lento". Hablemos de por qué es así.
Pruebas
El proceso de prueba de SSG está diseñado para comenzar investigando algunos proyectos populares y explorando el procesamiento de formatos de datos simples. Esta es la base sobre la cual construir un estudio de generadores de sitios más estáticos y expandir este estudio con formatos de datos más complejos. El estudio ahora incluye seis SSG populares:
Al estudiar cada uno de ellos, se aplica el siguiente enfoque y las siguientes condiciones:
- La fuente de datos para cada prueba (proceso de construcción del proyecto) son archivos de Markdown que contienen un encabezado generado aleatoriamente (lo que se denomina "material preliminar") y un cuerpo del documento (tres párrafos de texto).
- No hay imágenes en los documentos.
- Las pruebas se ejecutan varias veces en la misma computadora. Esto hace que los valores específicos obtenidos de la prueba sean menos importantes que la comparación de resultados relativos.
- La salida se presenta en texto sin formato en una página HTML. El procesamiento de datos se realiza utilizando la configuración estándar, que se describe en las guías de introducción para cada uno de los SSG examinados.
- « ». Markdown-.
Estas pruebas se consideran pruebas de rendimiento (evaluaciones comparativas). Utilizan archivos Markdown simples, lo que da como resultado un código HTML sin estilo.
En otras palabras, el resultado es, desde un punto de vista técnico, un sitio web que podría implementarse en producción. Pero esta no es una implementación de un escenario SSG real. En lugar de intentar reproducir una situación real, queremos obtener una línea de base para comparar los marcos en estudio. Al usar las herramientas anteriores para crear sitios reales, SSG trabajará con datos más complejos y con diferentes configuraciones, lo que afectará el tiempo de construcción de los proyectos (esto generalmente ralentiza la construcción).
Por ejemplo, una de las diferencias entre nuestros casos de uso de SSG de prueba y del mundo real es el hecho de que estamos investigando procesos de compilación en frío. En realidad, las cosas son un poco diferentes. Por ejemplo, si el proyecto incluye 10,000 archivos Markdown que son la fuente de datos para SSG, y si se usa Gatsby para construir el proyecto, entonces se usará la caché de Gatsby. Y esto reduce enormemente (casi a la mitad) el tiempo de montaje.
Lo mismo puede decirse de las compilaciones incrementales. Esto tiene que ver con comparar compilaciones en caliente y en frío, en el sentido de que solo se procesan los archivos modificados cuando se realiza una compilación incremental. No estamos examinando compilaciones incrementales en estas pruebas. En el futuro, es muy posible que este estudio se amplíe en esta dirección.
SSG de diferentes niveles
Antes de comenzar a explorar, veamos el hecho de que en realidad hay dos sabores de SSG, dos niveles de generadores de sitios estáticos. Llamémoslos "básicos" y "avanzados".
- Los generadores básicos (aunque no son tan simples) son, de hecho, herramientas de línea de comandos (Command-Line Interface, CLI) que toman datos y generan HTML. A menudo, sus capacidades se prestan a la expansión en la dirección del procesamiento de recursos adicionales (no estamos haciendo esto aquí).
- Los generadores avanzados ofrecen algunas características adicionales además de crear sitios estáticos. Estos son, por ejemplo, la representación de páginas del lado del servidor, las funciones sin servidor, la integración con varios marcos web. Por lo general, inmediatamente después de la instalación, se configuran para brindar al usuario capacidades más dinámicas que los generadores base.
Para esta prueba, seleccioné especialmente tres generadores de cada nivel. Los básicos incluyen Eleventy, Hugo y Jekyll. Los otros tres generadores se basan en marcos frontend. Estos SSG incluyen varias herramientas adicionales. 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 |
Hipótesis y supuestos
Propongo aplicar el método científico en nuestra investigación . La ciencia es muy emocionante (y puede ser muy beneficiosa).
Mi hipótesis es que si SSG es avanzado, significa que funcionará más lento que los generadores básicos. Estoy seguro de que esto se verá reflejado en los resultados del estudio, ya que hay más mecanismos involucrados en el trabajo de los GSS avanzados que en el trabajo de los básicos. Como resultado, es muy probable que, según la investigación, los generadores básicos y avanzados se puedan dividir claramente en dos grupos. Al mismo tiempo, los generadores básicos funcionarán más rápido que los avanzados.
▍Basic SSG: alta velocidad y dependencia lineal de la velocidad de construcción en el número de archivos
Hugo y Eleventy procesarán pequeños conjuntos de datos muy rápidamente. Son procesos (relativamente) simples creados por Go y Node.js respectivamente. Los resultados de sus pruebas deben reflejar esto. Si bien ambos SSG se ralentizarán a medida que aumente la cantidad de archivos, espero que sigan siendo los líderes. Al mismo tiempo, es posible que Once, con un aumento en la carga, demuestre la dinámica de cambio en el tiempo de montaje, que se desvía más de lo lineal que Hugo. Esto podría ser una simple consecuencia del hecho de que el rendimiento de Go suele ser mejor que el de Node.js.
▍SG avanzado: inicio de construcción lento y posterior aumento de velocidad, pero no demasiado
Los SSG avanzados, o aquellos vinculados a algún tipo de marco web, comenzarán lentamente, se notará. Sospecho que en una prueba de un solo archivo, la diferencia entre los marcos básicos y avanzados será bastante significativa. Para los básicos, serán unos milisegundos, y para los avanzados, para Gatsby, Next y Nuxt, serán segundos.
Los SSG basados en frameworks web usan webpack, que agrega carga adicional al sistema a medida que se ejecutan. Al mismo tiempo, esta carga adicional no depende de la cantidad de datos procesados. Pero nosotros mismos estamos de acuerdo con esto, utilizando herramientas más avanzadas (hablaremos más sobre esto a continuación).
Y cuando se trata de procesar miles de archivos, sospecho que la brecha entre los grupos generadores básicos y avanzados se reducirá. Sin embargo, al mismo tiempo, los SSG avanzados seguirán estando muy por detrás de los básicos.
Si hablamos de un grupo de generadores avanzados, entonces espero que el más rápido de ellos sea Gatsby. Solo lo creo porque no tiene un componente de representación del lado del servidor que pueda ralentizar las cosas. Pero esto es solo un reflejo de mis sentimientos internos. Quizás en Next y Nuxt la renderización del servidor está optimizada a un nivel tal que si no se usa, entonces no afecta el tiempo de construcción de los proyectos de ninguna manera. Sospecho que Nuxt será más rápido que Next. Hago esta suposición basándome en el hecho de que Vue es "más ligero" que React.
▍Jekyll es un representante inusual de SSG básico
La plataforma Ruby es conocida por su bajo rendimiento. Se optimiza con el tiempo, se vuelve más rápido, pero no espero que sea tan rápido como Node.js, y mucho menos Go. Pero, al mismo tiempo, Jekyll no soporta la carga adicional asociada con el marco web.
Creo que al comienzo de la prueba, al procesar una pequeña cantidad de archivos, Jekyll mostrará alta velocidad. Posiblemente tan alto como los once. Pero a medida que examinamos el procesamiento de miles de archivos, el rendimiento se verá afectado. Me parece que hay otras razones por las que Jekyll puede ser el más lento de los seis SSG que investigamos. Para probar esto, examinamos el rendimiento de nuestros generadores en conjuntos de archivos de diferentes tamaños, hasta 100.000.
A continuación se muestra un gráfico que muestra mis suposiciones.
Supuestos relacionados con la dependencia de la velocidad de trabajo de varios SSG
El eje Y representa el tiempo de construcción de los proyectos, el eje X representa el número de archivos. A continuación se muestra en verde, Nuxt en amarillo, Gatsby en rosa, Jekyll en azul, Eleventy en turquesa, Hugo en naranja. Todas las líneas reflejan el aumento en el tiempo de construcción del proyecto a medida que aumenta el número de archivos. Al mismo tiempo, la línea correspondiente a Jekyll tiene el mayor ángulo de inclinación.
resultados
Aquí está el código que produce los resultados que ahora discutiré. También hice una página que recopila los resultados de las pruebas relativas.
Después de muchos intentos de encontrar las condiciones para ejecutar las pruebas, me decidí por 10 ejecuciones de cada prueba utilizando tres conjuntos de datos diferentes.
- Conjunto de datos base (Base). Este es un archivo. Su procesamiento le permite estimar el tiempo que SSG necesita para prepararse para trabajar. Este es el tiempo que llevará iniciar SSG. Se puede llamar básico, independientemente del número de archivos que se procesen.
- Un conjunto de "sitios pequeños" (sitios pequeños). Examina el ensamblaje de conjuntos de archivos de 1 a 1024. Cada nueva pasada de prueba se lleva a cabo con un número duplicado de archivos (para que sea más fácil averiguar si el tiempo de procesamiento de los archivos crece linealmente con su número).
- Un conjunto de "sitios grandes" (sitios grandes). Aquí el número de archivos cambia de 1000 a 64000, duplicándose con cada nueva ejecución de prueba. Inicialmente, quería llegar a 128.000 archivos, pero encontré cuellos de botella en algunos marcos. Como resultado, resultó que 64.000 archivos son suficientes para averiguar cómo se comportan los SSG estudiados al procesar sitios a gran escala.
Estos son los resultados que obtuve.
Conjunto de datos base
Conjunto de datos de sitios pequeños
Conjunto de datos de sitios grandes
Resumiendo los resultados
Algunos de los resultados me sorprendieron, pero otros resultaron ser exactamente como esperaba. A continuación, presentamos algunos hallazgos generales:
- Como era de esperar, el SSG más rápido fue Hugo. Funciona muy bien en conjuntos de archivos de todos los tamaños. Pero no esperaba que otros generadores al menos se acercaran a él, incluso en el conjunto de datos Base (no esperaba que mostrara un comportamiento lineal, pero más sobre eso a continuación).
- Ambos SSG, básico y avanzado, son bastante distintos en los gráficos que muestran el procesamiento de archivos del conjunto de sitios pequeños. Esto era de esperarse. Sin embargo, fue inesperado que Next sea más rápido que Jekyll en un conjunto de 32000 archivos y que omita tanto a Jekyll como a Eleventy en 64000 archivos. Además, sorprendentemente, Jekyll es 64.000 archivos más rápido que Eleventy.
- SSG . Next, , , . Hugo , — - .
- , Gatsby , , . , .
- , , , . , , Hugo 170 , Gatsby. 64000 Hugo 25 . , Hugo, SSG, . , - .
¿Qúe significa todo esto?
Cuando compartí los resultados que obtuve con los creadores de estos SSG, y con quienes los apoyan, recibí de ellos, sin entrar en detalles, los mismos mensajes. Si estos mensajes se reducen a una especie de mensaje "promedio", se obtiene lo siguiente: Los
generadores que dedican más tiempo a construir un proyecto funcionan de esta manera porque tienen que resolver más problemas. Ofrecen a los desarrolladores más opciones, mientras que las herramientas más rápidas (es decir, "básicas") se ocupan principalmente de convertir plantillas a archivos HTML.
Estoy de acuerdo con eso.
Resumiendo todo, resulta que escalar los sitios Jamstack es muy difícil.
Las dificultades a las que se enfrentará un desarrollador cuyo proyecto está creciendo y desarrollándose dependen de las características de cada proyecto específico. No hay datos que respalden esto. Sí, no pueden estar aquí, ya que cada proyecto es, de una forma u otra, único.
Pero todo se reduce a las preferencias personales del desarrollador, a ese compromiso entre el momento de construir el sitio y la conveniencia de trabajar con SSG, que está listo para hacer.
Por ejemplo, si va a crear un sitio grande lleno de imágenes y planea usar Gatsby, debe estar preparado para el hecho de que este sitio llevará mucho tiempo construirlo. Pero a cambio, obtienes un enorme ecosistema de complementos y la base para construir un sitio web robusto, bien organizado y basado en componentes. Si usa Jekyll en el mismo proyecto, tendrá que esforzarse mucho más para mantener el proyecto en un estado bien organizado, a fin de garantizar la efectividad del trabajo en el proyecto. Y el montaje del sitio será más rápido.
En el trabajo, suelo crear sitios con Gatsby(o usando Next, dependiendo del nivel requerido de interactividad dinámica del proyecto). Trabajamos con Gatsby para crear un marco en el que construir rápidamente sitios web altamente personalizables que contienen muchas imágenes basadas en una gran cantidad de componentes. A medida que estos sitios crecieron en tamaño, tomó más y más tiempo construirlos y comenzamos a ser creativos. Se trata de implementar micro interfaces , procesamiento de imágenes fuera del sistema de compilación principal, vistas previas de contenido y muchas otras optimizaciones.
En proyectos propiosYo suelo usar Eleventy. Por lo general, solo escribo el código de tales proyectos, mis necesidades son bastante modestas (me percibo como mi propio buen cliente). Tengo un mejor control sobre los resultados de la construcción, lo que me ayuda a lograr una alta productividad del lado del cliente. Y esto es importante para mi.
Como resultado, la elección de SSG no es solo una elección entre "rápido" y "lento". Es la selección de la herramienta que más se adapta a un proyecto en particular, uno cuyos resultados justifiquen el tiempo que pasa esperando estos resultados.
Salir
De hecho, lo que he dicho es solo el comienzo. El objetivo de mi trabajo es crear una base a partir de la cual todos podamos medir los tiempos de construcción relativos de los proyectos producidos por el popular SSG.
¿Ha encontrado alguna inconsistencia en mi proceso de prueba propuesto para generadores de sitios estáticos? ¿Cómo mejorar el procedimiento de prueba? ¿Cómo acercar los juicios a la realidad? ¿Necesito transferir el procesamiento de imágenes a una computadora separada? Invito a todos los que se preocupan por SSG a unirse a mí y ayudarme a encontrar respuestas a estas y muchas otras preguntas.
¿Qué generadores de sitios estáticos usas?
