我决定帮助那些忙于选择SSG的人。我的一位同事整理了一系列问题，以帮助您找到静态网站生成器。此列表所附是受欢迎的SSG的摘要。它仅缺乏对不同SSG如何执行的评估。
所有SSG的共同点是它们的工作方式。即，它们接受一些数据作为输入，并将这些数据通过模板引擎传递。输出是HTML文件。此过程通常称为构建项目。
为了获得不同SSG的可比较性能数据，需要考虑许多细微差别。有必要注意项目的功能，要注意减慢或加快装配速度的因素。这是我们开始探索流行的SSG的性能的地方。
话虽如此，我们的目标不仅仅是找到最快的SSG。雨果已经成为“最快”的声誉。我的意思是，该项目的网站说Hugo是世界上最快的网站建设框架。这就是-的方式。
本文比较了流行的SSG的性能。即，我们正在谈论项目的构建时间。但是，这里最重要的是深入分析某些工具为何显示某些结果。无论何时进行项目组装，选择“最快的SSG”或立即放弃“最慢的” SSG都是错误的。让我们谈谈为什么会这样。
测验
SSG测试过程的设计从研究一些受欢迎的项目开始，并探索对简单数据格式的处理。这是构建更多静态站点生成器研究并以更复杂的数据格式扩展此研究的基础。该研究现在包括六个流行的SSG：
在研究它们中的每一个时，将应用以下方法和以下条件：
- 每个测试（项目构建过程）的数据源是Markdown文件，其中包含随机生成的标头（称为“前题”）和文档正文（文本的三个段落）。
- 文档中没有图像。
- 测试在同一台计算机上运行多次。这使得从测试中获得的特定值不如相对结果的比较重要。
- 输出以纯文本形式显示在HTML页面上。使用标准设置执行数据处理，这在每个检查的SSG的入门指南中都有介绍。
- « ». Markdown-.
这些测试被视为性能测试（基准）。他们使用简单的Markdown文件，从而生成未样式化的HTML代码。
换句话说，从技术角度来看，输出是可以在生产中部署的网站。但这不是实际SSG方案的实现。与其试图重现真实情况，不如想作为比较研究框架的基准。使用上述工具创建真实站点时，SSG将使用更复杂的数据和不同的设置来工作，这将影响项目的构建时间（通常会减慢构建速度）。
例如，我们的基准测试和实际SSG用例之间的差异之一是我们正在研究冷构建过程。实际上，情况有所不同。例如，如果一个项目包含10,000个Markdown文件（它们是SSG的数据源），并且如果使用Gatsby构建该项目，则将使用Gatsby缓存。这大大减少了将近一半的组装时间。
对于增量构建也可以这样说。这与比较热构建和冷构建有关，即执行增量构建时仅处理更改的文件。我们不在这些测试中检查增量构建。将来，很有可能会朝这个方向扩展这项研究。
不同级别的SSG
在开始之前，让我们看一个事实，实际上有两种SSG，两种级别的静态站点生成器。我们称它们为“基本”和“高级”。
- 实际上，基本生成器（尽管它们不是那么简单）是接受数据并输出HTML的命令行工具（命令行界面，CLI）。通常，他们的能力使他们能够朝着处理更多资源的方向扩展（我们在这里不做这些）。
- 除了创建静态站点之外，高级生成器还提供了一些其他功能。例如，这些是页面的服务器端呈现，无服务器功能，与各种Web框架的集成。它们通常在安装后立即配置为为用户提供比基本生成器更多的动态功能。
对于此测试，我特别选择了每个级别的三个生成器。基本的包括Eleventy，Hugo和Jekyll。其他三个生成器基于前端框架。这些SSG包括各种其他工具。Gatsby和Next基于React，而Nuxt基于Vue。
| 基本发电机 | 先进的发电机 |
| Eleventy | 盖茨比 |
| 雨果 | 下一个 |
| 杰基尔 | Nuxt |
假设和假设
我建议在研究中应用科学方法。科学非常令人兴奋（并且可能会带来巨大的好处）。
我的假设是，如果SSG先进，则意味着它将比基本发电机运行得慢。我相信这将反映在研究结果中，因为高级SSG的工作涉及的机制比基本SSG的机制更多。结果，根据研究结果，基本发电机和高级发电机很可能可以清晰地分为两组。同时，基本发电机的工作速度将比高级发电机快。
S基本SSG：构建速度对文件数量的高速和线性依赖
Hugo和Eleventy将非常快速地处理小型数据集。它们是（相对）分别由Go和Node.js创建的简单过程。他们的测试结果应反映出这一点。尽管这两个SSG都会随着文件数量的增长而变慢，但我希望它们将继续保持领先地位。同时，随着负载的增加，Eleventy可能会展示装配时间变化的动态变化，这比Hugo偏离线性变化的趋势更大。这可能是Go的性能通常优于Node.js的性能的简单结果。
▍高级SSG：缓慢的构建开始和随后的速度提高，但不太严重
高级SSG或与某种Web框架相关的SSG会缓慢启动，这很明显。我怀疑在单个文件测试中，基本框架和高级框架之间的差异会很大。对于基本的，它将是几毫秒；对于高级的，对于盖茨比，Next和Nuxt，将是几秒钟。
基于Web框架的SSG使用webpack，这会在运行时为系统增加额外的负载。同时，此额外负载不取决于处理的数据量。但是我们自己也同意使用更高级的工具（我们将在下面详细讨论）。
在处理数千个文件时，我怀疑基本生成器组和高级生成器组之间的差距会缩小。但是，与此同时，高级SSG仍将严重落后于基本SSG。
如果我们谈论一组高级生成器，那么我期望其中最快的是盖茨比。我之所以这么认为是因为它没有服务器端渲染组件，它可以减慢速度。但这只是我内心感受的反映。也许，在Next和Nuxt中，服务器渲染已优化到一个水平，如果不使用它，则不会以任何方式影响项目的构建时间。我怀疑Nuxt会比Next快。我基于Vue比React更“轻”这一事实做出这一假设。
ek杰基尔是基本SSG的不寻常代表
Ruby平台因性能不佳而臭名昭著。随着时间的流逝，它得到了优化，变得越来越快，但是我不希望它能像Node.js一样快，更不用说Go了。但是，与此同时，Jekyll不承担与Web框架相关的额外负担。
我认为在测试开始时，当处理少量文件时，Jekyll将显示出较高的速度。可能和Eleventy一样高。但是，当我们检查数千个文件的处理时，性能将受到影响。在我看来，还有其他原因使Jekyll成为我们调查的六个SSG中最慢的一个。为了测试这一点，我们检查了不同大小的文件集（最多100,000个）中生成器的性能。
下图显示了我的假设。
关于各种SSG的工作速度依赖性的假设
Y轴表示项目的构建时间，X轴表示文件数。下一个显示为绿色，Nuxt显示为黄色，Gatsby显示为粉红色，Jekyll显示为蓝色，Eleventy显示为绿松石，Hugo显示为橙色。所有行都反映了随着文件数量的增加，项目构建时间的增加。同时，对应于杰基尔的线具有最大的倾斜角。
结果
这是产生结果的代码，我现在将讨论它们。我还制作了一个页面，用于编译相对测试结果。
在尝试寻找运行测试的条件后，我尝试使用三个不同的数据集对每个测试进行10次运行。
- 基本数据集（Base）。这是一个文件。它的处理使您可以估计SSG准备工作所需的时间。这是SSG启动所需的时间。可以将其称为基本文件，而不管要处理的文件数量如何。
- 一组“小型站点”（小型站点）。它检查从1到1024的文件集的组合。每次执行新的测试时，文件数量都会增加一倍（以便更轻松地确定文件的处理时间是否随文件数量的增加而线性增长）。
- 一组“大型站点”（大型站点）。在这里，文件数从1000变为64000，每次新的测试运行都会增加一倍。我本来希望获得128,000个文件，但在某些框架中遇到了瓶颈。结果，发现64,000个文件足以找出在处理大型站点时所检查的SSG的行为。
这是我得到的结果。
基本数据集
小型网站数据集
大型网站数据集
总结结果
一些结果使我感到惊讶，但结果却完全符合我的预期。以下是一些一般性发现：
- 不出所料，最快的SSG是Hugo。它适用于各种大小的文件集。但是，我并不希望其他生成器至少会接近它，即使是在基本数据集上也是如此（我不希望它显示线性行为，但下面会更多）。
- 在显示“小型站点”集中的文件处理过程的图中，基本SSS和高级SSG都可以明显地区分开。这是预料之中的。但是，出乎意料的是，在一组32000个文件中，Next的速度比Jekyll快，并且在64000个文件中它绕过了Jekyll和Eleventy。同样，令人惊讶的是，Jekyll比Eleventy快64,000个文件。
- SSG . Next, , , . Hugo , — - .
- , Gatsby , , . , .
- , , , . , , Hugo 170 , Gatsby. 64000 Hugo 25 . , Hugo, SSG, . , - .
这一切是什么意思？
当我与这些SSG的创建者以及与支持它们的人分享我的发现时，我从他们那里收到了同样的信息，而没有详细介绍。如果将这些消息简化为某种“平均”消息，则会得到以下信息：
花费更多时间构建项目的生成器以这种方式工作，因为它们必须解决更多问题。它们为开发人员提供了更多选择，而更快的工具（即“基本”）主要用于将模板转换为HTML文件。
我同意这一点。
简而言之，事实证明，扩展Jamstack站点非常困难。
一个项目正在成长和发展的开发人员所面临的困难取决于每个特定项目的特征。没有任何数据可以支持这一点。是的，它们不能在这里，因为每个项目都以一种或另一种方式是唯一的。
但这一切都取决于开发人员的个人喜好，在网站构建时间和使用SSG的便利性之间做出的妥协，而他已经准备好了。
例如，如果您要创建一个包含图像的大型站点并计划使用Gatsby，那么您需要为该站点需要很长时间才能建立的事实做好准备。但是作为回报，您将获得庞大的插件生态系统，以及构建强大，组织良好，基于组件的网站的基础。如果在同一项目中使用Jekyll，则必须付出更多的努力才能使项目保持组织良好的状态，以确保项目工作的有效性。而且现场组装将更快。
在工作中，我通常使用盖茨比（Gatsby）建立网站（或使用Next，具体取决于项目动态交互的要求级别）。我们与Gatsby合作，创建了一个框架，可在该框架上快速构建高度可定制的网站，其中包含基于大量组件的许多图像。随着这些网站规模的扩大，建造它们的时间越来越长，我们开始变得富有创意。它是关于实现微前端，在主构建系统之外进行图像处理，内容预览以及许多其他优化的。
在自己的项目中我通常使用Eleventy。通常，只有我编写此类项目的代码，我的需求却很少（我认为自己是我自己的好客户）。我对构建结果有更好的控制，这有助于我提高客户端的生产率。这对我很重要。
结果，SSG的选择不仅是“快速”和“慢速”之间的选择。选择最适合特定项目的工具，其工作结果证明等待这些结果所花费的时间是合理的。
结果
实际上，我所说的仅仅是开始。我的工作目标是创建一个基础，我们可以据此来衡量由流行的SSG生成的项目的相对构建时间。
在提议的静态站点生成器测试过程中，您是否发现任何不一致之处？如何改善测试程序？如何使审判更接近现实？我需要将图像处理转移到另一台计算机上吗？我邀请所有关心SSG的人加入我的行列，并帮助我找到这些问题以及许多其他问题的答案。
您使用什么静态站点生成器？
