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