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

简介: 在大多数情况下, JeremyMorgan.com 网站的首页在世界各地的加载时间都不到一秒。

云栖号资讯:【点击查看更多行业资讯
在这里您可以找到不同行业的第一手的上云资讯,还在等什么,快来!

在大多数情况下, JeremyMorgan.com 网站的首页在世界各地的加载时间都不到一秒。

daacc21e6d21b09b914241b7d49c1df9

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

1693f4cf9a9cc4c854693724c7e57da7

我选择使用 Hugo 构建这个网站,并托管在 Netlify 上。

之前的网站设置

25b76ae2e563948c6df535c16bd0867c

大约在 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 。

所以,我几年前就开始研究解决方案,但一直没有时间去切换。几年来,我的工作流程是这样的:

03c8a623a9b97a8250df5aad591ef030

还不错,但这个过程有个致命缺点,就是 Octopress 构建,我知道这一点。为一个简单的构建步骤维护所有这些旧软件很容易,但前提是我不碰任何东西。

上个月,我用于构建 Octopress 镜像的服务器坏了。所以我启用了另一台服务器,安装了 Docker 和容器,但它无法工作。我试了我能想到的所有方法,事实很清楚:

我可以花数小时用这些古老的软件构建出另一个容器来让 Octopress 运行起来,或者我能把时间花在更换到另一个 CMS 上。

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

为什么选择 Hugo

4ba2e115f91dd49b8d3cbfdfdf50eb55

我花了很多时间来评估不同选项,归结起来就是以下几个:

  • 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

b2da68349265db89b58d5e8f740bbb3d

下一个问题是在哪里托管它。当服务器崩溃时,我决定把静态文件转移到一个Amazon Lightsail设置中。这个过程超级简单,而且非常快,我知道,另找一个托管服务器不会更好。

几乎没有理由在 2020 年建立一个完整的 Linux 服务器来托管一个静态网站。

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

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

因此,我考虑了以下选项:

  • 安装了 Nginx 的另一台 Linux/FreeBSD 服务器
  • Azure Windows VM with IIS
  • AWS 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 帮我实现了这个目标。

【云栖号在线课堂】每天都有产品技术专家分享!
课程地址:https://yqh.aliyun.com/live

立即加入社群,与专家面对面,及时了解课程最新动态!
【云栖号在线课堂 社群】https://c.tb.cn/F3.Z8gvnK

原文发布时间:2020-04-15
本文作者:jeremymorgan
本文来自:“InfoQ”,了解相关信息可以关注“InfoQ

相关文章
|
2月前
|
缓存 监控 前端开发
SPA 首屏加载速度优化
【10月更文挑战第14天】解决 SPA 首屏加载速度慢的问题需要综合运用多种优化策略和技术。通过资源压缩、减少异步请求、优化渲染流程、利用缓存、代码分割、预加载等方法,可以有效提高 SPA 首屏加载速度,为用户提供更好的体验。同时,性能监控和分析是持续优化的关键,应根据实际情况不断调整优化策略。在未来,随着技术的不断发展,我们还需要不断探索新的优化方法和途径,以适应不断变化的需求。
|
2月前
|
缓存 前端开发 网络协议
优化网站的加载速度
【10月更文挑战第8天】优化网站的加载速度
19 3
|
7月前
|
Oracle 数据库 UED
后台查询接口影响响应时间最大的因素:用空间换时间的优缺点及解决方案
1.当数据库的一个表记录很多显然查询数据很慢。 2.当数据库的一个表记录不大,但是数据很大也可能很慢。 我们的一个用户表中一个building很大,当查询100条数据就会把服务器的内存搞爆掉。 当然查询时要查询筛选有用字段,不可以直接把记录的所有字段都查拆来。这样能减少内存消耗和提高查询速度。 3.在经常查询字段上建立索引。据说oracle上用索查询和不用索引查询在超多记录的情况下相差1000倍。 4.若出现嵌套查询显然会大大增加相应查询时间。要先预处理用管道操作把能合并的查询合并到一个查询中,然后生成map,然后再处理。这是标准的用空间换时间的方案。
99 8
|
7月前
|
缓存 前端开发 JavaScript
|
3月前
|
缓存 前端开发
SPA首屏加载速度慢的怎么解决?
SPA首屏加载速度慢的怎么解决?
35 0
|
5月前
|
缓存 前端开发 JavaScript
如何减少页面加载时间
如何减少页面加载时间
52 1
|
7月前
|
缓存 数据安全/隐私保护 UED
深入了解304缓存原理:提升网站性能与加载速度
深入了解304缓存原理:提升网站性能与加载速度
|
前端开发 JavaScript API
MonacoEditor 加载很慢该怎么优化?
MonacoEditor 加载很慢该怎么优化?
1527 0
|
7月前
|
缓存 前端开发 JavaScript
SPA首屏加载速度慢怎么解决
SPA(单页面应用)的首屏加载速度慢可能是由于以下几个方面造成的:
89 0
|
7月前
|
缓存 前端开发 JavaScript
面试官 : 首屏加载速度慢怎么优化?
面试官 : 首屏加载速度慢怎么优化?