パフォーマンスを優先することは、ユーザーにとって良いだけでなく、ビジネスにとっても良いものです。このコレクションで紹介するおすすめの方法は主に Google パブリッシャー タグ（GPT）の統合を最適化することに重点を置いていますが、ページの全体的なパフォーマンスには他にもさまざまな要素が関係します。変更を導入する際は、その変更がサイトのパフォーマンスに及ぼすあらゆる影響を評価することが重要です。
ページのパフォーマンスを測定する
変更がサイトのパフォーマンスにどのように影響するかを把握するには、まず比較するベースラインを確立する必要があります。そのための最善の方法は、アイデアのベースラインを定義するパフォーマンス バジェットを作成することです。ベースラインは、サイトが現在満たしている可能性がある場合とそうでない場合があります。ただし、一定レベルのパフォーマンスを維持したい場合は、サイトの現在のパフォーマンス指標をベースラインとして使用できます。
パフォーマンスの測定を開始するには、次の方法を組み合わせて行うことをおすすめします。
- 合成モニタリング
- ラボ設定では、Lighthouse や Lighthouse によるパブリッシャー広告監査などのツールを使用してページのパフォーマンスを測定できます。このタイプの測定は、エンドユーザーとのやり取りを必要としないため、自動テストでの使用に適しています。また、ユーザーにリリースする前に変更のパフォーマンスを検証するために使用できます。
- 実際のユーザー モニタリング（RUM）
- Google アナリティクスや PageSpeed Insights などのツールを使用すると、実際のパフォーマンス データをユーザーから直接収集できます。このタイプの測定はエンドユーザーのインタラクションに基づいているため、合成テストでは簡単に確認できないラスト ワンマイル パフォーマンスの問題を特定するのに便利です。
測定値を確認し、定期的にベースラインと比較します。これにより、サイトのパフォーマンスが時間の経過とともに正しい方向に進んでいるかどうかを確認できます。
測定対象を選択する
パフォーマンスについては、サイトのパフォーマンスについて知っておくべきことをすべて確認できる単一の指標はありません。ページ全体のパフォーマンスを把握するには、ページのパフォーマンスに関するさまざまな指標を把握する必要がありますが、主なパフォーマンス分野と推奨指標については、以下の表をご覧ください。
| パフォーマンスの分野 | |
|---|---|
| 予想される読み込み速度 |
メジャー ページがすべての UI 要素を読み込んでレンダリングする速さ。 指標の候補
First Contentful Paint（FCP） |
| ページ読み込みの応答性 |
メジャー 最初の読み込みからページが応答するまでの速さ。 指標の候補 |
| 視覚的安定性 |
メジャー UI 要素がどの程度シフトするか、およびそれらのシフトがユーザー操作の妨げになるかどうか。詳細については、レイアウト シフトを最小限に抑えるをご覧ください。 指標の候補 |
ページのパフォーマンスに加えて、広告固有のビジネス指標も測定することをおすすめします。スロットごとのインプレッション、クリック、視認性などの情報は、Google アド マネージャーのレポートから取得できます。
テストの変更
パフォーマンス指標を定義して定期的に測定を開始したら、そのデータを参考にして、サイトの変更によるパフォーマンスへの影響を評価できます。これを行うには、変更後に測定された指標と、変更前に測定された指標（または以前に設定したベースライン）を比較します。この種のテストにより、ビジネスやユーザーに大きな問題になる前に、パフォーマンスの問題を検出して対処できます。
自動テスト
合成テストを通じて、ユーザー操作に依存しない指標を測定できます。このようなテストは開発プロセス中にできるだけ頻繁に実行して、リリースされていない変更がパフォーマンスにどのように影響するかを把握する必要があります。このようなプロアクティブなテストにより、変更がユーザーにリリースされる前にパフォーマンスの問題を発見できます。
これを行う 1 つの方法は、継続的インテグレーション（CI）ワークフローに合成テストを組み込むことです。このワークフローでは、変更が行われるたびにテストが自動的に実行されます。Lighthouse CI を使用して合成パフォーマンス テストを多くの CI ワークフローに統合できます。
A/B テスト
ユーザー操作に依存する指標は、変更がユーザーに実際にリリースされるまで、完全にテストできません。変更の動作が不明な場合はリスクが伴います。このリスクを軽減する手法の 1 つは、A/B テストです。
A/B テストでは、ページのさまざまなパターンがランダムにユーザーに表示されます。この方法では、改変されたページ全体を、トラフィックのごく一部に配信しながら、ほとんどは変更されていないページに配信できます。RUM と組み合わせることで、2 つのグループの相対的なパフォーマンスを評価し、トラフィックを 100% 危険にさらすことなく、どちらのパフォーマンスが優れているかを判断できます。
A/B テストのもう一つの利点は、変更の影響をより正確に測定できる点です。多くのサイトにとって、パフォーマンスのわずかな変化が最近の変化なのか、トラフィックの正常な変動によるものなのかを判断するのは、困難な場合があります。A/B テストのテストグループは、トラフィック全体のうち一定の割合を表すため、指標はコントロール グループと一定係数で異なる必要があります。したがって、2 つのグループ間で観察された差異は、テスト対象の変更に確実に帰属できます。
Optimizely や Google Optimize などのツールが、A/B テストの設定と実行に役立ちます。ただし、タグベースの A/B テスト（これらのツールのデフォルト構成）は、それ自体がパフォーマンスに悪影響を及ぼし、誤解を招く結果をもたらす可能性がありますのでご注意ください。そのため、サーバー側でのインテグレーションを強くおすすめします。
A/B テストの結果
A/B テストを使用して変更の効果を測定するには、コントロール グループとテストグループの両方から指標を収集し、比較します。これを行うには、どのトラフィックがどのグループの一部であるかを識別する方法が必要です。
ページのパフォーマンス指標の場合、多くの場合、コントロールとテスト バージョンのどちらが配信されたかを示すシンプルな識別子を各ページに入れるだけで十分です。この識別子は、指標を解析して関連付けできるものであれば、任意のものを使用できます。ビルド済みのテスト フレームワークを使用している場合、通常は自動的に処理されます。
広告固有のビジネス指標については、GPT の Key-Value ターゲティング機能を使用して、コントロール グループとテストグループと広告リクエストを区別できます。
// 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 アド マネージャーのレポートを作成する際に参照でき、グループ別に結果をフィルタできます。