はじめまして。プロダクト開発部に所属しているエンジニアの伊藤です。
弊社で開発しているKDDIのサービス、「auブックパス(運営:KDDI株式会社)」の保守開発を担当しています。
今回はそのauブックパスでLighthouse CLIを使用した性能検証の話をしていきます。
Lighthouse CLI使用の背景
auブックパスでは、昨年Webページの内部コードを一新し、メンテナンスがしやすくなったこともあり、今年度からSEO改善にも力を入れています。
今回はその中でもFIDの改善についての話をしていきます。
FIDとは
FID(First Input Delay)とは、ユーザーが最初にそのページ上で操作したときに、その操作処理が開始するまでの時間を計測したものです。
この時間が短いほど、より使いやすいWebページであるという保証になります。GoogleはFIDを「Core Web Vitals」と1つとしてSEOの指標にしています。
FIDは100ミリ秒程度になることが理想と言われています。
参考:https://web.dev/i18n/ja/fid/
FIDの改善策の1つに、画像の遅延読み込みがあります。
auブックパスは電子書籍のストアなので、トップ画面に書籍表紙の画像が多く表示されます。(ストアのトップはこちら)
何も対策しないとすべての画像を表示するまでユーザー操作処理が遅れ、FIDの測定値が悪くなります。
そのため、ユーザーが表示していない領域の画像を後で表示させるLazy Loading(遅延ローディング)を施す必要があります。
この施策がどれだけ効果があるのかを確認するため、Lighthouse CLIを使いました。
Lighthouse CLI とは
Lighthouseとは、Googleが提供するWebページの品質を計測するためのツールです。
ブラウザのGoogle Chromeに標準搭載されていて、Dev Toolsから使用できます。
Dev ToolsのLighthouseタブから計測したいカテゴリ(SEO、パフォーマンスなど)を選んで「Analyze page load」ボタンを押すと開いているWebページを計測してくれます。
Lighthouse CLIは、このLighthouseをNode.jsを使用してコマンドラインから実行できるツールです。
より細かい実行時の設定指定ができたり、コマンドを記述して自動化できるので柔軟な計測や複数回実行が手早くできるなどの利点があります。
Lighthouse CLI の導入・実施方法
実行環境
- Intel MacBook Pro メモリ32GB
- Node.js 16.17.1
- npm 8.15.0
- lighthouse(Lighthouse CLI) 9.6.7
計測環境について
今回は本番反映前に計測したかったので、ステージング環境を対象にしています。
アクセス制限のため、WebページにBasic認証がかけられているので、リクエストのHTTPヘッダー情報に認証情報を載せる必要があります。
CORS(Cross-Origin Resource Sharing)の対応
auブックパスはJavaScriptで外部オリジンから書籍の画像情報を取得しています。
withCredentialsを設定をしないとプリフライトリクエストでbasic認証のauth情報が渡せず、
CORSポリシーでブロックされてしまいます。
今回は性能の計測が目的なので、同一オリジンポリシーを適用させない方法で上記を解決します。
導入手順
実行環境にLighthouse CLIをインストール
npm install -g lighthouse
インストール確認
これでバージョン番号が出たらインストールが正常に完了しています。lighthouse --version
Basic認証のID・PASSWORDをbase64エンコード
echo -n '<ID>:<PASSWORD>' | base64
ligthouseコマンドを記述して実施
今回は以下の条件で計測を実施します。- 計測する値
- 指定なし(計測できる全項目を計測)
- 計測結果
- jsonで出力
- html形式でも出力可能です。
- リクエストヘッダ
- Authoricationの情報を搭載する。
- Chromeのオプション
--disable-web-security
を追加して、同一オリジンポリシーを適用外にする
lighthouse \ --chrome-flags="--disable-web-security" \ --extra-headers='{"Authorization": "Basic <3でエンコードしたIDとPASSWORD>"}' \ --output=json \ --output-path="[自分がレポートを置きたいディレクトリ]/[レポート名].json" \ --quiet "[検証したい画面のURL]"
- 計測する値
計測結果のjsonファイルから指定の結果を抽出
計測結果のjsonは、各項目の計測結果の数値の他、コンソールで出たエラー内容や計測過程のスクリーンショットの情報なども入り数千行に及びます。
目的の数値のみ取り出したい場合はcatなどを活用します。
今回はFIDの数値が欲しいので、Lighthouse内で相当するTBT(Total Blocking Time)の値を抽出します。
※注意
TBT(Total Blocking Time)は厳密に言えばFIDとは違う概念で、「Webページがユーザー操作をブロックしていた総時間数」です。
FIDは本番の環境下で実際のユーザーが使用した時にしか測定できない値なので、Lighthouseなどの自動操作での計測値にはTBTを使うのが一般的です。
cat [自分がレポートを置きたいディレクトリ]/[レポート名].json | jq '.audits."total-blocking-time"'
上記コマンドを打つと、以下の形式で出力されます。
{ "id": "total-blocking-time", "title": "Total Blocking Time", "description": "Sum of all time periods between FCP and Time to Interactive, when task length exceeded 50ms, expressed in milliseconds. [Learn more](https://web.dev/lighthouse-total-blocking-time/).", "score": 0.66, "scoreDisplayMode": "numeric", "numericValue": 412.9999999999991, "numericUnit": "millisecond", "displayValue": "410 ms" }
このdisplayValue
が計測結果なので、この値を抽出します。
あとは上記手順を複数回行って、結果を各自保存していきます。
計測結果をGUIで見たい
CLIからLighthouseを実行したときに、想定外の画面が表示されて正しく計測されていないことに気づけない場合があります。
実際私が計測した時は、--disable-web-security
のオプションをつけず実行してエラー画面が出ていることに気づけませんでした。
そういう時には、出力された結果のファイルを「Lighthouse Report Viewer」にドラックアンドドロップしてください。
最終的に表示されたページの画像・計測過程のスクリーンショットなどが見えるので想定外の計測がされていないかを確認できます。
まとめ
今回あくまで最低限のLighthouse CLIの活用方法について触れてきました。
この記事が読んでいる方の手助けになれば幸いです。