パフォーマンスを優先することは、ユーザーにとってだけでなく、ビジネスにとっても有益です。このコレクションのベスト プラクティスは主に 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 と組み合わせることで、2 つのグループの相対的なパフォーマンスを評価し、トラフィックの 100% をリスクにさらすことなく、どちらのパフォーマンスが高いかを判断できます。
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 アド マネージャーのレポートの実行時に参照して、グループごとに結果をフィルタできます。