サーバー側Google Tag Managerを活用したウェブサイトのページ表示速度改善

サーバー側Google Tag Managerの初期バージョンがリリースされた際、ウェブサイトのページ表示速度の最適化は、マーケターやウェブ開発者が期待した大きなメリットの1つでした。計測スクリプトを直接ハードコードするのではなく、Google Tag Manager経由で追加できるようになることで、速度向上が実現すると考えられていたためです。 

本記事では、タグをGTMのウェブコンテナからサーバーコンテナへ移行することがGTMのPageSpeedにどのように影響するのか、実際のデータはどうなっているのか、そしてセットアップ内容に応じてどちらのアプローチがより適しているのかを解説します。

早くも2016年には、Googleがウェブサイトの理想的な読み込み時間は3秒であると示しました。 その一方で、モバイルページが完全に読み込まれるまでには平均で22秒かかっています。 

現代ではデスクトップ端末よりもスマートフォンなどの携帯電話を利用する人が多く、スマートフォンのトラフィックはインターネット全体の50%以上を占めています。 しかし、Googleによるとモバイルでのコンバージョン率はデスクトップよりも低くなっています。だからこそ、パフォーマンス基準を満たす上でウェブサイトの読み込み速度が極めて重要な役割を果たすのです。

ユーザーが高速なサイト体験を求めているのは周知の事実です。ランディングページの表示が遅すぎると、ユーザーはページを閉じたりカートを放棄して競合サイトへと離脱してしまいます。 モバイルファーストの現代において、読み込みの速いサイトを作ることは不可欠です。ユーザーはどんなブログでもすぐに開いて記事を読んだり、新しい服を買ったり、ホテルの口コミをチェックしたりしたいと考えています。

Amazonの調査によると、ページの応答が1秒遅れるだけでコンバージョンが1%低下します。これは同社にとって年間16億ドルの収益損失に相当します。

このように、表示の重いページの読み込みをユーザーに待たせることは、あらゆる企業にとって莫大な損失につながりかねません。 

Google Tag Manager経由で追加するすべてのタグは、ユーザーのブラウザ上でJavaScriptとして実行されます。各スクリプトはページの読み込み前後にダウンロード、解析、実行される必要があり、それには時間がかかります。

すべてのGTMセットアップが同じように動作するわけではなく、この点が多くの混乱を生む原因となっています。コンテナがどのように実装されているか（ウェブかサーバーか）によって、GTMがブラウザへの負荷を増やすのか、それとも軽減するのかが決まります。ウェブコンテナでは、追加するすべてのタグ（アナリティクス、広告ピクセル、チャットウィジェット、ヒートマップ）が、訪問者のブラウザ上で直接読み込まれ実行されるスクリプトとなります。

それらのスクリプトはすべて、メインスレッド、帯域幅、レンダリング時間といった限られたリソースを取り合います。GTM自体は軽量なコンテナであるにもかかわらず、タグを増やせば増やすほどGoogle Tag Managerによるパフォーマンスへの悪影響は蓄積されていきます。

サーバー側GTMはタグが実行される場所を変更します。何十ものサードパーティスクリプトがクライアント側で実行される代わりに、サーバーコンテナがデータを受信し、クラウドからマーケティングプラットフォームやアナリティクスプラットフォームへと転送します。ブラウザは無数のサードパーティドメインと通信する必要がなくなり、自社のサーバーとだけ通信すれば済みます。これこそが、ウェブとサーバーのセットアップ間でGoogle Tag ManagerのPageSpeedスコアに大きな差が生じる根本的な理由です。

2020年、GoogleはGoogle Tag ManagerおよびTag Manager 360向けのサーバーコンテナをリリースしました。これにより広告主は、サードパーティタグを自社サイトからクラウドサーバー上にホストされた新しいサーバーコンテナへと移行できるようになりました。これにより、ウェブサイトの読み込みが高速化し、トラッキングの精度が向上し、データの安全性が高まります。タグをサーバーコンテナへ移行することは、Google PageSpeedの「第三者コードの影響を抑えてください — 第三者コードによってメインスレッドが550ミリ秒ブロックされました」というエラーの解決に役立ちます。

タグをウェブコンテナからサーバーコンテナへ移行すると、タグはブラウザ内ではなくサーバーコンテナに直接読み込まれるようになります。これによりページ読み込みが高速化され、ユーザー体験に良い影響をもたらします。このように、ページの読み込み時間の短縮、顧客データのセキュリティ向上、そしてより高度なデータ管理ツールの提供が可能になります。 これは、サーバー側Google Tag Managerがトラッキングの精度を損なうことなくウェブサイトのパフォーマンスを向上させることができる、最もわかりやすい例の1つです。

サーバーコンテナ内のタグは、サーバーに送信された情報にのみアクセスできます。 ユーザーがサイト上で入力した他の情報にアクセスすることはできません。また、これらのタグは自社のサーバーコンテナ内に配置されているため、どのタグが情報を収集し、その情報がどこに送信されているのかを正確に把握できます。

すべてのタグが均等にページ速度へ影響を与えるわけではありません。移行すればあらゆるパフォーマンス問題が解決すると考える前に、この重要なニュアンスを理解しておく必要があります。軽量なアナリティクスのスニペットと負荷の高い広告リターゲティングピクセルでは、どちらも「単なるタグ」でありながら読み込みにかかる負荷はまったく異なります。最も影響が大きいタグは、複数のネットワークリクエストを発行したり、追加のスクリプトを読み込んだり、特定のイベント時だけでなくページ読み込みごとに常に実行されたりする傾向があります。

これを直接確認する最も確実な方法は、移行の前後でGoogle Tag ManagerのPageSpeed Insightsレポートを確認し、結果の「第三者コード」セクションを直接比較することです。

この検証ではデモサイトを使用し、GTMのウェブコンテナ経由でタグを追加した場合と、GTMのサーバーコンテナ経由で追加した場合のGoogle PageSpeedの結果を比較しました。すべてのタグがGoogle PageSpeedに同じ影響を与えるわけではありません。この検証を行うにあたり、クライアントで最もよく利用されており、かつサーバーコンテナへ移行可能なタグとして、Facebook、Bing、Active Campaignを選択しました。

GTMのサーバーコンテナにはGA4用のネイティブタグが用意されています。GTMのサーバー側コンテナを使用したGA4トラッキングの設定方法に関する詳細情報はこちらでご確認いただけます。また、Facebookピクセルをサーバー環境へ移行するためのカスタムテンプレートも作成しました。 

以下がGoogleスピードテストの結果です。Google PageSpeedスコアはモバイルで95点、デスクトップで100点を記録しました。 

サーバーコンテナには、GA4、Facebook（ベースタグおよびコンバージョン測定タグ）、Hubspot、Klaviyoのタグを導入しています。

ピクセルをウェブコンテナに移行したところ、Google PageSpeedのスコアは56点に低下しました。 

タグをGoogle Tag Managerのサーバーコンテナに移行すると、サイトの表示速度が向上します。その効果の度合いは、使用しているタグによって異なります。今回のテストでは、クライアントの間で最も人気のあるタグ（GA4、Facebook、Active Campaign）をサーバー側に移行したことで、明確かつ測定可能な違いが現れました。