本文最初发布于 Hacker Noon 博客，经原作者授权由 InfoQ 中文站翻译并分享。
在大多数情况下， JeremyMorgan.com 网站的首页在世界各地的加载时间都不到一秒。
这个网站的速度之前就很快， 3 秒钟就可以加载完成，但现在更快了。我将在本文中披露我是怎么设置的。
我选择使用 Hugo 构建这个网站，并托管在 Netlify 上。
之前的网站设置
大约在 2011 年的某个时候，我决定从 WordPress 转移到静态站点生成器。理由很简单：我写好一篇文章，发表它，之后不会修改太多。这当然不足以证明从数据库提供服务更合理。因此，有一个系统可以为每篇文章生成一个 HTML 页面并以静态的方式提供出来就够了。
我决定选用 Octopress ，它在当时是一个非常受欢迎的 Jekyll 包装器，也很好地满足了我的需求。
仅这一步就大大减少了加载时间。然后，我变得有点沉迷于页面加载速度，做了很多事情来让它加载得更快，包括：
图像优化（我用过的一些工具）简化 CSS 和 JavaScript对某些资产使用 CDN我对这种设置当然很满意。多年来，我的工作流程就是新建一篇文章，在笔记本电脑或台式机上生成它，然后将文件 SCP 到运行 Nginx 的 FreeBSD 服务器上。这种方式持续了很长一段时间。回顾过去，那是一个糟糕的工作流程，但我两个月才写一篇文章，所以这样也没什么问题。
我花了很多年来定制我的 Octopress 安装，并为项目贡献代码和补丁。
问题成堆虽然一开始我很喜欢 Octopress，也很欣赏 Brandon Mathis 等人的工作，但 Octopress 开始变得让人非常痛苦。
对我来说，最大的问题不是 Octopress 本身，而是 Ruby 依赖。这里就不介绍太多细节了，但它变得非常难以管理。Octopress 需要比较老的 gems 来完成操作，因此，随着 Ruby 以及某些 gems 的发展，维护一个可构建的 Octopress 安装变得很有挑战性。
我无法再从我的笔记本电脑进行构建，因为我需要维护所有旧软件。我用旧软件搭建了一个 Linux 服务器，并用它来完成构建。然后，把这些东西转移到一个容器中，这样就可以维护 Ruby 以及那些 gems 的旧版本用来生成输出。例如，运行的 Ruby 版本不能高于 1.9.3 。
所以，我几年前就开始研究解决方案，但一直没有时间去切换。几年来，我的工作流程是这样的：
还不错，但这个过程有个致命缺点，就是 Octopress 构建，我知道这一点。为一个简单的构建步骤维护所有这些旧软件很容易，但前提是我不碰任何东西。
上个月，我用于构建 Octopress 镜像的服务器坏了。所以我启用了另一台服务器，安装了 Docker 和容器，但它无法工作。我试了我能想到的所有方法，事实很清楚：
我可以花数小时用这些古老的软件构建出另一个容器来让 Octopress 运行起来，或者我能把时间花在更换到另一个 CMS 上。
因此，我开始认真评估另一个静态站点生成器的选项。
为什么选择 Hugo
我花了很多时间来评估不同选项，归结起来就是以下几个：
Hugo （Go）Gatsby （JavaScript）Pelican （Python）这些都是静态站点生成器，它们都可以很好地解决我的问题。我了解 Go、JavaScript 和 Python，所以我可以修改一些东西。这只是一个普通的博客，它只是一个目录结构下的一组文件。这些方法都是可行的。但是，我的要求是什么呢？
静态文件生成器必须可以快速构建必须容易定制化必须可移植（Mac、OSX、Linux）最后一点可能看起来有点傻，但我永远不知道我将在什么平台上写作。我可能使用 Mac、Windows 或 Linux，这取决于所写的内容。我希望先在本地构建并查看页面，然后再推到开发环境，最后推到生产环境。这对我来说很重要。不过，经过大量评估后，我发现：
所有这些静态文件生成器都满足这些需求。
因此，这让选择变得困难起来。我有一个 JeremyMorgan.com 版本，在所有的平台上使用这三个生成器运行都没有问题。我可以自定义一些东西，它们都能快速地构建好页面。但我必须选择一个。
我最终选择了 Hugo ，因为我害怕陷入另一个依赖地狱。Gatsby 很酷，也很强大，但对我所做的事情来说似乎太复杂。它在 JavaScript 生态系统中也有大量的依赖，众所周知，JavaScript 生态系统有时会突发奇想做出破坏性的更改。
Pelican 依赖于 Python 生态系统，而 Python 生态系统不那么古怪，所以 Pelican 排第二位。而 Hugo 是从可执行文件构建的。因此，即使它被放弃或依赖关系被破坏，我也总是可以使用可执行文件来生成网站，直到我找到一个替代方案。
这就是我选择 Hugo 的原因。它有一个简单的保护层，可以让你免受依赖关系被破坏的影响。并不是每个人都关心破坏性更改和向后兼容性。项目被放弃，这是使用开源软件的一部分代价。Hugo 简单、可移植，而且是用 Golang 编写的，所以如果它被抛弃，我可以 fork 或修改它。
为什么选择 Netlify
下一个问题是在哪里托管它。当服务器崩溃时，我决定把静态文件转移到一个Amazon Lightsail设置中。这个过程超级简单，而且非常快，我知道，另找一个托管服务器不会更好。
几乎没有理由在 2020 年建立一个完整的 Linux 服务器来托管一个静态网站。
我对于托管设置的要求如下：
必须快必须安全必须能轻松部署因此，我考虑了以下选项：
安装了 Nginx 的另一台 Linux/FreeBSD 服务器Azure Windows VM with IISAWS Amplify 设置Netlify我开始准备服务器并进行测试。我发现，无论如何优化，托管的 Web 服务器都无法跟 AWS 或 Netlify 的速度相比。这部分是由于边缘服务器。我在以下地点测试速度：
波特兰，俄勒冈州杜勒斯，弗吉尼亚州奥兰多，佛罗里达州达拉斯，德克萨斯州旧金山，加利福尼亚圣保罗，巴西伦敦，英国玫瑰山，毛里求斯我在世界各地做了抽样测试，但这些是我最关注的城市。我想看看，所有这些地方中哪里最快。我选择了一个有很多文字和图片的页面。结果让我大吃一惊。
托管的 FreeBSD 服务器和 IIS 服务器速度很快，但在我离开美国后，与 Netlify 和 AWS 就不在一个级别了。我希望所有的网站访问者都能快速浏览，而不仅仅是我身边的人。这是我重点考虑的一个因素。
比速度，Netlify 几乎在每个地区都是赢家。
经过一天中不同时段的长时间测试，Netlify 胜出，AWS Amplify 与之相近。如果我在 AWS 的优质资产上花上一大笔钱，我相信也能取得好成绩，但我这个网站不赚钱，所以那不是我的选择。
看看我的要求，Netlify 全部满足：
速度快（它最快）；安全（据我所知它是安全的）；工作流异常简单。我将我的 Github 库连接到 Netlify。我可以提交到任何分支来存储更改。我能提交到一个开发分支，我可以把它推送到预览。当我把它推送到主干时，它会自动发布到 JeremyMorgan.com。
为什么加载速度如此之快？以下是我的网站加载速度如此之快的原因：
它是一个静态网站；只有 HTML、JavaScript 和 CSS；它比以前轻量化；使用了最少的 CSS 和元素；经过优化的 JPEG 图片；发布之前会压缩；Netlify 真得很快，在哪都很快。综合上面这些因素，我的网站主页加载时间不到一秒，而带有大量图片和文本的页面大约在三秒内加载完毕。超级快。
从用途方面说，网站快速加速非常重要。因为这个网站会提供关于开发的教程和信息，我不希望人们等半天才能看到。我希望，即使在互联网接入较差的国家，这个网站也能正常使用。无疑，Hugo 和 Netlify 帮我实现了这个目标。
关注我并转发此篇文章，私信我“领取资料”，即可免费获得InfoQ价值4999元迷你书！
