#20「Lighthouse v8.0のアップデートとCore Web Vitals」

Google Chrome バージョン93より、DevToolsに搭載されるLighthouseのバージョンが8にアップデートされます。今回はパフォーマンスに関連するアップデートの内容とCore Web Vitalsとの関係を中心にご紹介しました。

※ オフラインのため、音声ファイルを再生できません。ネットワーク状況をご確認の上、再度アクセスしてください。

加藤
こんにちは！
橋本
こんにちは！
加藤
ミツエーテックラジオは株式会社ミツエーリンクスのスタッフがWebデザイン、 WebフロントエンドなどのWeb技術に関するニュースやツールなどをシェアするためのポッドキャストです。今回はわたくし加藤と橋本君の二人でお届けします。橋本君、よろしくお願いします！
橋本
よろしくお願いします！
加藤
今回はGoogle Chromeのバージョン93が8月31日にリリースされる予定ということで、バージョン93に搭載されるLighthouse v8.0についてのお話をしようと思います！
橋本
バージョン8へのアップデートではスコアの重みづけの変更など、わりと影響が大きめの変更がありましたよね。
加藤
そうなんです。ほかにもコンテントセキュリティポリシーに関するチェックの追加などもあったのですが、今回はパフォーマンスに関連する変更を深堀りしながら、おさらいしていきたいと思います。
加藤
まず1つ目の変更は、いま橋本君が言ってくれたスコアリングに関する変更ですね。ざっくり言うと、いくつかの指標について、重みづけやスコアの計算に使われる係数がアップデートされます。
橋本
それってWebサイトに手を入れてなくてもLighthouseをアップデートするだけでスコアが変動する可能性があるってことですよね。
加藤
そうですね。HTTP ArchiveのデータをもとにテストされたWebサイトでは、全体の80%のサイトで5ポイント程度変動があると予想されているみたいです。
橋本
なるほど。でもその程度の変動は、普段の計測中もネットワーク環境などによって起こりますよね。
加藤
そうですね。なので、スコアの変動に一喜一憂する必要はないかなと思っています。ただ、どうして変更されたのかについては知っておいてもよいかなと思います。
橋本
そうですね。ではその変更の背景について聞いてもいいですか？
加藤
はい。注目は、CLS（Cumulative Layout Shift）とLCP（Largest Contentful Paint）と、TBT（Total Blocking Time）の3つの指標がより重視されていることですね。順番に説明していきたいと思います。
CLSは、画像などのコンテンツが遅れて表示されたり、スタイルが遅れてあたったことによって発生するガタツキの量をスコア化したものです。もともと重要な指標ではあったものの、Lighthouse v6.0で初めて指標として追加されたばかりだったので、そこまでスコアに大きな影響を与えるものではなかったんですよね。ただこれまで様々な変更、改善が行われてきていて、より成熟した指標になった、ということで今回から比重が重くなりました。
続いてLCPはビューポートの中で、一番サイズが大きな要素が表示されたタイミングをスコアにした指標です。Core Web Vitalsの一つとしても使われているもので、Core Web Vitalsはユーザー体験を表す指標なので、よりよいユーザー体験のためにLCPをより重視すべきとされているのではないかと思います。
最後にTBTなんですが、TBTは最初にコンテンツが表示されてから、ユーザーがページを操作できるようになるまでに起きているロングタスク、ロングタスクというのは50ms以上かかっている処理のことですね。このロングタスクの超過時間の合計をスコアにしたものです。
TBTは、Core Web VitalsにおけるFIDのプロキシと呼ばれています。FIDはFirst Input Delayの略で、ユーザーによるボタンクリックなどの操作から、実際にその処理が開始されるまでにかかった時間を指す指標です。なのでロングタスクが多ければ多いほど、そして長ければ長いほど、処理の開始が遅れることがあるので、TBTの改善ができればFIDの改善にもつながることから、こちらもより重視されているのではないかと思います。
橋本
なるほど。そういえばCLSもCore Web Vitalsの内の一つですよね。
加藤
そうですね。
橋本
ということはCore Web Vitalsを優先的に改善することで、スコアは上がりやすく、結果的にユーザー体験の改善にもつながるってことですね。
加藤
うん、そうですね。
橋本
ちなみにFCPよりLCPの比重が重いのはなぜなんでしょう。
加藤
FCPはFirst Contentful Paintなので、ページのコンテンツの一部が画面に表示されるまでを測定するのに対して、LCPはLargest Contentful Paintなので、ビューポート内に表示される最大のコンテンツが表示されるまでを計測します。
FCPはあくまで最初のタイミングを検知するだけなので、表示されたコンテンツがユーザーにとって価値のあるものとは限らないんですよね。例えばローディングバーが最初に表示されるページとか結構ありますけど、ローディングバーはユーザーに直接的な価値をあたえるものではなくて、ユーザーが本当に得たい情報はそのローディングの先にありますよね。
橋本
そうですね。でも一番大きなコンテンツが価値のある情報、とは限らないですよね。
加藤
それはその通りだと思います。W3CのWeb Performance Working Groupとの議論だったり、Google独自の調査に基づいて「一般的なサイトでは、最大の要素がメインコンテンツであることが多い」という結論を出しているんですけど、あくまで、一般的なサイトに当てはまる指標である、ということは気を付けておいたほうがいいですね。
橋本
そうですね。
加藤
先ほど話に上がったCLSについてですが、バージョン8で計測方法が変わったようなので、橋本君説明してもらってもよいですか。
橋本
はい。今回の変更についてより理解するためにまずCore Web Vitalsにおけるフィールドデータとラボデータについて簡単に説明します。
Core Web Vitalsを計測した結果には、フィールドデータとラボデータの2種類があります。フィールドデータは実際のユーザーの使用状況から集めたデータで、ラボデータは特定の制御された環境から集めたデータになります。今回CLSの計測方法に加えられた変更は、そのうちフィールドデータにより影響するものでした。
要点としては「CLSの計測は、1秒のギャップ、5秒を上限とする最大セッションウィンドウを基準にする」というものです。
加藤
なるほど？もう少し詳細を教えてもらってもいいですか？
橋本
フィールドデータにおけるCLSの計測は、ページロード時のレイアウトシフトだけではなく、ページを開いている間にわたって発生した合計のレイアウトシフトが対象になります。これはバージョン8でも変わらないのですが、ある条件ごとに計測期間をセッションとして区分し、その中で合計のレイアウトシフトが一番大きなセッションを基準にスコアを算出することで、セッション期間に関係なくCLSを一貫して測定できるようになりました。
加藤
ちなみにセッションとして区切らない場合だとどういう問題があったんですか？
橋本
さっきも少しお話した通り、フィールドデータではユーザーの操作によって発生したレイアウトシフトも含めて全て合計してスコアを算出していました。なので、たとえばシングルページアプリケーションとかSNSなどでよく見かける無限スクロール系のページだと、レイアウトシフトの数値がどんどん積み重なっていくんですよね。ただ、特にユーザーにストレスを与えるレイアウトシフトというのは、ページを開いている間に起きたレイアウトシフトの合計というよりは、ページロード直後のものであることが多いので、そこにより焦点を当てるようにした、ということみたいです。
加藤
なるほど。それでいくつかのセッションに区切って、そのセッションの中からよりガタツキが発生しているものをスコアリングの対象にしたというわけなんですね。
橋本
そうです。あと、ラボデータではページの読み込みが完了するまでに起こったレイアウトシフトを基準としてスコアを算出していたのに対して、フィールドデータでは、読み込み完了後のアクティビティを含むページの存続期間全体で起こったレイアウトシフトを基準としていました。その計測期間の長さが違っていたことが原因で発生していたスコアの差も比較的軽減されるみたいです。
加藤
フィールドデータとラボデータにおける結果の差が減るのはありがたいですね。
橋本
そうですよね。それでさっき、ある条件ごとにセッションウィンドウが区切られるって言ったんですけど、その条件というのが「1秒のギャップ、5秒を上限とする」というものです。最初にレイアウトシフトが起きたタイミングをセッションの開始として、その後1秒間レイアウトシフトが起きなければその段階でセッションを終了とします。再度レイアウトシフトが発生すれば新しいセッションウィンドウが開始して…ということを繰り返します。そのときの各セッションの開始から終了までの上限が5秒と設定されているということですね。
加藤
なるほど、なんとなく理解できました。ちなみに、これまでの算出方法、つまりページを操作している間の合計のレイアウトシフトによるスコアは参照できなくなるのですか？
橋本
これはDevTools上には表示されないんですけど、LighthouseからダウンロードできるJSONデータでは「totalCumulativeLayoutShift」という名前で参照できるみたいです。ただ、これも2021年、今年の12月14日には廃止されるみたいでした。
加藤
なるほど！そうなんですね。ありがとうございます。
スコアに関するアップデートの他にもLighthouse v7.5で初めてリリースされた、Lighthouse TreemapがDevToolsから使用可能になりますね。
橋本
サイトで読み込んでいるすべてのJavaScriptをファイルサイズや全体における割合と一緒に表現してくれるのですごい便利ですよね～。
加藤
そうですよね！SourcemapファイルをLighthouseから読み込むことができれば、バンドルされているJavaScriptのファイルを分析して、内部で使っているライブラリのサイズの割合も示してくれます。
橋本
あと、各ファイルのカバレッジを表示してくれるのもポイントだと思いました。ライブラリを読み込んでいても、ライブラリのすべての機能を使っているってことは結構少ないと思うんですよね。なので、ファイルサイズは大きいけど、その大半が使われていないようなコードがあれば、同じ機能を備えていてかつ、軽量なものがないかを探したり、もしくは自分で実装できないかを検討したりして、改善の手掛かりにできると思います。
加藤
うん、そうですね！
はい、ここまでLighthouseのアップデート情報について、話してきましたが、LighthouseのGitHubでは、アップデート情報のほかにも「v8.0 Performance FAQ」というページが公開されていました。そのページにはアップデートについてのQAだけでなく、Core Web Vitalsとの関係についてもいくつか記載がありました。
橋本
ここまでの話でも、わりとCore Web Vitals登場しましたね。
加藤
そうですね。なので最後にLighthouseとCore Web Vitalsの切り分け、関係について話しておきましょうか。
橋本
はい。大きくフィールドデータと、ラボデータという切り分けがあると思います。Core Web Vitalsは主にフィールドデータにより焦点を当てた指標ですが、Lighthouseはラボデータをもとに、どういうところに改善のきっかけがあるとか、どこから改善していくか、改善の効果が出ているかなどを手元で確認するツールだと思っています。
加藤
そうですね。フィールドデータは収集できたデータのみをもってスコア化されるので、何かの要因でそもそも収集に失敗したデータについては計測の対象にならないということは注意かなと思います。対してラボデータは「失敗した」という事実も収集できたり、テストする環境、ネットワーク速度やCPUのスペックなどをエミュレートしながら測定できるのも特徴ですね。
橋本
フィールドデータを見ながら、実際のユーザーが使用しているデバイスや、環境を理解して、それらをラボツールの条件に反映するといったように組み合わせて使っていくことが大事ですね。
加藤
そうですね！Chrome User Experience Reportなどを使えば、Chromeにおけるフィールドデータならだれでも参照できるので、活用していきたいところです！
ということで、Lighthouse v8.0のアップデート内容とCore Web Vitalsとの関係についておさらいしてみました。
橋本
やっぱりスコア全体に対する各指標の割合の変化が気になっちゃいますね～。スコアの高さに良さを見出すわけではないですけど、いろいろとアップデート後のLighthouseでスコアチェックしてみたいです！
加藤
最後に、ミツエーリンクスではスマートなコミュニケーションをデザインしたいUIデザイナー、UI開発者を募集しています。採用サイトではオンライン説明会やオンライン面接なども行っていますのでチェックしてみてください。
また、このPodcastはApple Podcast、 Google Podcast、Spotify、YouTubeで配信していますので、お好みのプラットフォームでフォローいただけると、最新のエピソードをすぐ視聴できます！こちらもぜひご活用ください。
それでは今日はこの辺で！ありがとうございましたー！
橋本
ありがとうございました！