Cumulative Layout Shift 指標を改善する計画について学び、フィードバックをお寄せください。
Cumulative Layout Shift（CLS）は、ウェブページの視覚的な安定性を測定する指標です。この指標は、個々のレイアウト シフトのスコアがページの存続期間を通じて合計されるため、累積レイアウト シフトと呼ばれます。
どのようなレイアウト シフトもユーザー エクスペリエンスは良くありませんが、ページを開いている時間が長くなるほど、その分だけユーザー エクスペリエンスは悪化します。そこで Chrome 速度指標チームは、ページの閲覧時間の影響を受けにくい CLS 指標の改善に着手しました。
ページの読み込み後、ページをスクロールしたり移動したりしている間にネガティブなエクスペリエンスが発生することが多いため、指標はページ存続期間全体のユーザー エクスペリエンスに焦点を当てていることが重要です。しかし、有効期間が長いページ、つまりユーザーが長時間開いているページにどのような影響があるかについての懸念が寄せられています。長く開いたままになる傾向のあるページにはいくつかの種類があります。最も一般的なものは、無限スクロールのソーシャル メディア アプリやシングルページ アプリケーションです。
CLS スコアが高い有効期間の長いページを社内で分析したところ、ほとんどの問題の原因が次のパターンであることがわかりました。
- ユーザーのスクロールに伴ってコンテンツが移動する無限のスクローラー。
- プレースホルダやスケルトン パターンを使用せずに、入力ハンドラがユーザー操作への応答として UI を更新するのに 500 ミリ秒以上かかる場合。
Google はデベロッパーにこうしたユーザー エクスペリエンスを改善することを奨励していますが、同時に指標の改善にも取り組んでおり、考えられるアプローチに関するフィードバックの募集も行っています。
新しい指標の方が優れているかどうかを判断するにはどうすればよいでしょうか？
指標の設計に入る前に、実際のさまざまなウェブページやユースケースでアイデアを評価するようにしたいと考えました。まず、小規模なユーザー調査を設計しました。
まず、さまざまなウェブサイトを訪れた 34 回のユーザー ジャーニーについて、動画と Chrome のトレースを記録しました。ユーザー ジャーニーを選択する際には、以下の点を重視しました。
- ニュース サイトやショッピング サイトなど、さまざまな種類のサイト。
- 最初のページ読み込み、スクロール、シングルページ アプリ ナビゲーション、ユーザー操作など、さまざまなユーザー ジャーニー。
- サイトでの個別のレイアウト シフトの数と強度はさまざまです。
- レイアウト シフト以外に、サイトで好ましくないエクスペリエンスはほとんどありません。
41 人の同僚に 2 つの動画を同時に視聴するよう依頼し、レイアウトの変化という点でどちらの動画がより優れているかを評価しました。これらの評価に基づいて、サイトの理想的なランキング順序を作成しました。ユーザー ランキングの結果から、当社の同僚は大部分のユーザーと同様に、読み込み後のレイアウト シフト（特にスクロールやシングルページのアプリ ナビゲーション）に不満を感じているようです。これらのアクティビティの間に、他のサイトよりも優れたユーザー エクスペリエンスを持つサイトがあることがわかっています。
Chrome のトレースを動画とともに記録したため、各ユーザー ジャーニーにおける個々のレイアウト シフトの詳細をすべて把握できました。これを基に、各アイデアのユーザー ジャーニーごとの指標値を計算しました。これにより、各指標のバリエーションがユーザー ジャーニーをどのようにランク付けしているか、および各指標が理想的なランキングとどの程度異なっているかを確認できました。
どのような指標のアイデアをテストしましたか？
ウィンドウ処理戦略
多くの場合、新しいコンテンツが 1 つずつ追加されるのに伴って要素が複数回移動するため、複数のレイアウト シフトが密接にまとまっています。そこで私たちは、シフトをグループ化する手法を試すことにしました。これを実現するために、3 つのウィンドウ処理アプローチを検討しました。
- タンブリング ウィンドウ
- スライディング ウィンドウ
- セッション ウィンドウ
それぞれの例で、ページのレイアウト シフトの重大度は時間とともに変化します。青色の各バーは 1 つのレイアウト シフトを表し、長さはそのシフトのスコアを表します。これらの画像は、さまざまなウィンドウ処理戦略で、時間の経過に伴うレイアウト シフトがどのようにグループ化されるかを示しています。
タンブリング ウィンドウ
最も簡単な方法は、ページを同じサイズのチャンクに分割することです。これらはタンブリング ウィンドウと呼ばれます。上のグラフを見ると、4 つ目のバーは実際には 2 つ目のタンブリング ウィンドウにグループ化されているように見えますが、ウィンドウはすべて固定サイズであるため、代わりに 1 つ目のウィンドウ内にあります。ページ上での読み込みやユーザー操作のタイミングがわずかに異なる場合、同じレイアウト シフトがタンブリング ウィンドウの境界の異なる側に適用される可能性があります。
スライディング ウィンドウ
同じ長さのグループ化の可能性をもっと多く表示できるアプローチは、潜在的な時間枠を経時的に継続的に更新することです。上の画像は、一度に 1 つのスライディング ウィンドウを示していますが、考えられるすべてのスライディング ウィンドウまたはその一部を確認して指標を作成することもできます。
セッション ウィンドウ
レイアウト シフトが頻繁に発生しているページの領域を特定するには、各ウィンドウをシフトで開始し、レイアウト シフトとの間に所定のサイズのギャップが見つかるまでウィンドウを拡大し続けることができます。このアプローチでは、レイアウト シフトがグループ化され、シフトしないユーザー エクスペリエンスのほとんどが無視されます。問題の一つとして、レイアウト シフトにギャップがない場合、セッション ウィンドウに基づく指標が現在の CLS 指標と同様に無限に増加することが挙げられます。そこで、最大ウィンドウ サイズでも試しました。
ウィンドウ サイズ
この指標から得られる結果は、ウィンドウの実際の大きさによって大きく異なる可能性があるため、次のように複数の異なるウィンドウ サイズを試しました。
- 各シフトを独自のウィンドウとして（ウィンドウなし）
- 100 ミリ秒
- 300 ミリ秒
- 1 秒
- 5 秒
要約
さまざまなウィンドウを要約するために、さまざまな方法を試しました。
パーセンタイル
最大ウィンドウ値、95 パーセンタイル、75 パーセンタイル、中央値を調べました。
平均
そこで、平均ウィンドウ値に注目しました。
予算
ユーザーが気付かないようなレイアウト シフトの最小スコアはあるのではないかと考え、その「予算」に対するレイアウト シフトをスコアにカウントしてみましょう。そこで、想定されるさまざまな「予算」値について、予算に対するシフトの割合と、予算に対するシフトの合計スコアを調べました。
その他の戦略
また、レイアウト シフトの合計をページ滞在時間で割った、最悪の N 個の個別のシフトの平均など、ウィンドウを使わない多くの戦略を調べました。
最初の結果
全体で 145 の異なる指標定義をテストし、上記の考え方を組み合わせました。指標ごとに、すべてのユーザー ジャーニーを指標のスコアによってランク付けし、次に理想的なランキングにどれだけ近いかによって指標をランク付けしました。
ベースラインを算出するため、現在の CLS スコアですべてのサイトをランク付けしました。CLS は 32 位で、他の 13 の戦略と同程度で、上記の戦略のほとんどの組み合わせよりも優れています。意味のある結果が得られるように、3 つのランダムな順序で追加しました。予想どおり、ランダムな順序は、テストしたすべての戦略よりも劣っています。
データセットに対して過学習になる可能性があるかどうかを把握するために、分析の後、新しいレイアウト シフトの動画とトレースをいくつか記録して手動でランク付けし、新しいデータセットと元のデータセットで指標のランキングが非常に類似していることを確認しました。
ランキングでは、いくつかの戦略が目立ちました。
最適な戦略
戦略をランク付けしたところ、3 つのタイプの戦略が最も上位にあることがわかりました。いずれもパフォーマンスがほぼ同じであったため、3 つすべての詳細な分析を進める予定です。また、ユーザー エクスペリエンス以外の要素を検討する際に考慮すべき要素があるかどうか、デベロッパーの皆様からのフィードバックもお待ちしております。（フィードバックを送信する方法については、下記をご覧ください）。
長いウィンドウの高いパーセンタイル
次のようなウィンドウ処理戦略は、長いウィンドウ サイズでうまく機能しました。
- 1 秒のスライディング ウィンドウ
- セッション ウィンドウは 1 秒間隔で 5 秒に制限
- 1 秒のギャップで制限が解除されたセッション ウィンドウ
これらはすべて、95 パーセンタイルと最大の両方で非常に優れています。
しかし、このような大きなウィンドウ サイズについては、95 パーセンタイルを使用することが懸念されました。多くの場合、4 ～ 6 個のウィンドウしか確認できず、その 95 パーセンタイルを取得すると、多くの補間が行われます。指標値の点で、補間がどのように行われているのかが不明確です。最大値の方がはるかに明確であるため、Google は最大値を確認することにしました。
長いギャップがあるセッション ウィンドウの平均
5 秒の間隔を空けたすべてのセッション ウィンドウのスコアを平均すると、非常に良い結果が得られました。この戦略にはいくつかの興味深い特徴があります。
- ページにレイアウト シフトの間隔がない場合、現在の CLS とまったく同じスコアの 1 つの長いセッション ウィンドウになります。
- この指標では、アイドル時間を直接考慮していませんでした。ページが移動していない時点ではなく、ページで発生した変化のみを確認しました。
短いウィンドウの高いパーセンタイル
最大 300 ミリ秒のスライディング ウィンドウは非常に高いランクと、95 パーセンタイルです。短いウィンドウ サイズの場合、パーセンタイル補間は大きいウィンドウ サイズよりも少なくなりますが、「繰り返し」スライディング ウィンドウについても懸念していました。2 フレームにわたって一連のレイアウト シフトが発生する場合、それらを含む 300 ms のウィンドウが複数あります。最大値を求めるほうが、95 パーセンタイルの場合よりもはるかに明確でシンプルです。そこで今回も、上限数を確認することにしました。
効果的でなかった戦略
レイアウト シフトなしの場合とレイアウト シフトありの場合の両方で費やした時間の「平均的」なエクスペリエンスを確認しようとした戦略は、あまり効果がありませんでした。どのウィンドウ処理戦略でも、中央値や 75 パーセンタイルのサマリーで、サイトを高く評価するものではありませんでした。また、時間の経過に伴うレイアウトの合計変化も見られませんでした。
レイアウト シフトを許容できるさまざまな「予算」を評価しました。
- レイアウト シフトが予算を超えてシフトした割合。どの予算も低評価でした。
- 平均的なレイアウト シフトがやや過剰。この戦略のほとんどのバリエーションはうまくいかなかったものの、ギャップの大きい長いセッションの平均的な過剰な場合は、ギャップの長いセッション期間の平均とほぼ同じでした。後者の方がシンプルなため、後者だけを採用することにしました。
次のステップ
より大規模な分析
Google は、Chrome に上記の主要な戦略を導入することで、はるかに広範なウェブサイトの使用状況に関するデータを取得できるようにしました。今後は、同様の手法で指標スコアに基づいてサイトをランク付けし、より大規模な分析を行う予定です。
- CLS と新しい指標候補ごとにすべてのサイトのランク付けを行います。
- CLS と各受験者によって最も異なるランクとなっているのはどのサイトですか？これらのサイトで予想外の発見はありましたか？
- 新しい指標候補間の最大の違いは何ですか？特定の候補者の長所と短所として際立った違いはありますか。
- 上記の分析を繰り返します（ただし、各ページの読み込みにかかる時間でバケット化します）。レイアウト シフトを許容することで、長時間のページの読み込みで期待される改善は見られますか？有効期間が短いページで予期しない結果が発生することはありますか？
Google のアプローチに関するフィードバック
これらのアプローチについて、ウェブ デベロッパーの皆様からのフィードバックをお待ちしています。新しいアプローチを検討する際は、次の点に留意してください。
変更されない点
新しいアプローチによって多くのことが変わらないことを明確にしたいと考えています。
- 指標のアイデアによって個々のフレームのレイアウト シフトのスコアが計算される方法はなく、複数のフレームを要約する方法が変わるだけです。つまり、レイアウト シフト用の JavaScript API は変わりません。デベロッパー ツールが使用する Chrome トレースの基になるイベントも変わりません。そのため、WebPageTest や Chrome DevTools などのツールのレイアウト シフト領域も引き続き同じように機能します。
- Google は、デベロッパーが指標を簡単に導入できるように、web-vitals ライブラリ内の指標や、web.dev でのドキュメントの作成、Lighthouse などのデベロッパー ツールでの報告などに引き続き取り組んでいきます。
指標間のトレードオフ
最も重要な戦略の 1 つは、レイアウト シフト ウィンドウを平均として要約し、残りの戦略は、最大ウィンドウをレポートします。非常に長い間開かれているページの場合、平均値はより代表的な値を報告しますが、一般的には、デベロッパーは単一ウィンドウ（発生した日時やシフトした要素など）をログに記録する方が簡単でしょう。デベロッパーにとって何がより重要なのか、フィードバックをお寄せください。
スライディング ウィンドウとセッション ウィンドウのどちらがわかりやすいと思いますか？違いはあなたにとって重要ですか？
フィードバックを送信する
新しいレイアウト シフトの指標は、JavaScript の実装例または Core Web Vitals 拡張機能のフォークを使用して、任意のサイトでお試しいただけます。
フィードバックを web-vitals-feedback Google グループにメールでお送りください。件名は「[Layout Shift Metrics]」です。皆様からのご意見、ご感想をお待ちしております。