我如何让我的网站在 1 秒内加载

大多数情况下，来自世界各地的JeremyMorgan.com首页的加载时间都少于一秒。

以前网站速度很快，用旧设计的时候3秒就能加载完。现在速度更快了，我会向你展示我是如何设置的。

我选择用Hugo搭建这个网站，并将其托管在Netlify上。在本文中，我将描述我是如何做出这个决定的。

旧网站设置

大约在 2011 年左右，我决定从 Wordpress 迁移到静态网站生成器。我的理由很简单：我写了一篇文章，发布后就很少修改了。这显然不足以证明需要通过数据库提供服务。因此，建立一个为每篇文章生成 HTML 页面并以静态方式提供的系统是合理的。

我决定使用Octopress，它当时是Jekyll的一个非常流行的包装器，并且对我很有用。

仅此一步就大大缩短了我的加载时间。之后，我开始对页面加载速度有点着迷，并做了很多事情来确保它快速加载，包括：

• 图像优化（我使用的一些工具）
• CSS 和 JavaScript 的精简
• 对某些资产使用 CDN

我对这个设置非常满意。多年来，我的工作流程是新建一篇文章，在笔记本或台式机上生成，然后将文件通过 SCP 上传到运行 Nginx 的 FreeBSD 服务器上。这种工作方式持续了很长时间。现在回想起来，那真是一个糟糕的工作流程，但我每隔几个月才写一篇文章，所以它还算管用。

我花了很多年定制我的安装并为 Octopress 项目贡献代码和修复。

问题堆积如山

尽管我最初很喜欢 Octopress，并且很欣赏Brandon Mathis和其他人所做的一切工作，但 Octopress 开始变得非常麻烦。

对我来说，最大的问题并非 Octopress 本身，而是 Ruby 依赖的噩梦。我不会过多地谈论它，但它变得非常难以管理。Octopress 需要较旧的 gem 才能运行，因此随着 Ruby 和某些 gem 的更新，维护一个可构建的 Octopress 安装变得愈发困难。

由于需要维护所有旧软件，我无法再用笔记本电脑进行构建。我搭建了一个装有旧软件的 Linux 服务器，并用它来构建。之后，我把所有东西都移到了一个容器中，这样我就可以维护旧版本的 Ruby 和那些用于生成输出的 gem。例如，你不能运行1.9.3以上的 Ruby 版本。

所以几年前我开始研究解决方案，但一直没能真正实现。几年来，我的工作流程大致如下：

还好，但这次操作的致命弱点始终是 Octopress 的构建，这一点我很清楚。只要我不碰任何东西，为了一个简单的构建步骤而维护所有旧软件就很容易了。

上个月，我的服务器坏了。那台服务器正在构建 Octopress 镜像。于是我又启动了另一台服务器，安装了 Docker 和容器，但还是不行。我试了所有能想到的办法，问题终于解决了。

我可以花费数小时使用古老的软件构建另一个容器来使 Octopress 工作，或者我可以花时间更换另一个 CMS。

因此我开始认真评估另一个静态站点生成器的选项。

我为什么选择 Hugo

我花了很多时间评估不同的方案。我将在以后的文章中更详细地讨论，但最终得出以下几点：

• 雨果（围棋）
• 盖茨比(JavaScript)
• 鹈鹕（Python）

这些都是静态网站生成器，它们都能很好地解决我的问题。我懂 Go、JavaScript 和 Python，所以我可以修改一些东西。这只是一个普通的博客，由一组结构化的文件组成。这些都可以用。但我的需求是什么呢？

• 静态文件生成器
• 必须快速建造
• 必须易于定制
• 必须是可移植的（Mac、OSX、Linux）

最后一点可能看起来有点傻，但我从来不知道写作时会用什么平台。我可能用的是 Mac、Windows 或 Linux，这取决于我写的内容以及我在哪里截屏。我希望在本地构建和查看页面，然后再推送到开发环境，最终发布到生产环境。所以这对我来说很重要。但经过多次评估后，我发现了以下几点：

所有这些静态文件生成器都满足了这些需求。

所以选择起来很困难。我搭建了一个 JeremyMorgan.com 的版本，并在所有平台上都使用了这三个生成器，运行起来毫无问题。我可以自定义一些功能，而且它们都能快速生成页面。但我必须选择一个。

我最终选择了Hugo，因为担心再次陷入依赖地狱。Gatsby 很酷，功能也很强大，但对于我正在做的事情来说似乎过于复杂。它还依赖 JavaScript 生态系统中的大量依赖项，而 JavaScript 生态系统以随时可能做出重大更改而闻名。

Pelican 依赖于 Python 生态系统，而 Python 生态系统的稳定性要好得多，因此它紧随其后。而 Hugo 则是基于可执行文件构建的。因此，即使 Hugo 被废弃或依赖关系开始崩溃，我也可以一直使用可执行文件来生成网站，直到找到替代方案。

这就是我选择 Hugo 的原因。它有一层简单的保护机制，可以防止依赖项丢失。并非所有人都关心重大变更和向后兼容性。项目会被放弃，这是开源软件的代价之一。Hugo 可移植、简单，并且使用 Golang 编写，所以如果它被放弃，我可以直接 fork 或修改它。我对我的选择很满意。

我为什么选择 Netlify

下一个问题是把它托管在哪里。我的服务器崩溃后，我决定把静态文件迁移到 Amazon Lightsail 上。这非常简单快捷，但我知道另一个托管服务器并不是最佳选择。

在 2020 年，几乎没有理由设置整个 Linux 服务器来托管静态网站。

我对托管设置的要求：

• 必须快
• 必须安全
• 必须是我可以轻松部署的东西

于是我仔细研究了一下我的选择。以下是我考虑的：

• 另一个带有 Nginx 的 Linux/FreeBSD 服务器
• 带有 IIS 的 Azure Windows VM
• AWS Amplify设置
• Netlify

我开始组建服务器并进行测试。我发现，无论我如何优化，托管的 Web 服务器根本无法跟上 AWS 或 Netlify 的速度。这部分是由于边缘服务器造成的。我从以下位置测试了速度：

• 俄勒冈州波特兰
• 弗吉尼亚州杜勒斯
• 佛罗里达州奥兰多
• 德克萨斯州达拉斯
• 加利福尼亚州旧金山
• 巴西圣保罗
• 英国伦敦
• 毛里求斯玫瑰山

我在世界各地做过抽样测试，但这些是我最关注的城市。我想看看所有城市中哪个城市的整体速度最快。我选择了一个有很多文字和图片的页面。结果让我很惊讶。

托管的 FreeBSD 服务器和 IIS 服务器速度很快，但在我离开美国后，速度就无法与 Netlify 和 AWS 相比了。我希望所有网站访问者都能快速访问，而不仅仅是我附近的访客。这对我来说是一个重要的考虑因素。

Netlify 在几乎所有地区都是速度赢家。

经过一整天不同时间的长时间测试，Netlify 最终胜出。AWS Amplify 的表现也相当接近。如果我在 AWS 优质资产上投入大量资金，我相信我能超越它，但我不会靠这个网站赚钱，所以这是不可能的。

因此，从我的要求来看，Netlify 满足了所有要求。

• 速度很快（最快）
• 它是安全的（根据我找到的所有信息）
• 工作流程非常简单。

使用 Netlify，我将我的 Github 仓库连接到了它。我可以提交到任何分支来存储更改。我可以提交到开发分支，并将其推送到预览版本。当我推送到主分支时，它会自动发布到 JeremyMorgan.com。

为什么加载时间这么快？

Pexels上的Daniel拍摄的照片

这就是该网站加载速度如此之快的原因。

• 这是一个静态网站。仅包含 HTML、JavaScript 和 CSS
• 它不再像以前那么混乱
• 我使用最少的 CSS 和元素
• 优化的 JPEG 图像
• 发布前已最小化
• Netlify 速度非常快，可以在任何地方快速提供服务

这就是我的秘诀。这些因素的结合意味着我的网站主页加载时间不到一秒，图片和文字较多的页面加载时间大约为三秒。超级快。

我的网站加载速度对我来说很重要，因为它服务于特定的目的。我提供开发方面的教程和信息，我不希望人们为了浏览而等待。我希望我的网站在网络覆盖较差的国家也能正常访问。Hugo 和 Netlify 帮助我实现了这个目标。

如果您想设置类似的功能并有任何疑问，请随时联系我，我会分享我的经验。
我优化网站速度的工作还没有完成，以后我会分享更多技巧！