A/B テストを活用して、サイトの速度がビジネス指標に与える影響を評価します。
サイトの速度パフォーマンスはユーザー エクスペリエンスの重要な要素であり、その改善がコンバージョン率や直帰率などのさまざまなビジネス指標の向上につながることは、ここ数年でわかってきました。これを裏付ける複数の記事やケーススタディが公開されています。たとえば、Cloudflare の How Website Performance Affects Conversion Rates、Deloitte の Milliseconds Make Millions、Shopping for Speed on eBay.com などがあります。
速度に関するケースは明らかですが、多くの企業は、サイトの速度を改善する作業の優先順位付けにまだ苦労しています。なぜなら、サイト速度がユーザーやビジネスに及ぼす影響を正確に把握できないためです。
データがなければ、サイトの速度に関する作業を遅らせ、他のタスクに集中しがちです。よくあるシナリオは、社内の一部の従業員がサイトの速度の重要性を認識しているにもかかわらず、その対応について複数の関係者に投資を説得できない場合です。
この記事では、A/B テストを活用してサイトの速度がビジネス指標に与える影響を評価し、問題に関してより効果的な意思決定を行う方法の概要を説明します。
ステップ 1: A/B テスト対象のページを選択する
目標は、ページの読み込み速度がビジネス指標と関連しているという仮説をテストすることです。わかりやすくするために、最初は分析用に 1 つのページを指定するように制限します。今後の作業は、検出結果を検証するために同じタイプの複数のページに拡大し、さらにサイトの他の領域にも展開する可能性があります。このステップの最後に、どこから始めるかに関する提案があります。ページ選択プロセスには、いくつかの要件があります。
- A/B テストは、モバイル ユーザーのデバイスでのみ実行する必要があります。世界全体で、Google がサポートしているパートナー サイトのトラフィックは平均で 50%以上（現在も増加）を占めていますが、地域やカテゴリによっては大幅に増加する可能性があります。モバイル デバイスは、処理能力やメモリの制約、ネットワークの安定性が低いため、低速なウェブサイトに対して敏感です。また、移動中の使用パターンにより、速度に対する期待が高まります。
テストに使用するページは、コンバージョン プロセスの重要な部分を担う必要があります。サイトごとに目的が異なるため、サイトごとに成功指標が異なります。これらの指標は通常、ファネルを使用して分析されるユーザー ジャーニーに関連しています。たとえば、e コマースサイトのユーザーが購入を完了するには、ホームページ、カテゴリページ、商品ページ、購入手続きページに移動する必要があります。コンバージョン重視で最適化する場合は、このようなページのいずれかが候補になります。
ページの目的は 1 つだけにします。サイトに明確な目的がある場合を除き、通常はホームページをテストに使用するのは避けることをおすすめします。多くの商用サイトのホームページは、分析を面倒にするさまざまな機能へのポータルになっています。たとえば、ニュースサイトのセッションあたりのページビュー数を重視して最適化する場合は、サイトの非営利目的の部分を除外して、収益化対象のセクションと記事に重点を置くことをおすすめします。
統計的に有意な結果が得られるまで長時間を費やす必要がないように、選択したページに十分なトラフィックがある必要があります。
選択したページは比較的低速になります。速度が遅いほど良い結果が得られます。これは、ページの改善が容易になるだけでなく、データが明確になるという意味でもあります。Google アナリティクスの Speed Report または Search Console の Core Web Vitals レポートにざっと目を通すと、速度が遅いページを確認できます。
ページは比較的安定している必要があります。テストが完了するまでページ（ビジネス指標に影響するもの）を更新しないでください。考慮すべき外部要因が少ないほど、分析は明確になります。
上記を参考にすると、どのページがテストに適した候補かがやや明確になります。ビジネス指標、A/B テスト、分析を自由に利用できる可能性が高いため、広告のランディング ページも優れた選択肢です。判断に迷う場合のために、カテゴリ別のアイデアをいくつかご紹介します。
- コンテンツ ウェブサイト: セクション、記事
- 外観: カテゴリページ、商品ページ
- メディア プレーヤー: 動画発見/検索ページ、動画再生ページ
- サービス &ディスカバリー（旅行、レンタカー、サービス登録など）: 最初のフォーム入力ページ
ステップ 2: パフォーマンスを測定する
指標を測定する一般的な方法は、ラボと現場の 2 つです。Google は、実際のユーザーの体験を反映する、現場での指標の測定（リアルユーザー モニタリング（RUM）とも呼ばれます）の方が便利であると感じています。RUM データのレポートに役立つライブラリとサービスには、Perfume、Firebase Performance Monitoring、Google アナリティクス イベントなどがあります。
ユーザー エクスペリエンスのさまざまな側面をキャプチャすることを目的としているため、多くの指標から選択できます。目標は最終的に速度とビジネス指標の間に直接的な相関関係があるかどうかを判断することであるため、いくつかの速度指標を追跡して、ビジネスの成功と最も強い相関がある指標を判断すると役立つ場合があります。通常は、ウェブに関する主な指標から始めることをおすすめします。web-vitals.js ライブラリを使用すると、現場で Core Web Vitals の一部を測定できます。ただし、ブラウザのサポートが 100%になるわけではありません。Core Web Vitals のほかに、Other Web Vitals もご確認ください。また、「最初の広告クリックまでの時間」などのカスタム指標も定義できます。
ステップ 3: 速度パフォーマンスのバリアントを作成する
このステージでは、変更を実装してページの高速バージョンを作成し、現在のバージョンとの比較テストを行います。
次の点にご注意ください。
- UI や UX には変更を加えないでください。一方のページの方がもう一方のページより処理が速いため、変更内容はユーザーに見えないようにする必要があります。
- 測定も、この段階では重要な要素です。開発中は、Lighthouse などのラボ用テストツールを使用して、変更がパフォーマンスに及ぼす影響を示す必要があります。ある指標の変更が別の指標に影響する場合が多いことに留意してください。ページが公開されたら、より正確な評価のため RUM を使用します。
パフォーマンスのパターンは、さまざまな方法で作成できます。テストでは、できる限り簡単にします。以下に、いくつかのオプションがあります。
ページをすばやく作成する
- Squoosh などのツールを使用して、テストページの画像を手動で最適化します。
- DevTools のコード カバレッジを使用して、そのページだけに使用されていない JavaScript や CSS を手動で削除します。
- サードパーティ スクリプトを効率的に読み込む
- Critical などのツールを使用して、重要な CSS を分割してインライン化します。
- ユーザー エクスペリエンスに影響を与えず、テストのために必要でなくともできる、重要でない JavaScript コード（特定のサードパーティ ライブラリなど）を削除します。
- ブラウザレベルの遅延読み込みを実装します。この遅延読み込みは、一部のブラウザでサポートされていませんが、サポートされている場合はパフォーマンスが大幅に向上する可能性があります。
- 重要性の低い分析タグを削除するか、非同期で読み込む
その他の最適化については、高速読み込み時間とフロントエンドのパフォーマンス チェックリストをご覧ください。また、PageSpeed Insights を使用して Lighthouse を実行することで、パフォーマンス改善の機会を特定することもできます。
ページの表示速度を遅くする
これがパターンを作成する最も簡単な方法であり、シンプルなスクリプトの追加、サーバーの応答時間を遅くする、大きな画像を読み込むなどの方法で実現できます。Financial Times は、パフォーマンスがビジネス指標に及ぼす影響をテストする際にこのオプションを選択しています。FT.com の高速化をご覧ください。
ページの読み込みを高速化する
テストページ（商品の詳細ページなど）が主に別のページ（ホームページなど）からリンクされている場合、テストグループのホームページから商品ページのプリフェッチまたは事前レンダリングを直接行うと、その後のページの読み込み時間を短縮できます。この場合、A/B テスト分割（ステップ 4）はホームページで行われます。また、これらはすべて最初のページの表示速度を低下させる可能性があるため、テスト結果を分析する際はそれを測定し、考慮に入れてください（ステップ 5）。
ステップ 4: A/B テストを作成する
同じページに 2 つのバージョンがあり、一方が他方よりも高速である場合、次のステップはトラフィックを分割して影響を測定します。一般に、A/B テストを実行するための手法やツールは多数ありますが、速度パフォーマンスへの影響を測定するには、すべての手法が適しているわけではありません。
Optimizely や Optimize などの A/B テストツールを使用している場合は、クライアントサイド テストではなくサーバーサイド テストを設定することを強くおすすめします。クライアントサイドの A/B テストでは多くの場合、テストが読み込まれるまでページ コンテンツを非表示にすることで、A/B テスト自体が測定したい指標に歪みます。クライアントサイド テストしか実施できない場合は、別のページでテストをセットアップし、テストページへのリンクを変更してトラフィックを分割することを検討してください。これにより、テストページ自体がクライアントサイド テストによって下にドラッグされなくなります。
サーバーサイド テストによって特定の商品詳細ページ（PDP）のパフォーマンスの変化を A/B テストでテストする例を次に示します。
リクエストがバックエンドに送信され、ユーザーが 2 つの異なるバージョンのページに分散されます。一般的にはこれが適切な設定ですが、サーバー側の分割を設定するために IT リソースが必要になることも少なくありません。
クライアント側のテスト設定の例を以下に示します。前のページ（下の図のホームページ）を使用してテスト用の JavaScript を実行します。
テスト用の JavaScript は、送信リンクを操作して、2 つのテストグループにユーザーの 2 つのバージョンの PDP へのリンクを提供します。Optimizely や Optimize などの一般的な A/B テストツールを使用して簡単に設定、管理できます。テスト用 JavaScript は別のページで実行されるため、パフォーマンス テストには影響しません。
あるいは、非常に似たような 2 つのページ（たとえば、2 つの非常に似た商品）を選択することもできます。そのうちの一つに変更を適用し、指標の経時的な差異を比較します。これは、A/B テストが適切に実施されていないことを意味しますが、非常に有用な情報が得られます。
テストページを広告キャンペーンのランディング ページとして使用する場合は、Facebook Ads Split Test や Google 広告の下書きとテストなど、広告ネットワークの組み込みの A/B テストツールを使用すると便利です。使用できない場合は、同じ設定で 2 つのキャンペーンを使用して、異なるランディング ページをターゲットとして設定できます。
ステップ 5: A/B テストを分析する
テストを長期間実行し、結果に確信を持てるのに十分なデータが集まったら、すべてをまとめ、分析を実行します。その方法はテストの実行方法によって異なるため、オプションを見ていきましょう。
上記のツールを使用して広告のランディング ページでテストを実行した場合、分析は結果を確認するのと同じくらいわかりやすいものである必要があります。Google の「下書きとテスト」を使用している場合は、ScoreCard で比較を確認できます。
Optimizely や Optimize などのプラットフォームでは、結果を解釈し、速度がページに与える影響を簡単に判断することもできます。
Google アナリティクスなどのツールを使用している場合は、自分でレポートを収集する必要があります。幸いなことに、Google アナリティクスではカスタム レポートを簡単に作成することができます。作成から始めるのがおすすめです。カスタム ディメンションを使用して速度データを Google アナリティクスに送信している場合は、レポートガイドで速度データを設定し、カスタム レポートに追加する方法をご確認ください。レポートにテストの日付が含まれ、両方のパターンを表示するように構成されていることを確認してください。このレポートの内容
- まず、コンバージョン数、ページビュー数、表示された広告数、コンバージョン率、e コマースの指標、クリック率など、最も重視するビジネス指標を含める必要があります。
- また、サイトの速度の改善に役立つその他の標準的なページ指標には、直帰率、平均セッション継続時間、離脱率などがあります。
場合によっては、モバイルでフィルタし、bot とその他のユーザー以外のトラフィックを除外する必要があります。より高度な分析では、リージョン、ネットワーク、デバイス、トラフィック ソース、ユーザー プロファイルと種類（新規ユーザーとリピーターなど）でフィルタすることもできます。ユーザー グループごとに速度の遅さは多かれ少なかれ、それを特定することも非常に役立ちます。
Looker Studio（旧データポータル）などのデータ可視化ツールを使用すると、Google アナリティクスなどのさまざまなデータソースを簡単に統合できます。これにより、分析が容易になるだけでなく、最新のウェブサイトの運営に関与する多くの関係者と共有可能なダッシュボードを作成して、さらなる賛同を得ることもできます。たとえば、Guardian は自動アラート システムを作成しました。これは、最近公開されたコンテンツがページサイズや速度のしきい値を超え、ユーザーが満足しない結果になる可能性がある場合に、編集チームに警告するものです。
ステップ 6: 結論を導き出し、次のステップを決定する
パフォーマンス指標とビジネス指標を関連付けるデータが得られたら、結果を調べて結論を導き出すことができます。
パフォーマンスの向上とビジネス指標の改善の間に明確な相関関係がある場合は、結果を要約して会社全体に報告します。スピード パフォーマンスをビジネス用語で説明できるようになったことで、さまざまな関係者の注意を引き、サイトのスピード パフォーマンスをすべての関係者に注目させる可能性が高まります。次のステップでは、結果に基づいてパフォーマンス予算を設定し、その予算を満たすように作業を計画します。このような作業がもたらす価値がわかっているため、それに応じて優先順位を付けることができます。
相関関係を特定できない場合は、以下の注意事項を確認し、同様のテストをサイトの別の場所（購入の目標到達プロセス全体、別のタイプのページなど）で実行する必要があるかどうかを評価します。
注意点
サイトの速度指標とビジネス指標の間に有意な相関関係が見つからない場合は、いくつかの理由が考えられます。
- 選択したページが、調査しているビジネス指標に十分な影響を与えていない。たとえば、商品ページが高速でも、購入手続きページが非常にわかりにくい場合や遅い場合は、コンバージョン率に大きな影響がない場合があります。直帰率、カート追加率、テスト対象のページにより直接関連するその他の指標など、より関連性の高い指標を確認することを検討します。
- 2 つのバージョン間で速度の違いが十分ではありません。これは、測定する RUM 指標に沿って評価する必要があります。
- A/B テスト メカニズムにエラーがあります。トラフィックが適切に分散されていないか、分析が正しく報告されない可能性があります。これを除外するには、A/A テストを実行して、同じテスト メカニズムを使用して同じバージョンのページをテストします。テストしても結果に違いがないことを確認します。
- サイトの速度はビジネス指標に実際には影響しません。これはまれですが、ターゲット市場が速度の影響を受けにくい場合（ほとんどの場合、サイトへのアクセスに強力なネットワーク上にある強力なデバイスがある場合）、またはユーザーの需要が非常に高く選択肢が限られている場合（需要の多い番組のチケットのみを販売するチケット販売サービスなど）に発生する可能性があります。これは、サイトを高速化してもユーザー エクスペリエンスの向上が目的ではなく、ブランドの評判に影響するという意味ではありません。
おわりに
サイト全体で速度の最適化に取り組みたくなりますが、長期的には、一般的には、ウェブサイトを高速化することがユーザーと会社にとってどのような意味を持つのかを最初に理解した方が有益です。「FCP を 1.5 秒改善した」と「FCP を 1.5 秒改善し、コンバージョン率を 5% 向上させた」との違いです。これにより、以降の作業に優先順位を付け、さまざまな関係者の賛同を得て、サイトの速度向上を全社的な取り組みにできます。