パフォーマンスを優先することは、ユーザーにとってだけでなく、ビジネスにとっても有益です。このコレクションのベスト プラクティスは主に Google パブリッシャー タグ（GPT）の統合の最適化に焦点を当てていますが、特定のページの全体的なパフォーマンスには、他にも多くの要因が影響します。変更を導入する際は、サイトのパフォーマンスのあらゆる側面に及ぼす影響を評価することが重要です。
ページ パフォーマンスを測定する
変更がサイトのパフォーマンスにどのように影響するかを把握するには、まず比較するベースラインを設定する必要があります。そのための最善の方法は、アイデアの基準を定義するパフォーマンス バジェットを作成することです。ただし、一定のパフォーマンス レベルを維持したい場合は、サイトの現在のパフォーマンス指標をベースラインとして使用できます。
パフォーマンスの測定を開始するには、次のアプローチを組み合わせることをおすすめします。
- 合成モニタリング
- Lighthouse や Lighthouse によるパブリッシャー広告監査などのツールを使用して、ラボ環境でページのパフォーマンスを測定できます。このタイプの測定ではエンドユーザーの操作が不要であるため、自動テストでの使用に適しています。また、変更をユーザーにリリースする前に、変更のパフォーマンスを検証するために使用できます。
- リアルユーザー モニタリング（RUM）
- Google アナリティクスや PageSpeed Insights などのツールを使用すると、ユーザーから直接実際のパフォーマンス データを収集できます。このタイプの測定はエンドユーザーの操作に基づいているため、合成テストでは容易に発見できないラスト ワンマイルのパフォーマンスの問題を特定するのに役立ちます。
測定値を定期的に記録し、ベースラインと比較してください。これにより、時間の経過とともにサイトのパフォーマンスが適切な方向に進んでいるかどうかがわかります。
測定対象を選択する
パフォーマンスに関して言えば、サイトのパフォーマンスに関するすべての情報を把握できる単一の指標はありません。ページのパフォーマンスの全体像を把握するには、ページのパフォーマンスのさまざまな側面を網羅するさまざまな指標を確認する必要があります。主なパフォーマンス領域と推奨される指標の一部を次の表に示します。
| パフォーマンス領域 | |
|---|---|
| 認識される読み込み速度 |
メジャー ページのすべての UI 要素を読み込み、レンダリングするまでの時間。 推奨される指標
First Contentful Paint（FCP） |
| ページ読み込みの応答性 |
測定
初期読み込み後にページが応答するまでの時間。 推奨される指標 |
| 視覚的な安定性 |
測定
UI 要素の移動量と、これらの移動がユーザー操作を妨げるかどうか。詳しくは、レイアウト シフトを最小限に抑えるをご覧ください。 推奨される指標 |
ページのパフォーマンスに加えて、広告固有のビジネス指標を測定することもできます。インプレッション数、クリック数、視認性などの情報をスロットごとに確認するには、Google アド マネージャーのレポートを使用します。
テストの変更
パフォーマンス指標を定義し、定期的に測定を開始したら、このデータを使用して、サイトの変更がパフォーマンスに与える影響を評価できます。変更後に測定した指標を、変更前（および前述のベースライン）に測定した指標と比較します。このようなテストを行うと、ビジネスやユーザーにとって大きな問題になる前にパフォーマンスの問題を検出して対処できます。
自動テスト
ユーザー操作に依存しない指標は、合成テストで測定できます。未公開の変更がパフォーマンスに与える影響を把握するには、開発プロセス中にこの種のテストをできるだけ頻繁に実行する必要があります。このような事前テストを行うと、変更をユーザーにリリースする前にパフォーマンスの問題を特定できます。
これを実現する 1 つの方法は、合成テストを継続的インテグレーション（CI）ワークフローの一部にすることです。このワークフローでは、変更が加えられるたびにテストが自動的に実行されます。Lighthouse CI を使用すると、合成パフォーマンス テストを多くの CI ワークフローに統合できます。
A/B テスト
ユーザー操作に依存する指標は、変更が実際にユーザーにリリースされるまで完全にテストすることはできません。変更の動作が不明な場合は、リスクが生じる可能性があります。このリスクを軽減する方法の一つが A/B テストです。
A/B テストでは、ページのさまざまなパターンがユーザーにランダムに表示されます。この手法を使用すると、全体のトラフィックのうちごく一部に変更版のページを配信し、残りのほとんどには変更されていないページを配信できます。RUM と組み合わせることで、トラフィックの 100% をリスクにさらすことなく、2 つのグループの相対的なパフォーマンスを評価して、どちらのパフォーマンスが優れているかを判断できます。
A/B テストのもう 1 つのメリットは、変更の効果をより正確に測定できることです。多くのサイトでは、パフォーマンスのわずかな差異が最近の変更によるものなのか、トラフィックの通常の変動によるものなのかを判断することが難しい場合があります。A/B テストのテストグループは、全体的なトラフィックの一定の割合を表すため、指標はコントロール グループと一定の係数で異なる必要があります。したがって、2 つのグループ間で観察された差は、テスト対象の変更により確実にアトリビューションされます。
Optimizely や Google オプティマイズ などのツールを使用すると、A/B テストの設定と実行が容易になります。ただし、タグベースの A/B テスト（これらのツールのデフォルト設定）自体がパフォーマンスに悪影響を及ぼし、誤った結果をもたらす可能性があることに注意してください。そのため、サーバーサイド統合を強くおすすめします。
A/B テストの結果
A/B テストを使用して変更の影響を測定するには、コントロール グループとテストグループの両方から指標を収集して、相互に比較します。そのためには、どのトラフィックがどのグループに属しているかを示す方法が必要です。
ページのパフォーマンス指標の場合、コントロール バージョンとテスト バージョンのどちらが配信されたかを示す単純な識別子を各ページに含めるだけで十分な場合がよくあります。この ID は、指標を解析して関連付けることができるものであれば、何でも構いません。ビルド済みのテスト フレームワークを使用している場合、これは通常、自動的に処理されます。
広告固有のビジネス指標の場合は、GPT のキーバリュー ターゲティング機能を使用して、広告リクエストをコントロール グループとテストグループで区別できます。
// On control group (A) pages, set page-level targeting to:
googletag.pubads().setTargeting('your-test-id', 'a');
// On experimental group (B) pages, set page-level targeting to:
googletag.pubads().setTargeting('your-test-id', 'b');
これらの Key-Value は、Google アド マネージャーのレポートの実行時に参照して、グループごとに結果をフィルタできます。