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

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

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

多くの一般的なリアル ユーザー モニタリング(RUM)分析プロバイダは、すでにツールでCore Web Vitals 指標(および多くのその他の Web Vitals)をサポートしています。現在これらの RUM 分析ツールを使用している場合は、サイトのページが Core Web Vitals の推奨しきい値をどの程度満たしているかを評価して、今後の回帰を防止できます。

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

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

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

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

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

  1. ツールの管理画面でカスタム指標を定義または登録します(必要に応じて)。(注: すべての分析プロバイダで、カスタム指標を事前に定義する必要はありません)。
  2. フロントエンドの JavaScript コード内の指標の値を計算します。
  3. 指標値をアナリティクスのバックエンドに送信します。名前または 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);

平均値を避ける

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

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

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

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

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

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

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

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

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

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

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

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

パフォーマンス指標には、ページの読み込み完了後に計算できるものや、ページの存続期間全体を考慮した指標(CLS など)があり、ページのアンロードが開始された後にのみ最終的なものになります。

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

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

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

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

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

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

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

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

試行錯誤

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

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

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

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

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

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

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

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

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

ページの読み込みタイムラインで後から計算できない指標を測定する場合は、ドキュメントの <head> に早期に実行する必要があるコードのみをインライン化し(つまり、レンダリング ブロック リクエストではありません)、残りは遅らせます。単一の指標で必要になるという理由だけで、すべての分析を早期に読み込まないでください。

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

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

非ブロック API を使用する

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

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

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

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

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

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

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