ECサイトの速度がCVRに与える影響をBigQueryのCrUXデータで検証する

はじめに（速いと売れる、は本当か）

「サイトが速いと売れる」とよく言われますが、自分のECサイトでそれが本当なのかを、CrUXの公開BigQueryデータとGA4を突き合わせて確かめる手順を整理しました。

EC運営をしていると、「ページの表示速度を上げればCVR（コンバージョン率）が上がる」という話を一度は聞いたことがあると思います。実際、表示が遅いとユーザーは待たずに離脱してしまう、という直感は多くの人が持っているはずです。

ただ、自分のサイトで「速度を上げたらどれくらいCVRが変わるのか」を数字で示そうとすると、意外とハードルが高い。速度のデータ（誰がどれくらい待たされたか）とCVRのデータ（誰が買ったか）は、別々の場所に存在しているからです。

この記事では、速度の実測データを集めた公開データセット「CrUX」をBigQueryで読み、自サイトのGA4コンバージョンと突き合わせて、速度改善の優先度を決めるところまでを扱います。先に結論を言うと、CrUXだけで「速くすれば必ず売れる」を証明することはできません。けれど、「どこから手をつけるか」を判断する材料としては十分に使えます。

CrUX（Chrome UX Report）の公開BigQueryデータセットの概要

CrUX（Chrome User Experience Report）は、Chromeの実ユーザーから集めた表示速度・操作性の実測データを、Googleが公開しているデータセットです。研究室で測ったスコアではなく、実際にサイトを訪れた人の端末・回線で計測された値（フィールドデータ）である点が特徴です。

BigQueryからは公開データセットとして参照できます。ポイントは次の3つです。

オリジン単位の集計値である：データは「ページ単位」ではなく「オリジン単位」（例：https://example.com）でまとめられています。トップページと商品ページを分けて見ることは、このデータセットだけではできません。
月次のスナップショットである：毎月、その月のデータをまとめたテーブルが追加されます。日次の細かい変化を追う用途には向きません。
十分なトラフィックがあるオリジンのみ収録される：訪問者が一定数に満たないサイトは、そもそもデータが収録されない場合があります。

CrUXのプロジェクト名・テーブル命名規則・カラム構造は更新されることがあります。実際にクエリを書く前に、必ず最新の公式ドキュメント（Chrome Developers の CrUX BigQuery 解説ページ）でデータセット名・スキーマを確認してください。この記事で示すクエリは構造の理解を助けるためのサンプルであり、列名やテーブル名はお使いの時点の仕様に合わせて読み替えてください。

公開データセットは、おおまかに次のような構成になっています（詳細は公式で確認してください）。

プロジェクト : chrome-ux-report
データセット : 国別（例: country_jp）や all など
テーブル     : 月ごとに分かれる（例: YYYYMM のような月次テーブル）
粒度         : origin（サイト単位）× form_factor（PC / モバイル）など

集計値という性質を理解しておくことが、後の解釈で効いてきます。CrUXに入っているのは「あなたのサイトを訪れた人たち全体で、表示速度がどう分布していたか」であって、「誰が」「どのページで」「買ったか買わなかったか」は一切含まれていません。

Core Web Vitals（LCP / INP / CLS）の見方

CrUXで中心になる指標が、Core Web Vitalsと呼ばれる3つです。

LCP（Largest Contentful Paint）：メインコンテンツが表示されるまでの時間。読み込みの体感速度。
INP（Interaction to Next Paint）：クリックやタップなどの操作に画面が反応するまでの応答性。
CLS（Cumulative Layout Shift）：表示中にレイアウトがガタッとずれる量。視覚的な安定性。

CrUXのデータは、これらを「ヒストグラム（区間ごとの割合）」として持っています。たとえばLCPなら「2.5秒未満の訪問が何%、2.5〜4秒が何%、4秒以上が何%」という形です。この区間ごとの割合（density）を足し上げていくと、よく使われる「75パーセンタイル（遅い方から数えて上位25%の境目）」も求められます。

ヒストグラムから「良い体験の割合」を出す

まずは、自サイトのオリジンについて、LCPが「良い」とされる範囲（一般的に2.5秒未満）に収まっている訪問の割合を見るイメージです。

-- 注意: テーブル名・カラム構造は最新の公式仕様で確認のこと。
-- 下記は CrUX のヒストグラム構造を理解するためのサンプル。
SELECT
  origin,
  -- bin.start が区間の下限（ミリ秒）、bin.density がその区間の割合
  ROUND(SUM(IF(bin.start < 2500, bin.density, 0)) * 100, 1) AS lcp_good_pct
FROM
  `chrome-ux-report.country_jp.20260601`,  -- 月次テーブル（要確認）
  UNNEST(largest_contentful_paint.histogram.bin) AS bin
WHERE
  origin = 'https://example.com'
GROUP BY
  origin;

bin.density は割合（合計するとほぼ1.0）として入っているため、条件に合う区間だけを足し合わせれば「その範囲に収まった訪問の割合」が出せます。

PC・モバイルを分けて見る

ECでは、PCとモバイルで体験がまるで違うことが珍しくありません。form_factor で分けると、どちらが足を引っ張っているかが見えてきます。

-- form_factor 列の有無・名称は公式スキーマで確認のこと
SELECT
  form_factor.name AS device,
  ROUND(SUM(IF(bin.start < 2500, bin.density, 0)) * 100, 1) AS lcp_good_pct
FROM
  `chrome-ux-report.country_jp.20260601`,
  UNNEST(largest_contentful_paint.histogram.bin) AS bin
WHERE
  origin = 'https://example.com'
GROUP BY
  device
ORDER BY
  device;

自分が見てきた範囲では、モバイルのLCPがPCより大きく劣っているケースが多く、改善の伸びしろもモバイル側にあることがほとんどでした。

月次の推移を追う

施策の前後で効果があったかを見たいときは、複数の月次テーブルをまとめて読みます。

-- ワイルドカードで複数月を一括参照（コスト増に注意、期間は絞る）
SELECT
  _TABLE_SUFFIX AS yyyymm,
  ROUND(SUM(IF(bin.start < 2500, bin.density, 0)) * 100, 1) AS lcp_good_pct
FROM
  `chrome-ux-report.country_jp.*`,
  UNNEST(largest_contentful_paint.histogram.bin) AS bin
WHERE
  origin = 'https://example.com'
  AND _TABLE_SUFFIX BETWEEN '202601' AND '202606'
GROUP BY
  yyyymm
ORDER BY
  yyyymm;

ワイルドカード参照は便利ですが、対象テーブルが増えるほどスキャン量＝コストが増えます。_TABLE_SUFFIX で期間をしっかり絞るのがコツです。コスト面の注意点は別記事のBigQueryのコストを月1万円以下に抑えるで詳しくまとめています。

自サイトGA4のCVと突き合わせて優先度を決める

CrUXは「サイト全体の速度の分布」を教えてくれますが、CVRは教えてくれません。CVRは自サイトのGA4側にあります。そこで、両者を並べて「優先度」を決めます。

ここで大事なのは、CrUXとGA4を1行に結合（JOIN）して因果を出そうとしないことです。CrUXはオリジン単位・月次の集計値、GA4はセッション単位の個票で、粒度がまったく違います。無理に突き合わせると、見かけ上の相関を因果と取り違えてしまいます。

現実的なやり方は、「並べて優先順位をつける」ことです。たとえば、次のような表を月次で作って眺めます。

観点	データの出どころ	見るもの
速度（体験の質）	CrUX	LCP/INP/CLSが「良い」割合、PC・モバイル別
流入の重さ	GA4	セッション数（どのデバイスが多いか）
成果	GA4	デバイス別CVR・購入数

判断のロジックはシンプルです。

GA4で、CVRが低く、かつセッション数が多いデバイスを特定する（改善インパクトが大きい層）。
その同じデバイスについてCrUXを見て、速度が悪い（「良い」割合が低い）かを確認する。
両方に当てはまれば、速度改善の優先度が高い。CVRは低いのに速度は十分速いなら、原因は速度以外（価格・導線・在庫表示など）にあると切り分けられる。

GA4側でデバイス別のCVRを出すクエリは、たとえば次のような形になります（GA4のBigQueryエクスポートを使っている前提です）。

-- GA4 BigQuery エクスポートのイベントテーブルから
-- デバイス別のセッション数・購入数・CVR を出すサンプル
WITH sessions AS (
  SELECT
    device.category AS device,
    CONCAT(
      user_pseudo_id, '-',
      CAST((SELECT value.int_value FROM UNNEST(event_params)
            WHERE key = 'ga_session_id') AS STRING)
    ) AS session_id,
    MAX(IF(event_name = 'purchase', 1, 0)) AS has_purchase
  FROM
    `your_project.analytics_XXXXXXXX.events_*`
  WHERE
    _TABLE_SUFFIX BETWEEN '20260601' AND '20260630'
  GROUP BY
    device, session_id
)
SELECT
  device,
  COUNT(*) AS sessions,
  SUM(has_purchase) AS purchases,
  ROUND(SUM(has_purchase) / COUNT(*) * 100, 2) AS cvr_pct
FROM
  sessions
GROUP BY
  device
ORDER BY
  sessions DESC;

このGA4側の結果と、先ほどのCrUX側の「デバイス別 LCP good割合」を、同じ月で横に並べます。たとえば「モバイルはセッションの7割を占めるのにCVRが低く、しかもLCPが良い割合も低い」と並べば、モバイルの速度改善が最優先、という判断ができます。

なお、購入だけでなく「カート追加で離脱した層」まで掘り下げたい場合は、GA4×BigQueryで商品ページの離脱率を分析するのアプローチと組み合わせると、速度と離脱の関係まで見えてきます。

⚠️ 解釈の注意：CrUXは集計値で個票でない・因果は限定的

ここまでの手順を実務で使う前に、必ず押さえておきたい注意点があります。

CrUXは集計値であり、個票ではない：「速度が遅かった人が買わなかった」という個人レベルの紐付けはできません。あくまで「サイト全体で速度がこう分布していた」という話です。
オリジン単位なので、特定ページの速度はわからない：商品ページだけが遅い、といった粒度の分析はCrUX単体では不可能です。ページ単位で見たいときは、PageSpeed Insightsや自前のRUM（実ユーザー計測）など、別の手段が必要になります。
相関は因果ではない：「速いサイトはCVRが高い」という傾向が見えても、それは「速いサイトはそもそも作りが丁寧でCVRも高い」だけかもしれません。速度を上げれば必ずCVRが上がる、とは言い切れません。
月次なので反応が遅い：施策を打ってもCrUXに反映されるのは翌月以降です。短期の効果検証には向きません。

つまりCrUXは、「犯人を特定する道具」ではなく「どこを疑うべきかの当たりをつける道具」です。最終的に速度がCVRに効いているかどうかは、自サイトでの改善前後のA/Bテストや、GA4での実測でしか確かめられません。

まとめ

「サイトが速いと売れる」は、自分のサイトで検証する価値のある仮説です。検証の入り口として、CrUXの公開BigQueryデータはとても便利でした。

この記事で扱った流れを振り返ると、次のようになります。

CrUXは、Chrome実ユーザーの速度実測値をオリジン単位・月次の集計値として公開している。
LCP/INP/CLSのヒストグラムから、「良い体験の割合」やPC・モバイル別の差が読める。
CrUX（速度）とGA4（CVR）は粒度が違うので、無理にJOINせず並べて優先度を決める。
CrUXは集計値で個票でなく、因果も限定的。当たりをつける道具として使う。

自分としては、速度改善は「やった方がいい施策」ではあるものの、限られた工数の中では「本当にCVRのボトルネックになっているのか」を先に切り分けることが大事だと感じています。CrUXとGA4を並べて見れば、その切り分けの精度は確実に上がります。

皆さんのECサイトでは、表示速度とCVRの関係をどのように見ていますか。