lighthouse-ciでGatsbyサイトをビルド毎にパフォーマンスチェックする

この記事は、Webパフォーマンス Advent Calendar 2019の記事です。

Lighthouseを使うことで、PWAやパフォーマンス・SEOに関する項目をチェックすることができます。

が、このような品質チェックは、本来定期的に行うことが重要です。

定期的にモニタリングすることで、現状が以前より良化しているのか悪化しているのか、なにが原因と思われるかなどを判断しやすくなります。

が、手動で計測というのはなかなか現実的ではありません・・・

GatsbyなどのStatic Site GeneratorやSPAでは、lighthouse-ciを利用することで「コミット・push・PR」などの粒度で自動的にLighthouseのチェックを走らせることができます。

環境情報

$ npm -v
6.9.0

$ node -v
v10.16.0

$ gatsby -v
Gatsby CLI version: 2.8.18

$ lhci --version
0.3.7

Gatsbyで計測対象サイトをセットアップ

まずは計測対象のサイトを作りましょう。

$ gatsby new
✔ What is your project called? … lhci-react
✔ What starter would you like to use? › gatsby-starter-blog

一応サイトもみてみます。

$ cd lhci-react
$ gatsby develop

ブラウザからLighthouseをまわすとこんな感じでした。

lighthouse-ciでローカルCLIからチェック

続いてローカルのCLIからlighthouseをまわしてみます。

LighthouseのCLIもありますが、あとで使うのでここからもうlighthouse-ciのほうを使っちゃいます。

// CLIをインストールして
$ npm i -g @lhci/cli

// サイトをビルドして
$ gatsby build

// Lighthouseを実行
$ lhci autorun
✅  .lighthouseci/ directory writable
⚠️   Configuration file not found
✅  Chrome installation found
Healthcheck passed!

Automatically determined ./public as `staticDistDir`.
Set it explicitly in lighthouserc.json if incorrect.

Started a web server on port 56329...
Running Lighthouse 3 time(s) on https://localhost:56329/404.html
Run #1...done.
Run #2...done.
Run #3...done.
Running Lighthouse 3 time(s) on https://localhost:56329/index.html
Run #1...done.
Run #2...done.
Run #3...done.
Done running Lighthouse!

起動結果はこの様になりました。

Checking assertions against 2 URL(s), 6 total run(s)

2 result(s) for https://localhost:56329/404.html

  ⚠️  redirects-http warning for minScore assertion
     Does not redirect HTTP traffic to HTTPS
     Documentation: https://web.dev/redirects-http

        expected: >=1
           found: 0
      all values: 0, 0, 0


  ⚠️  uses-http2 warning for minScore assertion
     Does not use HTTP/2 for all of its resources
     Documentation: https://web.dev/uses-http2

        expected: >=1
           found: 0
      all values: 0, 0, 0

2 result(s) for https://localhost:56329/index.html

  ⚠️  redirects-http warning for minScore assertion
     Does not redirect HTTP traffic to HTTPS
     Documentation: https://web.dev/redirects-http

        expected: >=1
           found: 0
      all values: 0, 0, 0


  ⚠️  uses-http2 warning for minScore assertion
     Does not use HTTP/2 for all of its resources
     Documentation: https://web.dev/uses-http2

        expected: >=1
           found: 0
      all values: 0, 0, 0

All results processed!

Done running autorun.

http -> httpsのリダイレクトと、HTTP/2を利用していないことについてのwarningですね。

ローカル実行でこれ対応する方法はちょっとよくわかりませんが、web.devのドキュメントURLが各項目についているのは便利ですね。

GitHub ActionsでLighthouseを実行

次はいよいよCI上でLighthouseを実行します。今回はGitHub Actionsを利用しました。

設定ファイルを以下の様に作成して追加します。

$ mkdir -p .github/workflows
$ vim .github/workflows/lhci.yml
name: Build project and Run Lighthouse CI
on: [push]
jobs:
  lhci:
    name: Lighthouse CI
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v1
      - name: Use Node.js 10.x
        uses: actions/setup-node@v1
        with:
          node-version: 10.x
      - name: npm install, build
        run: |
          npm install
          npm run build
      - name: run Lighthouse CI
        run: |
          npm install -g @lhci/cli@0.3.x
          lhci autorun --upload.target=temporary-public-storage || echo "LHCI failed!"

この状態でpushすると、GitHub側でActionが発火してテストが始まります。

ひとまずこれで、Gatsby上での更新によってLighthouseの点数が落ちたか落ちてないかという確認はできそうです。

おわりに

GatsbyなどのStatic Site Generatorで作られたサイトであれば、コミット毎にLighthouseなどでの計測を行うことで、「どのコミットで何がおきたか」を追跡しやすくなります。

もちろんブラウザ上での非同期処理やCDN経由のJS / CSSなどを利用しているなどの場合には、外部要因が発生するため、コミット単位の計測だけでは計測が難しいかもしれません。

ただ、「不定期に人力でブラウザからLighthouseを実行して、その結果を見ながら対策を考える」という状況よりは、そのサイトで何がおきているかを確認・把握して対策を立てやすいのではないかと思います。

Travis CIやAWSのCodeBuildなどであれば定期実行もできますので、そちらで実行する様にすれば定時計測も可能かもしれません。その場合は計測結果をレポートしたり通知する場所や仕組みが必要になりますので、また何かいい方法が見つかれば紹介します。