Google Analytics 導致核心 Web Vitals 失敗：後續步驟

對於想要吸引、參與和轉換用戶的線上企業主來說，失敗的核心網路生命是一個嚴重的警告。

Google 的 Core Web Vitals 是衡量網站對現實用戶的愉悅程度的官方基準，它包含三個效能指標：

• 最大內容繪製 (LCP) 測量初始載入時間
• 與 Next Paint 的交互 (INP) 衡量回應能力
• 累積佈局偏移 (CLS) 衡量佈局穩定性

這些指標共同提供了一種基於真實使用者互動來衡量網站效能的標準化方法。 透過評估表明您的網站加載速度快，反應快，並且在用戶與之互動時不會表現異常。

因此，當 Google 自己的 Analytics 似乎導致 Core Web Vitals 評估失敗時，我們會感到非常驚訝。

我們來調查一下吧！

谷歌分析如何運作？

Google Analytics 的工作原理是追蹤網站上的使用者互動並提供有關使用者行為、流量來源和轉換的見解。 它是透過添加 Google Analytics 提供的追蹤程式碼片段在網站上實現的。

此 JavaScript 程式碼片段也稱為全域網站程式碼 (gtag.js)，會進入您要追蹤的每個網頁上的網站部分：

此程式碼收集有關用戶互動的數據，例如頁面瀏覽量、點擊次數和轉換次數，並將其發送到 Google 的伺服器進行分析。 然後，網站所有者可以透過 Google Analytics 儀表板存取這些數據，以深入了解其網站的效能和使用者參與度。

到目前為止，一切都很好。

現在，讓我們看看幕後發生了什麼。

對性能的影響（仔細觀察）

在禁用快取和沒有主動效能優化的情況下進行仔細檢查後，我們發現 gtag.js 作為單一 HTTP 請求加載，重量僅為 111kB，Microsoft Clarity gtag 為 769B。

就初始頁面載入而言，Google Analytics（分析）追蹤程式碼會顯示預期的行為，並且不會導致過多的 HTTP 請求、未使用的 JavaScript 或阻塞的主執行緒。

那麼，這種誤解從何而來呢？

Google Analytics 真的會影響核心網路生命嗎？

僅將 Google Analytics 追蹤新增至您的網站並不會有未通過 Core Web Vitals 評估（或特別是 Lagest Contentful Paint）的風險。 這只是因為放置在網頁頭部的程式碼片段非常輕量級，並且不會阻止渲染頁面內容的任何重要過程。

那麼，為什麼網站所有者將失敗的 Core Web Vitals 連結到 Google Analytics？

實驗室數據和現場數據之間的差異

我們的經驗表明，在閱讀 Google PageSpeed 報告時仍然存在相當大的誤解。 主要是因為報告隨著時間的推移而演變。

讓我們澄清一下困惑。

在推出 Core Web Vitals 後，Google 團隊努力將注意力轉移到我們所謂的「現場數據」上——現在顯示在報告的最頂部，作為 Core Web Vitals 評估。

它是根據 CrUX 資料集（又稱 Chrome 使用者體驗報告）中與您的網站互動的真實使用者的資料產生的。

基於 amazon.com 現場數據的核心網路生命力評估

在 Google 的 Core Web Vitals 成為出色使用者體驗的標準之前，我們依賴效能分數（從 0 到 100 進行測量），現在顯示在 CWV 評估之後。

基於 amazon.com 實驗室數據的效能得分

它被取消優先順序的原因是它沒有準確地代表用戶登陸您的網站時發生的情況。 效能分數是使用 Lighthouse 的「實驗室數據」產生的，換句話說，這些是模擬環境的結果。

從上面的螢幕截圖中可以看出，亞馬遜出色地通過了核心網路生命力測試，但在受控環境中，總阻塞時間 (TBT)、速度指數 (SI) 和 LCP 問題被標記為需要進一步改進。 這是隔離特定問題並對其進行最佳化的好方法。

然而，歸根結底，最重要的是真實用戶如何體驗您的網站，這就是您應該首先關注的地方。

最終判決

總之，如果您未通過 Core Web Vitals，Google Analytics 追蹤不太可能是原因。 相反，請確保您閱讀的不是實驗室結果而是現場結果，並為您的 PSI 報告提供另一個捲軸以探索機會和診斷部分。

Google 追蹤代碼管理器和 Google AdSense 怎麼樣？

事實上，網站所有者很少會進行分析並結束工作。

對於想要追蹤特定事件並在其網站上投放廣告以從傳入流量中獲得額外收入的線上企業來說，Google 追蹤程式碼管理器和 Google AdSense 是流行的工具。

雖然 Google Analytics 本身並不是效能問題的根源，但我們 NitroPack 的工程師總是會進行深入分析，以確定真正的罪魁禍首。

使用我們先前的kiteworks.com範例，我們看到在與主頁互動時，來自標籤管理器的一系列額外事件標籤 (gtm.js) 被觸發。

這是許多額外的 gtm.js 標籤，因此 HTTP 請求數量太多。

由於 Google Analytics 程式碼先於其他所有內容加載，因此當您的網站有大量事件標籤時，您可以預期 GA 程式碼段會調用所有其他 gtm.js，從而導致加載延遲和指標結果惡化，例如：

• 最大的內容塗料
• 總阻塞時間
• 首次內容繪製 (FCP)

在您的 PSI 報告中，此類字串將標記為「減少未使用的 JavaScript」警告：

如果您的 Google 追蹤程式碼管理員看起來像這樣，那麼是時候整理和重新組織了：

修正 Google 標籤管理器導致的“減少未使用的 JavaScript”

第一步是使用async或defer屬性延遲第三方腳本，並讓它們在背景載入。 這些屬性本質上將腳本變成非阻塞並減少第三方程式碼的整體影響。

雖然相似，但這些屬性有重要的差異：

• 具有defer屬性的腳本保持其相對順序。 瀏覽器不會等待它們呈現頁面，而是按順序執行它們。 例如，我們有兩個腳本——腳本 1 和腳本 2——按這個順序。 如果我們推遲兩者，瀏覽器將始終首先執行腳本 1，即使首先下載了腳本 2。
• 具有async屬性的腳本是完全獨立的。 哪個先載入就先執行。

Gtm 標籤預設是非同步載入的，但是當有這麼多標籤時，就像有兩個很長的請求佇列一樣——即使它們正在傳遞，但一次只能傳遞一個，並且不可避免地要等待。

透過先優化 Google 追蹤程式碼管理員事件的數量，然後推遲它們，您可以確保初始載入不會遭受不必要的延遲。

使用 NitroPack 減少未使用的 JavaScript 並優化您網站的所有資源 →

Google AdSense 的風險和權衡

當網站擁有者在網頁上使用各種格式的專用廣告單元時，Google AdSense 會為每個廣告單元提供程式碼片段 (HTML/JavaScript)，這些程式碼片段將貼上到應顯示廣告的網站頁面的 HTML 中。

當使用者造訪包含 AdSense 廣告程式碼的網頁時，瀏覽器會執行 AdSense 提供的 JavaScript 程式碼，進而為網站擁有者帶來展示收入。

遺憾的是，由於 AdSense 廣告具有阻止呈現的特性，因此可能會影響網站效能（特別是 LCP 和 CLS 等 Web Vitals）。

使用 NitroPack，網站所有者可以選擇“優化廣告”，這將延遲 JS 直到用戶互動。 但由於 AdSense 是基於展示次數，這可能會導致一些廣告收入損失。

在這種情況下，根據受眾的行為，您應該決定什麼對您的業務更有利：

1)最佳效能以獲得更好的瀏覽體驗

或者

2)產生盡可能多的廣告收入，但最終會因不穩定的網站行為而失去流量。

常問問題

自託管 Google Analytics 值得嗎？

雖然一些網站所有者考慮使用自託管 Google Analytics 追蹤來實現最佳的核心網路生命週期，但幾乎沒有必要這樣做。 與依賴 Google 的基礎架構相比，不要增加複雜性、成本和潛在限制，而是專注於優化 Google 追蹤程式碼管理員事件以滿足 Core Web Vitals 標準。