站点优化记录

本文使用「署名 4.0 国际 (CC BY 4.0)」许可协议，欢迎转载、或从新修改使用，但须要注明来源。 署名 4.0 国际 (CC BY 4.0)

本文做者: 苏洋

建立时间: 2018年10月14日 统计字数: 3902字 阅读时间: 8分钟阅读 本文连接: soulteary.com/2018/10/14/…

---

站点优化记录

还记得十年前，当时就在追求页面在1s内打开，没想到十年后，我依旧在追求页面在1s内打开。

十年里，不论是客户端设备、客户端和服务端网络环境、服务端技术栈、甚至是开发语言技术栈都发生了不小的变化。

此次优化算是清理了几年前的技术债，简单记录一下吧。

第五次重构

若是你对以前的几回重构感兴趣，能够跳转文章尾部开始阅读。

九月的时候，我更新了配置并将运行了几个月的 Traefik 重启，进一步进行数据统计。

十一的时候，我购置了一台新的机器做为 Home Lab ，在将全部已有的服务进行了迁移，同时冗余的资源，能够提供给全部开发项目测试环境和预发验证环境。

在新环境的加持之下，本来完整编译发布的 1 分钟 能够被缩减到 40 秒，若是配合缓存使用，时间能够缩减到 25 秒 以内。

在环境完备以后，我将九月运行至今（42天）的数据下载并进行统计，发现几个有趣的数据 （下面分别是包含、不包含爬虫的数据截图）。

包含爬虫的数据

排除爬虫的数据

• 个别请求响应时间慢
  • 天天接近 200MB 的流量使用，其中有的资源要完整响应客户端，最大响应时间甚至到了 30s，个别例子甚至到了分钟级别，猜想是高频访问时刻，带宽被占满所致。
• 静态资源效率不高
  • 静态资源中，common.css 、 webfont 、core.js 、common.js、sidebar-cover.jpg 请求数量巨大，占用了固定带宽，影响了一部分用户的访问体验，浪费了这部分用户的移动流量。
• 古董浏览器用户很少了
  • 访客操做系统中 Windows、Mac、Android、iOS 等操做系统依次递减。访客浏览器占中 IE 仅占 4.56%，IE 系列中 IE 9 占了 0.85%，其余版本占比低到能够忽略。
• 404 资源须要进行兼容
  • 包含爬虫在内，请求中有 14.18% 的请求出现了404，虽然流量只消耗了 2.97%，可是感受应该进一步下降这个数值，毕竟要提供有价值和意义的内容呈现不是。

下面的截图是未重构前，包含异步加载图片的首页数据。

重构前请求数据

能够看到 384KB 的数据加载，让页面 DOM Ready 延迟到了 300ms， 而页面完整加载硬是拖到了 994ms。

寻遍访问记录，我发现轮播图内容的访问加起来不到 1%，并且脚本中用于适配桌面、移动端设备的轮播代码包含组件库代码(脚本、样式)，加起来接近 3k，延时加载的几张图竟然占用了总流量的 3%，而且前面说到的彻底加载时间被拖慢，这个组件功不可没，简直是猪队友，这种高投入低产出的组件，能够直接干掉。

为了照顾古董浏览器而使用的 jQ 库占用了接近 13% 的流量，结合上面的访客客户端数据，这个基础库该减肥了，在不大规模修改原来程序的基础上，考虑到最小成本替换，因而暂时使用 Zepto 进行了替换，源文件减小 60 KB，GZip 后的文件尺寸 13KB ，而随后清理掉页面加载的一些 inline script，每一个页面的 GZip 后的尺寸又减小了 1KB 。

对于桌面系统展现的侧边栏的图片，占用了超过 10% 的流量，客户端分辨率愈来愈高，可是这个图片却再也不好再进行尺寸上的扩张，一来浪费用户流量，二来仍是投入产出比的问题，因而我使用几张 SVG 化后的图片对它们进行了替换，在 GZip 压缩以后，每张图片只占用不到 10 KB，还可以应对将来分辨率的继续扩张的问题。

在查看页面数据的时候，我发现 common.css 和 Web Fonts 分别占用了总流量的 22.15% 和 13.47%。前者源码竟然 include 了大量未被使用的组件（前几版重构过程当中操做失误）、后者竟然没有使用定制的字体文件。在简单修正以后，两个文件总共减小了 100 KB 以上。至于暂时不使用 SVG SPRITE，我是这样考虑的，虽然将图标和字体放在 SVG 中，甚至合并到页面内容中，可以进一步减小请求，可是势必要引入额外的脚本进行资源挂载，并且渲染性能影响过大，页面DOM复杂度也会提高，还不利于缓存复用。等将来 Web Components 支持进一步完善再说吧。

另外，在处理过程，顺便修正了 Node 和 Hugo TPL 存在的 ReDoS 的问题，如今网站中的多数文章应该都显示正常了。

最后贴一下此次重构的战斗结果（Lighthouse v3.0.3）。

性能跑分

还有请求数据（无缓存）。

重构后请求数据

暂时的缺陷：

• PWA 彻底没有作的状况下，得分 58。
• 无障碍访问 88 分，失分在界面部份内容对比度不足，低分辨率的状况下不知足 WCAG 2 AA 高对比度要到 7:1 的要求。

回顾历史

虽然以前有说过，在去年已经对网站进行了全面升级，抛弃了传统的动态脚本，取而代之的是 Markdown 配合一个 DataBridge 进行全站静态生成，可是网站主题使用的还一直是在淘宝工做时使用的编写的模板。

初版

2014年最初设计模板的时候，其中有几个小功能比较有意思。

• 资源加载全凭前端加载器，配合自动切换不一样源头的资源，能够轻松作到站点资源永不失效。而且会针对不一样的浏览器加载不一样版本的jQ依赖库，从而在知足兼容性处理的状况下，提升执行性能。
• 模块粒度很细，可是入口统一由前端脚本把控，不论脚本、样式，仍是资源，都由页面脚本引入，使用构建工具在编译时，再进行拆分优化。
• 尽量避免 inline resource，每类页面单独具有该页面的脚本和样式，减小编写时须要额外进行命名空间或者书写规避，同时减小爬虫以及用户刷新带来的额外传输损耗，提升资源缓存利用率，提升响应速度。
• 配合修改过的 nginx concat ，能够作到在不更新资源的状况下，动态对页面进行调试。

第二版

随后，随着 gulp 的衰落、webpack 的兴起，Markdown 的流行，BootStrap 的大版本升级，以及 SSL 证书的获取从难到易，CDN 流量从贵到便宜，Hexo 缺少定制，网站服务器架构的变化… 网站又开始了变化。

• 使用 webpack 进行构建，基于 AST 进行资源优化和拆分，替换掉以前使用 AMD 进行资源显示声明以及手写工具的模式。
• 子域名合并，在 SSL 未开始普及的时代，从前普通 HTTP 流量分发，像是七牛、新浪云能够做为低成本、甚至无成本的服务商，可是伴随 HTTP 2.0 到来的 SSL ，若是还继续使用多域名，带来的第一个问题即是你须要申请多个域名的证书（当时泛域名证书很是贵），以及支付不是很便宜的 HTTPS 流量成本。
• Hexo 之类的的静态站点生成器不少，可是当时几乎都须要将文章 Meta 信息写在文章内部，而且对于特定目录结构的站点生成极其不友好，并且性能说实话不是很好。

第三版

2017年的时候，随着 Markdown 工具体验愈来愈好，考虑以后，实在没有必要在坚持使用 WordPress 做为内容管理，因而在博客架构中废弃了 WordPress 。而且当文章数量过千篇以后，Hexo 性能瓶颈愈来愈严重，交付于 CI 系统执行构建，须要消耗太多的资源，因而将其替换为 Hugo。

• 在更换 Hexo 换为 Hugo 前，我曾经挣扎着写过几个 Hexo 的插件，可是性能真的太差了，若是要平常使用，必须准备一台起码 2C2G 的云主机闲置，太浪费了。
• 可是使用 Hugo 以后，失去了对 Node.js 这类容易“编辑执行”的程序能力后，想要达到以前的网站生成结果，除了修改 Hugo TPL外，全部的“花样”便只剩下在构建先后进行文件处理、或者使用客户端完善页面内容了，不过这样反而更加适合交付 CI ，进行彻底自动化。

第四版

今年五一假期的时候，网站在上一个版本的基础上运行了快一年的时间里，当初没有转换清理完毕的文章内容也陆陆续续的补齐了，在补齐内容的过程当中，我进一步抽象了 DataBridge，将来能够轻易切换到更多不一样的静态站点生成工具或者静态发布平台上。

而随着一次次的迭代优化，CI/CD 流程和周边脚本也变的效率愈来愈高， 准备数据 -> 生成站点 -> 处理文件 -> 进行发布，这一套流程从最初的 2 分钟缩减到了1 分钟。

最后

计划接下来再更新一轮，将未添加的 PWA 功能添加完毕，另外完全移除不须要的 Lib 依赖，进一步提升网站呈现速度，而后再尝试可否将网站去中心化，借助不一样服务提供商的 CDN 和 页面内埋入的版本控制脚本，变为“分布式”的网站，或许还会把网站关闭许久的评论功能补回来吧。

— EOF

---

我如今有一个小小的折腾群，里面汇集了一些喜欢折腾的小伙伴。

在不发广告的状况下，咱们在里面会一块儿聊聊软件、HomeLab、编程上的一些问题，也会在群里不按期的分享一些技术沙龙的资料。

喜欢折腾的小伙伴欢迎扫码添加好友。（请注明来源和目的，不然不会经过审核） 关于折腾群入群的那些事

关于折腾群入群的那些事