Core Web Vitals のしきい値の背景にある調査と手法
Core Web Vitals は、ウェブ上の実際のユーザー エクスペリエンスの重要な側面を測定する一連のフィールド指標です。Core Web Vitals には指標と、各指標の目標しきい値が含まれています。これによりデベロッパーは、サイトのエクスペリエンスが「良好」か「改善が必要」か、「低い」かを定性的に把握できます。この投稿では、Core Web Vitals の指標のしきい値を選択する際の一般的なアプローチと、Core Web Vitals の各指標のしきい値がどのように選択されたかについて説明します。
復習: Core Web Vitals の指標としきい値
2020 年の Core Web Vitals は、Largest Contentful Paint（LCP）、First Input Delay（FID）、Cumulative Layout Shift（CLS）の 3 つの指標です。各指標は、ユーザー エクスペリエンスのさまざまな側面を測定します。LCP は、認識された読み込み速度を測定し、ページ読み込みタイムラインの中でページのメイン コンテンツが読み込まれた可能性が高い箇所をマークします。FID は応答性を測定し、ユーザーが最初にページを操作しようとしたときのエクスペリエンスを定量化します。CLS は、視覚的な安定性を測定し、表示されるページ コンテンツの予期しないレイアウト シフトの量を定量化します。
ウェブに関する主な指標の各指標にはしきい値が関連付けられています。しきい値は、パフォーマンスを「良好」、「改善が必要」、または「低速」に分類します。
| 良好 | 悪い | パーセンタイル | |
|---|---|---|---|
| Largest Contentful Paint | 2,500 ミリ秒以下 | 4,000 ミリ秒超 | 75 |
| First Input Delay | 100 ミリ秒以下 | 300 ミリ秒を超える | 75 |
| Cumulative Layout Shift | 0.1 以下 | 0.25 を超える | 75 |
また、ページまたはサイトの全体的なパフォーマンスを分類するために、そのページまたはサイトへのすべてのページビューの 75 パーセンタイル値が使用されます。つまり、サイトのページビューの 75% 以上が「良好」のしきい値を満たしていれば、そのサイトはその指標のパフォーマンスが「良好」に分類されます。逆に、ページビューの 25% 以上が「低い」しきい値を満たしている場合、そのサイトはパフォーマンスが「低い」サイトに分類されます。たとえば、75 パーセンタイルの LCP が 2 秒の場合は「良好」、75 パーセンタイルの LCP が 5 秒の場合は「低い」に分類されます。
Core Web Vitals の指標のしきい値の基準
Core Web Vitals の指標のしきい値を設定する際、Google はまず、各しきい値が満たす必要がある基準を特定しました。以下では Google が 2020 年の Core Web Vitals の指標の しきい値の評価に使用した基準について説明します以降のセクションでは、2020 年に各指標のしきい値を選択するためにこれらの基準がどのように適用されたかについて詳しく説明します。今後数年間で、ウェブでの優れたユーザー エクスペリエンスを測定する能力をさらに高めるために、基準としきい値の改善と追加を行う予定です。
質の高いユーザー エクスペリエンス
Google の第一の目標は、ユーザーとエクスペリエンスの質を最適化することです。 そのため、Google では、Core Web Vitals の「良好」基準を満たしているページで高品質のユーザー エクスペリエンスを提供することを目標としています。
質の高いユーザー エクスペリエンスに関連するしきい値を特定するため、Google は人間の認識と HCI の調査を調査します。この研究は、単一の固定しきい値を使用して要約されていることもありますが、基礎となる研究は通常、値の範囲として表現されることがわかっています。たとえば、フォーカスを失うまでにユーザーが通常待機する時間に関する調査は 1 秒と表現されることもありますが、基盤となる調査は実際には数百ミリ秒から数秒までの範囲で表されます。認識のしきい値はユーザーによって異なります。コンテキストは、集計および匿名化された Chrome 指標データによってさらに裏付けられます。これは、ページの読み込みが中止される前に、ウェブページがコンテンツを表示するのを待つ時間は決まっていないことを示しています。むしろ、このデータはスムーズで継続的な分布を示しています。人間の認識のしきい値と関連する HCI の調査について詳しくは、ウェブに関する主な指標の科学的根拠をご覧ください。
特定の指標について、関連するユーザー エクスペリエンス調査が可能であり、文献の値の範囲について妥当なコンセンサスがある場合は、この範囲を入力として使用し、しきい値選択プロセスに役立てます。Cumulative Layout Shift のような新しい指標など、関連するユーザー エクスペリエンス調査が利用できない場合は、代わりに指標の異なる候補しきい値を満たす実際のページを評価し、優れたユーザー エクスペリエンスにつながるしきい値を特定します。
既存のウェブ コンテンツで達成可能
また、サイト所有者がサイトを最適化して「良好」な基準を満たせるように、ウェブ上の既存のコンテンツについてこのしきい値を達成できることが求められます。たとえば、0 ミリ秒は瞬時に読み込みを行う理想的な LCP の「良好」しきい値ですが、ネットワークとデバイスの処理レイテンシが原因で、ほとんどの場合、ゼロミリ秒のしきい値は実現できません。したがって、0 ミリ秒は Core Web Vitals の LCP の「良好」しきい値として妥当ではありません。
ウェブに関する主な指標の候補の「良好」なしきい値を評価するときは、Chrome ユーザー エクスペリエンス レポート（CrUX）のデータに基づいて、これらのしきい値が達成可能であることを確認します。しきい値に到達可能であることを確認するには、送信元の少なくとも 10% が現在「良好」しきい値を満たしている必要があります。また、フィールド データのばらつきによって適切に最適化されたサイトが誤って分類されることがないようにするため、適切に最適化されたコンテンツが一貫して「良好」の基準を満たしていることも確認しています。
逆に、ごく一部のオリジンのみが現在満たしていないパフォーマンス レベルを特定することで、「低い」しきい値を確立します。「低い」しきい値の定義に関連する調査がない限り、デフォルトでは、パフォーマンスが最も低いオリジンの 10 ～ 30% が「低い」に分類されます。
基準について最後にまとめます
候補のしきい値を評価したときに、基準が競合する場合があることがわかりました。たとえば、しきい値が常に達成可能であることと、常に良好なユーザー エクスペリエンスを保証することとの間に緊張関係が生じる場合があります。また、人間の知覚調査では一般的にさまざまな値が提供され、ユーザー行動の指標では行動の緩やかな変化が示されるため、多くの場合、指標に単一の「正しい」しきい値は存在しないことがわかりました。したがって、2020 年の Core Web Vitals では、完璧なしきい値は 1 つではなく、複数の合理的な候補しきい値から選択しなければならない場合もあることを考慮しながら、上記の基準に最も適したしきい値を選択するというアプローチを採用しました。「最適なしきい値はどれか」ではなく、「この基準に最も適した候補しきい値はどれか」を問うことに重点を置きました。
パーセンタイルの選択
前述のように、Google ではページまたはサイトの全体的なパフォーマンスを分類するために、そのページまたはサイトへのすべての訪問の 75 パーセンタイル値を使用します。75 パーセンタイルは 2 つの基準に基づいて選択されました。まず、ページまたはサイトへの訪問の大部分が目標レベルのパフォーマンスを達成していることをパーセンタイルで確認します。次に、選択したパーセンタイルの値が、外れ値によって過度に影響を受けないようにする必要があります。
これらの目標は、互いにいくらか相反します。最初の目標を達成するには、通常、パーセンタイルが高いほうが良い選択です。ただし、パーセンタイルが高いほど、結果として得られる値が外れ値の影響を受ける可能性も高くなります。サイトへの少数のアクセスが不安定なネットワーク接続で行われて、LCP サンプルが過度に大きくなる場合、これらの外れ値サンプルによってサイトの分類が決まることは望ましくありません。たとえば、訪問数が 100 回のサイトのパフォーマンスを、95 パーセンタイルなどの高いパーセンタイルを使用して評価する場合、95 パーセンタイル値の影響を受ける外れ値サンプルは 5 つだけです。
これらの目標は若干異なるため、分析の結果、75 パーセンタイルは妥当なバランスであるという結論に至りました。75 パーセンタイルのデータから、サイトへのアクセスのほとんど（4 人中 3 人）で目標以上の成果を達成していることがわかります。また、75 パーセンタイル値は外れ値の影響を受ける可能性が低くなります。たとえば、訪問数が 100 件のサイトの場合、75 パーセンタイルの値の外れ値サンプルが 25 件で、外れ値の影響を受ける場合は、大きな外れ値サンプルを報告する必要があります。100 サンプルのうち 25 サンプルが外れ値になる可能性はありますが、95 パーセンタイルの場合よりもその可能性はかなり低くなります。
Largest Contentful Paint
エクスペリエンスの質
1 秒は、ユーザーがタスクにフォーカスを喪失し始めるまでの時間としてよく引用されます。関連する調査を詳しく調べると、1 秒が約数百ミリ秒から数秒の値の範囲を表す近似値であることがわかりました。
1 秒のしきい値に関して一般的に引用されるソースは、Card et al と Miller の 2 つです。Card は、Newell の Unified Theories of Cognition を引用し、1 秒の「即時応答」しきい値を定義しています。Newell 氏は、即時のレスポンスを「刺激に対して非常に約 1 秒以内（つまり、約 0.3 秒から約 3 秒以内）に行う必要があるレスポンス」と説明しています。これは、「認知に対するリアルタイムの制約」に関する Newell の議論に続き、「認知的な配慮を喚起する環境とのインタラクションは、約 0.5 ～ 2 ～ 3 秒の範囲で数秒で起こる」と述べています。1 秒のしきい値について広く引用されている別の情報源である Miller は、「レスポンスの遅延が 2 秒を超える場合、人間がマシン通信で実行でき、実行するタスクは、さらに 1 秒ほど延長される可能性がある」と述べています。
Miller and Card の調査では、ユーザーがフォーカスを失うまで待機する時間を約 0.3 ～ 3 秒の範囲と記述しています。これは、LCP の「良好」しきい値がこの範囲内にあるべきであることを示唆しています。さらに、既存の First Contentful Paint の「良好」しきい値が 1 秒であり、Largest Contentful Paint は通常 First Contentful Paint の後に発生することから、LCP 候補のしきい値の範囲は 1 秒から 3 秒までさらに制限します。この範囲で基準に最も適したしきい値を選択するために、以下の候補しきい値の達成可能性を確認します。
達成可能性
CrUX のデータを使用して、LCP の候補となる「良好」しきい値を満たすウェブ上のオリジンの割合を判断できます。
「良好」に分類された CrUX オリジンの割合（LCP 候補のしきい値）
| 1 秒 | 1.5 秒 | 2 秒 | 2.5 秒 | 3 秒 | |
|---|---|---|---|---|---|
| phone | 3.5% | 13% | 27% | 42% | 55% |
| パソコン | 6.9% | 19% | 36% | 51% | 64% |
1 秒のしきい値を満たすオリジンは 10% 未満ですが、1.5 ～ 3 秒の他のすべてのしきい値は、最低 10% のオリジンが「良好」しきい値を満たすため、有効な候補であるという要件を満たしています。
さらに、適切に最適化されたサイトでも、選択したしきい値が一貫して達成可能なものであることを確認するために、ウェブ全体でパフォーマンス上位のサイトの LCP パフォーマンスを分析し、それらのサイトで一貫して達成可能なしきい値を判断しています。具体的には、パフォーマンスの高いサイトについて、75 パーセンタイルで常に達成可能なしきい値を設定することを目指しています。1.5 秒と 2 秒のしきい値は一貫して達成可能ではなく、2.5 秒は一貫して達成可能であることがわかりました。
LCP の「低い」しきい値を特定するには、CrUX データを使用して、ほとんどのオリジンで満たされているしきい値を特定します。
「低い」に分類される CrUX オリジンの割合（候補の LCP しきい値）
| 3 秒 | 3.5 秒 | 4 秒 | 4.5 秒 | 5 秒 | |
|---|---|---|---|---|---|
| phone | 45% | 35% | 26% | 20% | 15% |
| パソコン | 36% | 26% | 19% | 14% | 10% |
しきい値が 4 秒の場合、スマートフォンのオリジンの約 26%、パソコンオリジンの 21% が「低」に分類されます。これは 10 ～ 30% の目標範囲内にあるため、4 秒が許容可能な「低い」しきい値であると結論付けます。
したがって、Largest Contentful Paint については、2.5 秒が妥当な「良好」しきい値であり、4 秒が妥当な「低い」しきい値であると結論付けます。
First Input Delay
エクスペリエンスの質
最大 100 ミリ秒程度の視覚的フィードバックの遅延は、ユーザー入力などの関連するソースによって引き起こされていると認識されているという結論に、調査にある程度の一貫性があります。このことから、100 ミリ秒の First Input Delay の「良好」しきい値が最小基準として適切であると考えられます。入力処理の遅延が 100 ミリ秒を超えると、他の処理やレンダリングのステップを時間内に完了する機会はありません。
Jakob Nielsen のよく引用されている「Response Times: The 3 Important Limits」では、システムが瞬時に反応しているとユーザーに感じさせる上限を 0.1 秒と定義しています。Nielsen の引用は Miller and Card です。同氏は Michotte の 1962 年の『The Perception of Causality』を引用しています。ミコットの研究では、テストの参加者の画面に「2 つのオブジェクト。オブジェクト A が離れて B に向かって進みます。B と接触した瞬間に停止し、B は A から離れて動き出します。」ミチョットは、オブジェクト A が停止してからオブジェクト B が移動し始めるまでの時間間隔を変化させます。Michotte は、最大約 100 ミリ秒の遅延において、参加者はオブジェクト A がオブジェクト B の動きを引き起こしているように感じていることに気づきました。約 100 ミリ秒から 200 ミリ秒までの遅延では因果関係の認識が混在し、200 ミリ秒を超える遅延ではオブジェクト B の動きはオブジェクト A に起因するものと見なされなくなります。
同様に、Miller は「Response to control activation」レスポンスのしきい値を、「通常は、キー、スイッチ、または物理的に操作されたことを知らせるその他のコントロール メンバーの動きによって与えられるアクションの表示として定義しています。この応答は、オペレーターによって引き起こされる機械的動作の一部として受け取られる必要があります。時間遅延: 0.1 秒以下」とそれ以降、「キーを押してから視覚的フィードバックするまでの遅延は 0.1 ～ 0.2 秒以内にする必要があります」。
最近、Kaaresoja らは、Towards the Temporally Perfect Virtual Button で、さまざまな遅延のために、タッチスクリーン上の仮想ボタンのタップと、それに続く視覚的なフィードバックでボタンがタップされたことを示す同時性の認識について調査しました。ボタンを押してから視覚フィードバックまでの時間が 85 ミリ秒以下の場合、75% の確率でボタンが押されると同時に視覚的なフィードバックが表示されると、参加者は報告しました。さらに、100 ミリ秒以下の遅延では、ボタン押下の品質が一貫して高いことが報告されました。100 ミリ秒から 150 ミリ秒の遅延で認識品質が低下し、300 ミリ秒の遅延で非常に低いレベルに達します。
以上を踏まえ、調査ではウェブに関する指標の適切な初回入力遅延のしきい値として、100 ミリ秒前後の値の範囲が指摘されていると結論付けています。また、300 ミリ秒以上の遅延に対してユーザーから低品質レベルが報告された場合、300 ミリ秒が妥当な「低い」しきい値となります。
達成可能性
CrUX のデータを使用して、ウェブ上のオリジンの大半が 75 パーセンタイルで 100 ミリ秒の FID の「良好」しきい値を満たしていると判断します。
FID 100 ミリ秒のしきい値で「良好」に分類された CrUX オリジンの割合
| 100ms | |
|---|---|
| phone | 78% |
| パソコン | >99% |
また、ウェブのトップサイトの場合、75 パーセンタイルで常にこの基準を満たしている（多くの場合 95 パーセンタイルで基準を満たしている）ことがわかっています。
以上から、100 ミリ秒が FID の妥当な「良い」しきい値であると結論付けます。
Cumulative Layout Shift
エクスペリエンスの質
Cumulative Layout Shift（CLS）は、ページの表示コンテンツがどの程度移動するかを測定する新しい指標です。CLS は新しいため、この指標のしきい値を直接通知できる研究は行っていません。したがって、ユーザーの期待に沿ったしきい値を特定するため、レイアウト シフト量が異なる実際のページを評価し、ページ コンテンツを消費する際に大幅な中断が発生する前に許容できると認識されるシフト量の最大を判断しました。Google の内部テストでは、0.15 以上からの変化は一貫して破壊的であると認識され、0.1 以下の変化は顕著であるものの、過剰な影響はないことがわかりました。したがって、レイアウト シフトがゼロであることが理想的ですが、0.1 までの値が「良好な」CLS しきい値の候補であると結論付けられました。
達成可能性
CrUX データに基づくと、送信元の約 50% で CLS が 0.05 以下であることがわかります。
「良好」に分類された CrUX オリジンの割合（CLS 候補のしきい値）
| 0.05 | 0.1 | 0.15 | |
|---|---|---|---|
| phone | 49% | 60% | 69% |
| パソコン | 42% | 59% | 69% |
CrUX データによると、0.05 が妥当な CLS の「良い」しきい値である可能性が示唆されていますが、レイアウト シフトの中断を回避することが現時点では難しいユースケースがあることも認識しています。たとえば、ソーシャル メディアの埋め込みなどのサードパーティの埋め込みコンテンツの場合、読み込みが完了するまで埋め込みコンテンツの高さがわからないことがあり、レイアウト シフトが 0.05 を超える場合があります。したがって、多くのオリジンが 0.05 のしきい値を満たしているものの、やや厳しくない CLS のしきい値 0.1 がエクスペリエンスの質と達成可能性のバランスを取ると結論付けています。今後、ウェブ エコシステムが、サードパーティの埋め込みによるレイアウト シフトに対処するためのソリューションを特定できるようになることを期待しています。これにより、Core Web Vitals の今後のイテレーションで、より厳格な CLS の「良好」しきい値 0.05 または 0 を使用できるようになります。
さらに、CLS の「低い」しきい値を判定するために、CrUX データを使用して、ほとんどのオリジンが満たすしきい値を特定しました。
「低い」に分類された CrUX オリジンの割合（CLS 候補のしきい値）
| 0.15 | 0.2 | 0.25 | 0.3 | |
|---|---|---|---|---|
| phone | 31% | 25% | 20% | 18% |
| パソコン | 31% | 23% | 18% | 16% |
しきい値が 0.25 の場合、スマートフォンのオリジンの約 20%、パソコンオリジンの 18% が「低速」に分類されます。これは 10 ～ 30% の目標範囲内にあるため、0.25 が許容可能な「低い」しきい値であると結論付けました。