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

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

現在の分析ツールでウェブに関する指標を測定する方法。

Philip Walton （Philip Walton）

パフォーマンスの推移を診断して改善するには、ページの実際のパフォーマンスを測定してレポートを作成できることが重要です。フィールドデータがないと、サイトに加えた変更によって、実際に望ましい結果が得られているかどうかを判断できません。

人気のある多くの Real User Monitoring（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, onFID, 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);
onFID(sendToAnalytics);
onLCP(sendToAnalytics);

平均を避ける

パフォーマンス指標の値の範囲を合計するには、平均値を計算します。平均は、大量のデータの簡潔な概要であり、一見すると便利なように見えますが、ページのパフォーマンスを解釈するために平均値を使用するのはやめましょう。

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

たとえば、少数のユーザーグループが非常に低速なネットワークやデバイスを使用していて、値が最大範囲に近づいているものの、問題があることを示唆する形で平均に影響を与えるほどの十分なユーザーセッションが考慮されていない場合があります。

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

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

Core Web Vitals の各指標の値を計算し、カスタム指標またはイベントを使用して分析サービスに送信したら、次のステップとして、収集された値を表示するレポートまたはダッシュボードを作成します。

Core Web Vitals の推奨しきい値を満たすには、レポートで各指標の値を 75 パーセンタイルで表示する必要があります。

分析ツールで分位点レポートを組み込み機能として提供していない場合でも、すべての指標値を昇順で並べ替えたレポートを生成することで、このデータを手動で取得できます。このレポートが生成されると、そのレポート内の並べ替えられたすべての値のリスト全体の 75% の結果が、その指標の 75 パーセンタイルになります。これは、データの分割方法（デバイスタイプ、接続タイプ、国など）に関係なく当てはまります。

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

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

ウェブに関する主な指標レポートのスクリーンショット

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

パフォーマンス指標には、ページの読み込み完了後に計算される指標もあれば、ページ全体の存続期間が考慮される指標もあります（CLS などの場合、これらはページの読み込みが始まって初めて最終的な指標となります）。

ただし、beforeunload イベントと unload イベントはどちらも信頼性が低く（特にモバイルの場合）、使用は推奨されません（ページがバックフォワードキャッシュの対象にならないため）。

ページの存続期間全体を追跡する指標の場合、ページの表示状態が hidden に変わるたびに、visibilitychange イベント中に指標の現在の値を送信することをおすすめします。これは、ページの表示状態が hidden に変わった後に、そのページのスクリプトを再度実行できる保証がないためです。これは特に、ページコールバックを発生させることなくブラウザアプリ自体を閉じることができるモバイルオペレーティングシステムに当てはまります。

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

ブラウザの一部のバグにより、visibilitychange イベントが発生しないケースがいくつかあります。独自の分析ライブラリを構築する場合は、これらのバグに注意することが重要です。web-vitals JavaScript ライブラリではこれらのバグはすべて考慮されます。

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

Core Web Vitals の指標のトラッキングとレポート作成の両方を行うようにアナリティクスの実装を更新したら、次のステップは、サイトの変更がパフォーマンスに及ぼす影響を追跡することです。

変更のバージョニング

変更を追跡するための単純な（そして最終的には信頼性が低い）アプローチは、変更を本番環境にデプロイし、デプロイ日以降に受信したすべての指標が新しいサイトに対応し、デプロイ日より前に受信したすべての指標が古いサイトに対応していると仮定することです。ただし、HTTP、Service Worker、CDN レイヤでのキャッシュ保存など、さまざまな要因によって機能しなくなる可能性があります。

より適切なアプローチは、デプロイされる変更ごとに一意のバージョンを作成し、そのバージョンを分析ツールで追跡することです。ほとんどの分析ツールはバージョンの設定をサポートしています。カスタムディメンションがない場合は、カスタムディメンションを作成し、そのディメンションをデプロイ済みのバージョンに設定できます。

試行錯誤

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

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

分析でテストを実施すると、テスト用の変更をユーザーのサブセットにロールアウトして、その変更のパフォーマンスをコントロールグループ内のユーザーのパフォーマンスと比較できます。変更によって実際にパフォーマンスが向上することを確認したら、すべてのユーザーに展開します。

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

実際のユーザーのパフォーマンスを測定する場合、実行するパフォーマンス測定コードがページのパフォーマンスに悪影響を与えないようにすることが非常に重要です。もしそうなら、分析コード自体の存在が最大の悪影響を及ぼしているかどうかがわからないため、パフォーマンスがビジネスに与える影響についての結論は信頼性に欠けます。

RUM 分析コードを本番環境サイトにデプロイする場合は、常に次の原則に従ってください。

分析を遅らせる

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

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

ページ読み込みのタイムラインで後で計算できない指標を測定する場合は、早い段階で実行する必要があるコードのみをドキュメントの <head> にインライン化し（そのため、レンダリングブロックリクエストではありません）、残りは遅延させます。1 つの指標で必要だからといって、すべての分析を早期に読み込むことは避けてください。

長いタスクを作成しない

多くの場合、分析コードはユーザー入力に応答して実行されますが、分析コードで大量の DOM 測定を実行している場合や、他のプロセッサ負荷の高い API を使用している場合は、分析コード自体が入力応答性の低下を引き起こす可能性があります。また、分析コードを含む JavaScript ファイルのサイズが大きい場合、そのファイルを実行するとメインスレッドがブロックされ、First Input Delay（FID）または Interaction to Next Paint（INP）に悪影響が及ぶ可能性があります。

非ブロック API を使用する

sendBeacon() や requestIdleCallback() などの API は、ユーザークリティカルなタスクをブロックせずに、重要性の低いタスクを実行するために特別に設計されています。

これらの API は、RUM 分析ライブラリで使用するのに最適なツールです。

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

必要以上のデータをトラッキングしない

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

たとえば、Resource Timing API は、ページに読み込まれたリソースごとに詳細なタイミングデータを提供します。ただし、そのすべてのデータがリソース負荷のパフォーマンスの改善に必ずしも役立つとは限りません。

要するに、データがあっても追跡するだけでなく、追跡しているリソースを消費する前にそのデータが使用されるようにします。