アクセス解析タグは意外と重い｜計測タグを「読み込み完了後」に回した話

計測タグ本体は、gzip後186KBありました

Googleアナリティクスを導入するとき、管理画面から数行のコードを渡され、「これをサイトに貼ってください」と案内されます。貼るコード自体は短いので、軽い作業に見えます。

ですが、あの数行は「本体を呼びに行くための呼び鈴」です。訪問者がページを開くたび、そのブラウザはGoogleのサーバーから計測プログラムの本体（gtag.jsというファイル）をダウンロードします。当社が自社サイトで実測したところ、この本体はgzip圧縮された転送時点で約186KBありました。

186KBがどれくらいかというと、当社サイトは日本語Webフォントを撤去する改善を経て、ページ全体を大きく軽量化してあります。文章中心のページなら、本文・スタイル・ロゴを合わせたよりも計測タグ1本の方が重い、ということが普通に起こる量です。

なぜ重さが問題になるのか

回線には、同時に流せるデータ量（帯域）の上限があります。特にスマートフォンの移動中の回線では、この上限が体感を直接左右します。

ページを開いた直後は、本文・スタイル・画像といった「見えるもの」を運ぶ通信が集中する時間帯です。ここに計測タグの186KBが割り込むと、表示に使えたはずの帯域の一部を、画面に何も映さない計測プログラムが使うことになります。

計測タグは訪問者に何も見せません。それ自体は悪いことではなく、裏方の仕事とはそういうものです。ただ、裏方が主役より先に舞台へ出て通路をふさぐ必要はない。当社はそう考えました。

標準の貼り方で何が起きているか

Googleが案内する標準のコードは、async（非同期）という指定つきでhead内に置かれます。asyncは「ダウンロード中もページの組み立てを止めない」という指定で、これ自体は良い仕組みです。

ただしasyncでも、ダウンロード自体はページの描画と同じ時間帯に走ります。組み立ては止まらなくても、回線は共用です。遅い回線ほど、この同居の影響は大きくなります。

表示速度の測定についてはPageSpeed Insightsの解説記事に書きましたが、外部から読み込むスクリプトの量は、パフォーマンススコアを左右する主要因のひとつです。

当社の実装：読み込み完了後に取得する

当社サイトの全ページに実際に入っているコードを、そのまま載せます。

<script>
  window.dataLayer = window.dataLayer || [];
  function gtag(){dataLayer.push(arguments);}
  gtag('js', new Date());
  gtag('config', 'G-F1Z6NP6M68');
  gtag('config', 'AW-18290826134');
  // 計測タグ本体（gzip後186KB）は描画の帯域を奪うため、
  // 読み込み完了後に取得する
  addEventListener("load",function(){
    var s=document.createElement("script");
    s.async=true;
    s.src="https://www.googletagmanager.com/gtag/js?id=G-F1Z6NP6M68";
    document.head.appendChild(s);
  });
</script>

やっていることを日本語にすると、こうなります。

• 計測の「受付窓口」（dataLayerという記録帳）だけは先に用意しておく
• 計測プログラムの本体186KBは、ページの読み込みがすべて終わってから（loadイベント後に）取りに行く
• 本体が届いたら、記録帳に溜まっていた分をまとめて処理してもらう

つまり、主役（本文・画像）が舞台に出そろってから、裏方（計測）が入場する順番に入れ替えただけです。計測の内容そのものは変えていません。コード中のコメントに「gzip後186KB」と書いてあるのは、将来の自分がこの行を消しそうになったときのための、理由のメモです。

トレードオフ：計測を取りこぼす可能性

この実装には、はっきりした代償があります。包み隠さず書きます。

ページの読み込みが完了する前に離脱した訪問者は、計測されない可能性があります。開いて1〜2秒で「違うな」と閉じた人は、本体が届く前に去っているため、記録に残らないことがあります。つまり、アクセス数が実際より少なめに記録されうるということです。

当社がそれでもこの実装を選んだ理由は、天秤のかけ方です。

• 計測を優先する：数字は正確に近づくが、すべての訪問者の表示がわずかに遅くなる
• 表示を優先する：すべての訪問者の表示が軽くなるが、直帰の一部を数え損ねる

当社にとってアクセス解析は「どのページが読まれているか」の傾向をつかむ道具であって、1件単位の正確さを求めるものではありません。一方、表示の速さは全訪問者が毎回受け取る体感です。傾向把握のための数字の精度を少し譲って、体感を取る。これが当社の判断です。

逆に言えば、広告の費用対効果を1件単位で追っているサイトでは、この実装は向かない場合があります。何を計測の目的にしているかで、正解は変わります。

計測ツールは積み上がる

もうひとつ、お伝えしたいことがあります。重いのはGoogleアナリティクスだけではない、ということです。

サイトを長く運用していると、アクセス解析のほかに、広告の計測タグ、ヒートマップ、チャットボット、SNSの埋め込みと、外部のスクリプトが少しずつ増えていきます。1つ1つは「貼るだけ」でも、訪問者のブラウザはそのすべてを毎回ダウンロードします。

数年運用したサイトの表示が遅い原因を調べると、誰も見ていない計測ツールが3つも4つも残っていた、ということは珍しくありません。入れた記録は残っても、やめた記録は残りにくいからです。

当社が自社サイトに入れている外部の計測はGoogleアナリティクス1本だけです。増やすときは「その数字を、誰が、何の判断に使うのか」を先に決めることにしています。答えられない計測は、帯域の無駄遣いだからです。

読者の方が自分でできること

専門知識がなくても、ここまでの話は自分のサイトで点検できます。

• PageSpeed Insightsで自社サイトを測る：検索で「PageSpeed Insights」と調べ、URLを入れるだけ。無料です
• 診断の一覧に「使用していないJavaScript」「第三者コードの影響」といった項目が出ていないかを見る
• 入れている計測ツールを棚卸しする：管理会社や過去の担当者に「外部のタグは何が入っているか」を聞く
• それぞれについて「最後にその数字を見たのはいつか」を思い出す。1年見ていない計測は、外す候補

読み込みタイミングの変更（この記事の実装）は、サイトの作りに手を入れる作業になるので、管理している会社に相談してください。その際、この記事を見せていただいて構いません。

ここでよく出る質問

貼るかどうかより、貼り方

計測タグは、貼るかどうかではなく貼り方の問題だと思っています。

• 「貼るだけ」の計測タグの裏で、本体186KB（当社実測・gzip後）がダウンロードされている
• 標準の貼り方では、表示と計測が同じ帯域を取り合う：遅い回線ほど影響が大きい
• 当社は本体の取得を「読み込み完了後」に回した：主役が出そろってから裏方が入場する順番
• 代償は計測の取りこぼし：早期離脱が記録されない可能性がある。計測の目的次第では向かない
• 計測ツールは棚卸しする：1年見ていない数字のために、全訪問者を待たせない

表示速度の改善というと、画像の圧縮やサーバーの話になりがちですが、「画面に何も映さない通信を、いつ流すか」という地味な設計も同じくらい効きます。そしてこの種の工夫は、公開後のスコアを測っても項目名としては出てきません。制作会社が裏で何をしているか。その一例として、当社の実装をそのまま公開しました。