指標

公開日: 2022 年 6 月 23 日、最終更新日: 2026 年 10 月 13 日

CrUX の指標は、ブラウザによって公開される標準のウェブ プラットフォーム API を利用しています。特に BigQuery データセットでは、このデータはオリジン単位で集計されます。サイトのパフォーマンスに関するより詳細な分析(URL レベルの解像度など)と分析情報を必要とするサイト所有者は、同じ API を使用して、独自のオリジンに関する詳細な実際のユーザー測定(RUM)データを収集できます。すべての API は Chrome で使用できますが、他のブラウザでは指標の完全なセットがサポートされていない場合があります。

ほとんどの指標はヒストグラム集計として表されるため、分布を可視化し、パーセンタイル値を近似できます。

Cumulative Layout Shift

「Cumulative Layout Shift(CLS)は、視覚的な安定性を測定するためのユーザー中心の重要な指標です。ユーザーが予期しないレイアウトの変化を目にする頻度を定量化するのに役立ちます。CLS が低いほど、ページが快適になります。」

web.dev/articles/cls

DOM コンテンツの読み込み完了

「DOMContentLoaded は、スタイルシート、画像、サブフレームの読み込みが完了するのを待たずに、最初の HTML ドキュメントが完全に読み込まれて解析された時点を報告します。」

MDN

最初の描画

「最初の描画は、ナビゲーション後にブラウザが最初にレンダリングした時点を報告します。デフォルトの背景の描画は除外されますが、デフォルト以外の背景の描画は含まれます。これは、ブラウザがページのレンダリングを開始した時点であり、デベロッパーがページ読み込みで最も重視する最初の重要なパートです。」

Paint Timing API

First Contentful Paint

「First Contentful Paint(FCP)は、ブラウザがテキスト、画像(背景画像を含む)、白色以外のキャンバス、SVG などを最初にレンダリングした時点を報告します。これには、保留中のウェブフォントを含むテキストが含まれます。ユーザーがページ コンテンツの利用を開始できる最初の時点です。」

Paint Timing API

Interaction to Next Paint

「Interaction to Next Paint(INP)は、応答性を評価するフィールド指標です。INP は、ページ ライフサイクル全体にわたるすべてのインタラクションのレイテンシを記録します。これらのインタラクションの最大値(または、インタラクションが多いページの場合は最大値に近い値)が、ページの INP として記録されます。INP が低いほど、ページは常に確実に応答します。」

web.dev/articles/inp

Interaction to Next Paint(INP)は、CrUX データセットに 2022 年 2 月に追加されました。この新しい指標は、個々のイベントのエンドツーエンドのレイテンシをキャプチャし、ページ ライフサイクル全体にわたるページ全体の応答性をより包括的に把握できます。

Largest Contentful Paint

Largest Contentful Paint(LCP)は、知覚される読み込み速度を測定するためのユーザー中心の重要な指標です。ページのページ読み込みタイムライン上で、ページのメインコンテンツが読み込まれた可能性が高いポイントをマークします。LCP が速いほど、ページが有用であることをユーザーに安心させることができます。

web.dev/articles/lcp

Largest Contentful Paint のリソースタイプ

「LCP は、ビューポート内に表示される最大の画像、テキスト ブロック、または動画のレンダリング時間を、ユーザーが最初にページに移動したタイミングと比較する形で確認できます。」

web.dev/articles/lcp - LCP の対象となる要素

テキストと画像(最初の動画フレーム画像を含む)は、読み込み特性と最適化手法が大きく異なることがよくあります。LCP リソースタイプの比率を把握することで、LCP 指標と最適化パスをより深く理解できます。

詳しくは、LCP リソースタイプのリリースに関するブログ投稿をご覧ください。

Largest Contentful Paint 画像のサブパーツ

「PageSpeed Insights でこの指標を改善する方法が示されない場合、LCP の最適化は複雑なタスクになる可能性があります。複雑なタスクの場合は、通常、より小さく管理しやすいタスクに分割し、それぞれ個別に対処することをおすすめします。」

web.dev/articles/optimize-lcp - LCP をサブパーツに分割する

画像の LCP を最も重要なサブパーツに分割することで、各パーツを最適化する方法に関する具体的な推奨事項とベスト プラクティスを活用できます。

LCP 画像のサブパーツは、次の 4 つの個別の指標で提供されます。

  • largest_contentful_paint_image_time_to_first_byte
  • largest_contentful_paint_image_resource_load_delay
  • largest_contentful_paint_image_resource_load_duration
  • largest_contentful_paint_image_element_render_delay

サブパーツは画像にのみ含まれます。最初の動画フレーム画像は、ダウンロード時間を完全に測定できないため、含まれません(最初の動画フレームは LCP リソースタイプの指標に含まれます。この指標では、この複雑さは関係ありません)。

テキストのサブパーツは、有用性が低く、画像の LCP の数値を歪めるため、含まれていません。主にテキストで構成されるサイトの場合、全体的な TTFB 指標と全体的な FCP 指標は有用な内訳となります。ただし、これらはすべての LCP に適用され、テキスト LCP に固有のものではありません。

詳しくは、LCP 画像のサブパーツのリリースに関するブログ投稿をご覧ください。

ナビゲーション タイプ 指標は、次のナビゲーションのページビューの割合の内訳を示します。

タイプ 説明
navigate 他のカテゴリのいずれにも当てはまらないページ読み込み。
navigate_cache メインリソース(メイン HTML ドキュメント)が HTTP キャッシュから提供されたページの読み込み。サイトでは、サブリソースにキャッシュを使用することがよくありますが、メイン HTML ドキュメントはキャッシュされることが少なく、キャッシュできる場合は、ローカルと CDN でキャッシュできるため、パフォーマンスが大幅に向上します。
reload ユーザーが [再読み込み] ボタンを押すか、アドレスバーで Enter キーを押すか、タブを閉じる操作を元に戻してページを再読み込みしました。ページの再読み込みでは、メインページが変更されたかどうかを確認するために、サーバーへの再検証が行われることがよくあります。ページの再読み込みの割合が高い場合は、ユーザー エクスペリエンスが低下している可能性があります。
restore ブラウザの再起動後、またはメモリ不足のために削除されたタブの後にページが再読み込みされました。Android 版 Chrome の場合、これらは「再読み込み」として報告されます。
back_forward 履歴ナビゲーション。つまり、ページが最近表示され、戻ったことを意味します。適切なキャッシュを使用すると、これらのエクスペリエンスは比較的高速になりますが、ページの処理と JavaScript の実行が必要になります。どちらも bfcache では回避できます。
back_forward_cache bfcache から提供された履歴ナビゲーション。ページを最適化して bfcache を活用するように、ブロッカーを削除すると、エクスペリエンスが高速になるため、サイトは
prerender ページが事前レンダリングされました。bfcache と同様に、ページの読み込みがほぼ瞬時に行われます。

ページ読み込みが複数のナビゲーション タイプの組み合わせになる場合があります。その場合、CrUX は表の逆順(下から上)で最初の一致を報告します。

詳しくは、ナビゲーション タイプのリリースに関する投稿をご覧ください。

Onload

「load イベントは、ページとその依存リソースの読み込みが完了したときに発生します。」

MDN

ラウンドトリップ時間

最近のネットワーク接続に基づいて、ナビゲーションの開始時の HTTP(アプリケーション レイヤ)のラウンドトリップ時間の推定値を提供します。 この指標は、以前の 有効な接続タイプ(ECT)ディメンションを担当していたのと同じ API であるNetwork Information APIのrtt プロパティに基づいています。

詳しくは、LCP リソースタイプのリリースに関するブログ投稿をご覧ください。

試験運用版の指標

試験運用版の指標は、BigQuery を使用する CrUX データセットと CrUX API の両方で使用できますが、すべての指標が両方で使用できるわけではありません。これらの指標は、ユーザーからのフィードバックに基づいて進化するため、変更される可能性があります。最新の変更については、リリースノートをご確認ください。

試験運用版のソフト ナビゲーション Core Web Vitals 指標

2026 年 10 月のリリースでは、ソフト ナビゲーションを含む Core Web Vitals 指標の試験運用版が導入されました。

  • experimental_largest_contentful_paint_with_softnavs
  • experimental_interaction_to_next_paint_with_softnavs
  • experimental_cumulative_layout_shift_with_softnavs

これらの指標には、ページ読み込みとソフト ナビゲーションの両方が含まれます。

詳しくは、Chrome ユーザー エクスペリエンス レポートに試験運用版の Core Web Vitals 指標を導入するをご覧ください。

Time to First Byte

CrUX の TTFB は、ページ全体の読み込み時にのみ収集されます。LCP など、戻る/進むキャッシュ(bfcache) ナビゲーションと 事前レンダリングされたページ でも収集される他のタイマーとは異なります。そのため、TTFB のサンプルサイズは他の指標よりも小さくなる可能性があり、直接比較できるとは限りません。CrUX の TTFB には、コールドページ読み込み、キャッシュされたページ読み込み、確立された接続からのページ読み込み(サイト内のページ読み込みなど)が含まれます。

TTFB は、リダイレクト時間などの測定値を含むため、サーバーの応答時間を直接測定するものではありません。また、レスポンスがキャッシュ、CDN、サーバーのいずれから提供されるかによって影響を受けます。これは CrUX などのフィールドデータで特に顕著ですが、ラボテストでは、エンド URL がテストされ、キャッシュの変更が繰り返し無効になることが多いため、これらの要因の影響は通常小さくなります。

人気度

人気度の順位指標は、オリジンでのナビゲーションの合計数で測定される、CrUX データセット内のサイトの人気度の相対的な指標です。順位は、半ステップの log10 スケール(上位 1,000、上位 5,000、上位 10,000、上位 50,000、上位 100,000、上位 500,000、上位 100 万など)で、各順位には前の順位は含まれません(上位 5,000 は実際には上位 1,000 を除く 4,000 URL です)。上限は、データセットの増加に伴って動的に変化します。

人気度は、広範な分析のガイドとして提供されます。たとえば、上位 1,000 のオリジンの国別のパフォーマンスを判断する場合に使用します。

通知権限

ユーザーに通知を表示する権限をリクエストするウェブサイトの場合、この指標は、プロンプトに対するユーザーのレスポンス(承諾、拒否、無視、閉じる)の相対的な頻度を表します。

広告の指標

Chrome は、サイトや広告主などのユーザーが実際のユーザーの広告エクスペリエンスとその影響をより深く理解できるように、公開指標とツールを提供しています。

  • 広告数: この指標は、一般的なユーザーがサイトで一度に表示する広告の数を示します。
  • 広告の密度: この指標は、一般的なユーザーのコンテンツと広告の表示のバランスを示します。
  • 広告の重み: CPU: この指標は、広告による CPU の使用量を示します。これはパフォーマンスに影響する可能性があります。
  • 広告の重み: ネットワーク: この指標は、広告によるネットワーク リソースの使用量を示します。

これらの指標は、ウェブ広告主と広告の掲載に使用するサービスにとって特に役立つと考えています。広告エコシステムの幅広い関係者から、これらの指標によって広告の機会の評価方法と広告プロダクトの意思決定を強化できるとの意見をいただいています。

詳しくは、広告の指標のリリースに関するブログ投稿と広告の測定に関するドキュメントをご覧ください。