Decidi ajudar aqueles que estão ocupados escolhendo o SSG. Um colega meu fez uma lista de perguntas para ajudá-lo a encontrar um gerador de site estático. Anexado a esta lista está um resumo dos SSGs populares. Falta apenas uma avaliação de como os diferentes SSGs atuam em ação.

O que todos os SSGs têm em comum é como funcionam. Ou seja, eles aceitam alguns dados como entrada e os passam pelo mecanismo de modelo. A saída são arquivos HTML. Este processo é comumente referido como construção do projeto.
Para obter dados de desempenho comparáveis para SSGs diferentes, há muitas nuances a serem consideradas. É preciso estar atento às características dos projetos, aos fatores que retardam ou aceleram a montagem. É aqui que começa nossa exploração do desempenho de SSGs populares.
Dito isso, nosso objetivo não é apenas encontrar o SSG mais rápido. A reputação de "o mais rápido" já se apoderou de Hugo . Quer dizer, o site do projeto diz que Hugo é o framework de construção de sites mais rápido do mundo. E isso significa - do jeito que está.
Este artigo compara o desempenho de SSGs populares. Ou seja, estamos falando sobre o tempo de construção de projetos. Mas o mais importante aqui é uma análise profunda de por que certas ferramentas mostram certos resultados. Será um erro, independentemente do tempo de construção do projeto, escolher o "SSG mais rápido" ou abandonar imediatamente o "mais lento". Vamos falar sobre por que isso acontece.
Testes
O processo de teste SSG é projetado para começar pesquisando alguns projetos populares e explorando o processamento de formatos de dados simples. Esta é a base sobre a qual construir um estudo de geradores de sites mais estáticos e expandir este estudo com formatos de dados mais complexos. O estudo agora inclui seis SSGs populares:
Ao estudar cada um deles, a seguinte abordagem e as seguintes condições são aplicadas:
- A fonte de dados para cada teste (processo de construção do projeto) são arquivos Markdown contendo um cabeçalho gerado aleatoriamente (o que é chamado de "matéria frontal") e um corpo do documento (três parágrafos de texto).
- Não há imagens nos documentos.
- Os testes são executados várias vezes no mesmo computador. Isso torna os valores específicos obtidos do teste menos importantes do que a comparação dos resultados relativos.
- A saída está em texto simples em uma página HTML. O processamento de dados é executado usando configurações padrão, que são descritas nos guias de introdução para cada um dos SSGs examinados.
- « ». Markdown-.
Esses testes são considerados testes de desempenho (benchmarks). Eles usam arquivos Markdown simples, resultando em código HTML não estilizado.
Em outras palavras, a saída é, do ponto de vista técnico, um site que poderia ser implantado em produção. Mas esta não é uma implementação de um cenário SSG real. Em vez de tentar reproduzir uma situação real, queremos obter uma linha de base para comparar as estruturas em estudo. Ao usar as ferramentas acima para criar sites reais, o SSG trabalhará com dados mais complexos e com configurações diferentes, o que afetará o tempo de construção dos projetos (isso geralmente retarda a construção).
Por exemplo, uma das diferenças entre nossos casos de uso de SSG de teste e do mundo real é o fato de que estamos examinando processos de construção fria. Na realidade, as coisas são um pouco diferentes. Por exemplo, se o projeto incluir 10.000 arquivos Markdown que são a fonte de dados para SSG, e se Gatsby for usado para construir o projeto, o cache de Gatsby será usado. E isso reduz bastante (quase pela metade) o tempo de montagem.
O mesmo pode ser dito para compilações incrementais. Isso tem a ver com a comparação de compilações quentes e frias, no sentido de que apenas os arquivos alterados são processados ao executar uma compilação incremental. Não estamos examinando compilações incrementais nesses testes. No futuro, é bem possível que este estudo seja expandido nessa direção.
SSG de diferentes níveis
Antes de começarmos a explorar, vejamos o fato de que na verdade existem dois tipos de SSG, dois níveis de geradores de site estáticos. Vamos chamá-los de "básicos" e "avançados".
- Geradores básicos (embora não sejam tão simples) são, na verdade, ferramentas de linha de comando (Command-Line Interface, CLI) que pegam dados e geram HTML. Freqüentemente, suas capacidades podem ser expandidas no sentido de processar recursos adicionais (não estamos fazendo isso aqui).
- Geradores avançados oferecem alguns recursos adicionais, além de criar sites estáticos. São, por exemplo, renderização de páginas do lado do servidor, funções sem servidor, integração com vários frameworks da web. Eles geralmente são, imediatamente após a instalação, configurados para fornecer ao usuário recursos mais dinâmicos do que os geradores básicos.
Para este teste, selecionei especialmente três geradores de cada nível. Os básicos incluem Eleventy, Hugo e Jekyll. Os outros três geradores são baseados em estruturas de front-end. Esses SSGs incluem várias ferramentas adicionais. Gatsby e Next são baseados em React, enquanto Nuxt é baseado em Vue.
Geradores básicos | Geradores avançados |
Onze | Gatsby |
Hugo | Próximo |
Jekyll | Nuxt |
Hipóteses e suposições
Proponho aplicar o método científico em nossa pesquisa . A ciência é muito estimulante (e pode ser de grande benefício).
Minha hipótese é que se o SSG for avançado, isso significa que funcionará mais lentamente do que os geradores básicos. Tenho certeza de que isso se refletirá nos resultados do estudo, uma vez que mais mecanismos estão envolvidos no trabalho dos SSGs avançados do que no trabalho dos básicos. Como resultado, é muito provável que, com base na pesquisa, os geradores básicos e avançados possam ser claramente divididos em dois grupos. Ao mesmo tempo, os geradores básicos funcionarão mais rápido do que os avançados.
▍ SSG básico: alta velocidade e dependência linear da velocidade de compilação do número de arquivos
Hugo e Eleventy irão processar pequenos conjuntos de dados muito rapidamente. Eles são processos (relativamente) simples criados por Go e Node.js respectivamente. Os resultados dos testes devem refletir isso. Embora ambos os SSGs diminuam à medida que o número de arquivos aumenta, espero que continuem sendo os líderes. Ao mesmo tempo, é possível que a Eleventy, com o aumento da carga, demonstre a dinâmica da mudança no tempo de montagem, que se desvia mais do linear do que o Hugo. Isso pode ser uma simples consequência do fato de que o desempenho do Go geralmente é melhor do que o desempenho do Node.js.
▍ SSG avançado: início lento da construção e aumento de velocidade subsequente, mas não muito sério
SSGs avançados, ou aqueles vinculados a algum tipo de estrutura da web, começarão lentamente, será perceptível. Suspeito que em um teste de arquivo único, a diferença entre estruturas básicas e avançadas será bastante significativa. Para os básicos, serão alguns milissegundos, e para os avançados, para Gatsby, Next e Nuxt, serão segundos.
SSGs baseados em estruturas da web usam webpack, que adiciona carga adicional ao sistema conforme são executados. Ao mesmo tempo, essa carga adicional não depende da quantidade de dados processados. Mas nós mesmos concordamos com isso, usando ferramentas mais avançadas (falaremos mais sobre isso a seguir).
E quando se trata de processar milhares de arquivos, suspeito que a lacuna entre os grupos de geradores básicos e avançados diminuirá. Ao mesmo tempo, no entanto, os SSGs avançados ainda ficarão muito aquém dos básicos.
Se falarmos de um grupo de geradores avançados, espero que o mais rápido deles seja Gatsby. Só acho que sim porque não tem um componente de renderização do lado do servidor que pode atrasar as coisas. Mas isso é apenas um reflexo dos meus sentimentos internos. Talvez no Next e no Nuxt a renderização do servidor seja otimizada a tal nível que, se não for usada, não afetará o tempo de construção dos projetos de forma alguma. Suspeito que Nuxt será mais rápido do que Next. Eu faço essa suposição com base no fato de que Vue é "mais leve" que React.
▍Jekyll é um representante incomum do SSG básico
A plataforma Ruby é conhecida por seu baixo desempenho. Ele é otimizado com o tempo, fica mais rápido, mas não espero que seja tão rápido quanto o Node.js, muito menos Go. Mas, ao mesmo tempo, Jekyll não carrega o fardo adicional associado a um framework web.
Acho que no início do teste, ao processar um pequeno número de arquivos, Jekyll vai mostrar alta velocidade. Possivelmente tão alto quanto Eleventy. Mas, à medida que examinamos o processamento de milhares de arquivos, o desempenho será afetado. Parece-me que há outras razões pelas quais Jekyll pode ser o mais lento dos seis SSGs estudados. Para testar isso, examinamos o desempenho de nossos geradores em conjuntos de arquivos de tamanhos diferentes - até 100.000.
Abaixo está um gráfico que mostra minhas suposições.

Suposições relacionadas à dependência da velocidade de trabalho de vários SSGs
O eixo Y representa o tempo de construção dos projetos, o eixo X representa o número de arquivos. A seguir é mostrado em verde, Nuxt em amarelo, Gatsby em rosa, Jekyll em azul, Eleventy em turquesa, Hugo em laranja. Todas as linhas refletem o aumento no tempo de construção do projeto conforme o número de arquivos aumenta. Ao mesmo tempo, a linha correspondente a Jekyll tem o maior ângulo de inclinação.
resultados
Aqui está o código que produz os resultados que discutirei agora. Também fiz uma página que compila os resultados dos testes relativos.
Depois de muitas tentativas de encontrar condições para a execução de testes, decidi fazer 10 execuções de cada teste usando três conjuntos de dados diferentes.
- Conjunto de dados de base (Base). Este é um arquivo. Seu processamento permite estimar o tempo que o SSG precisa para se preparar para o trabalho. Este é o tempo que levará para iniciar o SSG. Pode ser chamado de básico, independentemente do número de arquivos sendo processados.
- Um conjunto de "pequenos sites" (sites pequenos). Ele examina a montagem de conjuntos de arquivos de 1 a 1024. Cada nova passagem de teste é realizada com um número duplicado de arquivos (para tornar mais fácil descobrir se o tempo de processamento de arquivos aumenta linearmente com seu número).
- Um conjunto de "sites grandes" (sites grandes). Aqui, o número de arquivos muda de 1.000 para 64.000, dobrando a cada nova execução de teste. Inicialmente, eu queria chegar a 128.000 arquivos, mas encontrei gargalos em alguns frameworks. Como resultado, descobriu-se que 64.000 arquivos são suficientes para descobrir como os SSGs examinados se comportam ao processar sites de grande escala.
Aqui estão os resultados que obtive.

Conjunto de dados base

Conjunto de dados de sites pequenos

Conjunto de dados de grandes sites
Resumindo os resultados
Alguns resultados me surpreenderam, mas alguns foram exatamente como eu esperava. Aqui estão algumas descobertas gerais:
- Como esperado, o SSG mais rápido foi o Hugo. Funciona muito bem em conjuntos de arquivos de todos os tamanhos. Mas eu não esperava que outros geradores se aproximassem dele, mesmo no conjunto de dados Base (eu não esperava que ele mostrasse um comportamento linear, mas mais sobre isso abaixo).
- Ambos os SSGs, básicos e avançados, são bastante distintos nos gráficos que mostram o processamento de arquivos do conjunto de sites pequenos. Isso era de se esperar. No entanto, foi inesperado que o Next seja mais rápido do que o Jekyll em um conjunto de 32.000 arquivos, e que ignore tanto o Jekyll quanto o Eleventy em 64.000 arquivos. Além disso, surpreendentemente, Jekyll é 64.000 arquivos mais rápido do que Eleventy.
- SSG . Next, , , . Hugo , — - .
- , Gatsby , , . , .
- , , , . , , Hugo 170 , Gatsby. 64000 Hugo 25 . , Hugo, SSG, . , - .
O que tudo isso significa?
Quando compartilhei minhas descobertas com os criadores desses SSGs e com aqueles que os apóiam, recebi deles, se não entrar em detalhes, as mesmas mensagens. Se essas mensagens forem reduzidas a um tipo de mensagem "média", você obterá o seguinte: Os
geradores que gastam mais tempo construindo um projeto trabalham dessa maneira porque têm que resolver mais problemas. Eles fornecem aos desenvolvedores mais opções, enquanto as ferramentas mais rápidas (ou seja, "básicas") se preocupam principalmente com a conversão de modelos em arquivos HTML.
Eu concordo com isso.
Resumindo, descobrimos que dimensionar sites Jamstack é muito difícil.
As dificuldades que um incorporador, cujo projeto está em crescimento e desenvolvimento, enfrentará dependem das características de cada projeto específico. Não há dados para apoiar isso. Sim, não podem estar aqui, pois cada projeto é, de uma forma ou de outra, único.
Mas tudo se resume às preferências pessoais do desenvolvedor, àquele compromisso entre o tempo de construção do site e a conveniência de trabalhar com SSG, que ele está pronto para fazer.
Por exemplo, se você vai criar um grande site cheio de imagens e planeja usar Gatsby, então você precisa estar preparado para o fato de que esse site vai demorar muito para ser construído. Mas, em troca, você obtém um enorme ecossistema de plug-ins e a base para a construção de um site robusto, bem organizado e baseado em componentes. Se você usar Jekyll no mesmo projeto, terá que se esforçar muito mais para mantê-lo em um estado bem organizado, a fim de garantir a eficácia do trabalho no projeto. E a montagem do site será mais rápida.
No trabalho, geralmente construo sites com Gatsby(ou usando Next, dependendo do nível necessário de interatividade dinâmica do projeto). Trabalhamos com Gatsby para criar uma estrutura na qual pudéssemos construir rapidamente sites altamente personalizáveis contendo muitas imagens baseadas em um grande número de componentes. Conforme esses sites aumentaram de tamanho, demorou cada vez mais para criá-los e começamos a ser criativos. Trata-se de implementar microfront-ends , processamento de imagem fora do sistema de compilação principal, visualizações de conteúdo e muitas outras otimizações.
Em projetos própriosEu costumo usar Eleventy. Normalmente, só escrevo o código de tais projetos, minhas necessidades são bastante modestas (me considero meu próprio bom cliente). Tenho melhor controle sobre os resultados da construção, o que me ajuda a alcançar alta produtividade do lado do cliente. E isso é importante para mim.
Como resultado, a escolha do SSG não é apenas uma escolha entre "rápido" e "lento". É a seleção da ferramenta mais adequada para um determinado projeto, cujos resultados de trabalho justifiquem o tempo de espera por esses resultados.
Resultado
Na verdade, o que eu disse é apenas o começo. O objetivo do meu trabalho é criar uma base a partir da qual todos possamos medir os tempos de construção relativos de projetos produzidos pelo popular SSG.
Você encontrou alguma inconsistência em meu processo de teste proposto para geradores de sites estáticos? Como melhorar o procedimento de teste? Como aproximar as provações da realidade? Eu preciso transferir o processamento de imagem para um computador separado? Convido todos os que se preocupam com o SSG a se juntarem a mim e me ajudarem a encontrar respostas para essas e muitas outras perguntas.
Quais geradores de sites estáticos você usa?

