このページは Cloud Translation API によって翻訳されました。

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

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

Katie Hempenius

Barry Pollard

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

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

この記事では、パフォーマンスと 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 はこれと同じユースケースに対応するように設計されているが、信頼性は間違いなく向上しているなります。

注: sendBeacon() API と fetch() keepalive API は、ブラウザがページをアンロードしている状況でも機能します。たとえば、この両方の API を使用してアウトバウンドリンクのクリックをトラッキングできます。一方、ピクセルや XMLHttpRequest などの手法はこのようなケースでは失敗する可能性が高くなります。

ピクセルの使用を継続しても問題はありません。ピクセルは適切にサポートされており、パフォーマンスへの影響が最小限に抑えられますただし独自のビーコンを構築する場合はこれらの 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() 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 タグマネージャーのトリガー条件を示すスクリーンショット

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

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

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

タグマネージャー自体の読み込みタイミングを調整すると、向上しますトリガーは、その設定にかかわらず、タグマネージャーが読み込まれた後に適切なトリガーを選択することは重要ですが、上記のように、タグの読み込み時にテストします。 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 つは時間: タグは追加されますが、削除されることはほとんどありません。タグを定期的に監査することがこの傾向を反転させる方法ですこれを行う理想的な頻度は、サイトのタグが頻繁に更新されます

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

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

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