このページは 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 のサポートをサービスに追加することを検討している分析ベンダーにとっても、ガイドとして活用できます。

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

前述のように、ほとんどの分析ツールでカスタムデータを測定できます。お使いの必要な場合、各 Core Web サイトおよびこのメカニズムを使用した主な指標。

分析ツールでカスタム指標やイベントを測定するのは通常、次の 3 ステップによるプロセス:

Google Cloud で登録必要な場合は、ツールの管理でカスタム指標を確認してください。（注: 分析プロバイダでは、カスタム指標を事前に定義する必要があります）。
フロントエンドの 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);

平均を避ける

パフォーマンス指標の値の範囲を合計したくなるのは、平均を計算しています。平均は一見便利そうに見えますが、大量のデータを整理して要約できますが、ページのパフォーマンスを解釈できます

平均値には問題がある単一のユーザーのセッションを表すものではないからですいずれかの範囲の外れ値誤解を招くような形で平均が歪んでいる可能性があります

たとえば、少数のユーザーグループが著しく遅いネットワークやデバイスを使用していることなどが考えられます値の上限に近づいているものの、十分なユーザーを考慮していない問題があることを示唆する傾向にあります。

可能な限り、平均ではなくパーセンタイルを使用します。期間全体にわたるパーセンタイル特定のパフォーマンス指標の分布の方が向上させることができますこれにより実際のエクスペリエンスに重点を置いて、これまでよりも多くの分析情報を得ることができますできます。

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

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

Core Web Vitals の推奨基準を満たしていることを確認する設定するにはレポートが必要ですこれにより、75 パーセンタイルの各指標の値が表示されます。

分析ツールの組み込み機能として分位点レポートが提供されていない場合は、このデータは通常レポートを生成する方法とすべての指標値が昇順で並べ替えられます。このレポートが生成されると結果の 75% の確率で、すべての値を並べ替えてそのレポートの 75 パーセンタイルがどの方法で（デバイスタイプ、接続タイプ、国など）を指定します。

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

Web Vitals レポート Google アナリティクスを使用するこの手法の一例です。次のコードは、レポートがオープンソースであるできます。開発者はこのスライドで概説している手法の例として、できます。

Web Vitals のスクリーンショット
報告

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

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

ただし、beforeunload と unload の両方が（特にモバイルでは）信頼性が低く、その用途は推奨（ページがバックフォワードキャッシュ）。

ページの存続期間全体をトラッキングする指標の場合は、指標の現在の値が visibilitychange イベント中の場合は、ページの公開設定が hidden に変わります。なぜなら、ページの表示状態が 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> に追加します（したがって、レンダリングブロック機能ではなくリクエストするもので、それ以外は遅延します。すべての早期に分析できるわけではありません。

長いタスクを作成しない

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

非ブロック API を使用する

たとえば、 sendBeacon() および requestIdleCallback() 重要でないタスクの実行のために特別に設計されたものですブロックできます。

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

一般に、すべての分析ビーコンは sendBeacon() API を使用して送信する必要があります。（利用可能な場合）、すべてのパッシブな分析測定コードは、使用できます。

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

ブラウザからは多くのパフォーマンスデータが公開されますが、必ずしも、それを録画して使用できます。

たとえば、Resource Timing API などです。ページでは、ページで読み込まれた各リソースの詳細なタイミングデータを確認できます。とはいえ、そのすべてのデータが、組織にとって必然的に、あるいはリソース負荷のパフォーマンスを向上させます

要するに、データがあるからといって追跡するのではなく、データが使用されるようにします。追跡しているリソースを消費しないようにできます