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

Core Web Vitals のタグとタグ マネージャーを最適化します。

タグはスニペット 通常はタグ マネージャーを介してサイトに挿入される第三者のコードです。 タグは、マーケティングや分析に最もよく使用されます。

タグとタグ マネージャーのパフォーマンスへの影響は、サイトによって大きく異なります。 タグ マネージャーはエンベロープのようなもので、タグ マネージャーには 何を入れて何をどのように使うかは、ほとんどが自分次第です。

この記事では、 パフォーマンスと 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 タグですベンダータグは機能によって 許可します。

ただし、タグの使用方法はパフォーマンスに大きく影響します。 あります。"Pixels"主にこのタグの性質上 高いパフォーマンスが 使用方法に厳密な制限があります。カスタム HTML タグは 必ずしもパフォーマンスに悪影響を及ぼしますが その自由度の高さから 悪用されると、パフォーマンスに悪影響が及ぶ可能性があります。

タグを検討する際はスケールを念頭に置きます 1 つのタグで処理される場合、ごくわずかな場合もありますが、数十、数百のタグが存在する場合、 タグが同じページ内で使用されている。

タグ マネージャーを使用してすべてのスクリプトを読み込む必要はありません

タグ マネージャーは一般に、リソースの読み込みに 視覚的または機能的な側面を即座に実装できる たとえば、Cookie に関する通知、ヒーロー画像、サイト機能などです。タグ マネージャーを使って リソースの読み込みは通常 配信が遅れますユーザーに悪影響を及ぼす LCP や CLS などの指標も向上できますさらに タグ マネージャーをブロックしているユーザーもいます。タグ マネージャーを使って UX を実装する 一部のユーザーにウェブサイトが壊れることがあります。

カスタム HTML タグの使用に関する注意事項

カスタム HTML タグ 何年も前から存在しており、ほとんどのサイトで頻繁に使用されています。カスタム HTML タグを使用すると、ほとんど制限なしで独自のコードを入力できます。名前に反して、 このタグの主な用途は、カスタム <script> 要素をページに追加することです。

カスタム HTML タグはさまざまな用途で使用でき、パフォーマンスに及ぼす影響 大きく異なります。サイトのパフォーマンスを測定する場合の注意点 ほとんどのツールで、カスタム HTML タグのパフォーマンスへの影響はタグに起因する 注入したクライアント マネージャーによって管理されます。

Google タグ マネージャーでカスタムタグを作成するスクリーンショット

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

  • ほとんどの場合、要素がページに挿入されると、ブラウザは ページ上の各アイテムのサイズと位置を再計算する必要があります。このプロセスは これは、 layout を使用します。 1 つのレイアウトがパフォーマンスに及ぼす影響は最小限であるが、 パフォーマンスの問題の原因になる可能性があります。このことが この現象は、ローエンドのデバイスや、 DOM 要素。
  • 表示可能なページ要素を DOM 内の周囲に配置された後に挿入すると、 レイアウト シフトを引き起こす可能性があります。この現象は ただし、タグは通常後で読み込まれるため、タグ マネージャーに固有のものではありません。 他の部分とは異なる場合、通常は 周囲のページがレンダリングされた後の DOM。
で確認できます。

カスタム テンプレートの使用を検討する

カスタム テンプレートのサポート カスタム HTML タグと同じ操作の一部。ただし、サンドボックスを基盤として構築されている という API を使って、 一般的な用途の API 一般的なユースケースの 1 つです名前のとおり 作成対象のテンプレート。これはパワーユーザーが 考えています技術的な知識があまりないユーザーでもテンプレートを使用できます。通常はこの方法のほうが安全です。 完全なカスタム HTML アクセス権を提供する場合よりも効率的です。

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

Google タグ マネージャーでカスタム テンプレートを使用するスクリーンショット

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

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

includeScript API を使用して既存のカスタム HTML を変換する方法: 詳細は、既存の タグ

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

  • ライブラリや大規模なサードパーティ スクリプトは、スクリプトタグで読み込む必要がある スクリプトの<script src="external-scripts.js"> 挿入します。<script> タグの使用は省略しているが スクリプトの内容をダウンロードするための個別のラウンドトリップが不要になります。 スクリプトがキャッシュされないようにして、コンテナのサイズを ブラウザによって個別に処理されます。
  • 多くのベンダーは、<script> タグをページの一番上に配置することを推奨しています。 <head>。ただし、タグ マネージャーで読み込まれるスクリプトの場合は、 通常は必要ありません。ほとんどの場合、ブラウザは処理を終了しています タグ マネージャーの実行時刻までに <head> を解析します。

ピクセルを使用する

状況によっては、第三者スクリプトを画像や iframe に置き換えることができる 「pixels」です。スクリプトベースのバージョンと異なり、ピクセルでは あまり好ましくない実装と思われがちです。 考えてみましょうタグ マネージャー内で使用すると、ピクセルをより動的に行うことができます。 さまざまな変数を渡すことができます。彼らは 高パフォーマンスかつ安全なタイプのタグです。タグの実装後は JavaScript が実行されないため、 トリガーされます。ピクセルのリソースサイズは非常に小さく(1 KB 未満)、 レイアウト シフトは発生しません。

サポートについて詳しくは、ご利用のサードパーティ プロバイダに ピクセルです。また、<noscript> タグがあるかどうかを調べることもできます。 ベンダーがピクセルをサポートしている場合、通常、ベンダーは <noscript> タグ。

Google タグ マネージャーのカスタム イメージタグのスクリーンショット

ピクセルに代わる方法

Google Pixel の人気が高まりました。その理由は、かつて Google Pixel は HTTP リクエストを行う最も信頼性の高い方法です。 (たとえば、データをアナリティクスに送信する場合) 。「 navigator.sendBeacon() および 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() 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() keepalivesendBeacon() が非常に似ているように見えるのは、 説明します。実際、Chromium ブラウザでは、sendBeacon()fetch() keepalive 上に構築されるようになりました。

fetch() keepalive または sendBeacon() を選択する場合は、次の点に留意してください。 必要な機能とブラウザ サポートを検討します。fetch() API は、 柔軟性が大幅に向上しますkeepalive のブラウザは少ないですが、 sendBeacon() よりサポート

詳細を確認する

多くの場合、タグは第三者ベンダーが提供するガイダンスに沿って作成されます。 ベンダーのコードが不明な場合は、知っている人に尋ねることを検討してください。 セカンド オピニオンを得ると、タグが生成する可能性があるかどうかを判断するのに役立つ セキュリティに関する問題を解決できます。

タグ マネージャーで所有者を使用してタグにラベルを付けることもおすすめします。遠い タグの所有者を忘れがちで、万が一に備えて削除するのを恐れなければなりません。

トリガー

大まかに言うと、最適化に関するタグ トリガー 通常は、必要以上にタグをトリガーすることと、 ビジネスニーズとパフォーマンス コストのバランスが取れたトリガーを選択する。

トリガー自体は、サイズと実行サイズを大きくする JavaScript コードである コストを抑えることができますほとんどのトリガーは小さいものの、累積の影響が 加算されますたとえば多数のクリック イベントやタイマー トリガーを使用すると、 タグ マネージャーの負荷が増加します

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

タグのパフォーマンスへの影響は固定ではありません。一般的に、 パフォーマンスへの影響は大きくなります通常、リソースには 制約があるため、ページ読み込み時や あるリソース(またはタグ)によって、リソースが別の場所から切り離されます。

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

タグは ページビュー (通常は Page loadDOM ReadyWindow Loaded)、または 作成できます。ページの読み込みに影響しないように、 Window Loaded より後の必須ではないタグ。

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

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

カスタム イベントを使用するには、まずカスタム イベント トリガーを作成してタグを更新します 指定する必要があります

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

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

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

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

特定のトリガー条件を指定することで、不必要なタグの配信を回避できます。 このコンセプトを適用する方法は多数ありますが、 タグが配信されるページでのみタグを配信し 見てみましょう。

Google タグ マネージャーのトリガー条件を示すスクリーンショット

組み込み変数でできること トリガー条件にも組み込めば、タグの配信を制限できます。

ただし、複雑なトリガー条件や例外を設定すると、 複雑になりすぎないようにします。

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

タグ マネージャー自体の読み込みタイミングを調整すると、 向上しますトリガーは、その設定にかかわらず、 タグ マネージャーが読み込まれた後に適切なトリガーを選択することは重要ですが、 上記のように、タグの読み込み時にテストします。 1 つのマネージャーが 同じかそれ以上の影響力を持つことは ページのすべてのタグに影響します

後でタグ マネージャーを読み込むと、管理性も高まるため、今後の タグ マネージャーのユーザーが誤って読み込まれることを防げるため、 タグが及ぼす影響に気づかないことです。

変数

変数を使用すると、ページからデータを読み取ることができます。これらはトリガーに役立ちます。また、 使用します。

トリガーと同様に、変数を設定すると JavaScript コードがタグ マネージャーに追加され、 パフォーマンスの問題が発生する可能性があります変数は比較的シンプルな組み込みと たとえば、URL、Cookie、データレイヤー、DOM の一部を読み取ることができるデータ型です。 または、実行できる処理に基本的に無制限のカスタム JavaScript を使用することもできます。

変数は評価が必要になるため、シンプルかつ最小限に留めます。 継続的に報告されます使用されなくなった古い変数を削除する タグ マネージャーのスクリプトのサイズを小さくして あります。

タグ管理

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

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

データレイヤーには、 Google タグ マネージャーに渡す必要があるすべての情報が含まれています。もっと見る 具体的には、JavaScript の配列であり、 表示されます。タグをトリガーするためにも使用できます。

// 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 か所にまとめることで、 使用状況を把握しやすくなります。特に、セキュリティ脅威の スクリプトの実行を自動化できます。データレイヤーを使用すると、 タグによってアクセスされるデータを制御するため、 変数や DOM アクセスを指定しています。

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

タグが重複するのは、ページの HTML マークアップに タグ マネージャーを介して挿入されます

未使用のタグは、 トリガー例外。 タグを一時停止または削除すると、コンテナからコードが削除されます。ブロックすることで できません。

未使用のタグを削除したら、トリガーと変数も削除する必要があります。 それらの関係者のみが使用したのであれば、削除できるかどうかを確認する できます。

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

許可リストと拒否リスト タグ、トリガー、メッセージに 表示できるようになります。これを使用して、パフォーマンスを最大限に高め、 その他のポリシーが適用されます。

許可リストと拒否リストはデータレイヤーを通じて設定される。

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

たとえば、カスタム HTML タグ、JavaScript ファイル、 直接 DOM アクセスする方法も学びます。これはピクセルと事前定義済みタグのみです データレイヤーのデータとともに使用できます。厳密に制限されますが パフォーマンスと安全性が大幅に向上します。

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

サーバーサイド タグ設定への切り替えは簡単ではありませんが、メリットはあります 特に、サイトの規模を細かく制御したい場合には、 できます。サーバーサイド タグ設定では、クライアントからベンダーコードが削除され、 クライアントからサーバーに処理をオフロードします。

たとえば、クライアントサイド タグ設定を使用している場合、データを複数のアナリティクスに送信する エンドポイントごとに個別のリクエストを開始します。 一方、サーバーサイド タグ設定では、クライアントによって そして、そのデータが別のサーバーに転送されて、 できます。

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

詳しくは、サーバーサイド メッセージの概要 タグ付けをご覧ください。

コンテナ

タグ マネージャーでは通常、複数のインスタンス(コンテナ)を使用できます。同じ あります。これにより、1 つのタグで複数のコンテナを制御できる クライアント センター(MCC)アカウント。

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

複数の コンテナ 同じページ上に配置すると パフォーマンス上の大きな問題が発生します スクリプトの実行時間が長くなります。少なくとも コンテナのコードの一部として提供されるため、 コンテナ間で再利用することはできません。

複数のコンテナを効果的に使用することはまれです。ただし、 適切に制御されていれば、次のような状況でもうまくいく可能性があります。

  • より軽い「早期読み込み」「後期負荷」が重く、container, おすすめします。
  • 技術的な知識のないユーザーのみが使用できる制限付きのコンテナを用意し、 使用できないタグを格納するコンテナです。制限が厳しく管理されています。 作成します。

1 つのページで複数のコンテナを使用する必要がある場合は、Google タグ マネージャーを使用します。 設定に関するガイダンスを コンテナをご覧ください。

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

複数のプロパティでタグ マネージャーを使用している場合(例: ウェブアプリと )- 使用するコンテナの数はワークフローの改善に役立つか、害になるか 向上しますまた、パフォーマンスに影響する可能性もあります。

一般的には、1 つのコンテナを複数のコンテナ間で効率的に使用できます。 サイトの使用と構造が類似している場合に、サイトが表示されます。たとえば、 モバイルアプリとウェブアプリが 似たような役割を果たす場合 アプリの構造が異なるため、より効果的に管理できるようになります。 個別にコンテナを使用します

1 つのコンテナの再利用の範囲を広げすぎると、一般的に不必要に増加する 複雑なロジックを採用しなければならず、コンテナの複雑さとサイズを タグとトリガーを管理できます

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

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

タグを最適化する際、コンテナサイズを方向性の指標として使用しない 使用状況コンテナのサイズが大きいと、コンテナに不具合が 適切に管理されておらず、悪用される可能性もあります。

Google タグ マネージャー 制限コンテナ 200 KB に引き上げられ、140 KB から始まるコンテナのサイズに関する警告が表示されます。ただし、 ほとんどのサイトでは、コンテナをこれよりはるかに小さく抑える必要があります。対象 サイトコンテナの中央値は約 50 KB です。

コンテナのサイズを特定するには、レスポンスのサイズを確認します。 https://www.googletagmanager.com/gtag/js?id=YOUR_ID から返されます。この レスポンスには Google タグ マネージャー ライブラリと されます。Google タグ マネージャーのライブラリ単独では約 33 KB です。 なります。

コンテナのバージョン名の設定

コンテナ バージョン 特定の時点におけるコンテナのコンテンツのスナップショットです。使用 わかりやすい名前とわかりやすい名前の 簡単な説明を添えて 将来のパフォーマンスのデバッグを 簡単に行えるようにします サポートします。

タグ設定ワークフロー

タグに変更が加えられることがないよう、変更内容を管理することは重要です。 パフォーマンスに悪影響を及ぼします

デプロイ前にタグをテストする

導入前にタグをテストすれば、問題(パフォーマンスや 配送されます。

タグをテストする際は、以下の点を考慮してください。

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

プレビュー モード

プレビュー モードでは、 実装することなく、実際のサイトでタグの変更をテストできる あります。プレビュー モードではデバッグ コンソールで、 確認しましょう。

Google タグ マネージャーの実行時間が異なる(やや遅い) これは、プレビュー モードで実行した場合です。 デバッグ コンソールで情報を確認します。Web Vitals の測定値を比較して プレビュー モードで収集したデータと本番環境で収集したデータは推奨されません。 ただし、この不一致がタグの実行動作に影響することはありません。 できます。

スタンドアロンのテスト

タグをテストする別の方法として、 単一のタグ(テストするタグ)を持つコンテナに作成されます。このテスト設定は タグによってレイアウトが原因であるかどうかなど、 とはいえ、クラウド インフラストラクチャがもたらす影響を スクリプトの実行などに タグを付ける必要がありますTelegraph がこれをどのように使用しているかをご覧ください。 分離アプローチを採用して、 パフォーマンス 不要です。

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

Google タグ マネージャーのモニタリング API を使用できます。 実行に関する情報を収集するため 時間 追跡しますこの情報は、 選択します。

詳細については、Google タグ マネージャーの構築方法{/1}をご覧ください モニタリング

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

ファースト パーティのコードは通常、デプロイ前にレビューとテストを受けます。 タグは同じものとして扱えます2 段階の追加 オーナー確認 コンテナの変更には管理者の承認が必要ですが、 できます。または、2 段階認証プロセスを必須ではなく、 引き続き変更を監視したい場合は、コンテナ 通知を 選択したコンテナ イベントに関するメール通知アラートを受信できます。

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

タグを使用する場合の課題の 1 つは 時間: タグは追加されますが、削除されることはほとんどありません。タグを定期的に監査することが この傾向を反転させる方法ですこれを行う理想的な頻度は、 サイトのタグが頻繁に更新されます

所有者がわかりやすいように各タグにラベルを付けると、誰が誰なのかを簡単に識別できます。 そのタグに対する応答があり、まだ必要かどうかを判断できます。

タグを監査する際は、必ずトリガーと変数をクリーンアップし、 ありますこれらもパフォーマンスの問題の原因になりやすいです。

詳しくは、サードパーティ スクリプトを 。