比较静态网站生成器构建时间

有 如此之多 静态网站生成器 (SSG)。 尝试决定从哪里开始令人不知所措。虽然大量有用的文章可能有助于浏览（流行的）选项，但它们并不能神奇地使决策变得容易。

我一直在努力帮助简化这一决策。我的同事 构建了一个静态网站生成器评估备忘单。它提供了许多流行的 SSG 选择的非常好的快照。缺少的是它们在实际操作中的表现。

每个静态网站生成器都有一个共同的功能，即它接收输入数据，将其通过模板引擎运行，然后输出 HTML 文件。我们通常将此过程称为构建。

需要太多的细微差别、上下文和可变性来比较各种 SSG 在构建过程中如何执行以显示在电子表格上——因此我们开始测试以针对流行的静态网站生成器对构建时间进行基准测试。

这不仅仅是为了确定哪个 SSG 最快。 Hugo 已经拥有了这样的声誉。我的意思是，他们在他们的网站上说——构建网站的全球最快框架——所以它一定是正确的！

这是对多个流行 SSG 的构建时间的深入比较，更重要的是，分析这些构建时间为何是这样的。盲目选择最快的或贬低最慢的都是错误的。让我们找出原因。

测试

测试过程旨在从简单开始——仅使用一些流行的 SSG 和简单的数据格式。一个可以扩展到更多 SSG 和更细致数据的基础。今天，测试包括六种流行的 SSG 选择

• Eleventy
• Gatsby
• Hugo
• Jekyll
• Next
• Nuxt

每次测试都使用了以下方法和条件

• 每个构建的数据源都是 Markdown 文件，具有随机生成的标题（作为前置 matter）和正文（包含三段内容）。
• 内容不包含图像。
• 测试在单台机器上按顺序运行，这使得实际值比它们之间相对比较不那么重要。
• 输出是在 HTML 页面上的纯文本，通过默认启动器运行，遵循每个 SSG 的各自入门指南。
• 每次测试都是冷运行。缓存被清除，Markdown 文件在每次测试中都会重新生成。

这些测试被认为是基准测试。它们使用基本的 Markdown 文件并将未设置样式的 HTML 输出到构建输出中。

换句话说，输出技术上是一个可以部署到生产环境的网站，尽管它并非真正是真实场景。相反，这提供了这些框架之间的基线比较。您作为使用其中一个框架的开发人员做出的选择将以各种方式调整构建时间（通常是使其变慢）。

例如，它不代表现实世界的一种方式是我们正在测试冷构建。在现实世界中，如果您有 10,000 个 Markdown 文件作为您的数据源并且正在使用 Gatsby，您将利用 Gatsby 的缓存，这将极大地减少构建时间（最多减少一半）。

增量构建也可以说相同，它与热运行与冷运行相关，因为它们只构建已更改的文件。我们没有在这些测试中测试增量方法（目前）。

静态网站生成器的两个层级

在我们这样做之前，让我们首先考虑一下实际上存在静态网站生成器的两个层级。让我们称它们为基本和高级。

• 基本生成器（在后台并不基本）本质上是一个命令行界面 (CLI)，它接收数据并输出 HTML，并且通常可以扩展以处理资产（我们在这里不做）。
• 高级生成器除了输出静态站点之外，还提供其他功能，例如服务器端渲染、无服务器函数和框架集成。它们往往被配置为开箱即用地更具动态性。

我故意在这个测试中选择了每种类型的生成器中的三种。属于基本类别的是 Eleventy、Hugo 和 Jekyll。其他三个基于前端框架，并附带不同数量的工具。Gatsby 和 Next 基于 React 构建，而 Nuxt 基于 Vue 构建。

基本生成器	高级生成器
Eleventy	Gatsby
Hugo	Next
Jekyll	Nuxt

我的假设

让我们将科学方法应用于这种方法，因为科学很有趣（也很有用）！

我的假设是，如果一个 SSG 是高级的，那么它的性能将比基本 SSG 慢。我相信结果会反映这一点，因为高级 SSG 比基本 SSG 有更多的开销。因此，我们很可能看到两组生成器——基本和高级——捆绑在一起，结果是基本生成器移动得快得多。

让我详细阐述一下这个假设。

线性（ish）且快速

Hugo 和 Eleventy 在较小的数据集上运行速度很快。它们分别是在 Go 和 Node.js 中的（相对）简单的过程，它们的构建输出将反映这一点。虽然这两个 SSG 随着文件数量的增长而速度会变慢，但我预计它们将保持在该类别中的领先地位，尽管 Eleventy 在大规模情况下可能不太线性，仅仅因为 Go 往往比 Node 性能更好。

缓慢，然后快速，但仍然缓慢

高级或与框架绑定的 SSG 将开始并看起来很慢。我怀疑单文件测试包含显着差异——基本文件为毫秒，而 Gatsby、Next 和 Nuxt 为几秒钟。

基于框架的 SSG 都是使用 webpack 构建的，无论它们处理多少内容，都会带来大量的开销。这是我们在使用这些工具时要承担的负担（稍后详细介绍）。

但是，当我们添加数千个文件时，我怀疑我们会看到这两个类别之间的差距缩小，尽管高级 SSG 组将继续落后于某个显着数量。

在高级 SSG 组中，我预计 Gatsby 将是最快的，仅仅因为它没有服务器端组件需要担心——但这只是一个直觉。Next 和 Nuxt 可能已经对此进行了优化，以至于如果我们不使用该功能，它不会影响构建时间。而且我怀疑 Nuxt 会击败 Next，仅仅因为与 React 相比，Vue 的开销要少一些。

Jekyll：特立独行的孩子

Ruby 众所周知速度很慢。它随着时间的推移性能有所提高，但我预计它不会与 Node 扩展，当然也不会与 Go 扩展。然而，与此同时，它也没有框架的负担。

起初，我认为我们会看到 Jekyll 速度很快，甚至可能与 Eleventy 没有区别。但是当我们到达数千个文件时，性能将受到影响。我的直觉是，可能存在 Jekyll 成为所有六个中最慢的点。我们将提升到 100,000 的标记以确保。

结果出来了！

为这些测试提供支持的代码位于 GitHub 上。还有一个 显示相对结果的网站。

在多次迭代构建这些测试可以运行的基础后，我最终得到了一系列 10 次运行，分布在三个不同的数据集中

• 基础：单个文件，用于比较基础构建时间
• 小型站点：从 1 到 1024 个文件，每个文件加倍到时间（以便更容易确定 SSG 是否线性扩展）
• 大型站点：文件数量从 1,000 到 64,000，每次运行翻倍。我最初想增加到 128,000 个文件，但遇到了一些框架的瓶颈。64,000 个文件最终足以让我们了解到，当站点规模更大时，这些生成器将如何扩展。

点击或轻触图片以查看更大的尺寸。

结果总结

一些结果让我感到惊讶，而另一些则在意料之中。以下是重点：

• 正如预期的那样，Hugo 速度最快，无论站点大小如何。但令我意外的是，即使在基本构建中，它的速度也远超其他任何生成器。
• 从小型站点的结果来看，SSG 的基础组和高级组之间的区别非常明显。这是预料之中的，但令人惊讶的是，Next 和 Eleventy 在 64,000 个文件时表现接近。同样令人惊讶的是，Jekyll 在每次运行中都比 Eleventy 运行得更快。
• 我原本以为 Gatsby 会是高级框架中最快的，并且预计它会更接近基础框架。但Gatsby 却成为了最慢的，产生了最明显的曲线。
• 虽然假设中没有特别提到，但差异的规模比我想象的要大得多。在处理一个文件时，Hugo 的速度大约是 Gatsby 的 250 倍。但在处理 64,000 个文件时，速度差距缩小了——大约快了 40 倍。这意味着，虽然 Hugo 仍然是最快的（显著更快），但随着站点规模的增加，它的构建时间与其他生成器的差距正在缩小。

这一切意味着什么？

当我与这些 SSG 的创建者和维护者分享我的结果时，通常会收到同样的信息。概括来说：

构建时间较长的生成器之所以如此，是因为它们做了更多的事情。它们为开发者提供了更多可用的功能，而构建速度较快的站点（即“基础”工具）则主要专注于将模板转换为 HTML 文件。

我同意。

总结一下：扩展 Jamstack 站点很困难。

在扩展站点时，您（开发者）将会面临的挑战会因您尝试构建的站点而异。这些数据在这里没有被捕捉到，因为它们无法被捕捉——每个项目在某种程度上都是独一无二的。

归根结底是您愿意为了开发体验而等待多久。

例如，如果您要使用 Gatsby 构建一个大型的、图片密集型的站点，您将需要为构建时间付出代价，但同时您也会获得一个庞大的插件网络以及构建一个稳固、组织良好、基于组件的网站的基础。如果您使用 Jekyll 做同样的事情，那么在整个过程中保持组织性和效率将需要付出更多的努力，尽管您的构建速度可能会更快。

在工作中，我通常使用 Gatsby（或 Next，取决于所需的动态交互级别）构建站点。我们与 Gatsby 框架合作，构建了一个核心，以便能够快速构建高度定制的、图片丰富的网站，并包含丰富的组件。随着站点的扩展，我们的构建速度会变慢，但这时我们会发挥创意，通过实施微前端、卸载图像处理、实现内容预览以及许多其他优化来解决问题。

业余时间，我倾向于使用 Eleventy。通常只有我一个人编写代码，我的需求也简单得多。（我喜欢认为自己是一个对自己来说的好客户。）我觉得我对输出文件有更多的控制权，这使得我更容易在客户端性能方面获得 💯 的分数，这一点对我来说很重要。

归根结底，这不仅仅是关于速度快慢的问题。而是关于什么最适合您以及您愿意等待多久。

总结

这仅仅是个开始！这项工作的目标是创建一个基础，以便我们能够共同对流行的静态站点生成器的相对构建时间进行基准测试。

您有什么想法？您能在这个过程中发现什么漏洞？我们如何改进这些测试？如何使它们更接近真实场景？我们是否应该将处理过程卸载到专用机器上？

这些都是我希望您帮助我解答的问题。让我们来讨论一下。