CrUX データが RUM データと異なるのはなぜですか?

RUM データに CrUX とは異なる Core Web Vitals の数値が表示される理由について説明します。

Chrome ユーザー エクスペリエンス レポート(CrUX)では、Chrome ユーザーがウェブ上の人気ページに実際にアクセスしたときのユーザー エクスペリエンスに関する指標を確認できます。このデータは、オプトインしたユーザーから Chrome によって自動的に収集され、CrUX の利用条件に基づいて提供されます。

そのため、CrUX データは何百万ものウェブサイトで利用できます。多くのサイト所有者はこれまでフィールド データにアクセスすることがありませんでしたが、CrUX のおかげで、多くのサイトで初めてフィールド データの価値を実感できるようになりました。CrUX は一般公開データセットとして、ユーザー エクスペリエンス指標の競合分析やベンチマークにも使用できます。

実際のユーザー モニタリング(RUM)は CrUX と似ていますが、Chrome がユーザー エクスペリエンス指標を自動的に収集する代わりに、収集用のコードがウェブサイトに含まれています。そのデータは RUM プロバイダや分析ソリューションにフィードされ、詳しく分析されます。

どちらのソリューションでもユーザー エクスペリエンス指標を測定する場合、両者は同等であるべきだと考えるのは自然なことです。相違があると、混乱を招く可能性があります。このガイドでは、このような問題が発生する理由を説明し、数字が一致しない場合の対処方法を提案します。

RUM ソリューションで CrUX を補完するメリット

CrUX は、サイトをまたいで一貫したビューを実現する優れたツールであり、Core Web Vitals プログラムの公式データセットとして、サイトに表示される内容に目を光らせたいと思うでしょう。CrUX の目的は、統計的に有意な、数百万のウェブサイトの概要を提供し、相互比較することです。

ただし、データが数値を示している理由を詳しく調べるには、CrUX を補完する完全な RUM ソリューションに投資すると、一般公開されているクエリ可能なデータセットで入手可能な情報よりも詳細な情報にアクセスできます。このレポートは、さまざまな方法で指標について説明し、改善するのに役立ちます。

詳細な分析で問題を調査

CrUX は、サイトに問題があるかどうかを示すのによく使用されますが、必ずしもサイトのどこに問題があるか、またはなぜ問題があるとは限りません。RUM ソリューションは、web-vitals ライブラリなどの媒体を通じて独自に開発されたものでも、多数の市販製品を通じて開発されたものでも、このギャップを埋めるのに役立ちます。

RUM ソリューションを使用すると、すべてのページとすべてのブラウザで、より詳細なデータにアクセスできます。また、CrUX にはない方法でデータをセグメント化して分析できるため、サイトの問題点をドリルダウンして調査できます。特定のユーザー層による影響を受けているのか?または、特定のアクションを行ったユーザー。問題が発生したのはいつごろですか?RUM ツールで提供される追加データがあれば、これらの質問に簡単に答えられます。

他のビジネス指標と関連付ける

RUM では、ウェブのパフォーマンス指標をビジネス指標と直接比較して、パフォーマンスに投資することの価値や、他に重視すべきパフォーマンスを確認できます。Google は、FarfetchThe Economic Times など、この相関分析を行っている企業の事例紹介が多数存在します。

その他のパフォーマンス データの収集

RUM ソリューションを使用すると、特定のビジネスに直接関連する他のカスタム指標を収集できます。よく知られている例として、Twitter の「Time to first Tweet」が挙げられます。表示されます。サイト固有のこうした指標は、Core Web Vitals の改善やビジネス指標と関連付けることができます。

2 セットのフィールド データの違い

時計を持っている男性が今何時か知っている。時計を 2 つ持っている男には、確信がありません。

シーガルの法則

データソースが 2 つあると、なぜ 2 つが異なるのかわかりづらくなりがちです。ラボとフィールドの指標の違いを理解することが重要であるのと同じように、フィールド データの 2 つのソースにも差異が生じることがあります。理想の世界ではデータは同じでも、異なる理由はさまざまです。

ラボデータとフィールド データ

まず、ラボ(合成)指標とフィールド(RUM)指標のどちらが表示されているかを確認します。RUM プロダクトがフィールド データのみを参照するのは自然なことですが、その多くはラボ コンポーネントも提供しています。

ラボデータは一定の条件下で測定されるため、非常に役立ちます。これを使用すると、本番環境での予期せぬ変化や回帰を、現場で変化するノイズにさらされることなくモニタリングできます。ただし、ラボデータは実際のユーザー エクスペリエンスを反映していない可能性があるため、フィールド指標からはまったく異なる結果が得られます。

人口

CrUX と RUM のソリューションで使用されるデータセットは異なる場合があります。これは、比較するブラウザ、ユーザー、サイト、デバイスによって、ページ訪問数が測定される方法が異なるためです。

含まれるブラウザ

Chrome ユーザー エクスペリエンス レポートは、その名前が示すように Chrome 専用です。Chromium ベースのブラウザは多数あり(Edge、Opera、Brave など)、共有コア コードベースがあるため Chrome と同じ指標もサポートしていますが、CrUX にデータをフィードするのは Chrome ユーザーのみです。この制限により、iOS の Chrome ユーザーは含まれません。これは、基盤となる Webkit のブラウザ エンジンを使用しているためです。また、Android WebView は「Chrome」としてカウントされないため、これらのユーザーのデータは含まれませんが、Chrome カスタムタブは含まれます。

Chrome は世界的に広く利用されているブラウザであり、ほとんどの場合、サイトのパフォーマンスを幅広く表すことができますが、そのブラウザだけを測定してもすべてのユーザーを測定できるわけではありません。このことから、RUM と CrUX の主な違いを 1 つ説明できます。API や Chrome でのみ利用可能な画像形式に依存するパフォーマンス手法の場合は特にそうです。

iOS データが不足していることも、バイアスにつながる可能性があります。たとえば、iOS ユーザーは一般的にパフォーマンスの高いデバイスを使用しているため、ネットワーク インフラストラクチャが優れた多くの国からアクセスしているため、全体的なパフォーマンス指標が高くなる可能性があります。一方、CrUX のように除外すると、サイト訪問者の下位層に偏るデータになる可能性があります(ケーススタディ)。Android ユーザーは通常、幅広いデバイスや機能、市場をカバーしています。

RUM ソリューションは、Chrome 以外のブラウザ、特に同じ指標(Core Web Vitals など)が組み込まれていることが多い Chromium ベースのブラウザからのデータを取得できます。Chromium ベース以外のブラウザも RUM ソリューションで測定されますが、利用できる指標が限られている場合があります。たとえば、Cumulative Layout Shift(CLS)Interaction to Next Paint(INP) は、Chromium ベースのブラウザでのみ使用できます。First Contentful Paint(FCP)など、他の一部の指標はまったく異なる方法で測定される場合があります(後述)。

オプトインしたユーザー

CrUX は、Chrome ユーザーに限定されるだけでなく、ブラウザのインストール時に CrUX データの共有をオプトインした一部の Chrome ユーザーのみを測定することで、さらに制限されます。

また、RUM プロバイダはユーザーのサブセットのみを確認します。通常は、Cookie バナー プロンプト(RUM データ収集を有効にするようユーザーに促すメッセージやトラッキング ブロッカー)が使用されます。サイトアセットの一部が前のページからキャッシュされた状態で 2 ページ目以降のページまで確認を行わないと、最初のページの読み込みに悪影響が及ぶ可能性があります。この状況が頻繁に発生する場合は、最初のページ読み込みの低速化が十分な数のケースで除外されれば、RUM の指標が実際よりも有利に見えることがあります。

追加したサイト

CrUX は公開ウェブサイトでのレポートのみを目的としているため、他の利用条件によってデータが CrUX に記録されない場合があります。これらの基準の中で最も注目すべきは、有意な結論を導き出すサンプル数を最小限にとどめるには、そのウェブサイトが一般公開されており、十分な人気がある必要があることです。その結果、ほとんどの場合、CrUX ではデータを利用できません。利用できるデータと比べると、わかりにくい違いではありませんが、その理由が異なります。

ただし、サイト内の特定のページがインデックス登録可能とマークされていて他のページはインデックス登録可能とマークされていない場合は、CrUX で一部の URL しか表示されないことがあります。オリジンが一般公開されている場合、そのオリジン内のすべてのページビューがオリジン レベルのデータに含まれますが、URL レベルのデータは利用できない場合があります。

デバイス

CrUX では、データをモバイル、パソコン、タブレットごとに分割します。ただし、多くのツールは最初の 2 つに集中しており、タブレットのデータを公開していないか、モバイルまたはパソコンに含まれている可能性があります。モバイルとパソコンのパフォーマンス特性は、配信するコンテンツと、それを表示するデバイスの機能の両方で、まったく異なる場合があります。

RUM データでも同じようにトラフィックを分割できますが、多くの場合、デフォルトで統合されたデータが表示されます。RUM では、デバイスの種類(モバイルなど)またはブラウザ(Chrome など)による分割のみを許可できますが、両方でモバイル Chrome トラフィックのみを確認することはできません。CrUX のデータと比較する際は、デバイスタイプと Chrome ブラウザでフィルタすることで、同一条件で比較します。

サンプリング

RUM ソリューションでは通常、データを収集するオプトイン ユーザーのサンプリング レートを調整できます。これにより、分析が必要なデータの量を減らし、商用 RUM サービスの費用を削減できます。サンプルサイズが小さすぎて母集団を表していない場合、結果として得られる指標にも同様に偏りが生じます。サイトの適切なサンプリング サイズについては、RUM の提供元と相談してください。

データの集計

フィールド データには、その性質上、ラボデータと比較して同じ指標のデータポイントが多数あり、単一の値になります。このデータをレポートで集計する方法が異なる場合は、CrUX と RUM で別の原因が発生する可能性があります。

期間

CrUX データは 28 日間のスライディング トラフィックに基づいており、この期間を変更することはできません。ただし、CrUX BigQuery データは月ごとに保存されるため、前月を確認できます。また、CrUX History API でも、週単位の履歴データを確認できます。どちらも、引き続き 28 日間のスライディング ウィンドウに基づくデータを提供します。

RUM データは通常、より粒度が高いため、変更の影響をより迅速に確認できます。ただし、期間を短くすると、ウェブサイトのトラフィックや訪問者の変動によって RUM データが過度に影響を受けることがあります。RUM データと CrUX データを比較する場合は、常に 28 日間のパフォーマンスを確認するようにしてください。データが類似していることを確認したら、他の期間を確認して RUM データの詳細を確認できます。

統計情報の集計

CrUX 指標は 75 パーセンタイル、つまりページビューの 75% が達成した値で測定されます。現場データに極端な差が生じ、最悪の 25% のエクスペリエンスが排除されることになります。これは、大部分の訪問者が達成すると合理的に期待できる価値を提供することを目的としています。

RUM サービスでは多くの場合、75 パーセンタイル、中央値、その他のパーセンタイルなど、指標を集計する方法の選択肢が広がります。RUM 値を CrUX データと比較する場合は、同程度のデータを比較するために 75 パーセンタイルのデータを確認する必要があります。

CrUX のヒストグラム データには 75 パーセンタイルだけでなく、利用可能なすべてのデータが含まれ、各評価のページビュー数が表示されますが、集計スコアは 75 パーセンタイルに基づきます。この CrUX データは、PageSpeed Insights などのツールに表示されます。

LCP 評価ページ読み込みのヒストグラムを示す PageSpeed Insights のスクリーンショット
PageSpeed Insights で CrUX の 75 パーセンタイル データとヒストグラム データが表示される

指標の違い

ウェブ パフォーマンスの測定にはさまざまな指標が使用されます。そのため、2 つの異なるデータセットを比較する際は、測定する指標とその用途を理解することが重要です。

測定される指標

CrUX データは Core Web Vitals イニシアチブの公式データセットであり、主にこれらの指標(LCPCLSINP)を測定し、これらを補完するいくつかの追加指標も測定しています。

RUM ツールには通常、Core Web Vitals が含まれていますが、多くの場合、他の多くの指標も含まれています。RUM プロバイダによっては、これらすべての指標を独自に組み合わせてユーザー エクスペリエンスを測定し、「幸福度指数」を算出している場合もあります。できます。RUM データを CrUX と比較する際は、ほぼ同等に比較するようにしてください。

Core Web Vitals の合格 / 不合格ステータスを評価するツールでは、すべての Core Web Vitals の 75 パーセンタイルで推奨目標を満たしている場合、ページ合格とみなす必要があります。インタラクションがないページに INP が存在しない場合は、LCP と CLS のみに合格する必要があります。

ブラウザごとの指標の違い

CrUX が測定されるのは Chrome ブラウザでのみです。各バージョンの Chrome での変更点については、ウェブに関する指標の変更履歴をご覧ください。

一方、RUM ソリューションは、さまざまなブラウザから測定できます。Chromium ベースのブラウザ(Edge、Opera など)は、変更履歴に記載されている新しい変更が Chrome に実装されている場合を除き、Chrome と類似している可能性があります。

Chromium 以外のブラウザでは、その違いはより顕著になります。たとえば、First Contentful Paint(FCP)は Safari と Firefox で利用できますが、測定方法が異なります。そのため、報告される時刻に大幅な差異が生じることがあります。前述のように、RUM と CrUX を比較する場合は、Chrome ユーザーだけをフィルタして、ほぼ同じ条件で比較できるようにすることをおすすめします。

指標のタイミング

Core Web Vitals の指標はウェブブラウザの API によって提供されますが、それはその API を使用してレポートされる値に差異がある可能性がないという意味ではありません。ページの読み込み時やページのライフサイクル全体を通して、指標がいつ測定されたかによって差異が生じることがあります。RUM ツールでは、データの取得に同じ名前や同じブラウザ API を使用している場合でも、常に同じ方法で指標を測定するとは限らず、混乱を招く可能性があります。

Largest Contentful Paint(LCP)はページ読み込みの指標です。最初のレンダリングの後、大きな要素が読み込まれた場合は、Web API によって多数の LCP 要素が報告されることがあります。最後の LCP 要素は、ページの読み込みが終了したとき、またはユーザーがページを操作したときです。そのため、LCP 要素がこの 2 つのイベントよりも早く報告されると、差異が生じることがあります。

また、フィールド データ内の LCP 要素は、ページの読み込み方法によって異なる場合があります。デフォルトのページ読み込みでページ コンテンツの最上部を表示する場合、LCP 要素は主に画面サイズに依存します。ただし、ドキュメントのさらに下のアンカーリンクでページを開いたり、同様にシングルページ アプリ(SPA)へのディープリンクで開いたりした場合(詳細は後述します)、LCP 要素が異なる場合があります。

CrUX または RUM で提供される LCP のタイミングが、ラボツールと同じ要素に基づいているとは想定しないでください。CrUX ではページまたはオリジンごとの LCP の全体値を確認できますが、RUM ではさらにセグメント化して、個々の LCP 問題のセッションを特定できます。

Cumulative Layout Shift(CLS)は、ページのライフサイクル全体で測定されるため、最初のページ読み込みの CLS は、ページが読み込まれてユーザーが操作した後に大きな変動が生じるページを示しているとは限りません。そのため、多くの RUM サービスと同様に、ページの読み込み後にのみ CLS 値を取得すると、ユーザーがページでそのページを終了した後に CLS 値を取得する結果とは異なる結果が得られます。

Interaction to Next Paint(INP)の応答性指標では、入力を測定する必要があります。また、CLS と同様に、ページ全体を通してすべてのクリック、タップ、キーボードの操作が測定されるため、ユーザーがページで何度か操作を行った後に測定された場合、INP のレポート値は大きく異なる場合があります。

CrUX は、Core Web Vitals のドキュメントに沿って、ページの全期間にわたって測定します。RUM プロバイダの多くは、ページの読み込み後やその他のタイミング(主要な行動を促すフレーズがクリックされたときなど)に、さまざまな理由からこれらの指標を測定しています。

2 つのデータソース間で不明な差異が見られる場合は、Core Web Vitals がいつ測定されるかについて RUM プロバイダから理解してもらうことが重要です。

シングルページ アプリケーション

シングルページ アプリケーション(SPA)は、ブラウザレベルで実際のページ ナビゲーションを実行するのではなく、現在のページのコンテンツを更新するという形で動作します。つまり、ユーザーがこのような操作を経験しているにもかかわらず、ブラウザではこれらの操作をページ ナビゲーションとして認識しません。ブラウザが提供する Core Web Vitals API では考慮されないため、CrUX ではこうしたページ ナビゲーションをサポートしていません。現在、この問題の解決に取り組んでいます。詳しくは、ソフト ナビゲーションの測定のテストの投稿をご覧ください。

一部の RUM プロバイダは「ソフト ナビゲーション」を検出しようとするCore Web Vitals の指標をこうした「ソフト ナビゲーション」に結び付ける場合、基盤となる API が多くの指標でサポートしていないため、CrUX との相違が生じます。

CrUX と Web API の違い

測定されるページビューと測定対象のページビューの違いだけでなく、CrUX と RUM のデータに差異をもたらす可能性がある、より複雑なシナリオもいくつかあります。その一部は、指標の測定に使用するウェブ API の制限によるものです。また、特定のシナリオでは、API から返される結果を別の方法で処理する必要があります。Core Web Vitals のドキュメントでは、LCPCLS の違いについて説明していますが、主な違いについては以下のセクションでも説明されています。

バックフォワード キャッシュ

CrUX では、従来のようなページ読み込みは行われませんが、バックフォワード キャッシュ(bfcache)による復元はページ ナビゲーションと見なされます。Web API ではこれらのページがページの読み込みとして扱われないため、RUM ソリューションで CrUX と一致するには、これらのページをカウントするには追加の手順を行う必要があります。これらはページ読み込みが大幅に高速化されるため、サイトの全体的なパフォーマンス向上につながる可能性があるため、含めないと、ページの全体的なパフォーマンス指標が低下する可能性があります。RUM ソリューションを参照して、bfcache によって復元されたページが処理されるかどうかを確認してください。

iframe

セキュリティおよびプライバシー上の理由から、最上位レベルのページは iframe 内のコンテンツにアクセスできません(同一オリジンの iframe であってもアクセスできません)。つまり、コンテナ内のコンテンツのパフォーマンス指標は iframe 自体でのみ測定でき、フレーム処理ページのウェブ API からは測定できません。iframe コンテンツに LCP 要素、またはユーザーが認識する CLS または INP に影響するコンテンツが含まれている場合、RUM ソリューション(Google web-vitals JavaScript ライブラリを含む)では利用できません。

ただし、CrUX は、ページ上の JavaScript ではなく、Chrome ブラウザ自体によって測定されるため、このような制限はないため、Core Web Vitals を報告するときに iframe 内の指標を測定します。これはユーザー エクスペリエンスをより正確に反映しますが、iframe を使用しているサイトでは違いが生じる別の原因になることがあります。

これが CrUX と RUM の LCP データの違いをどのように引き起こすかについての具体的な例の 1 つは、<video> です。自動再生される <video> 要素で最初に描画されるフレームは LCP の候補としてカウントできますが、一般的な動画ストリーミング サービスの埋め込みでは、これらの要素を <iframe> に配置できます。CrUX は <iframe> コンテンツにアクセスできるため、このことを考慮できますが、RUM ソリューションはアクセスできません。

クロスオリジン リソース

他のドメインから配信される LCP メディアは、PerformanceObserver API でレンダリング時間を与えません(Timing-Allow-Origin ヘッダー(TAO)が指定されている場合を除く)。これは、タイミング攻撃を軽減するためのブラウザのセキュリティ制限によるものです。これはリソースの読み込み時間にフォールバックしますが、コンテンツが実際にペイントされたときとはかなり異なる場合があります。

そのため、ウェブ API によって LCP が FCP よりも早く報告されるという、一見ありえない状況につながりかねません。これは、このセキュリティ制限によるものです。

繰り返しになりますが、CrUX は Core Web Vitals のレンダリング時間データをレポートします。Core Web Vitals の指標に影響を与えるクロスオリジン コンテンツを制限するとともに、より正確に測定したい場合は、可能であれば TAO を有効にすることをおすすめします。他のクロスオリジン リソースにも同様の制限が適用される場合があります。

バックグラウンドのタブ

ページがバックグラウンドのタブで開かれていない場合でも、ウェブ API を使用して指標が出力されます。ただし、ユーザー エクスペリエンスと矛盾するタイミングが提供されるため、CrUX では報告されません。RUM ソリューションでは、これらを無視するか、少なくともページビューの処理方法を説明できるようにする必要があります。

どうすればよいでしょうか

CrUX データと RUM データに差異が生じる理由は、それぞれで使用される手法の違いや、ユーザーとページビューが対象または除外対象になっているためです。両方のデータ セットが有用であるためには、両方のデータ セットがサイトのパフォーマンスを表すことが理想的ですが、それぞれのデータでまったく同じ数値が得られる可能性が非常に低い理由を説明する必要があります。

違いがわずかである場合(たとえば、2.0 秒と 2.2 秒の LCP を報告するなど)、両方のデータセットが有用であり、通常はほぼ同期していると考えられます。

顕著な違いによってデータの正確性に疑問がある場合は、その違いを理解しようとするべきです。RUM データをフィルタして CrUX に近づけて(パソコンまたはモバイルの Chrome ユーザーのみに着目し、28 日間で 75 パーセンタイルの値にする)ことで、これらの違いを減らすことはできるでしょうか?

もしそうで、データをより正確に一致させることができる場合は、データ全体でこのような違いが見られる理由と、それが何を意味するのかを考える必要があります。Chrome 以外のユーザーによる指標の歪みは、プラスまたはマイナスのどちらのものですか?これによって、優先すべきパフォーマンスの問題がどこにあるかについて、より詳細な分析情報を得られますか?

Chrome を使用していないユーザーでも異なる結果が得られる場合は、RUM から得た貴重な分析情報を活用して、別の方法で最適化できます。たとえば、一部の API は特定のブラウザでは使用できませんが、サポートされていないブラウザの代替機能を検討して、エクスペリエンスを改善することもできます。または、制約のあるデバイスやネットワークを使用するユーザーに、従来とは異なるパフォーマンスの高いエクスペリエンスを提供することもできます。CrUX は Chrome のデータに限定されますが、サイト訪問者の改善の優先順位付けに役立てます。RUM データでこのギャップを埋めることができます。

差異の理由がわかれば、どちらのツールもウェブサイトのユーザー エクスペリエンスを把握するのに非常に役立ちます。また、数値が同一でない場合でも改善に役立ちます。RUM データを使用して CrUX データを補完し、トラフィックをセグメント化して注意が必要なサイトまたはユーザーベースを特定することで、CrUX が何を伝えているかを大まかに掘り下げることができます。

多くの場合、2 つのデータソース間でそれぞれの数値が正確に一致しているよりも、改善によって期待されるプラスの効果が得られたかどうかを確認することが重要です。前述したように、RUM ではさまざまな期間を調べることで、28 日間の CrUX スコアを事前に確認できます。ただし、期間が短すぎるとデータのノイズが多くなる可能性があるため、CrUX では 28 日を使用しています。

多くの場合、「正しい」ものはまたは「wrong」これらは、ユーザーに対する視点やサイトに対する体験の違いにすぎません。こうした相違が発生する理由と、それによって意思決定の原動力となるものを理解している限り、それはサイト訪問者により良いサービスを提供するために何よりも重要です。

謝辞

Steven Lelham によるサムネイル画像(Unsplash より)