个人网站性能优化

本文最后更新于:2022年3月25日 上午

发布新的个人网站

前两天吾辈发布了新版的个人网站,但当时仍然存在一些未解决的性能问题,包括

  • 性能优化
    • 减少依赖数量
      • 砍掉运行时依赖 marked
    • 压缩图片尺寸
    • 添加 .nojekyll 避免 github actions 做无谓的构建
  • 验证工具
    • rollup-plugin-visualizer:检查 bundle 尺寸
    • chrome devtools 中的 lighthouse:测试运行时性能

验证工具

工欲善其事,必先利其器。吾辈主要使用两个工具来测试和验证优化效果

rollup-plugin-visualizer

npm

这是一个集成到 rollup 中的依赖分析工具,它会分析在 bundle 中吾辈的代码与依赖的占比关系,这对找到是哪些依赖需要优化非常重要。

1648171955116

lighthouse

在线版本

这是 chrome 浏览器的自带功能,它能检查出网页的问题,包含阻塞时间、图片过大等问题都是通过这个工具检查出来的。下面是 v1 版本的测试结果,性能简直惨不忍睹,因而 v2 吾辈着力解决这些问题。

1648172483272

性能优化

减少依赖数量

自网站从 v1 => v2 更新以来,减少依赖数量就是一个吾辈重点关注的事情

v1 的直接依赖不多,只有 9 个,但实际依赖项多得多(node_modules 黑洞),去重后有 133 个

  • @fortawesome/fontawesome-free 6.0.0
  • @liuli-util/react-router 0.3.1
  • mockjs 1.1.0
  • normalize.css 8.0.1
  • rc-util 5.18.1
  • react 17.0.2
  • react-dom 17.0.2
  • react-markdown 8.0.0
  • react-use 17.3.2

v2 在上次发布网站时仅有 3 个运行时依赖,首先吾辈第一个砍掉的就是 react,它在小型项目中太大了,classnames 由于是只有 1kb 的工具函数并且需要频繁使用所以保留,marked 则是目前最小、最流行的 markdown 解析器,吾辈需要用它来渲染一些 markdown 片段。

  • preact
  • classnames
  • marked

但其中 marked 仍然占比很大,大约 58%,更致命的是,它是 cpu 密集型的操作,会让 TBT 达到 510ms,这显然是吾辈必须要着手解决的。

1648170006760

在查看了原始项目 bchiang7 v4 之前,吾辈也考虑过在构建时使用插件将 markdown 转换为 html 避免运行时的性能损失,但当然考虑到小的 markdown 片段似乎不方便拆分成单独的 markdown 文件,所以便没有实施。但原始项目也是如此做的,所以吾辈也实践了一下 – 出乎意料的简单,因为只有两个 markdown 片段需要处理,所以吾辈轻而易举的就用 vite-plugin-markdown 解决了这个问题。

现在,它在移动端设备上的性能也是 100 分了!

1648170247717

最终 bundle 尺寸从 2.18M 减小到 58.96k,这确实基本满足了吾辈的期望。

压缩图片尺寸

图片之前吾辈并未刻意关注,后来通过 lighthouse 检查之后采取对其做了压缩,吾辈使用的是 Squoosh。之所以并未使用构建工具插件的原因是图片并不多,而且构建工具适合批量处理但不适合精细调整,例如某些图片需要压缩之后再调整大小。

1648172958949

  • 28 => 19
  • 196 => 56
  • 103 => 28

整体而言图片尺寸优化了 68%,lighthouse 不再报告说图片需要优化的问题。

添加 .nojekyll 避免 github actions 做无谓的构建

做这件事的动机是吾辈感知到了 github pages 的部署变慢了,有时候推送上去却无法在 github deployments 中看到,这让吾辈感觉有点奇怪,于是去检查了一下,发现现在 gh-pages 部署已经走 github actions 的流程了,而 github actions 会分为两个步骤:build => deploy

1648173439512

而在 build 这一步,github 会默认使用 jekyll 来构建

1648173643373

这会减慢一些发布速度,所以吾辈添加了 .nojekyll 来绕过这一步

1648173684396

可以看到,这减少了超过 50% 的构建时间,以后的每次发布都将受益于此。

总结

性能优化是没有尽头的,从 chrome v8 大幅度优化了 js 的性能,到构建工具的编程语言由 nodejs 到 golang/rust,再到连 vue 作者不满 webpack 自行创建 vite 以来,无不证明了这点,吾辈也只是对个人网站做一些小小的尝试罢了。


本博客所有文章除特别声明外,均采用 CC BY-SA 4.0 协议 ,转载请注明出处!