このページは Cloud Translation API によって翻訳されました。

CrUX で LCP 画像のサブパートと RTT が利用可能に

Barry Pollard

Johannes Henkel

公開日: 2025 年 2 月 11 日

2025 年 2 月の Chrome ユーザーエクスペリエンスレポート（CrUX）のリリースでは、次のような新しい（および変更された）指標が追加されます。

Largest Contentful Paint（LCP）画像のサブパーツとリソースタイプ
ラウンドトリップ時間（RTT）の詳細
有効な接続タイプ（ECT）ディメンションの削除

これらの指標は、CrUX で利用可能なオリジンと URL のパフォーマンス指標に関するより詳細な分析情報を提供します。この投稿では、その理由について詳しく説明します。

LCP の診断情報

当初、Google I/O 2022 で LCP サブパートのコンセプトを導入しました。これは、画像の LCP があるページの LCP 時間を小さなコンポーネントに分割し、LCP の増加の正しい原因を特定して最適化に取り組めるようにするための効果的な手法です。

その講演で紹介された HTTP Archive ラボのデータの分析によると、画像のダウンロード時間は LCP 時間の最も短い部分であることがよくあります。多くのラボツール（Google 独自の Lighthouse を含む）では、画像の形式とサイズを最適化してダウンロード時間を短縮し、パフォーマンスを向上させるというアドバイスが頻繁に行われていました。アドバイスは正しいものの、分析の結果、そのアドバイスが過度に強調されている可能性があることが判明しました。また、画像がブラウザで検出され、ダウンロードが開始されるまでの遅延が大きな問題であることも判明しました。

ラボデータの分析は有用ですが、ウェブの実際の使用方法は異なる場合が多いので、フィールドデータのこれらのサブパートを確認できることが重要です。昨年公開された投稿では、フィールドデータに基づいてLCP の最適化方法に関する一般的な誤解が確認されました。

LCP イメージのサブパーツ

このリリースにより、サイト所有者は、オリジンまたは URL レベルで、画像 LCP のサブパートを自分のサイトで確認できるようになります。

サブパートは画像でのみ使用できます。動画の最初のフレーム画像は含まれません（ダウンロード時間全体を測定できないため、少し複雑です）。テキストのサブパートも、有用性が低く、画像の LCP 数を歪める可能性があるため、含まれません。サイトの大部分がテキスト LCP で構成されている場合は、全体的な TTFB と全体的な FCP の指標が有用です。ただし、これらの指標はすべての LCP にわたるものであり、テキスト LCP に固有のものではありません。最後に、画像のサブパートは、ページ全体の読み込み時にのみ収集されます。これは、前後ナビゲーションやプリレンダリングされたページでも収集される LCP 指標とは異なります。

このデータは、2025 年 2 月に CrUX API と CrUX History API に追加されました（BigQuery ではありません）。CrUX History API はリリース時点で 2 週間分のデータが提供されますが、今後、25 週間分の履歴が提供される予定です。API では、各サブパートの 75 パーセンタイル（ミリ秒単位）としてデータを利用できます。

たとえば、PHONE ページビューの https://web.dev/ の LCP 画像サブパートを取得するには、次の curl コマンドを使用します（API_KEY は独自のキーに置き換えてください）。

curl "https://chromeuxreport.googleapis.com/v1/records:queryRecord?key=API_KEY" \
  --header 'Content-Type: application/json' \
  --data '{ "formFactor": "PHONE",
            "url": "https://web.dev/",
            "metrics": [
              "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"]}'

次のような結果が返されます。

{
  "record": {
    "key": {
      "formFactor": "PHONE",
      "url": "https://web.dev/"
    },
    "metrics": {
      "largest_contentful_paint_image_element_render_delay": {
        "percentiles": {
          "p75": 2088
        }
      },
      "largest_contentful_paint_image_resource_load_delay": {
        "percentiles": {
          "p75": 828
        }
      },
      "largest_contentful_paint_image_resource_load_duration": {
        "percentiles": {
          "p75": 417
        }
      },
      "largest_contentful_paint_image_time_to_first_byte": {
        "percentiles": {
          "p75": 2385
        }
      }
    },
    "collectionPeriod": {
      "firstDate": {
        "year": 2025,
        "month": 1,
        "day": 12
      },
      "lastDate": {
        "year": 2025,
        "month": 2,
        "day": 8
      }
    }
  }
}

このデータを含めるように CrUX Vis ツールを更新しました。また、CrUX API を使用する他のサードパーティ製ツールでも、この貴重なデータが公開される予定です。

CrUX Vis の LCP 画像サブパートのグラフ。4 つのサブパートの 2 つのデータポイントを示しています — CrUX ビジュアリゼーションの LCP 画像のサブパーツ

この例では、人気のあるメディアサイトのリソースの読み込み時間が最も短いコンポーネントであることがわかります。このサイトの改善の余地は、TTFB とリソース読み込み遅延にあり、要素のレンダリングの遅延は改善の余地が小さいです。

各サブパートの値が高い場合は、次のような問題を示しています。

Time to First Byte（TTFB） が長い場合、通常はサーバー、ネットワーク、またはリダイレクトの問題が原因です（TTFB を最適化するを参照）。
リソースの読み込み遅延が高い場合、LCP 画像がブラウザで遅れて検出されています。たとえば、クライアントサイドの JavaScript によって挿入された LCP 画像で、実行に時間がかかる場合があります。
リソースの読み込み時間が長い場合は、画像のダウンロードサイズを小さくすることを検討してください。
要素のレンダリング遅延が高い場合、画像は利用可能である（<link rel=preload> を介して利用可能であるが、長時間使用されていない場合など）が、画像の表示にクライアントサイドの JavaScript が必要なことが原因で、遅延が発生します。

このデータが CrUX でオリジンと URL の両方のレベルで利用可能になることで（通常の利用条件が適用されます）、サイトが LCP 指標を簡単に最適化できるようになることを願っています。

LCP リソースタイプ

サブパートは画像の LCP に最適なため、CrUX ではこのデータは画像を含むページにのみ制限されます。そのため、LCP のうち、テキスト LCP（<h1> の見出しや長い段落など）ではなく画像 LCP がどれくらいあるかを把握することが重要です。

CrUX API に、LCP 画像のサブパートに加えて、LCP ページ読み込みがテキストと画像にどのように分割されているかを示したリソースの内訳が追加されました。

たとえば、PHONE ページビューの https://web.dev/ の LCP リソースタイプを取得するには、次の curl コマンドを使用します（API_KEY は独自のキーに置き換えます）。

curl "https://chromeuxreport.googleapis.com/v1/records:queryRecord?key=API_KEY" \
  --header 'Content-Type: application/json' \
  --data '{ "formFactor": "PHONE",
            "url": "https://web.dev/",
            "metrics": ["largest_contentful_paint_resource_type"]}'

次のような結果が返されます。

{
  "record": {
    "key": {
      "formFactor": "PHONE",
      "url": "https://web.dev/"
    },
    "metrics": {
      "largest_contentful_paint_resource_type": {
        "fractions": {
          "image": 0.0155,
          "text": 0.9845
        }
      }
    },
    "collectionPeriod": {
      "firstDate": {
        "year": 2025,
        "month": 1,
        "day": 12
      },
      "lastDate": {
        "year": 2025,
        "month": 2,
        "day": 8
      }
    }
  }
}

CrUX Vis も更新され、以下のデータが表示されるようになりました。

CrUX Vis の LCP リソースタイプグラフ。2 つのリソースタイプに 2 つのデータポイントが表示されています。 — CrUX Vis の LCP リソースタイプ

たとえば、web.dev のホームページでは、LCP の 98.5% がテキスト LCP であるため、このページでは LCP 画像のサブパートはあまり役に立ちません。その場合は、元の TTFB と FCP の指標を、より適切な診断分類として使用できます。

LCP リソースタイプは、LCP の理解と改善に役立つ診断ツールです。特に、LCP 画像のサブパートの有用性を把握するのに役立ちます。

RTT の診断情報

また、2024 年 8 月に初めて導入された RTT 指標も拡張しました。

RTT 3 分割ビン

CrUX API に 3 つのビンが追加され、RTT 密度の 3 つのグループが表示されるようになりました。

ネットワークレイテンシ	開始	終了
低	0 ミリ秒	75 ミリ秒未満
中	75 ミリ秒	275 ミリ秒未満
高	275 ミリ秒	∞

これらのビンは、270 ミリ秒未満のすべてを 4g カテゴリに含めていた以前の ECT カテゴリよりも有用な情報を提供します。これらのカテゴリが導入されてからネットワーク技術が進歩し、ほとんどのサイトのトラフィックがこのカテゴリに分類されるようになったため、この分類の有用性が低下しました。

そのため、通常の「良好」、「改善が必要」、「低い」ラベルではなく、「低い」、「中程度」、「高い」ラベルを使用することをおすすめします。これらの指標は、サイト所有者が直接改善できる指標ではないため、他の指標とその指標が想定と異なる理由を把握するための診断指標です。また、ユーザーベースに変化が見られる場合は、サイトが変更されていないにもかかわらず他の指標が時間とともに変化する理由を説明するのにも役立ちます。

これらのビンは CrUX API で使用できます。たとえば、PHONE ページビューの場合は web.dev です（API_KEY は独自のキーに置き換えてください）。

curl "https://chromeuxreport.googleapis.com/v1/records:queryRecord?key=API_KEY" \ --header 'Content-Type: application/json' \ --data '{ "formFactor": "PHONE", "url": "https://web.dev/", "metrics": ["round_trip_time"]}'

次のような結果が返されます。

{ "record": { "key": { "formFactor": "PHONE", "url": "https://web.dev/" }, "metrics": { "round_trip_time": { "histogram": [ { "start": 0, "end": 75, "density": 0.1524 }, { "start": 75, "end": 275, "density": 0.6641 }, { "start": 275, "density": 0.1835 } ], "percentiles": { "p75": 230 } } }, "collectionPeriod": { "firstDate": { "year": 2025, "month": 1, "day": 12 }, "lastDate": { "year": 2025, "month": 2, "day": 8 } } } }

分布が選択されている場合、CrUX Vis に分割が表示されます。

CrUX ビジュアリゼーションの RTT データ

BigQuery での RTT

CrUX API の RTT 指標を拡張してトリプルビンを含めるだけでなく、月次 BigQuery データセットでもデータを利用できるようにしました。元のテーブルでは 25 ミリ秒のバケットで完全なヒストグラムが、マテリアライズドテーブルではトリプルビンと p75 値が利用できます。

これにより、CrUX API で利用可能な 3 つのビンを超えて、データの分布をより詳細に把握できます。また、今月 CrUX から削除された ECT の内訳を再現することもできます（詳細は後述）。ただし、4g のしきい値が 270 ミリ秒から 275 ミリ秒に変更されています。ECT の内訳（現在は RTT データから取得）は、CrUX BigQuery マテリアライズドテーブルで引き続き利用できるため、CrUX ダッシュボードなどのツールで引き続きこの内訳を表示できます。

BigQuery データセットには、国（ISO 3166-1 で定義）別のデータも含まれています。これにより、より詳細な分析が可能になり、一部のユーザーのパフォーマンス指標が低下している理由を説明するのに役立ちます。たとえば、https://www.google.com のデータを確認することで、Google Pixel ユーザーのデータを確認できます。

SELECT `chrome-ux-report`.experimental.GET_COUNTRY(country_code) AS geo, least(500, p75_rtt) AS capped_p75_rtt, p75_rtt FROM `chrome-ux-report.materialized.country_summary` WHERE origin = 'https://www.google.com' AND yyyymm = 202501 AND device = 'phone' ORDER BY p75_rtt DESC, country_code

次に、地図でデータを可視化します。

https://www.google.com
の 75 パーセンタイルフォン RTT（国別）（インタラクティブなグラフを含むソースデータ）。

世界中のほとんどの地域（特に「西洋」）では RTT が非常に良好ですが、サハラ以南のアフリカ、中東の一部、アジアの一部の地域では、RTT がより長くなっています。実際、グラフは RTT 500 ミリ秒で上限が設定されています。これは、すべてのデータを使用すると色が歪むためです。特に、エリトリアの 75 パーセンタイルが 3,850 ミリ秒であるためです。

これは、トラフィックパターンが変化した場合にも役立ちます。たとえば、RTT が長い国からのユーザーの割合が高いと、サイトに変更を加えていないにもかかわらず Core Web Vitals の統計情報が悪化する可能性があります。

サイトは RTT を直接改善することはできませんが、サイトの訪問者がこのデータを利用できるようにすることで、世界中のサイトのユーザーをより深く理解できます。また、今後の分析の機会も数多くあります。研究者の方々がこのデータセットから興味深い分析情報を見出されることをお祈りいたします。

ECT ディメンションの削除

2025 年 2 月のリリースの最後の変更は、BigQuery から有効な接続タイプ（ECT）ディメンションが削除されることです（RTT 指標を導入した 2024 年 9 月から API から RTT が削除されています）。

この投稿で前述したように、RTT 指標を使用すると、サイト訪問者の接続の詳細をより詳細に把握できます。これらのヒストグラムから ECT バケットを再作成することもできます。（技術的には、ECT は RTT とダウンリンク速度の組み合わせである必要がありますが、Chrome では RTT のみが使用されていました）。

重要な違いは、ECT は CrUX ディメンションだったことです。つまり、他の指標を ECT でセグメント化できました。RTT はディメンションではなく CrUX 指標であるため、たとえば RTT 別の LCP を表示することはできません。他のディメンション（デバイスタイプと国）別の RTT のみを表示できます。

ディメンションから指標に移行すると制限が増えるように思えますが、実際には CrUX で利用できるデータが増えます。これは、CrUX でデータを表示するために必要な最小しきい値があるためです。2022 年にディメンションをオプション化し、より高いレベルでレポートするために必要な場合は ECT やデバイスを削除しましたが、ほとんどのページ読み込みで発生しない指標（次のペイントまでのインタラクション（INP）、さまざまなナビゲーションタイプ、LCP 画像のサブパート）は、BigQuery のオリジンで使用できないことが多々ありました。

ディメンションの数を減らすと、データのセグメント化が軽減され、これらの最小要件を満たすオリジンの数が増えます。1 月のデータセットでは、68.1% のオリジンで INP が報告されていますが、12 月のデータセットでは、64.5% のオリジンでのみ INP が報告されています。このメカニズムは、このリリースのナビゲーションタイプ、LCP サブパート、リソースタイプにも適用されます。これらはすべて、ECT ディメンションの削除によってメリットを得られます。CrUX API では、カバレッジの拡大は 2 月上旬から有効になっています。

ECT 列は、以前のデータセットとの整合性を確保するために BigQuery に残ります。マテリアライズドビュー内の ECT データは引き続き使用できますが、新しい RTT p75 と 3 分割ビンに加えて、RTT 情報（前述のように 3g と 4g で 5 ミリ秒の差異あり）に基づいて使用されます。

まとめ

公開 CrUX データセットに指標が追加されたことで、サイト所有者と研究者は、パフォーマンスの問題の診断と最終的な修正に役立つ多くの情報を入手できるようになりました。

公開データセットである CrUX では、表示できる詳細レベルに一定の制限があります。たとえば、個々の要素セレクタは CrUX に表示されません。このような詳細なデータを必要とするサイト所有者は、制約の少ない RUM ソリューションを実装することを強くおすすめします。

ただし、この投稿で詳しく説明しているような、より上位の集計データは、問題があることと、問題が発生している理由のギャップを埋めるのに役立ちます。この追加データがお役に立ちますと幸いです。フィードバックやご質問がございましたら、ディスカッショングループでぜひお知らせください。