之前的网站设置

大约在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服务器来托管一个静态网站。

我对于托管设置的要求如下：

必须快
必须安全
必须能轻松部署

因此，我考虑了以下选项：

我开始准备服务器并进行测试。我发现，无论如何优化，托管的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帮我实现了这个目标。

英文原文：

How I Got My Website To Load in 1 Second

创作场景

我怎样将网站的加载时间减少 67%？