タグとタグ マネージャーのベスト プラクティス

公開日: 2021 年 7 月 29 日

タグは、通常はタグ マネージャーを使用してサイトに挿入されるサードパーティ コードのスニペットです。タグは、主にマーケティングと分析に使用されます。

タグとタグ マネージャーがパフォーマンスに与える影響は、サイトによって大きく異なります。タグ マネージャーは封筒に例えることができます。タグ マネージャーは入れ物を提供しますが、何を入れるか、どのように使うかは、ほとんどの場合、ユーザー次第です。

ここでは、パフォーマンスと Core Web Vitals のためにタグとタグ マネージャーを最適化する手法について説明します。このドキュメントでは Google タグ マネージャーについて説明しますが、ここで説明するアイデアの多くは他のタグ マネージャーにも適用できます。

Core Web Vitals への影響

タグ マネージャーは、ページをすばやく読み込んで応答性を維持するために必要なリソースを使い果たすことで、Core Web Vitals に間接的に影響を与えることがよくあります。サイトのタグ マネージャー JavaScript のダウンロードや、その後の呼び出しに帯域幅が消費されることがあります。メインスレッドの CPU 時間は、タグ マネージャーとタグに含まれる JavaScript の評価と実行に費やされる可能性があります。

Largest Contentful Paint(LCP)は、重要なページの読み込み時間中に帯域幅の競合の影響を受けやすくなります。また、メインスレッドをブロックすると、LCP のレンダリング時間が遅れる可能性があります。

Cumulative Layout Shift(CLS)は、最初のレンダリングの前に重要なリソースの読み込みを遅らせるか、タグ マネージャーがページにコンテンツを挿入することで影響を受ける可能性があります。

Interaction to Next Paint(INP)は、メインスレッドでの CPU 競合の影響を受けやすく、タグ マネージャーのサイズと INP スコアの低下には相関関係があることがわかっています。

適切なタグタイプを選択する

タグがパフォーマンスに与える影響は、タグの種類によって異なります。一般的に、最もパフォーマンスが高いのは画像タグ(「ピクセル」)で、次にカスタム テンプレート、最後にカスタム HTML タグが続きます。ベンダータグは、許可する機能によって異なります。

タグの使用方法は、パフォーマンスへの影響に大きく関係します。「ピクセル」のパフォーマンスが高いのは、このタグタイプの性質上、使用方法に厳しい制限が課されていることが主な理由です。カスタム HTML タグは、必ずしもパフォーマンスに悪影響を及ぼすわけではありませんが、ユーザーに提供される自由度が高いため、パフォーマンスに悪影響を及ぼすような方法で誤用されやすい傾向があります。

タグについて考えるときは、規模を考慮してください。1 つのタグがパフォーマンスに与える影響は無視できる程度かもしれませんが、同じページで数十個または数百個のタグが使用されると、大きな影響を与える可能性があります。

すべてのスクリプトをタグ マネージャーで読み込む必要はない

通常、タグ マネージャーは、Cookie の通知、ヒーロー画像、サイト機能など、ユーザー エクスペリエンスの視覚的または機能的な側面を即座に実装するリソースを読み込むには最適な方法ではありません。タグ マネージャーを使用してこれらのリソースを読み込むと、通常、配信が遅れます。これはユーザー エクスペリエンスを損なうだけでなく、LCP や CLS などの指標を増加させる可能性もあります。

また、一部のユーザーはタグ マネージャーをブロックしています。タグ マネージャーを使用して UX 機能を実装すると、一部のユーザーのウェブサイトが破損する可能性があります。

カスタム HTML タグに注意する

カスタム HTML タグは長年にわたって使用されており、ほとんどのサイトで頻繁に使用されています。カスタム HTML タグを使用すると、独自のコードをほとんど制限なく入力できます。このタグの主な用途は、ページにカスタム <script> 要素を追加することです。

カスタム HTML タグはさまざまな方法で使用でき、パフォーマンスへの影響は大きく異なります。サイトのパフォーマンスを測定する際は、ほとんどのツールがカスタム HTML タグのパフォーマンスへの影響を、タグ自体ではなく、タグを挿入したタグ マネージャーに帰属させることに注意してください。

Google タグ マネージャーでカスタムタグを作成する

カスタム HTML タグを使用すると、周囲のページに要素を挿入できます。ページに要素を挿入する行為は、パフォーマンスの問題の原因となる可能性があり、場合によってはレイアウト シフトの原因にもなります。

  • ほとんどの場合、ページに要素が挿入されると、ブラウザはページ上の各アイテムのサイズと位置を再計算する必要があります。このプロセスはレイアウトと呼ばれます。1 つのレイアウトがパフォーマンスに与える影響はごくわずかですが、過剰に発生するとパフォーマンスの問題の原因となる可能性があります。この現象の影響は、ローエンド デバイスや DOM 要素数が多いページで大きくなります。
  • 周囲の領域がすでにレンダリングされた後に、表示されるページ要素が DOM に挿入されると、レイアウト シフトが発生する可能性があります。この現象はタグ マネージャーに固有のものではありませんが、通常、タグはページの他の部分よりも後に読み込まれるため、周囲のページがすでにレンダリングされた後に DOM に挿入されるのが一般的です。

カスタム テンプレートの使用

カスタム テンプレートは、カスタム HTML タグと同じオペレーションの一部をサポートしていますが、サンドボックス化されたバージョンの JavaScript を基に構築されており、スクリプト インジェクションやピクセル インジェクションなどの一般的なユースケースに対応する API を提供します。その名前が示すように、パフォーマンスを考慮してテンプレートを作成できるパワーユーザーがテンプレートを作成できます。技術的な知識があまりないユーザーでも、このテンプレートを使用できます。多くの場合、この方法はカスタム HTML へのフルアクセスを許可するよりも安全です。

カスタム テンプレートにはより厳しい制限が課されるため、これらのタグでパフォーマンスやセキュリティの問題が発生する可能性ははるかに低くなります。同じ理由で、カスタム テンプレートはすべてのユースケースで機能するわけではありません。

Google タグ マネージャーのカスタム テンプレート

スクリプトを正しく挿入する

タグ マネージャーを使用してスクリプトを挿入することは、非常に一般的なユースケースです。これを行うには、カスタム テンプレートと injectScript API を使用することをおすすめします。

injectScript API を使用して既存のカスタム HTML タグを変換する方法については、既存のタグを変換するをご覧ください。

カスタム HTML タグを使用する必要がある場合は、次の点に注意してください。

  • ライブラリと大規模なサードパーティ スクリプトは、スクリプトの内容をタグに直接コピーして貼り付けるのではなく、外部ファイルをダウンロードするスクリプトタグ(<script src="external-scripts.js"> など)を使用して読み込む必要があります。<script> タグを使用しないことで、スクリプトのコンテンツをダウンロードするための往復を 1 回減らすことができますが、コンテナのサイズが大きくなり、ブラウザでスクリプトを個別にキャッシュできなくなります。
  • 多くのベンダーは、<script> タグを <head> の上部に配置することを推奨しています。ただし、タグ マネージャーで読み込まれるスクリプトでは、多くの場合、これは不要です。ほとんどの場合、タグ マネージャーが実行されるまでに、ブラウザは <head> の解析をすでに完了しています。

ピクセルを使用する

サードパーティ スクリプトを画像または iframe ピクセルに置き換えることができる場合があります。スクリプトベースのピクセルと比較すると、ピクセルはサポートする機能が少ないため、実装方法としてはあまり好まれないことがよくあります。ただし、タグ マネージャー内で使用する場合、ピクセルはトリガーで起動し、さまざまな変数を渡すことができるため、より動的になります。

ピクセルは、起動後に JavaScript が実行されないため、最もパフォーマンスが高く安全なタイプのタグです。ピクセルのリソースサイズは非常に小さく(1 KB 未満)、レイアウト シフトは発生しません。

ピクセルのサポートについて詳しくは、サードパーティ プロバイダにお問い合わせください。また、コードに <noscript> タグが含まれているかどうかを確認することもできます。 ベンダーがピクセルをサポートしている場合、通常は <noscript> タグ内にピクセルが含まれます。

Google タグ マネージャーのカスタム画像タグ

ピクセルに代わる方法

ピクセルが普及した主な理由は、サーバーのレスポンスが重要でない状況(アナリティクス プロバイダにデータを送信する場合など)で HTTP リクエストを行うための、最も安価で信頼性の高い方法の一つだったからです。navigator.sendBeacon() API と fetch() keepalive API は、この同じユースケースに対応するように設計されていますが、ピクセルよりも信頼性が高いと言えます。

ピクセルを引き続き使用しても問題はありません。ピクセルは十分にサポートされており、パフォーマンスへの影響は最小限に抑えられています。ただし、独自のビーコンを構築する場合は、これらの API のいずれかを使用することを検討する価値があります。

sendBeacon()

navigator.sendBeacon() API は、サーバーのレスポンスが重要でない状況で、少量のデータをウェブサーバーに送信するように設計されています。

const url = "https://example.com/analytics";
const data = JSON.stringify({
    event: "checkout",
    time: performance.now()
});

navigator.sendBeacon(url, data);

sendBeacon() には制限付きの API があります。POST リクエストの作成のみをサポートし、カスタム ヘッダーの設定はサポートしていません。すべての最新のブラウザでサポートされています。

Fetch API keepalive

keepalive は、Fetch API を使用して、イベント レポートや分析などの非ブロッキング リクエストを行うことができるフラグです。fetch() に渡されるパラメータに keepalive: true を含めることで使用されます。

const url = "https://example.com/analytics";
const data = JSON.stringify({
  event: "checkout",
  time: performance.now()
});

fetch(url, {
    method: 'POST',
    body: data,
    keepalive: true
});

fetch() keepalive と sendBeacon() はよく似ています。実際、Chromium ブラウザでは、sendBeacon() は fetch() keepalive を基盤として構築されています。

fetch() keepalive と sendBeacon() のどちらを選択するかは、必要な機能とブラウザのサポートを考慮することが重要です。fetch() API の方がはるかに柔軟ですが、keepalive は sendBeacon() よりもブラウザのサポートが少なくなっています。

タグの役割を理解する

タグは、サードパーティ ベンダーが提供するガイダンスに沿って作成されることがよくあります。ベンダーのコードの動作が不明な場合は、詳しい人に尋ねることを検討してください。セカンド オピニオンを得ることで、タグがパフォーマンスやセキュリティの問題を引き起こす可能性があるかどうかを特定できます。

タグマネージャーでタグにオーナーのラベルを付けることをおすすめします。タグの所有者を忘れてしまい、何かを壊してしまうことを恐れて削除できないということがよくあります。

トリガー

大まかに言えば、タグトリガーの最適化とは、一般的に、タグを必要以上にトリガーしないようにすること、そしてビジネスニーズとパフォーマンス コストのバランスが取れたトリガーを選択することです。

トリガーは JavaScript コードであり、タグ マネージャーのサイズと実行コストを増加させます。ほとんどのトリガーは小さいものですが、累積効果が加算される可能性があります。たとえば、複数のクリック イベントやタイマー トリガーがあると、タグ マネージャーのワークロードが大幅に増加する可能性があります。

適切なトリガー イベントを選択する

タグがパフォーマンスに与える影響はさまざまです。一般に、タグが早く配信されるほど、パフォーマンスに大きな影響を与えます。通常、リソースは最初のページ読み込み時に制約されるため、特定のリソース(またはタグ)を読み込んだり実行したりすると、他のリソースが奪われます。

すべてのタグに適切なトリガーを選択することが重要ですが、大きなリソースを読み込むタグや長いスクリプトを実行するタグでは特に重要です。

タグは、ページビュー(通常は Page load、DOM Ready、Window Loaded)またはカスタム イベントに基づいてトリガーできます。ページの読み込みに影響しないように、重要でないタグは Window Loaded の後に呼び出します。

カスタム イベントを使用する

カスタム イベントを使用すると、Google タグ マネージャーの組み込みトリガーでは対応できないページ イベントに応じてトリガーを配信できます。たとえば、多くのタグではページビュー トリガーが使用されます。ただし、DOM Ready と Window Loaded の間の時間が長くなる可能性があるため、タグが配信されるタイミングを微調整することが難しくなります。カスタム イベントは、この問題の解決策となります。

まず、カスタム イベント トリガーを作成し、このトリガーを使用するようにタグを更新します。

Google タグ マネージャーのカスタム イベント トリガー

トリガーを配信するには、対応するイベントをデータレイヤーにプッシュします。

// Custom event trigger that fires after 2 seconds
setTimeout(() => {
  dataLayer.push({
    'event' : 'my-custom-event'
  });
}, 2000);

特定のトリガー条件を使用する

不要なタグの配信を避けるために、特定のトリガー条件を定義します。最も簡単で効果的な方法の一つは、タグが実際に使用されているページでのみタグを配信することです。

Google タグ マネージャーのトリガー条件

組み込み変数をトリガー条件に組み込んで、タグの配信を制限できます。

適切なタイミングでタグ マネージャーを読み込む

タグ マネージャー自体の読み込みタイミングを調整することで、パフォーマンスを改善できます。 トリガーは、設定方法に関係なく、タグ マネージャーが読み込まれるまで配信できません。タグ マネージャーを読み込むタイミングをテストします。これは、同等以上の影響を与える可能性があります。この決定は、ページ上のすべてのタグに影響します。

タグ マネージャーを後で読み込むことで、タグが誤って早期に読み込まれるのを防ぎ、将来のパフォーマンスの問題を回避できます。

変数

変数を使用してページからデータを読み取ります。変数を使用すると、トリガーやタグ自体で

トリガーと同様に、変数によって JavaScript コードがタグ マネージャーに追加されるため、パフォーマンスの問題が発生する可能性があります。変数は、URL、Cookie、データレイヤー、DOM の一部を読み取るコードなど、比較的小さいものにすることができます。また、無制限の機能(およびサイズ)を持つカスタム JavaScript を含めることもできます。

変数はタグ マネージャーによって継続的に評価されるため、変数の使用は最小限に抑えてください。使用されなくなった古い変数を削除して、タグ マネージャー スクリプトのサイズと処理時間を削減します。

タグ管理

タグを効率的に使用すると、パフォーマンスの問題が発生するリスクを軽減できます。

データレイヤーを使用する

データレイヤーは、ページに関する情報を含むオブジェクトの JavaScript 配列です。これらのオブジェクトには、Google タグ マネージャーに渡す情報がすべて含まれています。

データレイヤーは、タグをトリガーするためにも使用できます。

// Contents of the data layer
window.dataLayer = [{
    'pageCategory': 'signup',
    'visitorType': 'high-value'
  }];

// Pushing a variable to the data layer
window.dataLayer.push({'variable_name': 'variable_value'});

// Pushing an event to the data layer
window.dataLayer.push({'event': 'event_name'});

Google タグ マネージャーはデータレイヤーなしでも使用できますが、データレイヤーを使用することを強くおすすめします。データレイヤは、サードパーティ スクリプトがアクセスできるデータを 1 か所に統合するため、その使用状況をより明確に把握できます。これにより、冗長な変数計算やスクリプト実行を減らすことができます。

データレイヤーを使用すると、JavaScript 変数や DOM へのフルアクセスを許可するのではなく、タグがアクセスするデータを制御できます。

データレイヤーを更新すると、Google タグ マネージャーがすべてのコンテナ変数を再評価し、タグをトリガーする可能性があるため、JavaScript の実行が必要になります。このため、データレイヤーのパフォーマンス上のメリットは直感的にはわかりにくいかもしれません。データレイヤを誤用する可能性はありますが、一般的に、データレイヤがパフォーマンスの問題の原因であると思われる場合は、コンテナ自体にパフォーマンスの問題がある可能性があります。データレイヤを使用すると、これらの問題がより明確になります。

重複するタグや未使用のタグを削除する

タグがタグ マネージャーを介して挿入されるだけでなく、ページの HTML マークアップにも含まれている場合、タグが重複することがあります。

使用していないタグは、除外トリガーを使ってブロックするのではなく、一時停止または削除する必要があります。タグを一時停止または削除すると、コンテナからコードが削除されます。ブロックしてもコードは削除されません。

未使用のタグを削除したら、トリガーと変数を確認して、それらも削除できるかどうかを判断します。

一時停止したタグはコンテナサイズに影響しますが、ペイロードの合計はタグがアクティブな場合よりも小さくなります。

許可リストと拒否リストを使用する

許可リストと拒否リストを使用して、ページで許可されるタグ、トリガー、変数にきめ細かい制限を構成します。これは、パフォーマンスのベスト プラクティスやその他のポリシーを適用するために使用できます。

許可リストと拒否リストは、データレイヤを介して構成されます。

window.dataLayer = [{
  'gtm.allowlist': ['<id>', '<id>', ...],
  'gtm.blocklist': ['customScripts']
}];

たとえば、カスタム HTML タグ、JavaScript 変数、直接 DOM アクセスの使用を禁止できます。つまり、データレイヤのデータとともに使用できるのは、ピクセルと事前定義されたタグのみです。これは制限的ですが、タグ マネージャーの実装のパフォーマンスとセキュリティを向上させることができます。

サーバーサイド タグ設定の使用を検討する

特に、データをより詳細に管理したい大規模なサイトでは、サーバーサイド タグ設定への切り替えを検討することをおすすめします。サーバーサイド タグ設定では、クライアントからベンダーコードが削除され、処理がクライアントからサーバーにオフロードされます。

たとえば、クライアントサイドのタグ設定を使用する場合、複数のアナリティクス アカウントにデータを送信するには、クライアントがエンドポイントごとに個別のリクエストを開始する必要があります。サーバーサイド タグ設定では、クライアントからサーバーサイド コンテナに 1 つのリクエストが送信され、そこからこのデータがさまざまなアナリティクス アカウントに転送されます。

サーバーサイド タグ設定は、一部のタグでのみ機能します。タグの互換性はベンダーによって異なります。

詳しくは、サーバーサイド タグ設定の概要をご覧ください。

コンテナ

タグ マネージャーでは通常、設定内で複数のインスタンス(コンテナと呼ばれることが多い)を使用できます。1 つのタグ マネージャー アカウントで複数のコンテナを管理できます。

1 ページにつき 1 つのコンテナのみを使用する

1 つのページに複数のコンテナがあると、オーバーヘッドとスクリプトの実行が増えるため、パフォーマンスの問題が発生する可能性があります。少なくとも、コアタグコード自体が重複します。これはコンテナの JavaScript の一部として配信されるため、コンテナ間で再利用することはできません。

複数のコンテナが効果的に使用されることはまれです。ただし、適切に管理されていれば、これが機能する場合もあります。次に例を示します。

  • 1 つの大きなコンテナではなく、軽量の「早期読み込み」コンテナと、より重い「後読み込み」コンテナを含める。
  • 技術的な知識があまりないユーザーには制限付きのコンテナを使用し、複雑なタグには制限が少ないものの、より厳密に管理されたコンテナを使用する。

ページごとに複数のコンテナを使用する必要がある場合は、Google タグ マネージャーのガイダンスに沿って複数のコンテナを設定します。

必要に応じて別々のコンテナを使用する

ウェブアプリやモバイルアプリなど、複数のプロパティにタグ マネージャーを使用している場合、使用するコンテナの数によってワークフローの生産性が向上することもあれば、低下することもあります。また、パフォーマンスに影響する可能性もあります。

複数のサイトの用途と構造が類似している場合は、1 つのコンテナを複数のサイトで効果的に使用できます。たとえば、ブランドのモバイルアプリとウェブアプリが同様の機能を提供している場合でも、アプリの構造が異なる可能性が高いため、別々のコンテナで管理する方が効果的です。

1 つのコンテナを広範囲に再利用すると、タグとトリガーを管理する複雑なロジックが必要になり、コンテナの複雑さとサイズが増大する可能性があります。

コンテナサイズに注意する

コンテナのサイズは、タグ、トリガー、変数によって決まります。小さなコンテナでもページのパフォーマンスに悪影響を及ぼす可能性がありますが、大きなコンテナではほぼ確実に悪影響を及ぼします。

タグの使用を最適化する際に、コンテナサイズを最も重要な指標にするべきではありません。ただし、コンテナのサイズが大きい場合は、コンテナが適切に管理されておらず、誤用されている可能性があることを示す警告サインであることがよくあります。

Google タグ マネージャーでは、コンテナサイズが 300 KB に制限されており、サイズ上限の 70% に達するとコンテナサイズに関する警告が表示されます。

ほとんどのサイトでは、コンテナを制限よりも小さく保つことを目指す必要があります。比較のために、中央値のサイトコンテナは約 50 KB です。Google タグ マネージャー ライブラリ単体では、圧縮すると約 33 KB になります。

コンテナ バージョンに名前を付ける

コンテナ バージョンは、特定の時点におけるコンテナのコンテンツのスナップショットです。わかりやすい名前を使用し、意味のある変更の簡単な説明を含めることで、将来のパフォーマンスの問題をデバッグしやすくなります。

ワークフローにタグを付ける

タグの変更を管理して、ページのパフォーマンスに悪影響を与えないようにすることが重要です。

デプロイ前にテストする

デプロイ前にタグをテストして、パフォーマンスなどの問題をリリース前に検出します。

タグをテストする際の考慮事項は次のとおりです。

  • タグは正しく機能していますか?
  • タグによってレイアウト シフトが発生するかどうか。
  • タグはリソースを読み込みますか?これらのリソースのサイズはどのくらいですか?
  • タグが長時間実行されるスクリプトをトリガーしているか?

プレビュー モード

プレビュー モードを使用すると、タグの変更を一般に公開する前に、実際のサイトでテストできます。プレビュー モードには、タグに関する情報を提供するデバッグ コンソールが含まれています。

Google タグ マネージャーをプレビュー モードで実行すると、デバッグ コンソールに情報を表示するために追加のオーバーヘッドが必要になるため、実行時間が異なります(少し遅くなります)。したがって、プレビュー モードで収集されたウェブに関する主な指標の測定値を、本番環境で収集された測定値と比較することはおすすめしません。ただし、この不一致がタグ自体の実行動作に影響することはありません。

スタンドアロン テスト

タグをテストする別の方法として、テスト対象のタグが 1 つだけ含まれるコンテナを空のページに設定する方法があります。このテスト設定は現実的ではなく、一部の問題(タグがレイアウト シフトを引き起こすかどうかなど)を検出できません。ただし、スクリプトの実行などに対するタグの影響を分離して測定しやすくなります。Telegraph がこの分離アプローチを使用してサードパーティ コードのパフォーマンスを向上させている方法をご覧ください。

タグのパフォーマンスをモニタリングする

Google タグ マネージャーの Monitoring API を使用すると、特定のタグの実行時間に関する情報を収集できます。この情報は、選択したエンドポイントに報告されます。

詳細については、Google タグ マネージャー モニターの作成方法をご覧ください。

コンテナの変更に承認を必須にする

ファーストパーティ コードは通常、デプロイ前にレビューとテストを受けます。タグも同様に扱います。

これを行う方法の一つは、2 段階認証プロセスを追加することです。これにより、コンテナの変更に管理者の承認が必要になります。また、2 段階認証プロセスを必須にせず、変更を監視する場合は、コンテナ通知を設定して、選択したコンテナ イベントに関するメール通知アラートを受信できます。

タグの使用状況を定期的に監査する

タグを扱う際の課題の一つは、タグが時間の経過とともに蓄積される傾向があることです。タグは追加されますが、削除されることはほとんどありません。この傾向を逆転させる方法の一つは、タグを定期的に監査することです。これを行う理想的な頻度は、サイトのタグが更新される頻度によって異なります。

各タグにラベルを付けて所有者を明確にすることで、そのタグの責任者を簡単に特定し、そのタグがまだ必要かどうかを判断できます。

タグを監査する際は、トリガーと変数もクリーンアップしてください。また、パフォーマンスの問題の原因になることもよくあります。

詳しくは、サードパーティ スクリプトを管理するをご覧ください。