GTMでCore Web Vitalsを計測する方法｜FIDはINPに置き換わった｜未経験から100日後にGTMのプロになる話【Day 57】

ここまでキャリアや運用ルールの話が続いたので、今日は毛色を変えて、まだ扱っていない具体的な技術トピックとして「GTMでCore Web Vitalsを計測する」方法を扱います。

まず訂正：Core Web Vitalsの3指標は変わった

Core Web Vitalsという言葉自体は以前から知られていますが、構成する指標は固定ではありません。2024年3月に、応答性を測る指標が「FID（First Input Delay）」から「INP（Interaction to Next Paint）」に置き換わっています。FIDは「最初の入力までの遅延」だけを見ていましたが、INPはページ滞在中に発生するあらゆる操作への応答性を評価するため、より実態に近い指標とされています。現在のCore Web Vitalsは、LCP（最大コンテンツの描画時間）・INP（応答性）・CLS（レイアウトのずれ）の3つです。古い解説記事で「FID」が現役の指標として紹介されていたら、それは2024年3月より前の情報だと判断してください。

GTMでCore Web Vitalsを計測する方法

Googleが公開している「web-vitals」というJavaScriptライブラリを使うのが標準的な方法です。このライブラリを読み込むカスタムHTMLタグ（または対応するコミュニティテンプレート）を用意し、各指標が計測されるたびにdataLayer.push()でGTMに通知する構成にします。GTM側では、この記事全体で扱ってきたのと同じ流れ――データレイヤー変数で値を受け取り、カスタムイベントトリガーで検知し、GA4イベントタグで送信する――で計測を組み立てます。

数値の見方

INPを例にすると、200ミリ秒以下が「良好」、200〜500ミリ秒が「改善が必要」、500ミリ秒超が「不良」の目安とされています。GTM経由で集めたCore Web Vitalsのデータは、Day15・43で扱ったBigQueryエクスポートと組み合わせれば、ページ単位・デバイス単位でどこに遅延が集中しているかをSQLで分析できます。ただし、これはあくまで「実際のユーザー環境で計測したフィールドデータ」であり、開発者ツールのLighthouseなどで測る「ラボデータ」とは性質が異なる点も押さえておいてください。

今日のまとめ

Core Web Vitalsを語るときは、まずFIDがすでにINPに置き換わっている事実を押さえること。そのうえでGTM経由の計測は、これまで扱ってきたdataLayer活用の応用でしかありません。新しい技術というより、既存の仕組みの新しい適用先だと捉えてください。次回は、GTMを実務で使いこなすための総仕上げを扱います。