CrUX（Chrome User Experience Report）は、ChromeユーザーがWebサイトを閲覧したときのスピード指標を収集したビッグデータだ。このデータの素晴らしいところは、
- 事前準備なしに、思いついたときにサイトスピードの状態を確認できる
- 他のサイトも同様に確認し、競合サイトと比較できる
こういった点にある。
一方で弱点もある。Chromeユーザーの、さらにオプトインしたユーザーだけが対象であることだ。
スマホで言うと日本はiPhone利用者が多く、デスクトップもEdgeがシェアを伸ばしている。このように偏ったデータであることは否めない。
弊社では、より詳細なスピード体験を観測するため、RUM（Real User Monitoring）収集サービス「Speed is Money」を運営している。Speed is Moneyでは、iPhone SafariやEdgeといったChrome以外の有力ブラウザからも、可能な限りスピードを収集している。
この記事では、この二つのデータにどんな違いがあるかを比較してみた。
CrUXはGoogleのおかげで手軽にアクセスできる貴重なデータだが、実際のユーザー体験とどんな誤差があるのか？ CrUXを見てサイトスピードに関する判断をするとき、何が正しくて、何が間違っているのか？
このような疑問に、一応の回答を示したい。
ただし、Speed is Moneyもより多くのユーザーをカバーした標本ではあるが、真実（母数）ではない。また、今回は14の通販サイトを対象に調査を行ったが、これもネット全体からすると微小なサンプルだ。
そうした限界は承知のうえで、「CrUXって、サイトスピードに関する意思決定をする上で信用できるよね？」を、実データで再確認してみたい。
そもそもCrUXは誰を見ているのか
「Chromeユーザーだけ」と言うと軽く聞こえるが、実際にどれだけの人が抜け落ちるのか。まず、そこを日本のブラウザシェアで具体的に押さえておきたい。ここが、この記事のすべての土台になる。
CrUXに体験が集計されるのは、Googleの公式メソドロジーによれば、次を満たすChromeユーザーだけだ。
対象
- デスクトップ版Chrome（Windows / macOS / ChromeOS / Linux）
- Android版Chrome
対象外（公式が明記して除外）
- iOS版のChrome
- Android アプリ内の WebView
- その他のChromium系ブラウザ（Microsoft Edge を明示）
そのうえで、利用統計レポートを有効化し、閲覧履歴を同期している（オプトインした）人だけがカウントされる。
「モバイルのChromeは全部CrUXに入る」は誤り
iPhoneではAppleの制約で、Chromeを含むすべてのブラウザがSafariと同じWebKitエンジンで動く。CrUXの計測機構はChromiumのBlinkエンジン上でしか働かないため、iOS版のChromeはまるごと対象外だ。CrUX対象のモバイルChromeは、実質「Android版Chrome」だけと考えてよい（web.dev: CrUXとRUMの違い）。
デスクトップ：CrUXが見ているのは3分の2だけ
日本のデスクトップ・ブラウザシェアに、CrUXが拾う範囲を重ねてみる。上段が各ブラウザの内訳、下段はCrUX対応（緑）と対象外（グレー）に分けたもので、横軸はいずれもシェア（%）だ。赤い破線がCrUX対応の境界を示す。
CrUXが拾うのは Chromeの65.4%だけ（StatCounter, 2026年6月）。次点の Edge（22.2%）はChromium系でも対象外で、SafariやFirefoxも当然入らない。つまりデスクトップ来訪のおよそ3分の1を、CrUXは一切見ていない。後で「デスクトップのLCPが実測と大きくズレる」ことを確かめるが、その根っこは、この見えていない3分の1にある。
モバイル：iPhoneが過半なのに丸ごと不可視
モバイルは非対称がさらに極端だ。同じく上段が各ブラウザの内訳、下段がCrUX対応の上限（Android・緑）と対象外（iOS等・グレー）で、横軸はシェア（%）である。
まず日本のモバイルOSは iOS 58.7% / Android 41.2%。iPhoneのほうが多い。そして前述のとおり iOSはSafari・Chromeともに同じWebKit＝丸ごとCrUX対象外だ。グラフのChrome 55%はAndroid版とiOS版の合算で、そのうちCrUXに入るのはAndroid版だけ。Safari 40%も当然入らない。
結局、CrUXのモバイル値は「Android Chromeの体験」であって、iPhoneが過半を占める日本のモバイル実体験の代表ではない。この前提を頭の隅に置いて、以降のデータを見てほしい。
出典
ブラウザ・OSシェアはいずれも StatCounter GlobalStats（日本・2026年6月）。内訳はデスクトップ・ブラウザ／モバイル・ブラウザ／モバイルOSを参照した。CrUXの対象範囲はChrome公式のメソドロジーによる。
CrUXのデータはどんな数字でできているか
対象ブラウザを理解したところで、CrUXが保持している数字の意味も確認しておこう。
まず、ユーザーの体験スピードは、同じページであってもかなりのばらつきが生じる。端末や回線が人それぞれだからだ（このばらつきは「ページスピードは一定ではない？」で詳しく書いた）。したがって、単純に「何秒」とひとつの数字では表現できない。そこでCrUXは、体験のばらつきを次の2つの形にまとめて持つ。
- p75（75パーセンタイル） — 大多数（訪問者の75%）の体験が、何秒以内に収まっているか。たとえばLCPのp75が2.5秒なら「4人に3人は2.5秒以内に表示できていた」を意味する。
- Good（良い）／ Needs improvement（要改善）／ Poor（悪い）の比率 — 指標ごとに良い・悪いの基準線を設け、全体験が3グループに分かれる。その構成比だ。PageSpeed Insightsの緑・黄・赤の帯がこれで、LCPなら2.5秒以下ならGood（良い）、4秒超ならPoor（悪い）。
この記事で特に見るのは、次の3つの指標だ。あわせて、どちらの向きがよいかも押さえておきたい。
- p75 — 小さいほどよい
- Good（良い） — 大きいほどよい
- Poor（悪い） — 小さいほどよい
デバイスは分けて見る
CrUXは、端末を phone（スマホ）／ desktop（PC）／ tablet（タブレット） の3種類に分けて集計している。
PCはスマホより端末性能が高い。だから全体的によい数値が出やすい。両者を混在させると互いにノイズになり、データの意味が曖昧になる。したがって、デバイス別に集計するのが基本となる。
なお、タブレットはごく少数で、分析に足る母数がない。そこでSpeed is Moneyでは、タブレットをPCに含めている。本記事でも、タブレットは分析対象から外している。
データの取り出し方——CrUX APIとBigQuery
CrUXには、データの取り出し方がふたつある。
- CrUX API：直近28日のスナップショット。現在のスピードを速報として知りたいときに使う。ドメイン単位・ページ単位それぞれのデータを得られ、数値の精度も高い（1ミリ秒精度）。
- BigQuery：過去のアーカイブで、毎月中旬くらいに前月分までの集計が出揃う。ドメイン単位に集約される。
イメージとしては、売上の速報値と、月次決算で締めた確定値といったところだろうか。普段おなじみのPageSpeed InsightsやSearch Consoleに表示される数値は、CrUX APIのほうだ。
BigQueryには過去のデータが何年分も蓄積されている。特別なトラッキングなしでも、サイトスピードの長期的な推移を分析できるわけだ。BigQueryにはいくつかデータセットがある。弊社では、デバイスごとに集計された device_summary をよく使う。
BigQueryの難点は、反映の遅さと、p75の値が丸められることだ（LCPは100ミリ秒、INPは25ミリ秒刻み）。
そこで今回は、一致の精度をまず1ミリ秒精度のAPIで確かめ、そのうえで実運用で頼る月次アーカイブ（device_summary）が13か月×14サイト＝182点でどれだけ実測と合うかも検証した。
用途の線引き：参考になるケース／注意が必要なケース
先に結論を、用途別に整理する。「正しい使い方」と「間違えやすい使い方」の切り分けだ。
ただし、この「正しい／間違い」という物言いには留保がいる。正確には、今回の14サイト横断調査で「その読み方を否定する材料が見つかったか、そうでなかったか」を述べているにすぎない。14サイトはネット全体からすればごく小さな標本で、真偽を証明したわけではない。それでも、数字を扱って意思決定をする以上、どこかで何らかの態度を決める必要はある。弊社としては、今回支持された仮説をひとまず採用したうえで、今後のサイトスピード改善提案に活かしていく所存だ。以下の「正しい／間違い」は、その立場からの表現だと受け取ってほしい。
参考にしてよい（CrUXが当てになる）
- ✅ 競合と自社の速度の順位付け——「A社とB社、どちらが速いか」
- ✅ モバイルの速度水準——スマホのLCPなら、CrUXの数字はほぼ実測どおり
- ✅ モバイルの「良し悪しの割合」——Good（良い）率が何割か、はモバイルなら信頼できる
- ✅ INP（操作の反応性）——これはモバイル・デスクトップを問わず当てになる
- ✅ 月々の大きな変化——例えばLCPの数百ミリ秒単位の変動。ただしp75で追うよりGood（良い）率のほうが正確
注意が必要（CrUXを鵜呑みにしない）
- ⚠️ デスクトップの絶対値、とくにLCP——実測よりかなり楽観的に出る
- ⚠️ 「デスクトップがどれだけ悪いか」——遅い層を捉えきれず、Poor（悪い）を過小に見せる
- ⚠️ 月々の小さな変動——誤差やp75の丸めに埋もれる
- ⚠️ アクセス数の少ないサイト——そもそもデータが生成されず欠測しやすい
以下、なぜこう言えるのかを、突き合わせの実データで一つずつ示す。
検証（1）順位はよく当たる
ここから検証（3）までのグラフは、精度の高いCrUX API（直近28日のスナップショット・1ミリ秒精度）の数字を使い、Speed is Moneyの同じ28日と突き合わせている。
まず、CrUXとSpeed is MoneyのLCPを14サイト分プロットする。横軸・縦軸ともにLCPのp75（ミリ秒・小さいほど速い）で、横軸がCrUX、縦軸がSpeed is Moneyだ。破線は両者が完全一致する位置（y=x）を示す。
点は右肩上がりに並ぶ。速いサイトはCrUXと実測のどちらでも速く、遅いサイトも同様に遅い。順位の一致度を数値で見ると高く、LCPで順位相関0.96、INPで0.87、TTFBで0.93、FCPで0.96。「競合と比べてどちらが速いか」の相対評価に、CrUXは十分使える。
INP（こちらも横軸・縦軸ともにp75・ミリ秒）でも同じで、順位はよく当たる。
ただし、どちらの散布図も点は完全一致の線（破線）から外れている。LCPは線の上（実測のほうが遅い＝中央値で27%遅い）、INPは線の下（CrUXのほうが大きめに出る）に寄る。順位は当たるのに、絶対値はズレる。 しかも指標で外れる向きが逆——これは単なる測定誤差ではなく、構造的な要因があることを示唆する。
検証（2）モバイルは一致しデスクトップはずれる
その答えはデバイスにある。軸は変わらずLCPのp75（ミリ秒）で、同じ点をモバイル（青丸）とデスクトップ（橙の三角）に塗り分けてプロットすると、二つの層がくっきり分かれる。
- デスクトップ（橙）は完全一致の線から上に外れる。 実測のほうが中央値で46%遅く、相関は r=0.640。前に見たとおり、CrUXはデスクトップでもChromeしか拾わず、Edge・Safariを含む約3分の1を計測していない。対象がブラウザの一部に限られる以上、ここにズレが出るのは想定の範囲だ。
- モバイル（青）は完全一致の線に乗る。 CrUXのモバイル値と実測の差は中央値で+1.6%、相関 r=0.985。14サイトすべてがほぼ線上に並ぶ。検証（1）で見た「全体で27%ズレる」のは、このデスクトップ側のズレが全体値に混ざったためだ。
ここで思い出したいのが、CrUXのモバイルはAndroid Chromeだけの数値であることだ。日本ではモバイルの過半数がiPhoneで、Android Chromeのサンプルは半数に満たない。それでもCrUXとSpeed is Moneyの実測でp75がここまで一致するなら、iPhoneとAndroidも近いスピード分布を持つ、と推測できる。
この仮説の検証は今後の研究に譲る。現時点でも、CrUXモバイルのp75は全体像に近く、実測の参考として使える可能性が高い。
検証（3）INPはデスクトップでも一致する
次に、INP（操作してから画面が反応するまでの速さ）も同じ軸で見る。散布図はINPのp75（ミリ秒）で、モバイル（青丸）とデスクトップ（橙三角）に分けている。
LCPでは外れたデスクトップ（橙）が、INPでは線の近くに収まる（r=0.925）。モバイル（r=0.964）と合わせ、INPはデバイスを問わず実測とそろう。モバイルで反応が遅めの領域（右上）ではCrUXがやや大きめに出るが、その差は小さい。
つまり——INPに関しては、CrUXはLCP以上に「全体の実態に近い」データを見せていると言ってよさそうだ。読み込みの速さ（LCP）はデスクトップの見えない層に引っ張られたが、操作の反応（INP）はそうした層の影響を受けにくく、Android Chromeだけを見ても全体の姿とほとんど変わらない。INPで「このサイトは反応がよい/悪い」を読むなら、デバイスを問わずCrUXを信じてよいだろう。
検証（4）月次アーカイブでもモバイルのLCPは誤差が小さい
ここまでの検証（1）〜（3）は、1ミリ秒精度のCrUX APIでの話だった。 だが実務で過去をさかのぼるとき見るのは、丸められた月次アーカイブ（BigQueryのdevice_summary）のほうだ。ここから検証（6）までは、このアーカイブの数字を使う。そこで、13か月×14サイト＝182点をすべて打って、アーカイブが実測とどれだけ合うかを確かめた。まずは水準——LCPのp75（ミリ秒）——の散布図から。
APIのときと同じ構図だ。モバイルは完全一致の線に近い分布を描き、デスクトップにはやや大きなばらつきが見られる。過去の月をさかのぼっても、モバイルの速い/遅いは正しく読める。p75の系統差はSpeed is Moneyが約1割遅め（全ブラウザぶんの上振れ＋丸めで速めに出るぶん）で、これは目安として織り込めばよい。
同じp75でも、INPはアーカイブだと緩くなる。
デスクトップ（橙）はINPが小さく（25〜75ms）低い位置に固まる。モバイル（青）は縦縞状に散らばっている。アーカイブのINP p75は25ミリ秒刻みに丸められるため、連続値の実測との間に階段状のズレが出る。相関もモバイルで r=0.83と、LCPの0.96より緩い。アーカイブのINP p75は水準の目安どまりと見ておきたい。「p75は丸めに弱い」というこの性質が、月々の変動をGood（良い）率で追うべき理由（検証6）でもある。
検証（5）割合で見てもモバイルは一致する
p75だけでなく、Good（良い）／Poor（悪い）の割合でも突き合わせる。
具体的な数値が得られるp75は意味を解釈しやすい反面、丸めのぶん若干精度に劣る。イメージしやすければ、Good（良い）率——その指標の「良い」基準を満たした割合——を追うほうが、より正確だ。
まず、182点それぞれ（CrUX＝横軸、実測＝縦軸）を散布図にする。点が完全一致の線に寄るほど、CrUXと実測は近い。LCPから見る。左にGood（良い）率、右にPoor（悪い）率を並べた（各軸＝判定に入った割合%）。
モバイル（青）はどちらも完全一致の線に寄る（Good（良い）率の相関0.98、Poor（悪い）率0.95）。一方デスクトップ（橙）は線から外れる。CrUXがGood（良い）を約5ポイント多く、Poor（悪い）は約3ポイント少なく見せるためだ。デスクトップのLCPは「良く」見えやすい——水準の話と同じ癖だ。実務でひとつ覚えておくなら、これくらいでよい。
INPも同じ2枚で見る（左＝Good（良い）率、右＝Poor（悪い）率）。
Good（良い）率を見ると、デスクトップ（橙）は95%超に固まって線に近い。モバイル（青）は、とくにGood率が低めの左下で散らばりも見られるものの、おおむね線に沿う。相関はモバイル・デスクトップとも0.86前後だ。Poor（悪い）率は、どのサイトもほぼ0%に張り付く。点が集中するため相関係数は小さく出る。とはいえ「揃ってほぼ0%」という一致だ。CrUXで「INPが悪いサイトは少ない」と判断してよい。
最後に、指標ごとに数値でまとめる。device_summary と実測の Good（良い）率・Poor（悪い）率について、相関係数と両者の差（実測−CrUX・pt）を並べた。
| 指標 | 判定 | モバイル | デスクトップ | ||
|---|---|---|---|---|---|
| 相関 r | 差(pt) | 相関 r | 差(pt) | ||
| LCP | Good（良い） | 0.98 | -1.5 | 0.89 | -4.9 |
| Poor（悪い） | 0.95 | +0.6 | 0.67 | +3.3 | |
| FCP | Good（良い） | 0.99 | -1.2 | 0.97 | -5.2 |
| Poor（悪い） | 0.99 | +0.2 | 0.93 | +2.8 | |
| TTFB | Good（良い） | 0.95 | +4.1 | 0.88 | -2.0 |
| Poor（悪い） | 0.97 | -0.9 | 0.91 | +0.7 | |
| INP | Good（良い） | 0.86 | -1.2 | 0.86 | -1.4 |
| Poor（悪い） | 0.56 | +0.8 | 0.59 | +0.6 | |
モバイルはどの指標もGood（良い）率の相関が高く、差も数pt以内におさまる。一方デスクトップはGood（良い）の差が開きやすい（LCPで-4.9pt、FCPで-5.2pt）。Poor（悪い）率も傾向は同じだ。INPのPoor（悪い）は相関こそ低い。ただし値がほぼ0%に固まるためで、不一致ではない。
検証（6）月次トレンドは方向を追えるが乖離も残る
引き続き月次アーカイブ（device_summary）で「経緯」を見る。ここで確かめたいのは、月ごとに上がった/下がったという変動が、どこまで実際のスピード変化を映すかだ。CrUXの履歴を見て「今月このサイトは速くなった（遅くなった）」と判断してよいものか。
実際に動きのあった4サイトについて、モバイルのLCP p75の月次推移を、実測（実線）とCrUX（破線）で重ねた。縦軸はLCPのp75（ミリ秒）、横軸は月だ。
方向はおおむね合っている。Site C・Kは2025年夏にLCPが1.5〜1.8秒台から3.4秒前後へ悪化した。実線と破線はそろって跳ね上がる。Site Jはほぼ横ばい。Site Nは改善だ。大きめの変化なら、CrUXの履歴でも向きは読める。 14サイトの月次連動は、サイト別相関の中央値0.74（14サイト中13が正）だった。
ただし、水準が一段ずれるサイトもある。改善したSite N（最後の図）がその例だ。実測とCrUXは同じ下降トレンドを描くものの、実測が一段高い位置にある。p75は100ミリ秒刻みに丸められるため、こうしたずれが出やすい。
同じ4サイトを、今度はGood（良い）率（Good（良い）判定の割合・%）で見る。
実線と破線が、p75よりもさらに密に重なる。Site C・Kの急落や、Site Nの改善を、実測とCrUXがほぼ同じ軌跡でなぞる。Good（良い）率は割合で出るぶん丸めに強く、月々の変化を素直に映す。
最後にPoor（悪い）率（%）を見る。
こちらは実測とCrUXの開きが目立つ。CrUXはPoor（悪い）を実測より小さめに見せ（Site C・Kで顕著）、値も小さいぶん揺れやすい。悪化の向きこそ捉えるが、水準を月次で細かく追うのは心もとない。
整理すると、月次で追うときの信頼性は Good（良い）率 ＞ p75 ＞ Poor（悪い）率 の順になる。月々の変動を追うなら、まず見るべきはGood（良い）率だ。 p75は直感的だが、丸めで一段ずれる。Poor（悪い）率は数字が小さく、揺れやすい。
それでも、追えるのは方向までだ。本物の変化かどうかの確証が要るなら、CrUXで見当をつけ、最後はRUMで実測したい。
まとめ：CrUXが使える範囲と注意点
最初の問いに戻ろう。「CrUXって、サイトスピードの意思決定に信用できるよね？」——答えは、用途を選べばイエスだ。
CrUXの守備範囲は狭い。日本で見ているのはデスクトップChrome（65%）とAndroid Chromeだけで、デスクトップのEdge・Safari・Firefox（約3分の1）も、iPhoneのSafari（モバイルの過半）も含まない。それでも、モバイルのLCPは14サイトすべてで実測とそろい、INPはデスクトップまで一致した。対象が限られていても、モバイルの水準はおおむね言い当てられていた。
だから、競合との順位、モバイルの水準と割合、INP、大きな変化の履歴は、全ブラウザのRUMと突き合わせても十分に信頼できる。裏を返せば、CrUXが実態からはっきりズレるのは、対象が構造的に狭いことに起因する一点——デスクトップの絶対値、とくにLCPの「どれだけ悪いか」——にほぼ絞られる。そこだけ割り引いて読めば、CrUXは「地図」として相当に正確だ。
CrUXを疑う必要はないし、盲信する必要もない。地図と実測の縮尺の違いを知って使い分ける。それが、フィールドデータと正しく付き合うということだと思う。
なお冒頭で断ったとおり、突き合わせに使ったSpeed is Money自身も全数ではなく標本で、対象は14サイトという小さなサンプルだ。ここで引いた線は「決定版」ではなく、あくまで一つの実測に基づく目安として受け取ってほしい。
全ブラウザで実測するには
冒頭で触れた「Speed is Money」は、サイトスピードに特化したシンプルな無料アクセス解析サービスだ。Safari・Edgeも含めた全ブラウザ・全訪問者の速度を取りこぼさず記録するので、CrUXでは見えないデスクトップの実態や、iPhoneユーザーの体験、実来訪の本当のデバイス構成まで把握できる。
この記事のデータも、Speed is Moneyを利用中の通販サイト14サイトに協力をいただいた。CrUXの数字だけで物足りなくなった方は、ぜひ実測を試してみてほしい。
なお、速度がCVRにどう効くのかについては、「通販サイトが遅いと損失はどのくらい？」でも機会損失の見える化として詳しく扱っている。あわせて読んでいただけると幸いだ。