2

个人网站性能优化

 2 years ago
source link: https://blog.rxliuli.com/p/8c832a14b75a4d50b6916882518dcec0/
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

发布新的个人网站

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

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

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

rollup-plugin-visualizer

npm

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

lighthouse

在线版本

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

减少依赖数量

自网站从 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,这显然是吾辈必须要着手解决的。

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

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

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

压缩图片尺寸

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

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

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

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

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

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

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

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

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


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK