衡量核心網絡生命力的深入指南

谷歌宣布，從 2021 年 5 月（編輯：日期剛剛移至 2021 年 6 月）開始，他們將開始考慮將“頁面體驗”作為搜索排名的一部分，由一組稱為 Core Web Vitals 的指標衡量。 那個日期很快就要到了，我相信我們中的很多人都被要求確保我們通過了我們的核心 Web Vitals，但是你怎麼知道你是否通過了？

回答這個問題實際上比您想像的要困難得多，雖然現在許多工具都在揭示這些核心 Web 生命力，但仍有許多重要的概念和微妙之處需要理解。 甚至 Google Search Console 中的 PageSpeed Insights 和 Core Web Vitals 報告等 Google 工具似乎也提供了令人困惑的信息。

為什麼會這樣？您如何確定您的修復確實有效？ 如何準確了解您網站的 Core Web Vitals？ 在這篇文章中，我將嘗試更多地解釋這裡發生的事情，並解釋這些工具的一些細微差別和誤解。

什麼是核心網絡生命力？

Core Web Vitals 是一組三個指標，旨在衡量用戶感覺網站是快還是慢的“核心”體驗，從而提供良好的體驗。

網頁需要在所有三個 Core Web Vitals 的綠色測量範圍內才能獲得任何排名提升的全部好處。 在良好範圍之外，兩個頁面上不同的 Core Web Vital 指標值可能會導致不同的頁面體驗排名。

1.最大的內容塗料（LCP）

這個指標可能是最容易理解的——它衡量你在頁面上繪製最大項目的速度——這可能是用戶感興趣的內容。這可能是橫幅圖像、一段文本或任何。 它是頁面上最大的內容元素這一事實很好地表明它是最重要的部分。 LCP 相對較新，我們曾經測量類似名稱的 First Contentful Paint (FCP)，但 LCP 已被視為訪問者可能希望看到的內容何時被繪製的更好指標。

LCP 應該衡量加載性能，並且是我們在性能社區中過去使用的所有舊指標（即首字節時間 (TTFB)、DOM 內容加載、開始渲染、速度指數）的良好代理——但從經驗來看的用戶。 它沒有涵蓋這些指標所涵蓋的所有信息，而是一個更簡單的單一指標，試圖給出頁面加載的良好指示。

2. 首次輸入延遲 (FID)

第二個指標衡量用戶與頁面交互（例如點擊鏈接或按鈕）與瀏覽器處理該點擊之間的時間。 它可以用來衡量頁面的交互性。 如果所有內容都已加載，但頁面沒有響應，那麼這對用戶來說是一種令人沮喪的體驗。

重要的一點是，該指標無法模擬，因為它實際上取決於用戶何時實際點擊或以其他方式與頁面交互，以及需要多長時間才能採取行動。 在使用沒有任何直接用戶交互的測試工具時，總阻塞時間 (TBT) 是 FID 的一個很好的代理，但在查看 FID 時也要留意交互時間 (TTI)。

3. 累積版式偏移（CLS）

一個非常有趣的指標，與之前由於多種原因出現的其他指標完全不同。 它旨在衡量頁面的視覺穩定性——基本上是隨著新內容插槽的到位它跳來跳去的程度。 我敢肯定，我們都點擊了一篇文章，開始閱讀，然後在加載圖像、廣告和其他內容時讓文本跳來跳去。

這對用戶來說非常刺耳和煩人，因此最好將其最小化。 更糟糕的是，當您要單擊的按鈕突然移動時，您卻單擊了另一個按鈕！ CLS 試圖解釋這些佈局變化。

實驗室與朗姆酒

了解 Core Web Vitals 的關鍵點之一是它們基於現場指標或真實用戶指標 (RUM)。 Google 使用來自 Chrome 用戶的匿名數據來反饋指標，並在 Chrome 用戶體驗報告 (CrUX) 中提供這些數據。 這些數據就是他們用來衡量這三個搜索排名指標的數據。 CrUX 數據可在許多工具中使用，包括在您網​​站的 Google Search Console 中。

使用 RUM 數據這一事實是一個重要的區別，因為其中一些指標（FID 除外）可在合成或“基於實驗室”的 Web 性能工具（如 Lighthouse）中使用，這些工具過去一直是許多 Web 性能監控的主要工具. 這些工具在模擬網絡和設備上運行頁面加載，然後告訴您該測試運行的指標是什麼。

因此，如果您在高性能開發人員機器上運行 Lighthouse 並獲得高分，那可能無法反映用戶在現實世界中的體驗，因此 Google 將使用什麼來衡量您的網站用戶體驗。

LCP 將非常依賴於網絡條件和正在使用的設備的處理能力（並且您的用戶中可能有更多的用戶使用的設備功率比您想像的要低！）。 然而，與之相對的是，至少對於許多西方網站來說，我們的手機可能不像移動模式中的 Lighthouse 等工具所暗示的那樣低功耗，因為這些工具受到了很大的限制。 因此，您可能會注意到您在移動設備上的現場數據比使用此建議的測試要好（有一些關於更改 Lighthouse 移動設置的討論）。

同樣，FID 通常取決於處理器速度以及設備如何處理我們發送給它的所有這些內容——無論是要處理的圖像、要在頁面上佈局的元素，當然還有我們喜歡發送的所有 JavaScript到瀏覽器翻閱。

從理論上講，CLS 更容易在工具中測量，因為它不太容易受到網絡和硬件變化的影響，因此您會認為它不受 LAB 和 RUM 之間差異的影響——除了一些最初可能並不明顯的重要考慮因素：

• 它是在頁面的整個生命週期中測量的，而不僅僅是像典型工具那樣用於頁面加載，我們將在本文後面進行更多探討。 當實驗室模擬的頁面加載具有非常低的 CLS 時，這會導致很多混亂，但字段 CLS 得分要高得多，這是由於在測試工具通常測量的初始加載後滾動或其他更改引起的 CLS。
• 它可能取決於瀏覽器窗口的大小——通常是 PageSpeed Insights 等工具，用於測量移動設備和桌面設備，但不同的移動設備具有不同的屏幕尺寸，並且桌面設備通常比這些工具集大得多（Web Page Test 最近增加了它們的默認屏幕尺寸試圖更準確地反映使用情況）。
• 不同的用戶在網頁上看到不同的東西。 Cookie 橫幅、促銷、廣告攔截器、A/B 測試等定制內容，但一些可能不同的項目都會影響繪製的內容以及 CLS 用戶可能會體驗到的內容。
• 它仍在不斷發展，Chrome 團隊一直在忙於修復不應計入 CLS 的“隱形”​​轉變等。 實際測量 CLS 的方式也正在發生更大的變化。 這意味著您可以看到不同的 CLS 值，具體取決於正在運行的 Chrome 版本。

在基於實驗室的測試工具中為指標使用相同的名稱，當它們可能無法準確反映真實版本時會令人困惑，有些人建議我們應該在 Lighthouse 中重命名這些指標中的部分或全部，以區分這些模擬指標與為 Google 排名提供動力的真實世界 RUM 指標。

以前的 Web 性能指標

另一個令人困惑的地方是，這些指標是新的，與我們過去用來衡量 Web 性能的指標不同，而且這些指標是由其中一些工具浮出水面的，比如 PageSpeed Insights——一種免費的在線審計工具。 只需輸入您要審核的 URL，然後單擊分析，幾秒鐘後，您將看到兩個選項卡（一個用於移動設備，一個用於桌面），其中包含大量信息：

最重要的是 Lighthouse 性能得分（滿分 100）。這在 Web 性能社區中已經有一段時間了，並且經常被引用為關鍵性能指標，旨在將許多指標的複雜性總結為一個簡單的指標，通俗易懂的數字。 這與 Core Web Vitals 目標有一些重疊，但它不是三個 Core Web Vitals（甚至是基於實驗室的版本）的總結，而是更廣泛的指標。

目前，Lighthouse 性能得分由六個指標組成——包括一些 Core Web Vitals 和一些其他指標：

• 首次內容繪製 (FCP)
• 速度指數 (SI)
• 最大含量塗料 (LCP)
• 互動時間 (TTI)
• 總阻塞時間 (TBT)
• 累積版式偏移 (CLS)

為了增加複雜性，這六個中的每一個在性能得分中的權重都不同，儘管 CLS 是核心 Web Vitals 之一，但目前僅佔 Lighthouse 性能得分的 5%（我敢打賭這會很快增加） CLS 的下一次迭代發布）。 所有這一切意味著您可以獲得非常高的綠色 Lighthouse 性能分數並認為您的網站很好，但仍然未能通過 Core Web Vitals 閾值。 因此，您現在可能需要重新集中精力來查看這三個核心指標。

越過該屏幕截圖中的大綠色分數，我們轉到字段數據，我們得到另一個混淆點：儘管不是核心 Web 的一部分，但該字段數據中顯示了 First Contentful Paint 以及其他三個 Core Web Vitals Vitals，就像在這個例子中一樣，我經常發現它被標記為警告，即使其他人都通過了。 （也許這個門檻需要稍微調整一下？） FCP 是否差一點錯過了成為核心 Web Vital 的機會，或者它看起來更好地平衡了四個指標？ 這個字段數據部分很重要，我們稍後再討論。

如果正在測試的特定 URL 沒有可用的字段數據，則將顯示整個域的原始數據（當字段數據可用於該特定 URL 時，默認情況下隱藏，如上所示）。

在現場數據之後，我們得到了實驗室數據，我們在頂部看到了構成性能得分的六個指標。 如果您單擊右上角的切換按鈕，您甚至會獲得對這些指標的更多描述：

如您所見，LCP 和 CLS 的實驗室版本包含在此處，並且由於它們是 Core Web Vitals 的一部分，因此它們會獲得一個藍色標籤以將它們標記為特別重要。 PageSpeed Insights 還包括一個有用的計算器鏈接，用於查看這些分數對頂部總分的影響，它允許您調整它們以查看每個指標對您的分數有何改進。 但是，正如我所說，Web 性能得分可能會暫時退居次要地位，而 Core Web Vitals 此刻正沉浸在所有關注的光芒中。

Lighthouse 還對額外的機會和診斷執行近 50 項其他檢查。 這些不會直接影響分數，也不會影響 Core Web Vitals，但可以被 Web 開發人員用來提高他們網站的性能。 這些也出現在所有指標下方的 PageSpeed Insights 中，因此對於上面的屏幕截圖來說簡直是不可能的。 將這些視為有關如何提高性能的建議，而不是必須解決的具體問題。

診斷將向您顯示 LCP 元素和對您的 CLS 分數有貢獻的轉變，這些信息在優化您的 Core Web Vitals 時非常有用！

因此，雖然過去 Web 性能倡導者可能非常關注 Lighthouse 分數和審計，但我認為這會集中在三個 Core Web Vital 指標上——至少在我們了解它們的下一個時期是這樣。 其他 Lighthouse 指標和總體得分仍然有助於優化您網站的性能，但 Core Web Vitals 目前佔據了新網絡性能和 SEO 博客文章的大部分內容。

查看您網站的核心 Web Vitals

快速查看單個 URL 和整個源的 Core Web Vitals 的最簡單方法是在 PageSpeed Insights 中輸入 URL，如上所述。 但是，要查看 Google 如何看待您整個網站的核心 Web Vitals，請訪問 Google Search Console。 這是由 Google 創建的免費產品，可讓您了解 Google 如何“查看”您的整個網站，包括您網站的 Core Web Vitals（儘管有一些——我們應該說——對數據更新頻率感到“沮喪”） ）。

Google Search Console 長期以來一直被 SEO 團隊使用，但由於網站開發人員需要解決 Core Web Vitals 的問題，如果開發團隊還沒有使用該工具，他們也應該真的可以使用該工具。 要獲得訪問權限，您將需要一個 Google 帳戶，然後通過各種方式驗證您對該站點的所有權（在您的網絡服務器中放置文件、添加 DNS 記錄等）。

Google Search Console 中的Core Web Vitals 報告為您提供了過去 90 天內您的網站如何滿足 Core Web Vitals 的摘要：

理想情況下，要被認為完全通過了 Core Web Vitals，您希望所有頁面都是綠色的，沒有琥珀色也沒有紅色。 雖然琥珀色是您即將通過的一個很好的指標，但實際上只有果嶺才能獲得全部收益，所以不要滿足於次優。 是否需要傳遞所有頁面或僅傳遞關鍵頁面取決於您，但通常許多頁面上都會出現類似問題，為網站修復這些問題有助於將未傳遞的 URL 數量變得更易於管理您可以做出這些決定的水平。

最初，Google 只會將 Core Web Vitals 排名應用到移動設備上，但將其推廣到桌面肯定只是時間問題，所以當你在那裡審查和修復你的頁面時不要忽視桌面。

單擊其中一個報告將為您提供有關未滿足哪些 Web Vitals 的更多詳細信息，然後是受影響的 URL 樣本。 Google Search Console將 URL 分組到存儲桶中，理論上可以讓您將相似的頁面放在一起。 然後，您可以單擊 URL 以運行 PageSpeed Insights 以對特定 URL 運行快速性能審核（包括顯示該頁面的 Core Web Vitals 字段數據（如果可用））。 然後，您修復它突出顯示的問題，重新運行 PageSpeed Insights 以確認實驗室指標現在正確，然後轉到下一頁。

但是，一旦您開始查看 Core Web Vitals 報告（對於我們中的一些人來說非常著迷！），您可能會因為該報告似乎沒有更新以反映您的辛勤工作而感到沮喪。 隨著圖表的移動，它似乎每天都在更新，但即使您發布了修復程序，它通常也幾乎沒有變化——為什麼？

同樣，PageSpeed Insights 字段數據仍然頑固地將 URL 和站點顯示為失敗。 那麼這裡有什麼故事呢？

Chrome 用戶體驗報告 (CrUX)

Web Vitals 更新緩慢的原因是，現場數據基於 Chrome 用戶體驗報告 (CrUX) 中最近 28 天的數據，其中僅佔該數據的 75%。 使用 28 天的數據和第 75 個百分位數的數據是好事，因為它們可以消除差異和極端情況，從而更準確地反映您網站的性能，而不會造成大量難以解釋的噪音。

性能指標非常容易受到網絡和設備的影響，因此我們需要消除這些噪音，以了解您的網站對大多數用戶的實際表現。 然而，另一方面，它們的更新速度令人沮喪，從糾正問題創建了一個非常緩慢的反饋循環，直到您看到糾正的結果反映在那裡。

尤其是第 75 個百分位數（或 p75）和它造成的延遲很有趣，因為我認為這不是很好理解。 它會查看在這 28 天內訪問者的 75% 的頁面瀏覽量，以衡量每個 Core Web Vitals。

因此，它是75% 的頁面瀏覽量的最高核心 Web Vitals 分數（或者相反，75% 的頁面瀏覽量將低於的最低核心 Web Vitals 分數）。 所以它不是這 75% 的頁面瀏覽量的平均值，而是該組用戶的最差值。

這會導致報告延遲，而基於非百分位數的滾動平均值不會。 我們必須在這裡進行一些數學運算（我會盡量將其保持在最低限度），但是為了簡單起見，上個月每個人都獲得了 10 秒的 LCP，而您已修復它，所以現在它只需要 1 秒，假設您每天有完全相同數量的訪問者，他們都獲得了這個 LCP。

在那種過於簡單的場景中，您將獲得以下指標：

因此，您可以看到，直到第 22 天，CrUX 分數突然躍升至新的較低值（一旦我們超過 28 天平均值的 75% — 絕非巧合！），您才看到您的 CrUX 分數有顯著提高。 在那之前，超過 25% 的用戶是基於更改之前收集的數據，所以我們得到的是舊值 10，因此您的 p75 值停留在 10。

因此，看起來您很長一段時間都沒有取得任何進展，而平均平均值（如果使用的話）將顯示立即開始逐漸下降，因此實際上可以看到進展。 從好的方面來說，在過去的幾天裡，平均值實際上高於 p75 值，因為根據定義，p75 完全過濾掉了極端值。

上表中的示例雖然大大簡化，但解釋了為什麼許多人可能會看到如下 Web Vitals 圖表的一個原因，即有一天您的所有頁面都超過了一個閾值，然後就很好了（哇哦！ ）：

對於那些期望在處理頁面問題時進行更漸進（和即時）更改的人來說，這可能會令人驚訝，因為某些頁面的訪問頻率高於其他頁面。 在相關說明中，您的 Search Console 圖表在達到甜美、甜美的綠色之前，根據您的修復以及它們如何影響閾值，通常會經歷琥珀色時期：

Dave Smart 在 Search Console 的 Report Core Web Vitals Data 中進行了一項有趣的實驗，跟踪更改，他想查看更新圖表的速度。 他沒有考慮到 CrUX 的第 75 個百分位部分（這使得他的一些圖表中缺乏運動更有意義），但仍然是關於該圖表如何更新的迷人現實生活實驗，非常值得一讀！

我自己的經驗是，這種為期 28 天的 p75 方法並不能完全解釋 Core Web Vitals 報告中的滯後，稍後我們將討論其他一些潛在原因。

那麼，您能做到最好，進行修復，然後耐心等待，輕敲手指，直到 CrUX 認為您的修復值得併更新 Search Console 和 PageSpeed Insights 中的圖表？ 如果事實證明你的修復不夠好，那麼重新開始整個週期？ 在即時反饋滿足我們的渴望，以及開發人員提高生產力的緊密反饋循環的今天，這根本不是很令人滿意！

好吧，在此期間您可以做一些事情來嘗試查看任何修復是否會產生預期的影響。

更詳細地研究關鍵數據

由於測量的核心是 CrUX 數據，讓我們深入研究一下，看看它還能告訴我們什麼。 回到 PageSpeed Insights，我們可以看到它不僅顯示了網站的 p75 值，還顯示了下面顏色條中顯示的每個綠色、琥珀色和紅色存儲桶中的頁面瀏覽百分比：

上面的屏幕截圖顯示 CLS 未通過 Core Web Vitals 評分，p75 值為 0.11，高於 0.1 的通過限制。 然而，儘管字體的顏色是紅色，但這實際上是一個琥珀色的排名（因為紅色會高於 0.25）。 更有趣的是，綠色條為 73%——一旦達到 75%，這個頁面就通過了 Core Web Vitals。

雖然您看不到歷史 CrUX 值，但您可以隨著時間的推移對其進行監控。 如果明天達到 74%，那麼我們的趨勢是正確的（可能會出現波動！），並且有望很快達到 75% 的魔力。 對於更遠的值，您可以定期檢查並查看增加值，然後在您可能開始顯示為通過時進行投影。

CrUX 也可作為免費 API 獲得，以獲得這些百分比的更精確數字。 註冊 API 密鑰後，您可以使用如下 curl 命令調用它（根據需要替換 API_KEY、formFactor 和 URL）：

 curl -s --request POST 'https://chromeuxreport.googleapis.com/v1/records:queryRecord?key=API_KEY' \ --header 'Accept: application/json' \ --header 'Content-Type: application/json' \ --data '{"formFactor":"PHONE","url":"https://www.example.com"}'

你會得到一個 JSON 響應，像這樣：

 { "record": { "key": { "formFactor": "PHONE", "url": "https://www.example.com/" }, "metrics": { "cumulative_layout_shift": { "histogram": [ { "start": "0.00", "end": "0.10", "density": 0.99959769344240312 }, { "start": "0.10", "end": "0.25", "density": 0.00040230655759688886 }, { "start": "0.25" } ], "percentiles": { "p75": "0.00" } }, "first_contentful_paint": { ... } } }, "urlNormalizationDetails": { "originalUrl": "https://www.example.com", "normalizedUrl": "https://www.example.com/" } }

順便說一句，如果上面的內容讓您有些害怕，並且您想要一種更快的方法來查看僅一個 URL 的這些數據，那麼 PageSpeed Insights 還會返回此精度，您可以通過打開 DevTools 然後運行 PageSpeed Insights 測試來查看該精度，並且找到它發出的 XHR 調用：

還有一個交互式 CrUX API 瀏覽器，允許您對 CrUX API 進行示例查詢。 不過，對於 API 的常規調用，獲取免費密鑰並使用 Curl 或其他一些 API 工具通常更容易。

API 也可以使用“來源”而不是 URL 來調用，此時它將給出對該域的所有頁面訪問的匯總值。 PageSpeed Insights 會公開此信息，如果您的 URL 沒有可用的 CrUX 信息，但 Google Search Console 沒有，這可能會很有用。 谷歌沒有（也不太可能！）確切地說明 Core Web Vitals 將如何影響排名。 原始級別分數會影響排名，還是僅影響單個 URL 分數？ 或者，當個別 URL 數據不存在時，Google 是否會像 PageSpeed Insights 一樣退回到原始級別分數？ 目前很難知道，到目前為止唯一的提示是常見問題解答中的這個：

問：如何為最近發布但尚未生成 28 天數據的 URL 計算分數？

答：與 Search Console 報告頁面體驗數據的方式類似，我們可以採用諸如對相似的頁面進行分組並根據該聚合計算分數等技術。 這適用於幾乎沒有流量的頁面，因此沒有字段數據的小型站點無需擔心。

CrUX API 可以通過編程方式調用，來自 Google CrUX 團隊的 Rick Viscomi 創建了一個 Google Sheets 監視器，允許您批量檢查 URL 或來源，如果您想密切監視多個 URL 或來源，甚至可以隨時間自動跟踪 CrUX 數據. 只需克隆工作表，進入Tools → Script編輯器，然後使用您的密鑰輸入CRUX_API_KEY的腳本屬性（這需要在舊版編輯器中完成），然後運行腳本，它將調用給定的 CrUX API URL 或來源，並將行與數據一起添加到工作表的底部。 然後可以定期運行或安排定期運行。

我用它來檢查一個站點的所有 URL，在 Google Search Console 中更新緩慢的 Core Web Vitals 報告，它確認 CrUX 沒有很多 URL 的數據，其餘的大部分都通過了，所以再次顯示谷歌搜索控制台報告落後了——即使是它應該基於的 CrUX 數據。 我不確定這是否是由於以前失敗的 URL 但現在沒有足夠的流量來獲取顯示它們通過的更新的 CrUX 數據，或者是由於其他原因，但這向我證明了這個報告肯定很慢。

我懷疑其中很大一部分是由於 CrUX 中沒有數據的 URL 和 Google 搜索盡力為它們代理價值。 因此，此報告是開始了解您的站點的好地方，也是監控未來的好地方，但對於解決您需要更即時反饋的問題來說，它不是一個很好的報告。

對於那些想要深入研究 CrUX 的人，BigQuery 中提供了月度 CrUX 數據表（僅在原始級別，因此不適用於單個 URL），Rick 還記錄瞭如何根據可以創建的 CrUX 儀表板是監控幾個月來您的整體網站性能的好方法。

有關 Crux 數據的其他信息

因此，通過以上內容，您應該對 CrUX 數據集有一個很好的了解，為什麼使用它的一些工具似乎更新緩慢且不穩定，以及如何進一步探索它。 但在我們繼續討論它的替代方案之前，還有一些關於 CrUX 的知識需要了解，以幫助您真正理解它所顯示的數據。 因此，這裡是我收集的有關 CrUX 與 Core Web Vitals 相關的其他有用信息的集合。

CrUX 僅適用於 Chrome 。 所有這些 iOS 用戶和其他瀏覽器（Desktop Safari、Firefox、Edge 等），更不用說舊版瀏覽器（Internet Explorer - 快點淡出你會不會！）沒有將他們的用戶體驗反映在 CrUX 數據中等等關於 Google 對 Core Web Vitals 的看法。

現在，Chrome 的使用率非常高（儘管可能不適合您的網站訪問者？），並且在大多數情況下，它突出顯示的性能問題也會影響其他瀏覽器，但需要注意這一點。 至少可以說確實有點“噁心”，谷歌在搜索領域的壟斷地位現在正在鼓勵人們優化他們的瀏覽器。 我們將在下面討論這種有限視圖的替代解決方案。

正在使用的 Chrome 版本也會產生影響，因為這些指標（尤其是 CLS）仍在不斷發展，並且正在發現和修復錯誤。 這為理解數據增加了另一個維度的複雜性。 在最近的 Chrome 版本中對 CLS 進行了持續改進，在 Chrome 91 中對 CLS 進行了更大的重新定義。再次使用現場數據這一事實意味著這些更改可能需要一些時間才能傳遞給用戶，並且然後進入CrUX數據。

CrUX 僅適用於登錄 Chrome 的用戶，或引用實際定義：

“[CrUX 是] 從選擇同步瀏覽歷史、未設置同步密碼並啟用使用統計報告的用戶匯總而成。”

— Chrome 用戶體驗報告，谷歌開發者

因此，如果您正在尋找一個主要從企業網絡訪問的網站上的信息，而這些設置被中央 IT 政策關閉，那麼您可能看不到太多數據——尤其是如果那些可憐的企業用戶仍然被迫使用互聯網探險家也！

CrUX 包括所有頁面，包括那些通常不出現在 Google 搜索中的頁面，例如“將包括無索引/被盜用/登錄的頁面”（儘管在 CrUX 中公開 URL 和來源的最低閾值）。 現在這些頁麵類別可能不會包含在 Google 搜索結果中，因此對它們的排名影響可能並不重要，但它們仍然會包含在 CrUX 中。 然而，Google Search Console 中的 Core Web Vitals 報告似乎只顯示索引 URL ，因此它們不會出現在那裡。

PageSpeed Insights 和原始 CrUX 數據中顯示的原始數據將包括那些未編入索引的非公開頁面，正如我上面提到的，我們不確定其影響。 我工作的一個網站有很大比例的訪問者訪問我們的登錄頁面，雖然公共頁面的性能非常好，但登錄頁面卻沒有，這嚴重扭曲了原始 Web Vitals 分數。

CrUX API 可用於獲取這些登錄 URL 的數據，但 PageSpeed Insights 等工具不能（因為它們運行實際瀏覽器，因此將被重定向到登錄頁面）。 一旦我們看到 CrUX 數據並意識到影響，我們就修復了這些數據，原始數據開始下降，但與以往一樣，需要時間來反饋。

沒有索引或登錄的頁面也通常是“應用程序”，而不是單獨的頁面集合，因此可能會使用具有一個真實 URL 的單頁面應用程序方法，但其下有許多不同的頁面。 這尤其會影響 CLS，因為它是在頁面的整個生命週期內進行測量的（儘管希望即將對 CLS 進行的更改將對此有所幫助）。

如前所述，Google Search Console 中的 Core Web Vitals 報告雖然基於 CrUX，但絕對不是相同的數據。 正如我之前所說，我懷疑這主要是由於 Google Search Console 試圖為不存在 CrUX 數據的 URL 估計 Web Vitals。 此報告中的示例 URL 也與 CrUX 數據不符。

I've seen many instances of URLs that have been fixed, and the CrUX data in either PageSpeed Insights, or directly via the API, will show it passing Web Vitals, yet when you click on the red line in the Core Web Vitals report and get sample URLs these passing URLs will be included as if they are failing . I'm not sure what heuristics Google Search Console uses for this grouping, or how often it and sample URLs are updated, but it could do with updating more often in my opinion!

CrUX is based on page views . That means your most popular pages will have a large influence on your origin CrUX data. Some pages will drop in and out of CrUX each day as they meet these thresholds or not, and perhaps the origin data is coming into play for those? Also if you had a big campaign for a period and lots of visits, then made improvements but have fewer visits since, you will see a larger proportion of the older, worse data.

CrUX data is separated into Mobile , Desktop and Tablet — though only Mobile and Desktop are exposed in most tools. The CrUX API and BigQuery allows you to look at Tablet data if you really want to, but I'd advise concentrating on Mobile and then Desktop. Also, note in some cases (like the CrUX API) it's marked as PHONE rather than MOBILE to reflect it's based on the form factor, rather than that the data is based on being on a mobile network.

All in all, a lot of these issues are impacts of field (RUM) data gathering, but all these nuances can be a lot to take on when you've been tasked with “fixing our Core Web Vitals”. The more you understand how these Core Web Vitals are gathered and processed, the more the data will make sense, and the more time you can spend on fixing the actual issues, rather than scratching your head wondering why it's not reporting what you think it should be.

Getting Faster Feedback

OK, so by now you should have a good handle on how the Core Web Vitals are collected and exposed through the various tools, but that still leaves us with the issue of how we can get better and quicker feedback. Waiting 21–28 days to see the impact in CrUX data — only to realize your fixes weren't sufficient — is way too slow. So while some of the tips above can be used to see if CrUX is trending in the right direction, it's still not ideal. The only solution, therefore, is to look beyond CrUX in order to replicate what it's doing, but expose the data faster.

There are a number of great commercial RUM products on the market that measure user performance of your site and expose the data in dashboards or APIs to allow you to query the data in much more depth and at much more granular frequency than CrUX allows. I'll not give any names of products here to avoid accusations of favoritism, or offend anyone I leave off! As the Core Web Vitals are exposed as browser APIs (by Chromium-based browsers at least, other browsers like Safari and Firefox do not yet expose some of the newer metrics like LCP and CLS), they should, in theory, be the same data as exposed to CrUX and therefore to Google — with the same above caveats in mind!

For those without access to these RUM products, Google has also made available a Web Vitals JavaScript library, which allows you to get access to these metrics and report them back as you see fit. This can be used to send this data back to Google Analytics by running the following script on your web pages:

 <script type="module"> import {getFCP, getLCP, getCLS, getTTFB, getFID} from 'https://unpkg.com/web-vitals?module'; function sendWebVitals() { function sendWebVitalsGAEvents({name, delta, id, entries}) { if ("function" == typeof ga) { ga('send', 'event', { eventCategory: 'Web Vitals', eventAction: name, // The `id` value will be unique to the current page load. When sending // multiple values from the same page (eg for CLS), Google Analytics can // compute a total by grouping on this ID (note: requires `eventLabel` to // be a dimension in your report). eventLabel: id, // Google Analytics metrics must be integers, so the value is rounded. // For CLS the value is first multiplied by 1000 for greater precision // (note: increase the multiplier for greater precision if needed). eventValue: Math.round(name === 'CLS' ? delta * 1000 : delta), // Use a non-interaction event to avoid affecting bounce rate. nonInteraction: true, // Use `sendBeacon()` if the browser supports it. transport: 'beacon' }); } } // Register function to send Core Web Vitals and other metrics as they become available getFCP(sendWebVitalsGAEvents); getLCP(sendWebVitalsGAEvents); getCLS(sendWebVitalsGAEvents); getTTFB(sendWebVitalsGAEvents); getFID(sendWebVitalsGAEvents); } sendWebVitals(); </script>

Or alternatively, you can include this as an external script instead:

 <script type="module" src="/javascript/send-web-vitals.js"></script>

Now I realize the irony of adding another script to measure the impact of your website, which is probably slow in part because of too much JavaScript, but as you can see above, the script is quite small and the library it loads is only a further 1.7 kB compressed (4.0 kB uncompressed). Additionally, as a module (which will be ignored by older browsers that don't understand web vitals), its execution is deferred so shouldn't impact your site too much, and the data it can gather can be invaluable to help you investigate your Core Web Vital, in a more real-time manner than the CrUX data allows.

The script registers a function to send a Google Analytics event when each metric becomes available. For FCP and TTFB this is as soon as the page is loaded, for FID after the first interaction from the user, while for LCP and CLS it is when the page is navigated away from or backgrounded and the actual LCP and CLS are definitely known. You can use developer tools to see these beacons being sent for that page, whereas the CrUX data happens in the background without being exposed here.

The benefit of putting this data in a tool like Google Analytics is you can slice and dice the data based on all the other information you have in there, including form factor (desktop or mobile), new or returning visitors, funnel conversions, Chrome version, and so on. And, as it's RUM data, it will be affected by real usage — users on faster or slower devices will report back faster or slower values — rather than a developer testing on their high spec machine and saying it's fine.

At the same time, you need to bear in mind that the reason the CrUX data is aggregated over 28 days, and only looks at the 75th percentile is to remove the variance. Having access to the raw data allows you to see more granular data , but that means you're more susceptible to extreme variations. Still, as long as you keep that in mind, keeping early access to data can be very valuable.

Google's Phil Walton created a Web-Vitals dashboard, that can be pointed at your Google Analytics account to download this data, calculate the 75th percentile (so that helps with the variations!) and then display your Core Web Vitals score, a histogram of information, a time series of the data, and your top 5 visited pages with the top elements causing those scores.

Using this dashboard, you can filter on individual pages (using a ga:pagePath==/page/path/index.html filter), and see a very satisfying graph like this within a day of you releasing your fix, and know your fix has been successful and you can move on to your next challenge!:

With a little bit more JavaScript you can also expose more information (like what the LCP element is, or which element is causing the most CLS) into a Google Analytics Custom Dimension. Phil wrote an excellent Debug Web Vitals in the field post on this which basically shows how you can enhance the above script to send this debug information as well, as shown in this version of the script.

These dimensions can also be reported in the dashboard (using ga:dimension1 as the Debug dimension field, assuming this is being sent back in Google Analytics Customer Dimension 1 in the script), to get data like this to see the LCP element as seen by those browsers:

正如我之前所說，商業 RUM 產品也經常會暴露這類數據（甚至更多！），但對於那些剛剛涉足並沒有準備好承擔這些產品的財務承諾的人來說，這至少提供了第一次涉獵深入了解基於 RUM 的指標，以及它們在獲得有關您正在實施的改進的關鍵更快反饋方面的有用性。 如果這激起了您對這些信息的興趣，那麼一定要看看其他 RUM 產品，看看它們也能如何幫助您。

在查看替代測量和 RUM 產品時，請記住回到 Google 為您的網站看到的內容，因為它可能會有所不同。 在性能上努力工作，卻沒有同時獲得所有排名優勢，這將是一種恥辱！ 因此，請密切關注這些 Search Console 圖表，以確保您不會遺漏任何內容。

結論

Core Web Vitals 是一組有趣的關鍵指標，旨在代表用戶瀏覽網絡的體驗。 作為一個熱心的網絡性能倡導者，我歡迎任何提高網站性能的努力，這些指標的排名影響無疑在網絡性能和 SEO 社區中引起了轟動。

雖然指標本身非常有趣，但更令人興奮的是使用 CrUX 數據來衡量這些指標。 這基本上將 RUM 數據暴露給以前從未考慮過以這種方式測量現場性能的網站。 RUM 數據是用戶在其所有狂野和多樣的設置中實際體驗的內容，並且沒有什麼可以替代了解您的網站的實際性能和用戶體驗。

但是我們這麼長時間以來一直如此依賴實驗室數據的原因是因為 RUM 數據是嘈雜的。 CrUX 為減少這種情況而採取的措施確實有助於提供更穩定的視圖，但代價是難以看到最近的變化。

希望這篇文章能夠以某種方式解釋訪問您網站的 Core Web Vitals 數據的各種方法，以及每種方法的一些限制。 我也希望它能夠以某種方式解釋您一直在努力理解的一些數據，並提出一些解決這些限制的方法。

快樂優化！