瞭解 RUM 資料為何顯示不同的 Core Web Vitals 數值，與 CrUX 相同。
Chrome 使用者體驗報告 (CrUX) 可以提供使用者體驗指標，讓 Chrome 使用者實際瞭解造訪熱門網路網頁的情形。Chrome 會根據 CrUX 資格條件自動收集這些使用者的資料。
因此，CrUX 資料適用於數百萬個網站。許多網站擁有者過去都無法存取欄位資料，因此 CrUX 開放許多網站首次瞭解這項技術的價值。CrUX 可做為公開資料集，也能用來進行競爭分析，以及針對使用者體驗指標進行基準測試。
實際使用者監控 (RUM) 與 CrUX 類似，但網站會加入程式碼來進行這項收集作業，並將資料傳回 RUM 供應商或分析解決方案供進一步分析，而不是 Chrome 自動收集使用者體驗指標。
不論是使用這兩種解決方案來評估使用者體驗指標，一般都會假設兩者應該要對等。如果發現差異，您可能會感到困惑。本指南將說明可能的可能原因，並提供數字不一致時的處理方式。
以 RUM 解決方案輔助 CrUX 的好處
CrUX 是絕佳的工具，可讓您在網站上提供一致的檢視畫面，且如同 Core Web Vitals 計畫的官方資料集，網站可能會想隨時留意其中顯示的內容。CrUX 的目標是針對數百萬個網站提供具有統計關聯性的總覽，以便進行交叉比較。
不過，如要深入瞭解調查「為什麼」資料會顯示數據，建議您投資完整的 RUM 解決方案來補充 CrUX 資料，藉此取得比在可公開查詢資料集中取得的詳細資訊。這麼做能以多種方式說明並改善指標。
對問題進行更深入的分析
網站有問題時，通常可用來指出問題所在，但不一定是網站上問題的正確位置或原因。無論是透過 Web-Vitals 程式庫還是許多商業產品自行開發的 RUM 解決方案，都有助於彌補這樣的落差。
只要使用 RUM 解決方案，您就能針對所有網頁和瀏覽器存取更精細的資料。您也可以透過 CrUX 未採用的方式細分這項資料，以便深入瞭解並調查網站上的問題區域。他們是否受到特定族群的影響？還是採取特定行動的使用者？問題從何時開始？這些是 RUM 工具可提供的其他資料，更易於回答的問題。
與其他業務指標相關
您也可以使用 RUM 來比較網站效能指標與任何業務指標，瞭解投資成效的價值，以及需要優先考量哪些成效。我們有許多與這類企業有關的個案研究，例如 Farfetch 或 The Economic Times。
收集其他效能資料
RUM 解決方案可讓您收集與特定業務有直接關聯的其他自訂指標。其中一個知名的範例是 Twitter 的「首次張貼 Twitter 訊息的時間」指標。接著，這些網站專屬措施可與 Core Web Vitals 改善項目和業務指標建立關聯。
兩組欄位資料之間的差異
戴著智慧手錶的男子知道現在時間了。拿著兩支手錶的男子不確定何時會這麼做。
塞加爾法律
資料來源有兩個資料來源時，常會令人困惑和難以置信，以及背後的原因。請務必瞭解研究室和實際指標之間的差異，大同小異，同樣地，我們也發現兩個「現場」資料來源也有差異。雖然理想情況下的資料會完全相同，但有許多原因可能有所差異。
實驗資料與實際現場資料
首先，我們要檢查您是否查看研究室 (合成) 指標或領域 (RUM) 指標。我們假設 RUM 產品只會查看現場資料，但許多產品也提供實驗室元件。
研究室資料會根據用於評估的固定條件，因此非常實用。這可用於監控實際工作環境中的非預期變化或迴歸，而且不會產生瞬息萬變的現場填入作業。不過，研究室資料不一定能反映實際使用者體驗，因此實際數據顯示的結果可能大不相同。
人口數
CrUX 和 RUM 解決方案用來評估網頁造訪次數，會因比較的瀏覽器、使用者、網站和裝置而異，因此可能有所不同。
包含的瀏覽器
顧名思義，《Chrome 使用者體驗報告》中僅適用於 Chrome。雖然有許多以 Chromium 為基礎的瀏覽器 (例如 Edge、Opera 和 Brave 所命名)，但就共用核心程式碼集而言，支援與 Chrome 相同的指標，但只有 Chrome 使用者會將資料傳送至 CrUX 中。此外，這項限制也代表 iOS 裝置的 Chrome 使用者並未納入其中，因為這項限制採用基礎 Webkit 瀏覽器引擎。此外，Android WebView 也不算是「Chrome」，因此這些使用者的資料不會包含在內，但包括 Chrome 自訂分頁。
雖然 Chrome 是全球最熱門的瀏覽器之一，因此在大多數情況下，可能會更廣泛地呈現網站效能，不過這只是評估瀏覽器並非用來評估所有使用者的一種。這可能解釋了 RUM 和 CrUX 之間的主要差異。如果是依賴 Chrome 專屬 API 或圖片格式的效能技術，這一點尤其重要。
缺少 iOS 資料也可能導致偏見。舉例來說，由於 iOS 使用者通常使用效能較差的裝置，或造訪來自更多國家/地區且網路基礎架構較佳，包括這類裝置可獲得較高的整體成效指標。另一方面，CrUX 的「排除」這些特徵，也可能會導致網站訪客暴露在低端的資料 (個案研究範例)。Android 使用者通常支援更多裝置、裝置功能和市場。
RUM 解決方案可取得非 Chrome 瀏覽器的資料，尤其是在內建相同指標 (例如 Core Web Vitals) 的 Chromium 瀏覽器中。非 Chromium 瀏覽器也是由 RUM 解決方案評估，但可使用的指標可能有限。舉例來說，目前只有以 Chromium 為基礎的瀏覽器支援累計版面配置位移 (CLS) 和 Intraction to Next Paint (INP)。首次顯示內容所需時間 (FCP) 等其他指標的評估方式可能相當不同 (將於稍後說明)。
選擇加入的使用者
除了 Chrome 使用者以外，CrUX 也只會測量安裝瀏覽器時選擇分享 CrUX 資料的部分 Chrome 使用者。
此外，RUM 供應商只會注意部分使用者，通常是因為 Cookie 橫幅提示 (要求使用者選擇啟用 RUM 資料收集) 或追蹤攔截器所致。如未等到第二個或後續網頁才進行確認，且部分網站素材資源已從先前網頁快取的話，這可能會對部分初始網頁載入作業造成負面影響。如果這種情況經常發生，那麼在一定數量的情況下，如果網頁載入速度較慢，就代表 RUM 指標的表現可能比較好。
包含的網站
CrUX 只能用於公開網站報表，因此還有其他資格條件可能導致 CrUX 資料無法記錄。其中最值得注意的是，網站必須公開其可搜尋，且擁有足夠的熱門程度，如此可確保獲得有意義的結果時，樣本數必須少得最少。在大多數情況下，這會導致 CrUX 沒有可用的資料。與可用資料相比，這較不容易造成混淆，但解釋原因。
不過，如果網站的特定網頁標示為可建立索引，但其他網頁卻沒有，那麼你在 CrUX 可能只會看到一部分網址。如果來源可公開搜尋，則該來源中的所有網頁瀏覽量都會納入來源層級資料，但可能無法提供網址層級資料。
裝置
CrUX 區隔資料會按行動裝置、電腦和平板電腦區分，但許多工具主要都集中在前兩項，因此可能不會暴露平板電腦資料，或甚至會包含在行動裝置或電腦上。在行動裝置和電腦上，成效差異可能大不相同，包括放送的內容，以及觀看這些內容的裝置能力。
RUM 資料允許使用類似區隔流量的方式，但預設會顯示合併資料。RUM 可能只允許按裝置類型 (例如行動裝置) 或瀏覽器 (例如 Chrome) 進行區隔，無法同時查看行動版 Chrome 流量。與 CrUX 資料比較時，請務必依裝置類型「和」Chrome 瀏覽器進行篩選，這樣您才能以相同方式進行比較。
取樣
一般來說，RUM 解決方案可讓您針對選擇加入的訪客 (也就是收集資料) 調整取樣率。這有助於減少分析所需的資料量，並降低商用 RUM 服務的費用。如果樣本數量太小，無法代表更多人口，則產生的指標也會出現類似偏差。與 RUM 供應商討論您網站上的取樣大小。
匯總資料
相較於研究室資料，欄位資料性質上有許多相同的指標，因此能產生單一值。如果這些資料的匯總方式不同，可能會導致 CrUX 和 RUM 之間出現其他差異。
時間範圍
CrUX 資料是以 28 天的滑動區間為依據，您無法變更這個時間範圍，不過系統會儲存每個月的 CrUX BigQuery 資料，讓您查看過去幾個月的資料，CrUX History API 也提供每週的歷來資料。兩者都會根據 28 天滑動區間提供資料。
RUM 資料通常允許更精細，方便您更快看到變更所帶來的影響。不過，如果選擇較短的期間，訪客人數和訪客的波動就不會對 RUM 資料產生明顯的影響。比較 RUM 資料與 CrUX 資料時，請務必留意 28 天的成效表現。如果對資料感到滿意，可以參考其他時間範圍來細查 RUM 資料。
匯總統計資料
CrUX 指標是在第 75 個百分位數計算，也就是衡量 75% 網頁瀏覽量的價值。現場資料將存在極端主義，並移除最壞的 25% 體驗，目的是為大多數訪客提供合理的價值，以期為大多數訪客提供合理的價值。
RUM 產品通常提供更多指標的匯總選項，包括第 75 個百分位數、中位數和其他百分位數。如要比較 RUM 值與 CrUX 資料，您必須確實查看第 75 個百分位數的資料，然後進行比較。
CrUX 的直方圖資料包含所有可用資料，而不只是第 75 個百分位數，顯示每個評分的瀏覽量，匯總分數則是根據第 75 個百分位數計算。這項 CrUX 資料會顯示在 PageSpeed Insights 等工具中：
指標差異
評估網站效能時有許多指標，因此在比較兩組資料時，請務必瞭解評估的指標和使用指標的方式。
評估的指標
CrUX 資料是網站體驗核心指標計畫的官方資料集，主要評估這些指標 (LCP、CLS 和 INP)，並搭配一些其他指標來補充這些指標。
RUM 工具通常包含這些網站體驗核心指標，但通常也會包含許多其他指標。部分 RUM 供應商也會使用自己的各種指標組合來評估使用者體驗，或許是為了建立「快樂指數」等等。比較 RUM 資料與 CrUX 時，請務必進行比較
用來評估網站體驗核心指標通過/失敗狀態的工具，如果網頁達到所有 Core Web Vitals 指標的第 75 個百分位數建議目標，則應視為通過網頁通過。如果沒有任何互動的網頁沒有 INP，則只有 LCP 和 CLS 需要傳送。
不同瀏覽器的指標差異
CrUX 只能評估 Chrome 瀏覽器，您可以參閱網站體驗指標變更記錄，瞭解每個 Chrome 版本的變更情形。
不過，RUM 解決方案會使用更多種瀏覽器進行評估。除非 Chrome 導入了變更記錄中所述的更新內容，否則以 Chromium 為基礎的瀏覽器 (Edge、Opera 等) 可能會與 Chrome 類似。
如果是非 Chromium 瀏覽器，差異會更明顯。舉例來說，首次顯示內容所需時間 (FCP) 適用於 Safari 和 Firefox，但評估方式不同。這可能會導致報表時間出現大幅差異。如前所述，如果您想比較 RUM 與 CrUX 架構，最好僅篩選出 Chrome 使用者，以便進行同類比較。
指標時間
網站體驗核心指標是由網路瀏覽器 API 提供，但這並不表示使用這些指標回報的值不會有差異。評估指標時 (無論是在網頁載入時或整個網頁生命週期)，都可能會造成差異。RUM 工具不一定會以相同方式評估指標，即使使用相同的名稱，且取得的資料也可能因為使用同樣的瀏覽器 API 而產生混淆。
最大內容繪製 (LCP) 是網頁載入指標。如果系統在初始轉譯之後才載入較大的元素，則 Web API 可以回報一些 LCP 元素。最後一個 LCP 元素是指網頁載入完成或使用者與網頁互動時。因此，如果 LCP 元素較舊回報和這兩種事件的資料，可能就會產生差異。
此外，根據網頁的載入方式，欄位資料中的 LCP 元素可能會有所不同。如果預設載入網頁時會顯示網頁內容頂端，LCP 元素主要取決於螢幕尺寸。不過，如果該網頁是透過文件下方的錨定連結開啟，或透過單一頁面應用程式 (SPA) 的深層連結開啟 (稍後詳細介紹)，則 LCP 元素可能會有所不同。
請勿假設 CrUX 或 RUM 中提供的 LCP 時間與研究室工具相同。CrUX 會顯示每個網頁或來源的整體 LCP 價值，RUM 還能進一步區隔，找出個別 LCP 問題工作階段。
累計版面配置位移 (CLS) 的整個生命週期皆會測量一次，因此在網頁載入後段 CLS，可能就無法代表網頁載入後段以及使用者與網頁互動後轉移時間較長的網頁。如同許多 RUM 產品一樣，只在網頁載入之後才擷取 CLS 值，因此產生的結果，會與使用者完成網頁後擷取 CLS 的值不同。
「與下一個顯示的內容互動」(INP) 回應指標需要輸入內容才能進行評估，並觀察網頁整個生命週期中的所有點擊、輕觸和鍵盤互動情形 (採用與 CLS 類似)。因此，若在使用者在網頁上進行多次互動後衡量，INP 回報的值可能大不相同。
CrUX 會遵循網站體驗核心指標說明文件，在網頁的完整生命週期內進行評估。許多 RUM 供應商會基於各種原因，選擇在網頁載入後或其他時間 (例如按下重要行動號召時) 評估這些指標。
看到兩個資料來源之間出現無法解釋的差異時，請務必向 RUM 供應商瞭解他們評估網站體驗核心指標的時間。
單頁應用程式
單頁應用程式 (SPA) 的運作方式是更新目前網頁上的內容，而不是在瀏覽器層級進行傳統網頁瀏覽。也就是說，即便使用者遇到這種瀏覽方式，瀏覽器也不會將其視為網頁瀏覽。瀏覽器提供的 Core Web Vitals API 不會將這些 API 納入考量，因此 CrUX 並不支援這類網頁瀏覽功能。我們正設法解決這個問題，詳情請參閱《測試微型導覽功能的實驗》一文。
部分 RUM 供應商會試圖偵測 SPA 中的「軟導覽」，但如果他們同時也將網站體驗核心指標指標歸因於「軟導覽」的指標，就會與 CrUX 不同，因為基礎 API 對許多指標都不支援這項技術。
CrUX 和 Web API 差異
除了評估網頁瀏覽的「類型」與評估的「內容」差異外，還有其他幾種更複雜的情境需要留意，這會導致 CrUX 和 RUM 資料出現差異。其中有些是因為用於測量指標的 Web API 有所限制，有些是因為 API 傳回的結果需要在特定情況下以不同方式處理。網站體驗核心指標說明文件列出了 LCP 和 CLS 的這些差異，不過主要差異如下。
往返快取
CrUX 會將往返快取 (或 bfcache) 視為網頁瀏覽並還原，即使無法帶來傳統的網頁載入也一樣。由於 Web API 不會將這些內容視為網頁載入，因此 RUM 解決方案需要採取額外步驟，才能計算這些網頁符合 CrUX 模式的資料。這可能會大幅加快網頁載入速度，報表的整體成效表現會因此提升，因此若不納入這些網頁，可能會導致整體網頁效能指標下降。請查看您的 RUM 解決方案，瞭解該解決方案是否會處理 Bfcache 還原的網頁。
iframe
基於安全性和隱私權的考量，頂層網頁並無法存取 iframe 中的內容 (即使是相同來源的 iframe)。也就是說，這些內容的成效指標只能以 iframe 本身進行評估，而無法透過頁框上的 Web API 進行評估。如果 iframe 內容含有 LCP 元素，或是會影響使用者 CLS 或 INP 的內容，RUM 解決方案 (包括 Google Web Vitals 程式庫) 不會提供這些內容。
不過，CrUX 評估的是 Chrome 瀏覽器本身 (而非網頁中的 JavaScript)，因此在回報網站體驗核心指標時，不會考慮 iframe 內的指標。雖然這樣能更精確地反映使用者體驗，但也可能是網站使用 iframe 後出現差異的另一項原因。
嵌入 <video> 中有一個具體範例，說明此做法如何導致 CrUX 和 RUM 中的資料不一致。自動播放 <video> 元素的第一個繪製影格可計為 LCP 候選項目，但熱門影片串流服務的嵌入可能會將這些元素置於 <iframe> 中。CrUX 可考量到這一點，因為其可以存取 <iframe> 內容，但 RUM 解決方案無法存取。
跨來源資源
由於瀏覽器安全性限制，為了縮短時間攻擊，從其他網域提供的 LCP 媒體不會在 PerformanceObserver API 中提供轉譯時間 (除非提供了 Timing-Allow-Origin 標頭 (TAO)。)這會回到資源的載入時間，但這可能與內容實際繪製的時間大不相同。
這可能會導致看似不可能的情況，也就是網路 API 回報 LCP 低於 FCP。情況並非如此，只是因為有這項安全性限製而顯示出來。
同樣的，CrUX 會記錄網站體驗核心指標的轉譯時間資料。我們建議網站限制會影響 Core Web Vitals 指標的跨來源內容，如果希望更準確地評估這項數據，請盡可能啟用 TAO。其他跨來源資源可能有類似的限制。
背景分頁
如未在背景分頁中開啟網頁，則仍會使用 Web API 產生指標。不過，CrUX 並不回報這些事件，因為它們提供的時間與使用者體驗不一致。RUM 解決方案也應考慮忽略這些項目，或至少說明我們如何處理這些網頁瀏覽量。
該怎麼做呢？
我們已經說明 CrUX 和 RUM 資料可能會因為不同方法不同，或是納入/排除使用者和網頁瀏覽計算的原因。在理想情況下，這兩組資料仍足以代表網站成效，但本文將概述為何要分別取得相同數據。
在些微差異的情況下 (例如將 LCP 回報為 2.0 秒或 2.2 秒)，兩個資料集就非常實用，可以視為大致同步。
如果發音的差異會讓你質疑資料的準確性，建議你試著瞭解這些差異。是否可以篩選 RUM 資料，更符合 CrUX 環境 (僅檢視 Chrome 使用者、電腦或行動裝置，且 28 天內的第 75 個百分位數值) 來減少這些差異？
如果有，而且您可以取得更密切的資料比對結果，但您還是應該詢問為何在整體資料中看到這些差異，以及這是什麼意思。非 Chrome 使用者認為您的指標有正面或負面的感受？這是否有助於您進一步瞭解發生效能問題時可以優先處理的問題？
如果非 Chrome 使用者取得的結果不同，您可以參考 RUM 提供的寶貴資訊，瞭解如何以不同方式最佳化設定。舉例來說，某些瀏覽器不支援某些 API，但您可以考慮改用其他方法，藉此改善這些瀏覽器的使用體驗。也可以為受限裝置或網路的使用者提供不同但效能更佳的體驗。CrUX 僅限於 Chrome 資料，但您應考量網站訪客的所有體驗，並據以排定改善的優先順序。RUM 資料可以填補這個缺口。
瞭解造成差異的原因後，這兩項工具就能極為實用，協助您瞭解網站的使用者體驗；即使數據不一致，也有助於改善這一點。使用 RUM 資料來補充 CrUX 資料，並藉由區隔流量來概略瞭解 CrUX 可呈現的內容，以協助您判斷其是否屬於網站或應用程式的特定區域，或需要注意的使用者群。
相較於讓兩個資料來源之間的數字一致，查看趨勢來瞭解成效可帶來預期的正面影響，如上所述，RUM 可讓您查看不同時間範圍，進而預先查看過去 28 天的 CrUX 評分。不過，如果觀察時間範圍太短，可能會導致資料雜亂無章，進而使 CrUX 只使用 28 天。
在這些指標中，通常沒有「正確」或「錯誤」的答案，這只是從有別於使用者的角度看待您的網站，以及他們造訪您網站的方式。只要您瞭解造成差異的原因，以及如何在決策過程中做出決定，這種做法就更加重要，為網站訪客提供更完善的服務。
特別銘謝
Steven Lelham 於 Unsplash 提供的縮圖