blog

【WordPress高速化⑦】Googleタグマネージャーを遅延させて初速を上げる

Googleタグマネージャー（GTM）を遅延させ、計測を保ったまま初期表示を速くする方法を解説します。

WordPress で GTM を遅延読み込みする完全ガイド：仕組み・実装・計測まで

「GTM を入れたら PageSpeed Insights のスコアが下がった」「サードパーティスクリプトを削れと言われるが、タグは外せない」——この悩みを抱える WordPress 運用者は多い。Google Tag Manager はひとつのスクリプトでありながら、配下に GA4・Microsoft Clarity・広告ピクセルなどを芋づる式にロードする”スクリプトの親”だ。そのため遅延読み込みの効果が他のスクリプト最適化とは一桁違う場合がある。

この記事について

本記事は、自社サイト crystal-method.com（WordPress運用） で実際に表示速度を改善した一次データに基づきます（GTM等の計測タグをload後に遅延し、モバイルの全リソース読み込み完了(load)を 6,296ms→1,556ms(Ubersuggest読み込み時間でも 7.29秒→2.03秒)に短縮。Google Chrome + Puppeteer／モバイル相当スロットル・5回中央値）。
発行：クリスタルメソッド株式会社（代表取締役 河合 継）　｜　運営会社　｜　編集方針

実際、当サイト crystal-method.com でモバイルの load イベントを計測したところ、GTM を load イベント後 +0.5 秒に遅延させるだけで 6,296ms → 1,556ms（▲75%）・総転送量 571KB → 160KB（▲72%） という結果を得た（Slow 4G + CPU 4x スロットリング、5 回計測の中央値）。本記事ではその仕組みから具体的な実装コード、計測方法まで一気通貫で解説する。

そもそも「遅延読み込み」とは何か

ブラウザはHTMLを上から順に解析し、<script> タグに出会うとスクリプトのダウンロードと実行が終わるまでレンダリングを止める。これをレンダーブロッキングという。GTM のスニペットは通常 <head> 直後に設置するよう推奨されているため、ページの最初期にブラウザリソースを占有する。

遅延読み込みとは、このスクリプトのロードタイミングをページの重要コンテンツが表示された後まで意図的に後ろへずらす手法だ。大きく次の 3 段階に分けられる。

① defer / async 属性
HTML パース完了後または非同期で実行。GTM 公式スニペットには既に適用済み。効果は限定的。
→
② イベントトリガー遅延
load・DOMContentLoaded・インタラクション（scroll/click）を検知してから script タグを DOM に挿入。
→
③ タイマー遅延
load 後に setTimeout で数百ms〜数秒待機。ブラウザが描画完了を安定させてから GTM を起動する。

GTM の場合、配下のタグが多いほど② + ③の組み合わせが最も効果的だ。① だけでは GTM 本体は遅れても配下タグのリクエストは load 前後に集中したまま変わらない。

遅延させると何が改善されるのか：指標ごとの整理

PageSpeed Insights や Lighthouse が報告する「サードパーティコードの影響を排除してください」という警告は、ほぼ GTM 経由のスクリプト群を指している。遅延処理で改善が見込める指標と、そうでない指標をまず整理しておこう。

指標 遅延で改善？ 理由
FCP（First Contentful Paint） △ やや改善 GTM が head 内で同期ブロックしている場合は改善。async 設置済みなら効果は小さい。
LCP（Largest Contentful Paint） ◎ 大きく改善 GTM 配下のスクリプトがメインスレッドを圧迫している場合、LCP 遅延の主因になる。
TBT（Total Blocking Time） ◎ 大きく改善 GTM 本体＋配下タグの JS 実行がメインスレッドを長時間ブロックするため。
CLS（Cumulative Layout Shift） ○ 改善することがある 広告タグや A/B テストタグが遅延するとレイアウトシフトが減少する場合。
load イベント（ms） ◎ 劇的改善 GTM 配下の全リクエストが load 後に移動するため転送量・時間ともに激減。
Ubersuggest・GTmetrix の速度スコア ◎ 改善 これらのツールは内部的に load 時間を主要指標として使うケースが多い。

重要な注意点として、Ubersuggest などの外部ツールが表示するスコアは FCP ではなく load イベントを参照することが多い。そのため、Lighthouse の Core Web Vitals スコアがあまり変わらなくても、外部ツールのスコアが大きく向上するケースは多い。crystal-method.com での計測でも、load 時間の劇的な短縮が外部ツールのスコア改善に直結した。

GTM 遅延読み込みの実装方法：コード解説

基本構造：dataLayer の即時初期化が必須

ここで多くの開発者がはまる落とし穴がある。GTM 本体を遅延させると、GTM がロードされる前にページ内の他のスクリプトが window.dataLayer.push() を呼ぶとエラーになる。

対策は dataLayer 配列だけを即時に初期化し、GTM 本体は遅延させることだ。この 2 行を先行して <head> 内に書くだけでエラーを防げる。

window.dataLayer = window.dataLayer || [];
window.dataLayer.push({'gtm.start': new Date().getTime(), event: 'gtm.js'});

GTM はロード時に dataLayer 配列が存在することを期待する。配列自体は即時に確保しておき、実際の GTM スクリプトだけを遅らせる、というのが正しいアプローチだ。

実装コード：load + setTimeout による遅延

以下が crystal-method.com で実際に採用しているパターンだ。load イベント完了後、さらに 500ms 待ってから GTM スニペットを動的挿入する。

<!-- GTM dataLayer 即時初期化（head 内の最初期に配置） -->
<script>
  window.dataLayer = window.dataLayer || [];
  window.dataLayer.push({'gtm.start': new Date().getTime(), event: 'gtm.js'});
</script>

<!-- GTM 本体を load+500ms 後に遅延ロード -->
<script>
  (function() {
    function loadGTM() {
      setTimeout(function() {
        var s = document.createElement('script');
        s.src = 'https://www.googletagmanager.com/gtm.js?id=GTM-XXXXXXX';
        s.async = true;
        document.head.appendChild(s);
      }, 500);
    }

    if (document.readyState === 'complete') {
      // すでに load 済みの場合（キャッシュ等）
      loadGTM();
    } else {
      window.addEventListener('load', loadGTM);
    }
  })();
</script>

GTM-XXXXXXX の部分は自分の GTM コンテナ ID に置き換える。

WordPress への組み込み方

WordPress に上記コードを組み込む方法は主に 3 つある。

方法 難易度 メリット デメリット
functions.php に wp_head フック 中 プラグイン不要。テーマ管理で完結。 テーマ更新で上書きリスク。子テーマ推奨。
Code Snippets プラグイン 低 GUI で管理。テーマ更新の影響なし。 プラグイン追加になる。
カスタム HTML プラグイン（Header Footer Code Manager 等） 低 コーディング不要に近い。ページ別制御も可。 プラグイン追加。出力位置の制御に注意。

functions.php を使う場合の例

// 子テーマの functions.php に追記
function cm_gtm_delayed_load() {
  ?>
  <script>
    window.dataLayer = window.dataLayer || [];
    window.dataLayer.push({'gtm.start': new Date().getTime(), event: 'gtm.js'});
  </script>
  <script>
    (function() {
      function loadGTM() {
        setTimeout(function() {
          var s = document.createElement('script');
          s.src = 'https://www.googletagmanager.com/gtm.js?id=GTM-XXXXXXX';
          s.async = true;
          document.head.appendChild(s);
        }, 500);
      }
      if (document.readyState === 'complete') {
        loadGTM();
      } else {
        window.addEventListener('load', loadGTM);
      }
    })();
  </script>

add_action の第 3 引数を 1（優先度最高）にすることで、他のプラグインが head に出力するスクリプトより前に dataLayer の初期化が走るようにしている点がポイントだ。

noscript タグの扱い

GTM 公式スニペットには <body> 直後に置く <noscript><iframe> タグも含まれる。JS 無効環境用のフォールバックだが、現代のトラッキングへの影響は限定的だ。遅延実装と併せて以下のように <body> 直後に静的に残しておけばよい。

<noscript><iframe src="https://www.googletagmanager.com/ns.html?id=GTM-XXXXXXX"
height="0" width="0" style="display:none;visibility:hidden"></iframe></noscript>

遅延時間の設定：500ms が適切な理由

遅延時間をどれだけ取るかは「速度改善の最大化」と「計測精度の確保」のバランスで決まる。

0ms（即時）
改善効果なし。通常設置と同じ
→
500ms（推奨）
load 後のブラウザ描画安定後に起動。計測ロスも最小
→
3,000ms〜
直帰ユーザーの計測が困難に。GA4 のセッション精度が落ちる

500ms という数字の根拠は、load イベント後にブラウザが Paint・Composite など後処理を終えるまでの一般的な余裕時間だ。これより長くすると、ページを素早く閉じるユーザーが GTM ロード前に離脱してしまい、GA4 の直帰率やセッション数の計測に影響が出る。

インタラクション（scroll・click・mousemove）をトリガーにする方法もある。しかしこの場合、ページを開いてすぐ閉じるユーザーは一切計測されないというリスクが生じる。GA4 のコンバージョン計測を重視するサイトでは load + setTimeout 方式の方が安全だ。

GTM コンテナ内でのタグ最適化：遅延だけでは不十分なケース

GTM 本体を遅延させるだけで十分な改善が得られることが多いが、コンテナ内のタグ設定も最適化するとさらに効果が上がる。

タグの発火タイミングを見直す

GTM 管理画面では各タグに「発火タイミング（Firing Priority）」を設定できる。特に以下の設定を確認しよう。

  • GA4 設定タグ： "All Pages" トリガーで即時発火が多いが、Window Loaded イベントをトリガーにしてもページビュー計測は問題ない。
  • リマーケティングタグ・広告ピクセル： コンバージョンが発生するページのみに限定する。全ページに発火させると不要なリクエストが増える。
  • Clarity・ホットジャー等のヒートマップ： セッション記録なので DOM Ready 以降でよい。Page View より遅らせてもデータ品質に影響はほぼない。

タグの数を棚卸しする

GTM コンテナは長く使うとゾンビタグ（使われていないが残っているタグ）が蓄積する。crystal-method.com の運用でも、棚卸し前は 12 タグが稼働していたが、精査すると 5 タグで同等の計測が実現できた。タグ数が半分以下になればリクエスト数も比例して減る。

GTM 管理画面の「バージョン」機能で変更前のスナップショットを残してから削除するのが安全だ。

計測方法：正しい比較で効果を確認する

計測環境を統一する

速度改善の効果を正しく評価するには、計測条件を固定することが最も重要だ。特にモバイル端末の回線・CPU 性能は結果を大きく左右する。

項目 推奨設定 理由
ネットワーク Slow 4G（下り 1.6Mbps / 上り 0.75Mbps / RTT 150ms） 日本のモバイル中間層を模擬。差異が大きく出て比較しやすい。
CPU スロットリング 4x slowdown 中位〜低位 Android 端末を模擬。JS 実行時間の差が顕在化する。
計測回数 5 回以上の中央値 1〜2 回では外れ値の影響が大きい。平均値でなく中央値で比較する。
キャッシュ 毎回シークレットウィンドウ or キャッシュ無効化 ブラウザキャッシュが残ると正確な初回訪問を計測できない。

crystal-method.com の計測では Chrome DevTools の Network タブで「Slow 4G」「CPU 4x throttling」を固定し、シークレットウィンドウで 5 回ずつリロードして中央値を取った。この条件で load イベントが 6,296ms → 1,556ms と計測された。

何を見るべきか：load vs Core Web Vitals

Chrome DevTools の Network タブ下部には DOMContentLoaded と Load の 2 つの時間が表示される。GTM 遅延の効果確認には Load 時間と総転送量（Transferred） を見るのが直接的だ。

PageSpeed Insights（Lighthouse）の Core Web Vitals は LCP・TBT の改善として現れるが、変化が小さく見えることもある。これは Lighthouse が Labs データ（合成計測）を基にしており、GTM 遅延の効果が FCP ではなく load 後の処理時間に集中するためだ。外部ツールのスコアが大きく改善しているなら、それは実際のユーザー体験の改善と捉えてよい。

注意点とトラブルシューティング

よくある問題と対処法

問題 原因 対処
GTM Preview モードが動かない GTM のデバッグスクリプトが遅延に対応できていない Preview 時は遅延を無効にする条件分岐を追加するか、通常モードで確認後に遅延設定を適用する。
dataLayer.push is not a function エラー GTM より先に別スクリプトが dataLayer.push を呼んだが、dataLayer が未定義だった dataLayer 即時初期化のコードが GTM 本体より前に読み込まれているか確認。wp_head の優先度を 1 に設定。
GA4 のセッション数が減少した 遅延時間が長すぎて直帰ユーザーが計測されない setTimeout の値を 500ms 以下に縮小。3,000ms 以上は避ける。
特定ページでコンバージョンが計測されない サンクスページへのリダイレクトが GTM ロード前に発生している リダイレクト処理を見直す。または遅延なしの別コンバージョン計測手段（GA4 直接タグ）を検討。
WP Rocket や LiteSpeed Cache と競合 キャッシュプラグインが独自の遅延処理を適用し二重遅延になる キャッシュプラグイン側の GTM 遅延設定をオフにし、本記事のカスタムコードに一本化する。

キャッシュプラグインとの関係

WP Rocket には「Google Tag Manager の遅延読み込み」機能が組み込まれている。しかしデフォルト設定ではインタラクション（ユーザー操作）トリガーになっており、直帰ユーザーの計測精度が落ちるリスクがある。WP Rocket を使う場合も、GTM 遅延は本記事のカスタムコードで管理し、WP Rocket 側では GTM スクリプトを「除外リスト」に入れる方が制御しやすい。

実装後のチェックリスト

  1. Chrome DevTools でページをリロードし、Network タブで gtm.js のリクエストが load イベント（赤い縦線）より後に来ていることを確認する。
  2. GTM Preview モードで主要タグが発火しているかを確認する。
  3. GA4 リアルタイムレポートでページビューが計測されることを確認する。
  4. Slow 4G + CPU 4x で 5 回計測し、load 時間の中央値を記録・比較する。
  5. コンバージョンが発生するフォームや購入完了ページで、コンバージョン計測が正常に動作することを確認する。
  6. モバイルとデスクトップの両方でスクロール・クリック系のトリガーが期待通りに発火しているかを確認する。
GTM 配下のスクリプトを遅延最適化するイメージ：dataLayer・load・setTimeout などのキーワードが浮かび上がる
GTM 配下のスクリプトを遅延最適化するイメージ：dataLayer・load・setTimeout などのキーワードが浮かび上がる

実測エビデンス：自社サイトのUbersuggest計測（改善前→改善後）

GTM（タグマネージャー）の遅延読み込みを含む一連の最適化により、第三者ツールUbersuggestの「読み込み時間」も実際に改善しました（2026年6月時点・自社サイト crystal-method.com／モバイルは過去28日間の実ユーザー体験ベース）。

改善前：Ubersuggestモバイル読み込み時間 7.29秒（「悪い」判定）
改善前：Ubersuggestモバイル読み込み時間 7.29秒（「悪い」判定）
改善後：Ubersuggestモバイル読み込み時間 2.03秒（「良」判定）
改善後：Ubersuggestモバイル読み込み時間 2.03秒（「良」判定）
改善後：Ubersuggestデスクトップ読み込み時間 0.57秒（「良」判定）
改善後：Ubersuggestデスクトップ読み込み時間 0.57秒（「良」判定）

まとめ

WordPress での GTM 遅延読み込みは、サードパーティスクリプトによる表示速度低下に対処する最もコスパの高い施策のひとつだ。要点を整理しよう。

  • dataLayer の即時初期化 と GTM 本体の遅延挿入 は必ずセットで行う。GTM だけを遅らせると他スクリプトの dataLayer.push がエラーになる。
  • 遅延タイミングは load イベント後 + setTimeout(fn, 500) が速度改善と計測精度のバランスを取りやすい。
  • 計測は Slow 4G + CPU 4x スロットリング、5 回の中央値 で行う。Ubersuggest 等の外部ツールは FCP でなく load 時間を見ている場合が多い。
  • GTM コンテナ内のタグ棚卸し・発火タイミング見直しも並行して行うと効果が倍増する。
  • WP Rocket などのキャッシュプラグインの GTM 遅延機能と競合しないよう、設定を一本化する。

GTM の遅延設定はコード量も少なく、リバートも容易だ。「まず計測 → 実装 → 再計測」という順序で進めれば、リスクを最小化しながら確実な改善効果を得られる。

関連記事

AIブログ購読

　
クリスタルメソッドがお届けする
AIブログの更新通知を受け取る

Study about AI

AIについて学ぶ

  • Claude Code 公式ドキュメント完全読解ガイド｜導入判断から運用まで

    Claude Code 公式ドキュメント完全読解ガイド｜導入判断から運用まで

    監修 河合 継（クリスタルメソッド株式会社 代表取締役） AI・ディープラーニングに関する特許16件の発明者。国立がん研究センターとの共同研究や、テレビ番組での...

  • Claude Code ベストプラクティス完全解説｜実装現場で使える設計指針2026

    Claude Code ベストプラクティス完全解説｜実装現場で使える設計指針2026

    監修 河合 継（クリスタルメソッド株式会社 代表取締役） AI・ディープラーニングに関する特許16件の発明者。国立がん研究センターとの共同研究や、テレビ番組での...

  • Claude Code 自動化の実装ガイド――設計・事例・セキュリティを徹底解説

    Claude Code 自動化の実装ガイド――設計・事例・セキュリティを徹底解説

    監修 河合 継（クリスタルメソッド株式会社 代表取締役） AI・ディープラーニングに関する特許16件の発明者。国立がん研究センターとの共同研究や、テレビ番組での...

View more

AIで、業務の生産性を変革しませんか？

無料デモ・資料請求は1分で完了。お気軽にお問い合わせください。

無料デモを試す お問い合わせ