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

文章插图

本文最初发布于 Hacker Noon 博客，经原作者授权由 InfoQ 中文站翻译并分享。
在大多数情况下，JeremyMorgan.com 网站的首页在世界各地的加载时间都不到一秒。

文章插图

这个网站的速度之前就很快，3 秒钟就可以加载完成，但现在更快了。我将在本文中披露我是怎么设置的。

文章插图

我选择使用 Hugo 构建这个网站，并托管在 Netlify 上。
之前的网站设置

文章插图

大约在 2011 年的某个时候，我决定从 wordPress/ target=_blank class=infotextkey>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 和容器，但它无法工作。我试了我能想到的所有方法，事实很清楚：