lighthouse-ciでGatsbyサイトをビルド毎にパフォーマンスチェックする
この記事は、Webパフォーマンス Advent Calendar 2019の記事です。 Lighthouseを使うことで、PWAやパフォーマンス・SEOに関する項目をチェックすることができます。 が、このような品質チェッ […]
目次
この記事は、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/[email protected]
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などであれば定期実行もできますので、そちらで実行する様にすれば定時計測も可能かもしれません。その場合は計測結果をレポートしたり通知する場所や仕組みが必要になりますので、また何かいい方法が見つかれば紹介します。