Google Analytics がコア Web Vitals の失敗を引き起こす: 次のステップ

ユーザーを引き付け、エンゲージし、変換したいと考えているオンライン ビジネス オーナーにとって、失敗した Core Web Vitals は重大な警告です。

Web サイトが実際のユーザーにとってどれだけ楽しいかを示す公式ベンチマークである Google の Core Web Vitals は、次の 3 つのパフォーマンス指標のセットです。

• Largest Contentful Paint (LCP) による初期ロード時間の測定
• Interaction to Next Paint (INP) による応答性の測定
• 累積レイアウト シフト (CLS) はレイアウトの安定性を測定します

これらの指標を組み合わせることで、実際のユーザー インタラクションに基づいてサイトのパフォーマンスを測定する標準化された方法が提供されます。 評価に合格すると、サイトの読み込みが速く、反応が早く、ユーザーがサイトを操作しているときに異常な動作をしないことがわかります。

したがって、Google 独自の Analytics が Core Web Vitals 評価の失敗を引き起こしているように見えるのは、大きな驚きです。

調べてみましょう！

Google アナリティクスはどのように機能しますか?

Google Analytics は、ウェブサイト上でのユーザーのインタラクションを追跡し、ユーザーの行動、トラフィック ソース、コンバージョンに関する洞察を提供することによって機能します。 これは、Google Analytics が提供するトラッキング コード スニペットを追加することで Web サイトに実装されます。

この JavaScript スニペットは、グローバル サイト タグ (gtag.js) とも呼ばれ、追跡するすべての Web ページ上のサイトのセクションに挿入されます。

このコードは、ページビュー、クリック、コンバージョンなどのユーザーインタラクションに関するデータを収集し、分析のために Google のサーバーに送信します。 ウェブサイトの所有者は、Google Analytics ダッシュボードを通じてこのデータにアクセスし、ウェブサイトのパフォーマンスとユーザー エンゲージメントに関する洞察を得ることができます。

ここまでは順調ですね。

では、内部で何が起こっているのかを見てみましょう。

パフォーマンスへの影響 (詳細)

キャッシュを無効にし、アクティブなパフォーマンスの最適化を行わずに詳しく調べてみると、gtag.js は 769B の Microsoft Clarity gtag とともに、重さわずか 111kB の単一の HTTP リクエストとして読み込まれていることがわかります。

最初のページ読み込みに関する限り、Google Analytics トラッキング コードは予期した動作を示し、過度の HTTP リクエスト、未使用の JavaScript、ブロックされたメイン スレッドの原因にはなりません。

では、その誤解はどこから生じているのでしょうか？

Google Analytics は本当にコア ウェブ バイタルに影響を及ぼしますか?

Google Analytics のトラッキングを Web サイトに追加するだけでは、Core Web Vitals 評価 (特に Lagest Contentful Paint) に不合格になる危険はありません。 これは単純に、Web ページの先頭に配置されるスニペットが非常に軽量であり、ページのコンテンツをレンダリングする際の重要なプロセスをブロックしないためです。

では、なぜサイト所有者は失敗した Core Web Vitals を Google Analytics にリンクしているのでしょうか?

ラボデータとフィールドデータの違い

私たちの経験によれば、Google PageSpeed レポートの読み方に関しては、依然としてかなりの誤解が存在​​します。 その主な理由は、レポートが時間の経過とともにどのように進化したかによるものです。

混乱を解消しましょう。

Core Web Vitals の導入後、Google チームは、いわゆる「フィールド データ」に注目を移すことに熱心に取り組みました。このデータは現在、Core Web Vitals 評価としてレポートの一番上に表示されています。

これは、CrUX データセット (別名 Chrome ユーザー エクスペリエンス レポート) から Web サイトを操作する実際のユーザーのデータを使用して生成されます。

amazon.com のフィールド データに基づく Core Web Vitals 評価

Google の Core Web Vitals が優れたユーザー エクスペリエンスの標準になる前は、パフォーマンス スコア (0 から 100 で測定) に依存していました。現在は CWV 評価後に表示されます。

amazon.com のラボ データに基づくパフォーマンス スコア

優先順位が下がった理由は、ユーザーが Web サイトにアクセスしたときに何が起こるかを正確に表現していないためです。 パフォーマンス スコアは、Lighthouse からの「ラボ データ」を使用して生成されます。つまり、これらはシミュレートされた環境からの結果です。

上のスクリーンショットからわかるように、Amazon は Core Web Vitals を見事に合格させていますが、制御された環境では、Total Blocking Time (TBT)、Speed Index (SI)、および LCP の問題にさらなる改善のフラグが立てられています。 これは、特定の問題を切り分けて最適化に取り組むための優れた方法です。

しかし、結局のところ最も重要なのは、実際のユーザーが Web サイトをどのように体験するかということであり、まずそこに重点を置く必要があります。

最終評決

結論として、Core Web Vitals に失敗している場合、Google Analytics のトラッキングが原因である可能性は低いです。 代わりに、現場の結果ではなく検査結果を読んでいないことを確認し、PSI レポートをもう一度スクロールして、「機会」セクションと「診断」セクションを調べてください。

Google タグ マネージャーと Google AdSense についてはどうですか?

実際には、サイト所有者が分析をセットアップして終わりにするというところまではほとんど行いません。

Google タグ マネージャーと Google AdSense は、特定のイベントを追跡し、Web サイトに広告を掲載して受信トラフィックから追加収益を得るオンライン ビジネスに人気のツールです。

Google Analytics 自体はパフォーマンスの問題の原因ではありませんが、NitroPack のエンジニアは常に詳細な分析を行って真の原因を特定します。

kiteworks.comを使用した前述の例を使用すると、ホームページとの対話時に、タグ マネージャーからの追加のイベント タグ (gtm.js) のチェーンが起動されることがわかります。

そして、それは余分な gtm.js タグがたくさんあるため、過剰な数の HTTP リクエストが発生します。

Google アナリティクスのコードは他のコードよりも先に読み込まれるため、ウェブサイトに多数のイベント タグがある場合、GA スニペットが他のすべての gtm.js を呼び出すことが予想され、その結果、読み込みの遅延が発生し、次のような指標の結果が悪化します。

• 最大のコンテンツ豊富なペイント
• 合計ブロッキング時間
• 最初のコンテンツフル ペイント (FCP)

PSI レポートでは、このような文字列には「未使用の JavaScript を減らす」という警告が表示されます。

Google タグ マネージャーが次のようになっている場合は、整理整頓して再編成する必要があります。

Googleタグマネージャーによる「未使用のJavaScriptの削減」を修正

最初のステップは、非同期または遅延属性を使用してサードパーティのスクリプトを遅延させ、バックグラウンドで読み込まれるようにすることです。 これらの属性は基本的にスクリプトをノンブロッキングに変え、サードパーティ コードの全体的な影響を軽減します。

これらの属性は似ていますが、重要な違いがあります。

• defer属性を持つスクリプトは、相対的な順序を維持します。 ブラウザはページのレンダリングを待機せず、順番に実行します。 たとえば、スクリプト 1 とスクリプト 2 という 2 つのスクリプトがこの順序で存在します。 両方を延期すると、スクリプト 2 が最初にダウンロードされた場合でも、ブラウザは常にスクリプト 1 を最初に実行します。
• async属性を持つスクリプトは完全に独立しています。 最初にロードされたものが最初に実行されます。

Gtm タグはデフォルトで非同期で読み込まれますが、これだけ多くなると、非常に長いリクエストのキューが 2 つあるようなものになります。たとえそれらが通過しているとしても、一度に 1 つしか通過できないため、必然的に順番を待たなければなりません。

まず Google タグ マネージャー イベントの数を最適化し、次に延期することで、初期読み込みで不必要な遅延が発生しないようにできます。

NitroPack で未使用の JavaScript を削減し、サイトのすべてのリソースを最適化 →

Google AdSense のリスクとトレードオフ

サイト所有者が Web ページ上にさまざまな形式の広告ユニットを専用に配置すると、Google AdSense は各広告ユニットのコード スニペット (HTML/JavaScript) を提供し、広告が表示される Web サイトのページの HTML に貼り付けられます。

ユーザーが AdSense 広告コードを含む Web ページにアクセスすると、ブラウザは AdSense が提供する JavaScript コードを実行し、インプレッション時にサイト所有者に収益をもたらします。

残念ながら、AdSense 広告はレンダリングをブロックする性質があるため、サイトのパフォーマンス (特に LCP や CLS などの Web Vitals) に影響を与える可能性があります。

NitroPack を使用すると、サイト所有者は「広告の最適化」を選択して、ユーザーの操作が行われるまで JS を遅らせることができます。 ただし、AdSense はインプレッションに基づいて機能するため、これにより広告収益が一部損失する可能性があります。

この場合、視聴者の行動に基づいて、どちらがビジネスにとってより有益かを決定する必要があります。

1)最適なパフォーマンスによるブラウジング体験の向上

または

2)可能な限り多くの広告収入を生み出しますが、最終的には不安定なサイト動作によりトラフィックを失います。

よくある質問

自己ホスト型 Google Analytics には価値がありますか?

サイト所有者の中には、コア ウェブ バイタルを最適化するためにセルフホスティング Google Analytics のトラッキングを検討している人もいますが、それを実行する必要はほとんどありません。 Google のインフラストラクチャに依存する場合と比較して、複雑さ、コスト、潜在的な制限を追加するのではなく、Core Web Vitals 標準を満たすように Google タグ マネージャー イベントを最適化することに重点を置きます。