本文使用「署名 4.0 国际 (CC BY 4.0)」许可协议，欢迎转载、或重新修改使用，但需要注明来源。 [署名 4.0 国际 (CC BY 4.0)](https://creativecommons.org/licenses/by/4.0/deed.zh)

本文作者: 苏洋

创建时间: 2021年04月12日
统计字数: 2568字
阅读时间: 6分钟阅读
本文链接: https://soulteary.com/2021/04/12/site-optimization-log.html

-----


# 站点优化日志（2021.04.12）

记录网站最近的一些优化内容。



## 主要调整内容

- 构建系统迁移，由 GitLab Runner 变更至 [Drone CI](https://www.drone.io/)
- 网站构建工具更新，将几年前的 Node 脚本由 [Golang 1.16.0](https://golang.org/doc/go1.16) 重写
- Hugo 0.79 升级至 [Hugo 0.82.0](https://github.com/gohugoio/hugo/releases/tag/v0.82.0)
- 网站前端优化

## 构建系统迁移

和我相熟的朋友应该了解我从差不多十年前刚刚开始工作就在使用 GitLab，在随后的职业生涯里也经历了多家公司迁移使用 GitLab ，甚至自己也影响了其中两家公司在 GitLab 以及 GitLab Runner 在生产环境中的落地使用。

之所以要进行迁移，有一些原因：

我们期望系统交互，尤其是仓库下载使用 SSH 协议而非 HTTP 协议，官方 Runner 默认不支持这种方式交互，为此我编译了一个简单的定制版本，支持这种方式进行交互。如果你对 Runner 编译感兴趣，两年前[《源码编译 GitLab Runner》](https://soulteary.com/2019/08/04/source-code-compilation-gitlab-runner.html)一文中，有提到如何编译。而 Drone 的代码拉取等步骤都在容器中执行，简单配置下 `alpine/git` 镜像即可解决这个事情。

如我在“[第一个双月总结](https://soulteary.com/2021/03/06/summary-of-the-first-bimonthly-in-2021.html)”中提到的，我们期望更高频度的 CI 交互，以及相对轻量的仓库及 CI 服务，能够让 CI 在更早的时候发生，进一步减少在线上部署集成时遇到问题的可能性，提升交付效率和交付能力。相比较 GitLab 动辄几个GB的内存占用，和待机大百分比的 CPU 消耗来看，Gitea + Drone 长期运行使用的内存资源几乎可以忽略，CPU 待机状态只消耗 1% 甚至更少，至于团队协作和 PR / MR Review ，我计划引入一个新的工具来解决问题，暂且不提。

以及我们对 GitLab 中国公司落地的一些隐忧，担心出现 EverNote、印象笔记“分家”，以及国内运营后类似的问题。

所以，我开始尝试使用 Gitea + Drone 替换之前个人使用已久的 GitLab，目前运行三周有余，状况良好，如果接下来稳定性 OK，我们将尝试进行线上服务替换。

## 网站构建工具更新

在[关于网站](https://soulteary.com/about-site/)中有记录，2017年6月，我将网站架构进行重写，当时使用 Node 写了绝大多数 CI 工具，在 2019年1月的时候，随着网站内容的增多，构建速度有所降低，所以我重构了构建工具，并添加了各种缓存以提升构建速度。

上面的方式虽然能够解决问题，但是也产生了两个潜在的问题：

1. 工具的稳定性存在一定的风险。工具内的 NPM 依赖存在随着时间而被废弃维护，甚至和 Node 运行时不兼容的问题。解决方式要么得进行私有化仓库搭建，以及对应老版本软件包的持续缓存托管，要么得固定某一个 Node 运行时的版本，而无法享受版本升级带来的性能提升。最佳妥协方案是将一个可运行版本打包至容器镜像内，然后容忍上述问题，“安心使用”下去。
2. 资源使用率不够高。面对每次 CI 过程中几千文件的密集读写，Node 执行性能虽然满足场景需求，但是对于资源使用效率并不是特别好，相对直观的感受是全量构建时，机器风扇会瞬间起飞一下。

恰好赶上切换构建系统，于是趁着机会用 Go 重写了之前的 Node 工具，目前镜像尺寸缩小了 100倍以上（由近1G的镜像缩小到了几MB），执行性能提升了90%以上，因为性能足够高，每个阶段完整构建都在1～2秒左右，所以我可以将之前的缓存设计直接干掉，进一步减少维护成本。

另外，因为执行效率足够高，风扇根本来不及起飞，依赖平时的转速散热就足够了。

## Hugo 0.82.0

[去年年底](https://soulteary.com/2020/12/06/site-optimization-log.html)将 Hugo 升级到了 0.79.0 ，这次升级顺便将 Hugo 进一步进行了升级。带来比较直观的提升是生成 6000 个页面文件，只需要不到 3秒。

```TeXT
Start building sites … 

                   |  EN   
-------------------+-------
  Pages            | 3597  
  Paginator pages  |  732  
  Non-page files   |    0  
  Static files     |  158  
  Processed images |    0  
  Aliases          | 1861  
  Sitemaps         |    1  
  Cleaned          |    0  

Total in 2950 ms
```

## 网站前端优化

之前在页面构建过程中，会调用一个代码高亮接口，针对页面代码内容进行高亮着色。在思考再三，我决定使用 Hugo 内置代码高亮来进行功能替换。

目前 Hugo 已采用 [Chroma](https://github.com/alecthomas/chroma) 来进行代码高亮，后续如果有需要，可以将这部分功能迁移到网站构建工具中，进行更深入的定制。

在使用了新版本的代码高亮和构建工具后，网站首页 GZip 后的传输量降低了 20%。内容页面的传输量降低了 50%。

![左侧页面基准性能各提升了 0.1s](https://attachment.soulteary.com/2021/04/12/lighthouse-score.png)

虽然页面性能总体分数没有变化，但是页面基础绘制性能相比较上次均提升了 0.1s，接下来试试挑战 0.3s 之内。

### Golang 1.16.0

上次优化日志，还在等待 Node v16 正式版本的发布。没想到这篇记录中，等到的会是 Golang 的v1.16版本。

关于执行性能前文已经提过了，非常完美，应该是除了 C++、Rust 之外，兼顾开发效率和性能的最佳选择了。当然，异常处理这块真的是无力吐槽。

期望在接下来的使用中，可以积累一些长期有用的设计实践吧。

## 最后

这次先写到这里吧。

期待下一次的站点升级。

--EOF