パフォーマンス診断ツールLighthouse CIの4機能を試してみた

Published in

nextbeat-engineering

17 min readOct 21, 2022

こんにちは！
ネクストビートでWebエンジニアとして働いている米澤です。
業務では、宿泊業界特化の人材紹介サービス「おもてなしHR」の開発に携わっています。

Webページのパフォーマンスを確認する際に、Lighthouseを使用することは多いと思います。
Lighthouseは、ページの品質を5つのカテゴリ(パフォーマンス、アクセシビリティ、ベストプラクティス、SEO、PWA)でスコアリングしてくれるツールです。Chromeのデベロッパーツールにも導入されており、手軽に使えて便利ですよね。

私も業務で使用することはありますが、パフォーマンス改善施策や影響のありそうな機能追加時など、スポットでの使用となってしまっています。現状では、思わぬところでスコアに影響があった場合、問題が顕在化してから対処する、もしくはしばらく気づけないことになるため、個人的に課題を感じていました。

そこで、何か解決手段はないかと調べる中で、Lighthouse CIを見つけました。Lighthouse CIを使うと、CIでLighthouseレポートを継続的に出力できるようになるだけではなく、スコアの可視化も手軽に行えます。

この記事では、Lighthouse CIの主要機能：

Lighthouseレポート出力
GitHub Status Checks
アサーション指定
Lighthouse CIサーバ

の概要と、GitHub Actionsを使用した導入方法をご紹介します。

Lighthouse CIとは

先程も少し触れましたが、Lighthouse CIは、LighthouseをGitHub ActionsなどのCIに組み込んでサイト品質計測を継続的に行うことができるGoogle製のツールです。
ページ品質を5つのカテゴリ(パフォーマンス、アクセシビリティ、ベストプラクティス、SEO、PWA)で評価したレポートの出力や、複数レポートの可視化機能があり、ページエクスペリエンスの改善に利用できます。

ページエクスペリエンス

そもそも、なぜLighthouseでサイト品質を測る必要があるのでしょうか？

良いコンテンツや機能を用意しても、表示に時間が掛かったり、クリック領域が狭くボタンが押しづらいなどの事象が発生してしまうと、良い体験とはいえません。Googleは、こういったユーザーのページ上での体験「ページエクスペリエンス」をGoogle検索ランキングの指標の1つとして2021年から導入しています。

キーワード順位調査ツールAdvanced WEB RANKINGの運営会社の調査によると、Google検索結果の1位と2位の間には、CTRに約3倍もの差があるそうです。2位と3位の差は約2倍、1位と10位だと約40倍差。上位であればあるほどそれだけアクセスが増えるということになります。
検索結果の上位に表示されるといかにサービスにインパクトを与えるかが分かリますね。

よって、ページエクスペリエンスの向上は、単にユーザー体験をより良いものにするだけではなく、検索エンジンからのユーザー獲得増加にも繋がるということです。

リアルユーザーデータとラボデータ

ページエクスペリエンスのための計測データは、利用目的と取得環境によって「リアルユーザーデータ」と「ラボデータ」に分類されます。Lighthouseでは、「ラボデータ」での分析が可能です。

リアルユーザーデータ（フィールドデータ）
実際のユーザーが実際のアプリケーションで体験したパフォーマンスをキャプチャしたデータのことです。「実際のユーザー体験」に基づくため、端末スペック、通信環境などのユーザー環境により結果が変わります。
Core Web Vitalsの評価には、リアルユーザーデータが使用されます。
計測ツールとして、PageSpeed Insights、Search Console、Chrome User Experience Reportがあります。
ラボデータ
開発環境などの制御された環境下でのパフォーマンスデータのことです。環境要因を可能な限り統一して、確度の高い分析をすることができます。
計測ツールとして、Lighthouseの他にはWeb Vitals Chrome拡張機能、WebPageTestがあります。

推奨されている計測方法

ラボデータ説明部分で「環境要因を可能な限り統一」と書きましたが、完全に揃えることは難しく、ラボデータでも結果にブレが発生します。

Googleは、数値に惑わされないために、1回のスコアを見るのではなく診断を複数回実行して中央値や楽観的な値をその時点でのスコアとして扱うことを推奨しています。
Lighthouseを5 回の実行した時のスコアの中央値は、1 回の実行の 2 倍安定するそうです。

…さて、「URLごとに5回Lighthouseを実行してね！あと中央値も算出してね！」というのはなかなか大変ですね。さらに、本来の目的はレポート収集の後の改善実施なので、ここは効率的に行いたい部分です。

そこで、Lighthouse CIが役立ちます。

Lighthouse CIの主要機能4つ

Lighthouse CIには、主に4つの機能があります。

Lighthouseレポート出力
CI実行時点でのLighthouseレポートを出力できます。複数URLの一括診断や、1回のワークフローで実行するLighthouseの回数など詳細を指定できます。
GitHub Status Checks
「1」で作成したレポートスコアをPRページ上で確認ができます。
また、レポートページへの遷移も容易になります。
アサーション指定
カテゴリや詳細項目ごとにしきい値を指定し、満たさない場合はCIを失敗させたり、warningを出すことができます。
Lighthouse CIサーバ
診断結果のグラフ化や、2つのレポートの比較などができるダッシュボードを作成できます。

公式ドキュメントで「Lighthouse CI導入の推奨ステップ」が紹介されていますが、これに4機能を当てはめると以下の画像の通りになります。
「3」が2つあるのは、アサーション設定にプリセットを使うか自分でしきい値を指定するか、の違いになります。

※画像引用元：https://github.com/GoogleChrome/lighthouse-ci/blob/main/docs/getting-started.md#overview

前置きが長くなりましたが、ここから各機能を試してみたいと思います。

1. Lighthouseレポート出力

Lighthouseレポートを出力してみます。
今回は、Lighthouse CI Actionを利用して、GitHub Actions成功時に以下の2形式のレポートが出力されるよう設定します。

アーティファクトとしてhtml/jsonファイルを出力
temporary public storageにアップロード

1–1. ワークフローファイル作成

アーティファクト作成並びにtemporary public storageへのアップロードは、ワークフローファイルで指定します。
.github/workflows/lighthouseci.ymlを作成し、以下を記述します。

name: Lighthouse CI
on: push
jobs:
  lighthouse:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Lighthouse CI Action
        uses: treosh/lighthouse-ci-action@v9
        with:
          # lighthousercへのパス
          configPath: ./lighthouserc.js
          # アーティファクトを出力する
          uploadArtifacts: true
          # public storageにレポートを保存する
          temporaryPublicStorage: true

1–2. lighthouserc.js作成

Lighthouseの設定ファイルです。
js形式の他に、yml、jsonでも記述することができます。

module.exports = {
  ci: {
    collect: {
      url: [                          // 診断対象URL
        'http://localhost:9000/',
        'http://localhost:9000/greet',
      ],
      startServerCommand: 'sbt run',  // サーバ起動コマンド
      numberOfRuns: 5,                // 診断実行回数
    },
  },
};

url には診断対象のURL、startServerCommand にサーバ起動コマンドを指定します。その他の設定項目は、公式ドキュメントを参照ください。

また、記事前半の「推奨されている計測方法」でも触れた通り、数値にはブレが生じるため、numberOfRuns: 5 を指定して診断を5回実行するようにしています。
今回は集計方法を指定しないので、デフォルトの「楽観的（optimistic）」が適用されます。これは、診断のうち最も良いスコアを利用するものです。

1–3. 実行結果

アーティファクト
GitHub Actionsページからダウンロードができます。
URL/診断回数ごとに作成されるため、中央値等の集計は別途行う必要があります。

temporary public storage
GitHub Actionsのログに、レポートのURLが診断対象URLごとに発行されます。
こちらはスコア集計は自動で行なってくれますが、URLを知っていれば誰でもアクセス可能なこと、3日〜5週間ほどでデータが自動削除されることに注意が必要です。

2. GitHub Status Checks

「1. Lighthouseレポート出力」では、レポートを確認するために「GitHub Actionsのログから出力URLを探す」という手間が発生しました。
GitHub Status Checksの設定を追加すると、以下のようにPR上からのスコア確認と「Detail」リンクから該当レポートにアクセスできるようになります。

2–1. GitHub Appのインストール

GitHub AppのLighthouse CIのページから、アプリをインストールします。
LHCI_GITHUB_APP_TOKENが発行されるので、これをGitHubの環境変数に保存します。

2–2. ワークフローファイルの編集

発行されたトークンをLHCI_GITHUB_APP_TOKEN の値として追記します。

env:
    # PR上でスコアを表示する
    LHCI_GITHUB_APP_TOKEN: ${{ secrets.LHCI_GITHUB_APP_TOKEN }}

この状態でGitHub Actionsを実行すると、先ほどの画像の用にPR上でスコアが表示されます。簡単ですね！
注意点としては、レポートの出力先は「1」でも使用したtemporary public storageとなります。

3. アサーション指定

5つのカテゴリ（パフォーマンス、アクセシビリティ、ベストプラクティス、SEO、PWA）や、詳細項目ごとに、しきい値とログレベルの設定（off、warn、error）を指定できます。

アサーションの利用は、Lighthouseスコアがある程度改善されてからの導入が推奨されているようです。

3–1. プリセットを利用する

プリセットは以下の3種類用意されています。

lighthouse:all
全カテゴリの診断スコアのしきい値を100%に指定します。
lighthouse:recommended
カテゴリの1つである「パフォーマンス」以外の診断が完全であること、「パフォーマンス」に「改善」フラグがないことを指定します。また、メトリック値がスコア90を下回る場合にwarnとします。
lighthouse:no-pwa
lighthouse:recommendedから、PWAの診断を無効にしたものです。

プリセットは、この後紹介する「しきい値」で上書きすることができます。プリセットをベースにして、優先度の低い診断項目のアサーションは無効にする、といったこともできます。

3–2. しきい値を利用する

「1.Lighthouseレポート出力」で作成した、lighthouserc.js に指定します。形式は、カテゴリ/項目名：ログレベルまたは、カテゴリ/項目名： [ログレベル, オプション] で、以下のように指定できます。

assert: {
  assertions: {
    // プリセット
    preset: 'lighthouse:no-pwa',    // パフォーマンスのアサーションをオフ 
    'categories:performance': 'off',    // SEOのしきい値を0.9、スコア集計方法を「中央値」とする
    'categories:seo': ['error', 'median', {'minScore': 0.9}],    // viewport診断を満たさない場合warnとする
    'viewport': 'warn',              
  },
},

カテゴリ/項目については、Lighthouseのデフォルトconfigファイルから確認できます。

4. Lighthouse CIサーバ

これまでは、CI実行時点のレポートのみの取得でしたが、Lighthouse CIサーバを用意してレポートをアップロードすると、以下のように継続的なモニタリングができるようになります。

4–1. Lighthouse CIサーバの準備

公式ドキュメントにて、Dockerを使う場合とHerokuを使う場合の手順が紹介されています。

Dockerイメージが配布されているので、今回はこちらを利用します。
下記のコマンドを実行します。

$ docker volume create lhci-data
$ docker container run --publish 9001:9001 --mount='source=lhci-data,target=/data' --detach patrickhulce/lhci-server

この状態でhttp://localhost:9001にアクセスすると…ダッシュボードが表示できました。

実際にレポートをアップロードして使用するには、独自ドメインを割り当てる必要があります。
localtunnelを使用して、外部公開用のURLを発行します。

$ npx localtunnel --port 9001 --subdomain lighthouseci-sample
your url is: https://lighthouseci-sample.loca.lt

次は、このLighthouse CIサーバにプロジェクトを設定していきます。

4–2.プロジェクトを作成

lhci wizardコマンドを実行します。

# lhciをインストール（未インストールの場合）
$ yarn global add @lhci/cli# プロジェクト設定開始
$ lhci wizard

対話形式で設定内容を入力して、プロジェクトを作成します。

build tokenとadmin tokenが発行されます。
build tokenは、この後説明する「ワークフローファイルを更新」の工程で使用するので、GitHubの環境変数に保存しておきます。

admin tokenは、Lighthouse CIサーバのプロジェクトに設定します。
Lighthouse CIサーバの画面に再度アクセスし、サイドバーを開きます。プロジェクト名の横にある歯車アイコンをクリックすると、Administrative Settings画面が表示されます。
ここの「Admin Token」の欄に、先ほど発行されたadmin tokenを入力し、保存します。

これでサーバ側の設定は完了です。

4–3. ワークフローファイルを更新

「1」で作成したワークフローファイルLighthouseレポートの送信先を、先ほど作成したサーバに変更します。
同じくレポートの送信先指定である temporaryPublicStorage とは設定の共存ができないため、こちらはコメントアウトしてください。

- name: Lighthouse CI Action
    uses: treosh/lighthouse-ci-action@v9
    with:
        # lighthousercへのパス
        configPath: ./lighthouserc.js
        # アーティファクトを出力する
        uploadArtifacts: true        # LighthouseCIサーバURL
        serverBaseUrl: https://lighthouseci-sample.loca.lt/  ← 追加
        # build token          
        serverToken: ${{ secrets.LHCI_BUILD_TOKEN }}         ← 追加
        # public storageにレポートを保存する
        # temporaryPublicStorage: true                  ← コメントアウト