リアルユーザーモニタリング：実環境と実験環境におけるウェブサイトの速度を把握する

実際のユーザーと実験室でのテスト

リアルユーザーモニタリング (RUM)は、実際の訪問時にウェブサイトがどのように機能するかを記録します。古いスマートフォンでモバイル通信を利用してアクセスした場合と、高速接続のデスクトップ端末からアクセスした場合では、その挙動が大きく異なる可能性があります。また、閲覧されたページやユーザーの操作も、観測結果に反映されます。

A 実験室試験 これに対し、特定の呼び出しを管理された条件下で調査します。調査ごとに、デバイスの種類、ネットワーク環境、テスト手順を指定することができます。これにより、異常現象を再現しやすくなり、同様の条件下で変更の影響を検証することが可能になります。

この2つの視点は、それぞれ異なる疑問に答えるものです。フィールドデータからは、モバイル版の商品ページが頻繁に表示が遅いことが示されるかもしれません。しかし、その原因が例えば商品画像にあるのか、レンダリングパスにあるのか、あるいはドキュメントの応答が遅いからなのかについては証明できません。原因を特定するには、追加の診断と検証可能な仮説が必要となります。

PageSpeed Insights は、この 2 つの視点を結びつけています。つまり、Chrome User Experience Report の実測データと、Lighthouse に基づくラボ診断結果を比較・対照しているのです。実際のアクセスは様々な条件や利用フローを含むのに対し、ラボではあらかじめ定められたテストケースを検証するため、結果が一致しない場合があります。

したがって、RUMはラボテストに代わるものではありません。逆に、単一のラボテストだけでは、実際の訪問者において問題がどの程度の頻度で発生しているかを把握することはできません。また、公開前や訪問者がほとんどいないウェブサイトの場合、十分なフィールドデータが得られない可能性があります。実際の訪問がなければ、独自のRUM測定値はまったく得られないからです。

RUMの測定値はこのように算出されます

独自の測定を行うには、3つの要素が必要です。それは、ブラウザでのデータ収集、送信された値を受信する受信機、そしてデータの分析です。まず、どのページや訪問者グループを分析対象とするか、またデータをどのように保護するかを事前に決定します。個々の値を適切に集計して初めて、意思決定の根拠となるのです。

ブラウザは、このためにさまざまなパフォーマンスインターフェースを提供しています。 ナビゲーションのタイミング ドキュメントへのナビゲーションに関連するタイミング（ドキュメントリクエストへの応答など）を記述します。Resource Timingは、画像やスクリプトなど、読み込まれた個々のリソースに関する時間情報を提供します。これにより、読み込みプロセスの各段階をより詳細に特定することができます。

A PerformanceObserver 利用可能になり次第、サポート対象のパフォーマンスエントリを監視します。Core Web Vitals については、このライブラリは web-vitals 計算と報告を行います。利用可能な項目や指標は、ブラウザなどによって異なります。そのため、計測スクリプトではすべての訪問を自動的に完全に記録できるわけではありません。

すべての値が読み込み時に直接生成されるわけではありません。例えば、INPの場合、適切なインタラクションが発生する必要があります。単にページを読んで離脱するユーザーは、その値を提供しない可能性があります。したがって、測定値がないからといって、それがゼロであるわけでも、反応が速い証拠であるわけでもありません。

RUMサービスは、データ収集、受信、分析を一つのパッケージとして提供できます。自社開発の場合は、運用、保存、品質保証についても別途手配する必要があります。これには、ページライフサイクルにおける重複したメッセージを適切に処理することも含まれ、すべてのメッセージを検証せずに独立した訪問としてカウントしてしまうことを避ける必要があります。

Core Web Vitals を正しく読み取る

仝 コアウェブ・バイタル これらはユーザー体験の3つの異なる側面を表しています。「Largest Contentful Paint（LCP）」は、最も大きな関連コンテンツ要素がいつ表示されるかを測定する指標です。例えば、商品ページでは、大きな商品画像がこれに該当します。この画像の表示が遅れると、ナビゲーションが早くから表示されていても、ページがまだ完全に読み込まれていないように感じられる可能性があります。

Interaction to Next Paint（INP）は、ユーザー操作から次に表示が更新されるまでの遅延を測定する指標です。 クリックしてから製品フィルターの反応が明らかに遅れる場合、INPはこの問題を指摘する可能性があります。一方、Cumulative Layout Shift（CLS）は、後から表示された要素によってボタンの位置がずれるなど、表示されているコンテンツの予期せぬ位置ずれを表します。

PageSpeed Insights の評価において、LCP は 2.5 秒以下、INP は 200 ミリ秒以下、CLS は 0.1 以下であれば「良好」とみなされます。CLS は単位のない値です。 これらの閾値は各指標に適用されるものであり、個々のページ閲覧にかかる時間と混同しないようにしてください。

フィールド評価において決定的なのは、 75パーセンタイル (p75): 対象とした体験のうち、少なくとも約75パーセントは、それぞれの値を上回っていない。一方、平均値が良好であるだけでは、訪問の相当な割合が低速であるという事実が見えにくくなる可能性がある。モバイルとデスクトップを別々に分析し、デバイスグループ間の違いが明確に把握できるようにする。

「Time to First Byte（TTFB）」は、ドキュメントの応答が遅い原因を特定する際、これらの指標を補完するものです。 ただし、この値は単にサーバーの処理時間だけを示すものではありません。最初の応答バイトが届くまでのネットワークやその他の段階も影響を及ぼします。「ナビゲーション・タイミング」や、場合によっては提供される「サーバー・タイミング」データを活用することで、関連する各セクションをより詳細に調査することができます。

CrUX、独自のRUMおよびラボ

まずは、すぐに独自の測定システムを運用する必要はありません。PageSpeed Insightsは、 Chrome ユーザー体験レポート (CrUX) と Lighthouse のラボ診断。これら 2 つのビューは、それぞれ異なる疑問に答えるものです。一方は実際に記録された体験を記述するものであり、もう一方は管理された条件下でページを分析するものです。

PageSpeed Insights の CrUX フィールドデータは、過去 28 日間の期間を対象としています。特定の URL に関するデータが不十分な場合、レポートでは代わりにオリジンのデータが表示されることがあります。これには関連するウェブサイトのオリジンが含まれており、入力されたページでの実際の体験と完全に同一であるとは限りません。 そのため、レポートが実際にどのレベルの情報に基づいているかを確認するようにしてください。

CrUXは、所定の要件を満たすChromeユーザーのみを対象としており、他のブラウザや対象外のユーザーは含まれません。小規模なウェブサイトや非公開のウェブサイトでは、CrUXのデータが欠落している場合があります。そのような場合でも、法的・技術的に適切な独自のデータ収集を行うことで洞察を得ることが可能ですが、アクセス数が少ない場合は統計的な限界があります。

合成モニタリングは、たとえその時点でウェブサイトに訪問者がいなくても、あらかじめ定義されたテストを繰り返し実行します。これは、同様の条件下でプロセスを定期的に観察するのに適しています。ユーザーが別のデバイスやネットワークを使用した場合にも同様の体験ができるかどうかは、実地測定によって確認する必要があります。単一の合成テストでは、この視点に代わることはできません。

したがって、選択にあたっては、どのような問いに答えたいのかが重要になります。公開されている報告書はすぐに利用できますが、独自のシステムであれば、より的を絞ったデータ収集が可能です。外部サービスを利用すれば業務負担を軽減できますが、実験室での試験や合成試験では、管理された条件下での調査が可能になります。ただし、外部サービスを利用する場合でも、データや分析対象グループを慎重に選択する必要があります。

独自の測定を確実に準備する

まず、モバイルの商品ページが他のページタイプに比べてLCPが高くなる頻度が高いかどうかなど、具体的な質問を明確にします。次に、どのページやデバイスカテゴリを区別するか、そのために必要な指標は何か、そしてどのくらいの期間データを収集するかを決定します。その上で初めて、計測スクリプト、データ受信先、および分析方法について決定します。

最初の技術的なステップとして、ライブラリを web-vitals ブラウザプロジェクトにローカルで組み込み、開発者ツールで出力を確認します。以下の JavaScript は、公開されているパッケージバージョン 6.2.3 を使用しています。このコードを実行するには、プロジェクトにこのバージョンがインストールされており、ビルドがモジュールのインポートを処理できることが前提となります。 このサンプルでは、サーバーへのデータ送信は行わず、ソフトナビゲーションの個別の計測も有効化していません。

import {onCLS, onINP, onLCP} from 'web-vitals';

onCLS(console.log);
onINP(console.log);
onLCP(console.log);

コンソール出力は、統合状況を確認するための手段であり、訪問者の速度を示すものではありません。 プロジェクトページを開き、例えばフィルターを操作してみてください。INP値は適切な操作を前提としており、必ずしも即座に表示されるとは限りません。適切な操作が行われない場合、INP値がまったく表示されないこともあります。また、ブラウザの対応状況やページのライフサイクルも出力に影響を与えます。

後日の分析のために、 ページのライフサイクル 注：フィードバックは複数回発生する可能性があります。例えば、ページが非表示になった後、再び表示された場合などです。こうした通知を、一律に独立した訪問としてカウントしないでください。ライブラリでは、同じメトリクスに属する通知を紐付けることができるメトリクスIDを提供しています。

バック／フォワード・キャッシュからの復元についても、所定の処理が必要です。ドキュメントがキャッシュから戻ってくる場合でも、新しいメトリクス通知がトリガーされる可能性があります。 レポート内で、このような復元を通常のナビゲーションとどのように区別するかを明確にし、本番環境での収集を設定する前に、具体的なライブラリの注意事項を確認してください。

セグメントごとの測定値を分析する

ショップ全体の数値では、特にモバイル版の商品ページが読み込みに時間がかかっているという事実が見えにくくなる可能性があります。そのため、測定値を少なくともページの種類やデバイスの種類ごとに分類し、各指標について特定の期間を対象に分析してください。そうすることで、例えば、モバイル版の商品ページとモバイル版のカテゴリページを比較することができ、異なる利用状況を気づかぬうちに混同してしまうことを防げます。

各セグメントごとに、それは 75パーセンタイル 単なる平均値よりも意味のある指標です。これは、対象となった経験値の少なくとも約75％が超えない値を示しています。一方、平均値が低いと、特定のグループが長時間待たされているという事実が見えにくくなる可能性があります。p75の比較は、常に同じ指標かつ適切な単位で実施してください。

有効な値の数は、結果に直接影響します。あるセグメントの測定値がごくわずかしかない場合、個々のデータがパーセンタイルに大きな影響を与える可能性があります。その場合、変化が見られても、必ずしも一般的な問題を示しているとは限りません。必要に応じて、より長い期間を選択するか、比較可能性を損なわない範囲で、専門的に類似したページをまとめて分析してください。

INPが欠落している場合は「高速なINP」とはみなされず、分布にゼロとして含めてはならない。 その代わりに、有効なINP値の数を別途記載してください。多くのページビューで適切なインタラクションが記録されていない場合、INPの分析結果は記録されたインタラクション体験のみを表しており、すべてのページビューを自動的に反映するものではありません。

各フィードバックを独立した新しい観測値として扱うのではなく、メトリックIDに基づいて繰り返し発生するレポートを適切に統合してください。 また、バック/フォワードキャッシュからの復元がどのようにカウントされるかについても文書化してください。これにより、p75および指定された数に実際にどの観測値が含まれているかが追跡可能になります。

臨床上の問題から診断へ

フィールドデータから、モバイル版商品ページの表示が遅いことが判明した場合は、まず影響を受けているセグメントを絞り込みましょう。LCPの低下は多くの商品に及んでいるのか、それとも特定のページタイプに限られているのか？同時に、期間と有効な値の数も確認してください。これにより、調査の出発点は得られますが、どの要素が遅延の原因であるかという証拠はまだ得られません。

その後、 実験室試験 可能な限り類似した条件（例えば、モバイル端末の設定やネットワーク速度の制限など）を再現してください。どの要素がLCPとして表示されるか、またそれがいつ読み込まれ、表示されるかを調査してください。 大きな製品画像、画像リクエストの遅延、またはレンダリングパスのブロックなどが考えられる仮説であり、診断に基づいてこれらを検証する必要があります。

画像の配信に関する手がかりが見つかった場合は、ファイルサイズ、形式、および提供方法を調査することができます。1つの コンテンツ配信ネットワーク これは一つの対策ではありますが、LCPの改善を保証するものではありません。一方、ドキュメントの応答からボトルネックが示唆される場合は、追加の PHPワークロード向けのサーバーベンチマーク, 所定の条件下でそのアプリケーションを検証すること。

遅延型プロダクトフィルターの場合、読み込み処理そのものではなく、ユーザーとのインタラクションが鍵となります。フィルターをクリックした際の動作を再現し、画面上の更新が表示されるまでにどのような処理が行われているかを確認してください。ブラウザが対応している場合は、 長いアニメーションのフレーム レンダリングの更新に時間がかかることや、それに関与しているスクリプトに関する手がかりを提供しますが、それらが必ずしもすべての操作の遅延を自動的に説明するわけではありません。

特定の変更を実施し、その後、現場で同じページグループを再度観察する。実験結果が改善されたとしても、それは当初、選択された試験条件下での効果に過ぎない。実際の訪問者の行動に変化が見られたかどうかは、その後の現場での評価によって初めて明らかになる。

業務におけるデータ品質と個人情報保護

本番運用を開始する前に、調査課題の解決に必要な測定値と、それらを処理する担当者を明確に決めておきましょう。 計画には、受信者への安全な転送、アクセス制限、保存期間の制限、および削除手順が含まれます。具体的な実装や適用される規則については、一律の承認を前提とするのではなく、専門的な観点からデータ保護や同意に関する事項を精査してください。

を持つ。 データの最小化 診断フィールドを確認する価値があります。完全なURLにはクエリパラメータに機密情報が含まれている可能性があり、DOMセレクタもページの内容や入力に関する詳細を漏らす恐れがあります。可能であれば、一般的なページタイプと、厳選された少数の属性を収集してください。 また、連携しているサービスが、どのような情報を追加で収集または保存しているかも確認してください。

測定値は必ずしも即座に得られるとは限りません。web-vitals ライブラリは、ページのライフサイクルを通じて複数回フィードバックを出力する可能性があります。そのため、後から送信されたレポートを、そのまま新しい独立した訪問としてカウントしてはなりません。 関連するレポートの処理方法や、バック／フォワードキャッシュからの復元をどのように扱うかについて、計画を立てておく必要があります。

小規模な診断パッケージについては、 sendBeacon イベントにて visibilitychange 適している。これにより、ページを非表示にした際にデータを送信する可能性は高まるが、配信が保証されるわけではない。また、受信者はデータを確実に受け取り、繰り返し送信されるメッセージが気づかれないまま分析結果を歪めることのないよう、適切に処理しなければならない。

最後に、以下の点を考慮してください。 データの欠落: スクリプトのブロック、ブラウザの非対応、またはデータ送信の喪失により、特定の訪問が計測から漏れる可能性があります。推定される損失率と、計測方法を併せて評価してください。残りの計測値は、観察されたグループを反映したものであり、必ずしもすべての訪問者を均等に表しているとは限りません。

変更点を確認し、手順を選択する

デプロイ後の比較を行うには、事前に対象とするページタイプ、デバイスカテゴリ、期間を指定しておく必要があります。各メトリクスについて、変更前後の75パーセンタイル値と有効な値の数を比較してください。 同程度の期間を設定することで状況の把握に役立ちますが、それだけでは十分に比較可能なサンプルが自動的に得られるわけではありません。

訪問者の構成の変化に注意してください。デプロイメント後に、低速なモバイル接続を利用するユーザーが増加した場合、変更そのものは速度低下を伴わないにもかかわらず、総合的なパフォーマンスが低下する可能性があります。また、季節的な利用状況や、同時に発生するその他の変化も、原因の特定を困難にします。したがって、時間的な関連性はあくまで仮説であり、 因果関係の立証.

CrUXと独自のRUMは、必ずしも同じ結果を示すとは限りません。それぞれが異なるユーザーグループ、時間枠、測定条件を対象としている可能性があるからです。 CLSに関しては、さらにCrUXが、親ページの体験に対する埋め込みフレームからの貢献も考慮に入れる点が挙げられます。メインドキュメントでのJavaScriptによる測定では、こうした貢献を必ずしも完全に捕捉できるとは限りません。したがって、差異をエラーとみなす前に、まず測定の基礎となる基準を比較検討してください。

シングルページアプリケーションの場合、ドキュメントナビゲーションと内部のルート変更のどちらを調査するかを明確にすべきです。それぞれを個別に把握するためには、 ソフトナビゲーション バージョン6以降では、ブラウザが対応している場合、Web Vitalsのオプションがサポートされます。 reportSoftNavs: true。これは、それぞれのメトリクス・コールバックで設定する必要があります。このオプションを指定していない前述のコンソール例では、個別のルート測定は有効になりません。

ソフトナビゲーションの計測が有効になっている場合、新しいナビゲーションのCLSとINPはリセットされ、個別に扱われます。前のナビゲーションの値は、ルート変更時に確定されます。このように時間的な区切りが異なる値については、確認せずにドキュメント全体の測定値と比較すべきではありません。 適切なブラウザのサポートがない場合、このオプションを有効にしても、対応する個別のルート測定は行われません。

RUMサービスを選択する際は、ブラウザの対応状況に加え、必要なページグループやデバイスカテゴリが分析対象となっているかを確認してください。 サンプリング手法、データ処理、保存、およびエクスポート機能について確認してください。同様に重要なのは、計測スクリプト自体がページに与える影響や、その計測範囲を調査目的に必要な範囲に限定できるかどうかです。