アナリティクスとトラッキングスクリプトを制限すべき理由

アナリティクスとトラッキングスクリプトを制限すべき理由

私は多くの時間をウェブサイトの監査に費やしていますが、その監査の約90%で、使用されていないトラッキングスクリプトを発見します。誰も追加したことを覚えていないスクリプト、誰も読まないデータを追跡するスクリプト、2年前にマーケティング部門が追加した「もう1つのピクセル」などです。追加された当時はそれぞれ無害に思えたでしょう。しかし、それらが合わさることで、すべてのページの読み込みに数秒の遅れが生じます。

Kasperskyの2024年ウェブトラッキングレポートによると、平均的なウェブサイトには現在48個のトラッカーが存在します。2025年のWeb Almanacでは、90%以上のウェブページに少なくとも1つのサードパーティが含まれており、最も訪問者の多い上位1,000サイトでは、デスクトップ上で中央値129のサードパーティリクエストが発生していることが示されています。これはトラッキング戦略ではありません。パフォーマンスの問題です。

最終レビュー: 2026年3月 Arjen Karel

なぜサイトはアナリティクスとトラッキングスクリプトを使用するのか

アナリティクスとトラッキングスクリプトは実際の目的を果たしています。Googleアナリティクスは訪問者がどこから来たかを教えてくれます。Facebook Pixelは広告のコンバージョンを追跡します。Hotjarは人々がどこをクリックしたかを示します。これらのデータがなければ、推測に頼るしかありません。

問題は、これらのツールが存在することではありません。問題は、ほとんどのサイトが必要以上のトラッキングを読み込んでいることです。Googleアナリティクス、Facebook Pixel、Cloudflareアナリティクスのような人気のあるツールはすべて、JavaScript、Cookie、およびHTTPリクエストを追加します。そして、これらがページ上の唯一のトラッキングであることは稀です。

事実: すべての監査の約90%で、使用されていないトラッキングスクリプトが見つかります。通常、これらのスクリプトは、タグマネージャーや他のサードパーティスクリプトを介して遅れて挿入されます。

これらのスクリプトはどのくらい重いのか？

すべてのトラッキングスクリプトが同じように作られているわけではありません。最も一般的なスクリプトが実際にどれだけのコストをかけているかは次のとおりです。

• Google Analytics 4 (gtag.js): 圧縮時134 KB、非圧縮時371 KB。非同期で読み込まれるためレンダリングをブロックしませんが、JavaScriptは依然としてメインスレッドで解析および実行される必要があります。
• Google Tag Manager: ライブラリ自体は圧縮時約33 KBですが、さらにその中に配置したタグが加わります。中央値のコンテナは約50 KBです。空のGTMコンテナでも約100msの遅延が追加されます。GTM内に8つのトラッキングタグがあると、Fast 3Gで約3秒、Slow 3Gで10秒の遅延が追加されます。
• Facebook/Meta Pixel: 非圧縮時340 KB (圧縮時95 KB)。これはGoogleアナリティクスの7倍の大きさです。完了するまでに4つのHTTPリクエストを行い、すべてのページの読み込みに1.3〜1.5秒を追加します。
• 同意管理プラットフォーム (Consent Management Platforms): OneTrustは、設定によって124〜347 KBを追加する可能性があります。あるケースでは、同意バナーがLCP要素となり、LCPが1.43秒から3.61秒に増加しました。

GA4 + GTM + Facebook Pixel + 同意バナーを積み重ねると、独自のコードが実行される前に、約400〜600 KBのトラッキングJavaScriptが存在することになります。これは、ページコンテンツ全体よりも多いことがよくあります。

トラッキングスクリプトがCore Web Vitalsに与える影響

Largest Contentful Paint

すべてのスクリプトは、ページの読み込み中にネットワーク帯域幅とCPU時間を競い合います。非同期スクリプトであっても、LCP画像やクリティカルCSSに使用できる帯域幅を消費します。ヒーロー画像と一緒に8つのトラッキングスクリプトを読み込むと、限られたモバイル帯域幅をそれらすべてで共有するようにブラウザに強制することになります。

これはモバイルネットワークで特に悪影響を及ぼします。2025年のWeb Almanacでは、モバイルのTotal Blocking Timeの中央値が1,916ms (2024年から58%増加) であると報告されています。そのブロックの多くはサードパーティのJavaScriptによるものです。スクリプトを遅延させることはできますが、読み込みが開始されると、依然としてリソースを競合します。

Interaction to Next Paint

Interaction to Next Paint (INP)は、トラッキングスクリプトが最も被害をもたらす指標です。2024年のWeb Almanacでは、プレゼンテーションの遅延がINP悪化の主な要因であり、それを引き起こしているスクリプトは、行動トラッキングツール、同意プロバイダー、および広告ピクセルであることが判明しました。

多くのトラッキングスクリプトは、ページの読み込みが完了した後も長く機能し続けます。Googleアナリティクスは、すべてのクリックを追跡するように設定できます。Hotjarのようなヒートマップツールは、すべてのマウスの動きを監視します。これらのイベントリスナーのそれぞれが、ユーザーインタラクションの処理時間を増加させます。訪問者がボタンをクリックし、コードがそれを処理するのに50msかかると同時に、3つのトラッキングスクリプトもイベントリスナーを発火させ、さらに150ms追加されると、インタラクションが遅く感じられます。

数字が物語っています。モバイルページの77%がINPに合格していますが、最も訪問者の多い上位1,000サイトではわずか53%しか合格していません。これらの上位サイトには、より複雑なJavaScriptとより多くのサードパーティスクリプトが含まれています。ページを応答性の高い状態に保ちたい場合、トラッキングスクリプトは最初に見直すべきポイントです。

Time to First ByteとCookieのオーバーヘッド

各トラッキングスクリプトは、独自のCookieを配置できます。個々のCookieは小さい ( 2025年のWeb AlmanacのCookieの章によると中央値は40バイト) ですが、CookieデータはHTTPリクエストごとに送信されるため、それらの全体的な影響は蓄積されます。サイトが4 KBのCookieを設定し、39のリソースを読み込む場合、それらのリクエスト全体で156 KBの余分なアップロードデータが発生します。

Cookieの合計データが約1,500バイトを超えると、リクエストヘッダーが単一のTCPパケットに収まらなくなります。これにより余分なラウンドトリップが発生し、その後のナビゲーションや静的リソースの読み込みにおけるTime to First Byteが直接増加します。

Cumulative Layout Shift

同意バナーはここで最も悪影響を及ぼす要素です。Cookie同意バナーが遅れてレンダリングされ、ページコンテンツを押し下げると、レイアウトシフトが発生します。一部の同意プラットフォームは、ページをリフローさせる大きなDOMツリー (200以上のノード) を注入します。記録されたあるケースでは、同意バナーが実際のコンテンツの上にレンダリングされたため、ページビューの50%でLCP要素となっていました。

よりスマートなトラッキングのための戦略

実際に使用しているものを監査する

タグマネージャーを開き、すべてのタグを1つずつ確認してください。それぞれのタグについて、「誰がこのデータを読んでいるか？」「最後に確認されたのはいつか？」と尋ねてみてください。誰も答えられない場合は、それを削除します。数ヶ月前に終了したキャンペーンのA/Bテストツールのタグ、会社がもはや使用していない広告プラットフォームのピクセル、重複したアナリティクスの実装 (GTM経由のGA4とハードコードされたgtag.jsの両方) などを定期的に発見します。

必須ではないスクリプトを遅延させる

すべてをページビュー時に読み込む必要はありません。ヒートマップスクリプトの記録開始に3秒かかったからといって、がっかりする人は誰もいません。アナリティクスやトラッキングタグは、Window Loadedイベントで発火させるか、さらに良い方法として、ユーザーがページとインタラクションするまでそれらを遅延させます。AnalyticsManiaのテストでは、ページ読み込みの1.5秒後にタグの発火を遅らせることで、Slow 3Gで6秒節約できることが示されました。

// 初回のユーザーインタラクション後にのみアナリティクスを読み込む
const events = ['click', 'scroll', 'mousemove', 'touchstart'];
const loadAnalytics = () => {
    events.forEach(e => document.removeEventListener(e, loadAnalytics));
    // ここにアナリティクススクリプトを読み込む
    const script = document.createElement('script');
    script.src = 'https://www.googletagmanager.com/gtag/js?id=G-XXXXXXX';
    document.head.appendChild(script);
};
events.forEach(e => document.addEventListener(e, loadAnalytics, {once: true}));

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

カスタムのアナリティクスイベント (フォームの送信、ボタンのクリック、スクロールの深さ) を送信する場合は、XMLHttpRequestの代わりにnavigator.sendBeacon()を使用してください。Beacon APIは、メインスレッドをブロックすることなく非同期にデータを送信し、ページナビゲーション中であっても確実に完了します。これは特に、アナリティクスコールをトリガーするインタラクションにおいてINPを低く保つために重要です。

// インタラクションをブロックせずにアナリティクスデータを送信する
document.querySelector('.buy-button').addEventListener('click', (e) => {
    // sendBeaconを使用 - 非ブロッキング、ページナビゲーション後も残存
    navigator.sendBeacon('/analytics', JSON.stringify({
        event: 'purchase_click',
        timestamp: Date.now()
    }));
});

サーバーサイドの代替案を検討する

トラッキングJavaScriptを排除する最も効果的な方法は、それをまったく読み込まないことです。Cloudflare Zarazは、アナリティクスの実行をエッジに移動し、クライアントサイドのタグマネージャースクリプトを軽量のビーコンに置き換えます。GTMサーバーサイドコンテナを使用すると、ベンダーのJavaScriptをブラウザに到達させることなく、サーバーからアナリティクスプロバイダーにデータを転送できます。これらのアプローチは設定に手間がかかりますが、パフォーマンスへの影響はほぼゼロです。

よりシンプルなニーズには、Plausible (1 KB未満) やUmami (約2 KB) のような軽量の代替手段が、GA4の134 KBのコストのほんのわずかなコストでトラフィックアナリティクスを提供します。

理想的な状態とは

CoreDashで監視されているサイト全体で、サードパーティスクリプトの読み込みが5つ未満のページは、約88%がINPに合格していますが、15以上のスクリプトを読み込むページでは64%です。LCPの違いも同様に明白です。競合するリクエストが少ないということは、ブラウザが訪問者にとって実際に重要なものを優先できることを意味します。

すべてのトラッキングを削除する必要はありません。何を読み込むか、いつ読み込むか、そして誰もそのデータを実際に使用しているかどうかについて、意図的になる必要があります。まずはタグマネージャーの監査から始めましょう。必要のないものは削除します。必要なものは遅延させます。RUMを使用してフィールドデータの改善を検証してください。ラボテストでは、トラッキングスクリプトが実際のネットワーク状況や実際のユーザー行動とどのように相互作用するかという全体像を把握できないためです。