Day03 X Performance Analyzers feat. Lighthouse-CI

经过昨天，我们明白了效能对於前端应用的重要性，但是，我们要怎麽评估一个网站的效能呢？用感受的吗？自己使用这个网站时还算顺畅就定义为这是一个效能很好的网站吗？当然不是，我们还得考虑网站使用者的网路环境，如果今天网站使用者所在的区域网路速度非常缓慢，他还会觉得网站效能非常好吗？再者，就算对所有用户而言网站的体感效能都很好，如果搜寻引擎判断出来网站效能是不好的，那麽 SEO 还是有可能不会有一个好分数。

今天就要来介绍几个知名且专业的网站速度分析工具，它们使用一些特定且公认的指标来检测网站的效能，是 Web 开发者不可或缺的好帮手。

今天介绍三个检测网站的工具给各位读者：

• Google PageSpeed Insights
• WebPageTest
• Lighthouse

今天我会快速带过前两个工具，而 Lighthouse 的部分会额外介绍我觉得十分有趣的 lighthouse-ci，建议读者可以三个工具都亲自去玩玩看。

Google PageSpeed Insights

网址：https://developers.google.com/speed/pagespeed/insights/?hl=zh-TW

使用起来很简单，把需要检测的网址带进去输入框就好。这边为了方便 demo，我使用一个之前做到一半就不做的没用网站当作示范。

可以看到 PageSpeed 算出了手机版网站的分数，并给出了分数的等级区间，我们还可以切换查看电脑版网页的分数

再来可以看到分数下面提供了一些指标与它所花的时间，至於这些指标代表什麽，我们会在明天有详细的解说。

PageSpeed 也提供了一些资源的统计还有档案大小

值得一提的是，PageSpeed 背後其实也是根据等等要介绍的 Lighthouse 分析的研究资料计算出分数的

其实论资料的完整性与多元性，Lighthouse 是完胜 PageSpeed 的，不过等等介绍到 Lighthouse 就会发现，它的使用方式比起 PageSpeed 不方便许多，所以我自己认为 PageSpeed 的优点在於它非常容易使用，甚至想用手机检测看看一个网站的效能也只要打开浏览器就做得到罗！

WebPageTest

网址：https://www.webpagetest.org/

WebPageTest 似乎在这两年内对介面做了相当大的改版，功能选项也变得更多了，我认为它最大的优势就是「可以轻松检测网站在不同浏览器下的状况」。Lighthouse 与 PageSpeed Insights 毕竟是 Google 研发的工具，想当然一定是对 Chrome 有最好的支援，虽然说 Lighthouse 据说也可以跑在不同 Browser 环境，但 trace 了一下发现坑非常多。

WebPageTest 在使用上也满直觉的，也提供不同的检测等级，不过我自己使用後的心得是-它检测的速度真的有点缓慢。
这边就不多花篇幅赘述，有兴趣的读者可以自行体验看看。

Google Lighthouse

Lighthouse 是我最常使用也最推荐的一个工具，介面图表与网站检测後的资讯都十分完整，除了效能以外，还提供如 Accessibility、Best Practices、SEO，甚至还可以帮网站检测是不是有符合 PWA 的标准。

使用 Lighthouse 的方式有两种，第一个是安装 Lighthouse 的 Chrome Extension，并在想要检测的网站上点开 extension 的 generate report

另一种使用方式是在 Devtool 使用 Lighthouse

我觉得 Lighthouse 很实用的一点是除了给出各指标的分数以外，它也会给出明确可以让分数提升的建议

除了资讯比较完整以外，Lighthouse 操作方式与前面提到的 PageSpeed、WebPageTest 没有太大的区别，一样建议读者亲自去体验看看。不过今天还想花最後一点篇幅跟各位介绍一个可以与版本控制系统结合的的自动化网站检测 CI Tool -- lighthouse-ci。

lighthouse-ci

网址：https://github.com/GoogleChrome/lighthouse-ci

目前为止介绍的检测工具都是针对已经部署完成的网站做评估，然而网站一次推版部署可能就涵盖了非常多的 PR 与 commit，要是效能真的大幅度下滑，我们要 trace 究竟是哪个改动造成的效能瓶颈也会有点困难（当然也可以每个 PR 都 deploy 一个用来测试的网站，不过仍然要自己喂到 lighthouse 里，终究还是太麻烦了）。lighthouse-ci 让开发者可以将 lighthouse 检测网站指标的功能与 CI/CD workflow 结合，除了每次 Push 或是每次建立 Pull Request 时都可以自动化跑 lighthouse 检测以外，甚至还可以更细致地做到检测「每一次 commit 造成的指标分数变化」。

如果不熟悉 CI/CD 概念的读者可以参考这里
接下来的 demo 会使用 github actions，如果不熟悉的读者可以参考我之前写的一篇介绍 github actions 的文章

Talk is cheap, show me the demo !

光是讲概念恐怕还是太抽象了，不如就来个简单的 demo 吧！

我选择使用 github 来管理我的程序码，虽然说要跑 CI，当然也可以自己架例如 Jenkins 的 CI server，不过现在其实有非常多的 CI Provider 可以选择，再来既然都用 github 了，就使用整合度非常高的 github actions 当作 CI Runner 吧。

在今天的 demo 里，我们希望做到：

1. 每次 push 时都会自动跑 Lighthouse，如果没有达到自己定义的指标，CI workflow 会显示 failed。
2. 每次发 Pull Request 时也会自动跑 Lighthouse status check，如果自定义的指标没有达到，那 PR 里的 status check 就会显示 failed。

为了要做到每次发 Pull Request 都可以跟 lighthouse-ci 做整合，我们得先安装 lighthouse-ci 的 github app，安装完成後会看到像下面的画面，会显示一串 token

到 github repo 的 settings -> secrets 把 token 加进去 secret value。

接下来开始撰写 github actions 的 config 档，在 project 的 root 建立 ./github/workflows/lighthouse-demo.yml

name: Ironman challenge lighthouse-ci demo
on: [push]
jobs:
  lhci:
    name: Lighthouse CI
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v1
      - name: Use Node.js
        uses: actions/setup-node@v1
        with:
          node-version: 12.x
      - name: npm install, build
        run: |
          yarn
          npm run build
      - name: run lighthouse-ci
        run: |
          npm install -g @lhci/[email protected]
          lhci autorun --upload.target=temporary-public-storage || echo "LHCI failed!"
        env:
          LHCI_GITHUB_APP_TOKEN: ${{secrets.LHCI_GITHUB_APP_TOKEN}}

详细指令就不多赘述了，如果看不懂的读者建议先看我先前贴的关於 github actions 的文章喔～
简单来说就是每次 push 到 github 时都会跑 lighthouse-ci，记得要在最後带上刚刚在 github 上设定的 secret。

既然绑到 CI workflow 上了，我们应该会希望除了单纯呈现分数以外，还能够设定一些规则，让 CI workflow 或是 PR status check 在 lighthouse 跑完後如果有没有达到标准的时候可以让 workflow 或 status check failed，让开发者可以在 code review 阶段就发现可能造成的影响。

在 project 的 root 新增 .lighthouserc.json

{
  "ci": {
    "assert": {
      "preset": "lighthouse:no-pwa",
      "assertions": {
        "categories:performance": [
          "warn",
          { "aggregationMethod": "optimistic", "minScore": 0.93 }
        ],
        "categories:accessibility": [
          "error",
          { "aggregationMethod": "optimistic", "minScore": 0.95 }
        ]
      }
    }
  }
}

这边简单设定说如果跑完 lighthouse 後发现 performance 分数掉到 93 分以下，就要显示 warning，若 accessibility 分数掉到 95 分以下，就会显示 error。

lighthouse-ci 提供非常多样的 config 条件，完整的 config properties 可以参考官方文件。

最後就可以看到 github 的 CI workflow 与 PR 的 status check 都会自动跑 lighthouse 的检测了。如果没有通过我们刚刚设定的 assertions 条件，就会显示 failed 来提醒开发者要注意罗！

当点选 detail，可以看到这个 PR，甚至是 commit 层级，造成的 Lighthouse 各个指标的变化，是不是很酷啊。

Demo Code: https://github.com/kylemocode/it-ironman-2021/tree/master/lighthouse-ci-demo

本日小结

今天介绍了常见的几个网站检测工具，可以让我们较客观的去分析网站的效能，除了效能以外，各种工具也会提供其他指标例如 security、SEO，并且提供改进的建议，是提升网站品质的好帮手。另外也介绍了 lighthouse-ci，将网站检测绑定到自动化的 CI workflow 中，使开发者可以在网站正式上线以前就先发现可能会造成网站效能瓶颈的改动，真的是太强大啦！建议各位读者都可以亲自去玩玩看，毕竟今天的 demo 也仅仅示范皮毛而已呢！

也许许多读者目前还看不懂这些检测工具报告上的各项指标，别担心，明天将会为各位详细说明衡量网站的一些重要指标，明天见罗！

Reference

https://github.com/GoogleChrome/lighthouse-ci
https://github.com/GoogleChrome/lighthouse-ci/blob/main/docs/introduction-to-ci.md
https://web.dev/lighthouse-ci/