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

現場におけるウェブに関する指標の測定に関するベストプラクティス

現在の分析ツールで Web Vitals を測定する方法。

Philip Walton

ページの実際のパフォーマンスを測定してレポートを作成できる機能は、パフォーマンスを診断して改善していくうえで重要です。フィールドデータがないと、サイトに加えた変更が実際に目的の結果を達成しているかどうかを正確に把握することはできません。

多くの一般的なリアルユーザーモニタリング（RUM）分析プロバイダは、すでにツールでCore Web Vitals 指標（および多くのその他のウェブバイタルズ）をサポートしています。現在、これらの RUM 分析ツールのいずれかを使用している場合は、サイト上のページが推奨される Core Web Vitals のしきい値をどの程度満たしているかを評価し、将来の低下を防ぐことができます。

Core Web Vitals 指標に対応した分析ツールを使用することをおすすめしますが、現在使用している分析ツールが対応していない場合でも、必ずしも切り替える必要はありません。ほとんどの分析ツールには、カスタム指標やイベントを定義して測定する方法が用意されています。つまり、現在の分析プロバイダを使用して Core Web Vitals 指標を測定し、既存の分析レポートやダッシュボードに追加できる可能性があります。

このガイドでは、サードパーティまたは社内アナリティクスツールで Core Web Vitals 指標（またはカスタム指標）を測定する際のベストプラクティスについて説明します。また、サービスに Core Web Vitals のサポートを追加する分析ベンダーにとってもガイドとして役立ちます。

カスタム指標またはカスタムイベントを使用する

前述のとおり、ほとんどの分析ツールではカスタムデータを測定できます。アナリティクスツールがこれをサポートしている場合は、このメカニズムを使用してウェブに関する主な指標の各指標を測定できます。

分析ツールでカスタム指標やイベントを測定する手順は、通常 3 段階です。

ツールの管理画面でカスタム指標を定義または登録します（必要に応じて）。（注: すべてのアナリティクスプロバイダで、カスタム指標を事前に定義する必要はありません）。
フロントエンドの JavaScript コードで指標の値を計算します。
指標値をアナリティクスのバックエンドに送信します。名前または ID がステップ 1 で定義したものと一致していることを確認します（必要に応じて再度）。

手順 1 と 3 については、アナリティクスツールのドキュメントで手順をご確認ください。ステップ 2 では、web-vitals JavaScript ライブラリを使用して、各 Core Web Vitals 指標の値を計算します。

次のコードサンプルは、これらの指標をコードで簡単にトラッキングして分析サービスに送信する方法を示しています。

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

function sendToAnalytics({name, value, id}) {
  const body = JSON.stringify({name, value, id});
  // Use `navigator.sendBeacon()` if available, falling back to `fetch()`.
  (navigator.sendBeacon && navigator.sendBeacon('/analytics', body)) ||
      fetch('/analytics', {body, method: 'POST', keepalive: true});
}

onCLS(sendToAnalytics);
onINP(sendToAnalytics);
onLCP(sendToAnalytics);

平均値を避ける

実績指標の値の範囲を合計して平均値を計算したくなりますが、平均値は、大量のデータを整理して要約しているため、一見便利に思えますが、ページのパフォーマンスを解釈する際に平均値に頼ることは避けてください。

平均値は単一のユーザーのセッションを表さないため、問題があります。分布のいずれかの範囲にある外れ値は、誤解を招くような方法で平均を歪める可能性があります。

たとえば、少数のユーザーが極端に遅いネットワークを使用している場合や、値の最大範囲に近いデバイスを使用している場合でも、問題があることを示すような平均値に影響を与えるほどのユーザーセッション数はないため、問題と見なされることはありません。

可能な限り、平均ではなくパーセンタイルを使用します。特定のパフォーマンス指標の分布全体のパーセンタイルを使用すると、ウェブサイトのユーザーエクスペリエンスの全範囲をより正確に把握できます。これにより、実際のエクスペリエンスのサブセットに焦点を当てることができ、単一の値よりも多くの分析情報を得ることができます。

配布を報告できることを確認する

ウェブに関する主な指標の各値を計算し、カスタム指標またはイベントを使用してアナリティクスサービスに送信したら、収集した値を表示するレポートまたはダッシュボードを作成します。

ウェブに関する主な指標の推奨しきい値を満たしていることを確認するには、レポートに各指標の 75 パーセンタイル値が表示されている必要があります。

アナリティクスツールに分位レポートが組み込み機能として用意されていない場合でも、すべての指標値を昇順で並べ替えたレポートを生成することで、このデータを手動で取得できます。このレポートが生成されると、そのレポート内のすべての値の並べ替え済みリストの 75% に相当する結果が、その指標の 75 パーセンタイルになります。これは、データをどのようにセグメント化しても同じです（デバイスの種類、接続の種類、国など）。

分析ツールで指標レベルのレポートの粒度がデフォルトで設定されていない場合は、分析ツールがカスタムディメンションをサポートしている場合は、同じ結果が得られる可能性があります。トラッキングする個々の指標インスタンスごとに一意のカスタムディメンション値を設定すると、レポートの設定にカスタムディメンションを含めると、個々の指標インスタンスごとに分類されたレポートを生成できます。各インスタンスには一意のディメンション値があるため、グループ化は行われません。

ウェブに関する指標レポートは、Google アナリティクスを使用したこの手法の例です。このレポートのコードはオープンソースであるため、デベロッパーはこのセクションで説明する手法の例として参照できます。

ウェブバイタルレポートのスクリーンショット

適切なタイミングでデータを送信する

一部のパフォーマンス指標は、ページの読み込みが完了すると計算できますが、他の指標（CLS など）はページのライフスパン全体を考慮し、ページのアンロードが開始されて初めて確定します。

ただし、beforeunload イベントと unload イベントは（特にモバイルでは）信頼性が低く、バックフォワードキャッシュの対象からページが除外される可能性があるため、使用は推奨されません。

ページの全期間をトラッキングする指標の場合は、ページの公開状態が hidden に変更されるたびに、visibilitychange イベント中にその指標の現在の値を送信することをおすすめします。これは、ページの可視状態が hidden に変更されると、そのページ上のスクリプトが再び実行される保証がないためです。これは、ページコールバックが発生せずにブラウザアプリ自体を閉じることができるモバイルオペレーティングシステムでは特に重要です。

通常、モバイルオペレーティングシステムは、タブの切り替え、アプリの切り替え、ブラウザアプリ自体の終了時に visibilitychange イベントを発生させます。また、タブを閉じたり、新しいページに移動したりしたときに visibilitychange イベントも発生します。これにより、visibilitychange イベントは unload イベントや beforeunload イベントよりもはるかに信頼性が高くなります。

一部のブラウザのバグが原因で、visibilitychange イベントが発生しない場合があります。独自のアナリティクスライブラリを構築する場合は、これらのバグに注意する必要があります。web-vitals JavaScript ライブラリは、これらのバグをすべて考慮しています。

パフォーマンスの推移をモニタリングする

アナリティクスの実装を更新して、ウェブに関する主な指標の追跡とレポートの両方を行ったら、次はサイトの変更が長期にわたるパフォーマンスにどのように影響するかを追跡します。

変更にバージョン番号を付ける

変更をトラッキングするためのナイーブな（そして最終的には信頼できない）アプローチは、変更を本番環境にデプロイし、デプロイ日以降に受信したすべての指標が新しいサイトに対応し、デプロイ日より前に受信したすべての指標が古いサイトに対応していると仮定することです。ただし、HTTP レイヤ、サービスワーカーレイヤ、CDN レイヤでのキャッシングなど、さまざまな要因によって、この機能が機能しない場合があります。

デプロイされた変更ごとに一意のバージョンを作成し、そのバージョンをアナリティクスツールでトラッキングすることをおすすめします。ほとんどの分析ツールはバージョンの設定をサポートしています。含まれていない場合は、カスタムディメンションを作成して、そのディメンションをデプロイされたバージョンに設定できます。

試行錯誤

複数のバージョン（またはテスト）を同時にトラッキングすることで、バージョン管理をさらに進めることができます。

アナリティクスツールでテストグループを定義できる場合は、その機能を使用してください。そうでない場合は、カスタムディメンションを使用して、各指標値をレポート内の特定のテストグループに関連付けることができます。

アナリティクスでテストを実施すると、一部のユーザーにテスト用の変更をロールアウトし、その変更のパフォーマンスをコントロールグループのユーザーのパフォーマンスと比較できます。変更によってパフォーマンスが実際に向上すると確信できたら、すべてのユーザーにロールアウトできます。

測定がパフォーマンスに影響しないようにする

実際のユーザーのパフォーマンスを測定する際は、実行しているパフォーマンス測定コードがページのパフォーマンスに悪影響を及ぼさないことが絶対に重要です。パフォーマンスが低下している場合は、アナリティクスコード自体が最も大きな悪影響を及ぼしているかどうかを判断できないため、パフォーマンスがビジネスに与える影響について結論を出すことは不可能です。

本番環境サイトに RUM アナリティクスコードをデプロイする際は、常に次の原則に従ってください。

アナリティクスの処理を遅らせる

アナリティクスコードは常に非同期で非ブロックの方法で読み込む必要があります。通常は最後に読み込む必要があります。アナリティクスコードをブロック方式で読み込むと、LCP に悪影響が及ぶ可能性があります。

Core Web Vitals 指標の測定に使用される API はすべて、（buffered フラグを使用して）非同期および遅延スクリプト読み込みをサポートするように特別に設計されているため、スクリプトを早急に読み込む必要はありません。

ページ読み込みのタイムラインの後半で計算できない指標を測定している場合は、ドキュメントの <head> に、早い段階で実行する必要があるコードのみをインライン化し（レンダリングブロックリクエストにならないように）、残りのコードを遅らせる必要があります。1 つの指標が必要な場合に、すべてのアナリティクスを早期に読み込まないでください。

長いタスクを作成しないでください

アナリティクスコードは多くの場合、ユーザー入力に応じて実行されますが、アナリティクスコードが大量の DOM 測定を実行している場合や、プロセッサ使用率の高い他の API を使用している場合、アナリティクスコード自体が入力の応答性を低下させる可能性があります。また、アナリティクスコードを含む JavaScript ファイルが大きい場合、そのファイルの実行によってメインスレッドがブロックされ、ページの次のペイントまでのインタラクション（INP）に悪影響を及ぼす可能性があります。

非ブロッキング API を使用する

sendBeacon() や requestIdleCallback() などの API は、ユーザーにとって重要なタスクをブロックすることなく、重要でないタスクを実行するように特別に設計されています。

これらの API は、RUM アナリティクスライブラリで使用するのに適しています。

通常、すべてのアナリティクスビーコンは sendBeacon() API（利用可能な場合）を使用して送信し、すべてのパッシブアナリティクス測定コードはアイドル状態のときに実行する必要があります。

必要なもの以上にトラッキングしない

ブラウザは多くのパフォーマンスデータを公開しますが、データが利用可能だからといって、必ずしもデータを記録してアナリティクスサーバーに送信する必要はありません。

たとえば、Resource Timing API は、ページに読み込まれたすべてのリソースの詳細なタイミングデータを提供します。ただし、これらのデータのすべてが、リソースの読み込みパフォーマンスの向上に必要または有用である可能性は低いです。

つまり、データが存在するからといって、ただ追跡するのではなく、追跡にリソースを使用する前に、データが使用されることを確認してください。