本文使用「署名 4.0 国际 (CC BY 4.0)」许可协议，欢迎转载、或重新修改使用，但需要注明来源。 [署名 4.0 国际 (CC BY 4.0)](https://creativecommons.org/licenses/by/4.0/deed.zh) 本文作者: 苏洋 创建时间: 2021年11月29日 统计字数: 4297字 阅读时间: 9分钟阅读 本文链接: https://soulteary.com/2021/11/29/site-optimization-log.html ----- # 站点优化日志（2021.11.29） 记录网站最近的一些优化内容。 ## 主要调整内容 - 构建工具持续完善。将原本的构建工具重构为一个新的工具，并将运行时升级到了 Golang [1.17](https://go.dev/doc/go1.17)，缩短了 `2s` 的构建时间；新增一个 Node 工具镜像，能够在[关于本站](https://soulteary.com/about-site/)页面中，动态计算网站的完整统计数据。 - 升级了部分构建系统，将 Drone 1.x 升级到 2.x 版本。 - Hugo 0.82 逐版本升级至 [Hugo 0.89.4](https://github.com/gohugoio/hugo/releases/tag/v0.89.4)，将模版内容和前端部分进行小调整，容器构建性能和前端页面性能微小提升。 - 网站页面模块更新。考虑到现有的[文档归档](https://soulteary.com/archives.html)和[“工作生活”](https://soulteary.com/subject/life/)、[“编程记录”](https://soulteary.com/subject/code/)两个分类页面并不利于按照话题查看全部的相关内容，新增了一个 [“知识地图”](https://soulteary.com/subject/tech/) 页面；将一些远古的，对于读者没有阅读价值的内容进行了“隐藏”处理。 ## 构建工具持续完善 继[四月份的调整](https://soulteary.com/2021/04/12/site-optimization-log.html#%E7%BD%91%E7%AB%99%E6%9E%84%E5%BB%BA%E5%B7%A5%E5%85%B7%E6%9B%B4%E6%96%B0)之后，我将之前所有的 Node 脚本都用 Golang 重写了，除了得到构建性能巨大提升之外，还免除了之前需要维护构建缓存的问题。 然而，当时采取的方案是针对每一个 CI 过程，编写独立的 Golang 工具，并构建独立的镜像。虽然 “CI Stage” 看上去结构非常清晰，但是因为 CI Runner 每多一个阶段任务，就会多使用 Docker 初始化一次容器环境，所以**即使程序执行的再快，在启动容器环境这块还是会浪费一些时间**。所以，在保证构建结果正确，构建过程无“副作用”的前提下，我将一些可以进行合并的构建过程进行了合并，原本连带容器启动、程序执行一共要花费 4～5s 的过程，现在可以只使用 2s 就完成了。 ### 新增的 CI 阶段：统计分析 因为希望在每篇新的文章正式发布时，CI 能够对网站数据进行一个客观的分析，然后以可视化的方式展示出来，所以我添加了一个新的 CI 阶段：分析阶段。 除了想要统计分析网站文章的发布时间和周期、时间阶段之外，我还希望能够针对文章的文字数量进行有效统计。在试用了一众软件之后，我觉得 Office Word 的统计逻辑最为贴近传统的习惯。原本计划继续使用 Golang 来完成，然后在 GitHub 偶然搜索到了一个 [VSCode 插件](https://github.com/holmescn/vscode-wordcount-cjk)，能够计算出和 Office Word 基本一致的结果，于是我就将它的逻辑和规则简单调整，做成了一个新的 Node CI 工具镜像来解决这个分析需求。目前只在正式发布的时候调用程序进行计算，以我目前一千多篇文章来说，完整计算需要十几秒，或许我会考虑在过年的时候，针对它进行一次优化调整，网站最近的分析结果可以在[这里看到](https://soulteary.com/about-site/#%E5%85%B3%E4%BA%8E%E5%86%85%E5%AE%B9%E4%B8%AD%E7%9A%84%E5%85%B3%E9%94%AE%E8%AF%8D)。 ### Golang 1.17 这几个月每次 Golang 的升级，基本都会带来性能的绝对提升。基本上你什么都不用做，只要重新编译一下，就会获得更快的程序。 在慢慢习惯了 Go 这种极端克制的简单符号语言后，我开始想是否能将它复用到浏览器端，于是就出现了最近聊到的两篇有关“[WebAssembly](https://soulteary.com/tags/webassembly.html)”的文章，虽然用 Go 编译 WASM 程序比较反直觉，但是实际实验下来，不论是性能、还是书写成本，都让我比较满意。也算是印证了上一篇站点优化日志中，希望积累有用的设计实践的愿望吧，哈哈。 在本地实验中，我试着做了一些比较好玩的事，比如上文提到的“内容分析”，这种非常重的计算操作：先跑模型分词、然后做可视化展示。或许在那一次更新的时候，我会将这个小功能更新到某一个网站上。 ## 升级构建系统 继之前将构建系统从 GitLab Runner 切换为 Drone CI 后，我先后在 [soulteary/Home-Network-Note](https://github.com/soulteary/Home-Network-Note) 和 [soulteary/zheteng-it](https://github.com/soulteary/zheteng-it) 两个项目上开始使用新版本的 Drone 2.x 进行自动构建。 目前看起来运行状况良好，Drone 2.x 俨然一副 Travis CI 私有化部署的感觉。说起来蛮有意思的，这几年下来，我看到了各种仿造 Travis CI 界面的 CI 产品（有开源软件、也有内部闭源软件），但是多数软件都没有如 Travis 一样能够保持持久的迭代更新。 家里 HomeLab 目前没有升级计划，我对之前的 UI 和程序性能占用都挺满意的。 ## Hugo 0.89.4 算下了持续使用 Hugo [已经四年](https://soulteary.com/2017/06/28/welcome-to-hugo.html)了，一路从 `0.20.x` 升级到了 `0.89.4`，按照目前的开发节奏，估计明年的时候，有望能使用上 1.0 正式版的软件。 说起来，除了前两年在进行跨版本升级的时候出现过问题（[一](https://soulteary.com/2019/02/01/upgrade-hugo-across-versions.html)、[二](https://soulteary.com/2020/11/08/upgrade-hugo-across-versions-2.html)），最近一年以来，Hugo 的更新还算是比较稳定，break change 的事情发生的比较少了。（偶尔发生，因为用户数变多了，反馈更及时，官方回滚操作也就更快了） 而且软件的运行速度也越来越快，[相比较上次](https://soulteary.com/2021/04/12/site-optimization-log.html#hugo-0820)，差不多的构建页面，构建速度快了半秒左右： ```TeXT | EN -------------------+------- Pages | 3714 Paginator pages | 369 Non-page files | 0 Static files | 157 Processed images | 0 Aliases | 2034 Sitemaps | 1 Cleaned | 0 Total in 2484 ms ``` 由于我调整了分页数值，所以虽然几个月下来，生成的内容页面多了，但是总量反而少了几十个页面，不过这几十个页面不会对结果造成太大影响。 ### 网站前端优化 考虑到阅读体验，我将网站前端的样式进行了一些调整，将标题和正文的字号在不同设备下进行了放大，虽然在一些场景下，看着没有之前那么工整，但是整体更“省眼睛”。 我希望文字是有温度的，即使它是偏技术实践的“干货”，所以我将从 2014 年开始，用了许多年的无衬线字体换成了衬线字体。 当然，在调整的过程中，程序相关的文件体积依旧在我的检查列表中。我进一步对之前的基础样式组件、和前端组件进行了裁剪，让基础样式库的尺寸又缩简了不少， 目前整个网站的 CSS 和 JS 脚本在 GZip 的情况下，加起来不到 18KB。 ![近些年不断减肥成功的 Assets](https://attachment.soulteary.com/2021/11/29/bundle-size.jpg) 如果说程序目前还有什么让我不满意的地方，我认为有三点： - 网站在打印模式下展示链接的方案有点傻，我计划写一个小程序来将它编排成类似论文参考的格式。 - 响应式相关处理，存在冗余代码，性能不够高。因为这个程序使用了许多年，所以尽管我不断的优化调整，依旧存在不少冗余代码。或许什么时候，我会大刀阔斧的将这块相关的样式和程序都重写一番。 - 前端程序构建时间不够快，目前构建一次需要 7～8秒。同样和程序使用时间长有关，这套程序最初是由 Webpack 2 构建，在很久之前升级到了 Webpack 3，在之前也曾升级到最新版本，然后配合并行构建来提速，但是输出文件尺寸却大了不少，只好暂时作罢。我目前考虑使用 esbuild 或者自己定制一个编译器，在保证输出内容足够小的情况下，来进行构建加速，直接将构建时间降低到 3 秒之内。 ## 页面模块更新 网站内容采用“时间维度”和“传统的栏目分类”进行内容分类很久了，不论是从统计工具里看到的持续增长的读者数量，还是从搜索引擎里看到的日渐增加的索引量，似乎都在说“It's OK”。那么，为什么还要做这个额外的内容调整呢。 我在统计工具中看到了一个有趣的数字，目前只有 5000 多的用户会持续的翻阅网站中非常多内容。更多的用户是在看了一两页内容之后，就停止了浏览。虽然这个行为其实蛮正常的（对比浏览量更大的技术博客）。但凭借网站搜索关键词和直觉来看，我认为这些离开的用户里，除了得到了想要的内容、或者觉得无聊之外，应该还有一部分人是因为在网站中找不到更多的关联的参考信息，才停止的探索翻阅。 所以，我希望通过一种更清晰、更简单的呈现方式，将内容线索提供给他们。思考再三，我决定额外维护一个“技术关键词”+“工作学习中常见技术问题”的列表页面。希望他们能够在真的解决了问题、或者真的发展这个网站真无聊之后，再离开这里。 而不是通过搜索引擎，或者添加好友之后，再以私信私聊这种显然更低效的方式解决问题。虽然，因为文章结交到高质量的朋友，对我而言是一件性价比更高的事情，但是，这并阻碍帮助读者更快、更直接的获取“技术解决方案”。 ## 最后 先写到这里了，依旧期待下一次的站点升级。 --EOF