瞭解 RUM 資料與 CrUX 顯示的 Core Web Vitals 數值不同的原因。
Chrome 使用者體驗報告 (CrUX) 提供使用者體驗指標，說明 Chrome 使用者實際造訪熱門網頁的體驗。Chrome 會從使用者選擇加入這類資料後，自動收集這些資料，並根據 CrUX 資格條件提供。
因此，CrUX 資料可供數百萬個網站使用。許多網站擁有者之前都沒有存取欄位資料的權限，而 CrUX 讓許多網站首次看到這項功能的價值。CrUX 也可用於公開資料集，藉此進行使用者體驗指標的競爭分析及基準測試。
即時使用者監控 (RUM) 與 CrUX 相似，但由於不是 Chrome 自動收集使用者體驗指標，而是在網站上加入程式碼，以便進行這項收集作業，並提供給 RUM 供應商或數據分析解決方案供進一步分析。
這兩項解決方案都會評估使用者體驗指標，因此很自然地會假設兩者應該是等同的。如果我們發現差異，可能會讓使用者感到困惑。本指南將說明發生這種情況的原因，並提供當數字不一致時的建議處理方式。
使用 RUM 解決方案補足 CrUX 的優點
CrUX 是用於跨網站查看一致資料的絕佳工具，也是 Core Web Vitals 計畫的官方資料集，因此網站可能會想密切留意 CrUX 顯示的資料。CrUX 的目標是提供具有統計意義的數百萬個網站總覽資訊，以便進行交叉比較。
不過，如果想更深入瞭解為何資料會顯示統計數字，建議您投資完整的 RUM 解決方案來補強 CrUX，這樣就能取得比可公開查詢資料集更詳盡的資訊。這有助您透過多種方式解釋及改善指標。
深入分析以調查問題
CrUX 通常可用於指出網站是否有問題，但不一定能指出問題出在網站的哪個位置，也無法說明問題的原因。無論是透過 Web-Vitals 程式庫或部分商業產品自行開發的 RUM 解決方案，都能有助於消除落差。
使用 RUM 解決方案，您就能在所有瀏覽器上取得所有網頁的更精細資料。您也可以使用這項工具，以 CrUX 無法提供的方式區隔及分析這類資料，進而深入瞭解網站的問題所在。他們是否受特定的使用者區隔影響？或是採取特定動作的使用者？問題是從何時開始出現 (確切的時間點)？有了 RUM 工具提供的額外資料，這些問題就更容易回答。
與其他業務指標相關
此外，RUM 還可讓您直接比較網站成效指標與任何業務指標，瞭解投資成效的價值，以及應優先爭取的成效。我們有許多案例研究，說明商家如何進行這類關聯，例如 Farfetch 或 The Economic Times。
收集其他成效資料
RUM 解決方案可收集其他自訂指標，直接與您的特定業務相關。另一個知名的例子就是 Twitter 的「Time to first Tweet」(第一次 Tweet 訊息的時間) 指標。這些網站專屬指標可與 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 瀏覽器。RUM 解決方案也會評估非 Chromium 架構的瀏覽器，但可能會提供較少的指標。舉例來說，累積版面配置偏移 (CLS) 和Interaction to Next Paint (INP) 僅適用於以 Chromium 為基礎的瀏覽器。其他某些指標 (例如最初內容繪製 (FCP)) 的評估方式也不盡相同 (請參見後續說明)。
已選擇接受的使用者
除了 Chrome 使用者之外，CrUX 還會進一步限制，只評估部分 Chrome 使用者，也就是在安裝瀏覽器時選擇分享 CrUX 資料的使用者。
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 瀏覽器中進行評估，您可以參閱 Web Vitals 變更記錄，瞭解這些指標在各個 Chrome 版本中的變化。
不過，RUM 解決方案會從更多種瀏覽器進行評估。以 Chromium 為基礎的瀏覽器 (Edge、Opera 等) 可能會與 Chrome 相似，除非 Chrome 正在實作變更記錄中所述的新變更。
對於非 Chromium 瀏覽器，差異可能更明顯。舉例來說，首次顯示內容所需時間 (FCP) 可在 Safari 和 Firefox 中使用，但評估方式不同。這可能會導致回報的時間出現大幅差異。如先前所述，如果您想比較 RUM 和 CrUX，建議您只篩選 Chrome 使用者，以便進行類比比較。
指標時間
網站體驗核心指標是由網頁瀏覽器 API 提供，但這並不代表使用這些 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 供應商瞭解 Core Web Vitals 的評估時間。
單頁應用程式
單頁應用程式 (SPA) 的運作方式是更新目前頁面的內容，而不是在瀏覽器層級執行實際的網頁瀏覽。也就是說，即使使用者認為這些是網頁導覽，瀏覽器也不會將這些視為網頁導覽。瀏覽器提供的網站使用體驗核心指標 API 不會將這些因素納入考量，因此 CrUX 不支援這些頁面導覽。我們正在努力解決這個問題，詳情請參閱「嘗試使用導覽式導覽功能評估」一文。
部分 RUM 供應商會嘗試在 SPA 中偵測「軟性導覽」，但如果他們也將 Core Web Vitals 指標歸因於這些「軟性導覽」，就會導致與 CrUX 的差異，因為基礎 API 不支援許多指標。
CrUX 和 Web API 的差異
除了哪些網頁瀏覽次數會被評估，以及評估的內容有所差異之外，還有幾種較複雜的情況需要注意，這些情況可能會導致 CrUX 和 RUM 資料有所差異。有些原因是用於評估指標的 Web API 有所限制，有些時候，API 傳回的結果必須視情況以不同方式處理。核心網頁生命週期指南文件列出了 LCP 和 CLS 的這些差異，但主要差異也列在下列各節中。
往返快取
即使系統不會因往返快取 (或 bfcache) 還原作業而載入傳統網頁，CrUX 仍會將這類作業視為網頁瀏覽。由於 Web API 不會將這些視為網頁載入，因此如果 RUM 解決方案想要與 CrUX 相符，就必須採取額外步驟，才能計算這些網頁。這類網頁的載入速度明顯提升，有助於提升網站的整體成效，因此如果不加入這類網頁，可能會導致整體網頁成效指標下滑。請參閱 RUM 解決方案，瞭解該解決方案是否處理 bfcache 還原的網頁。
Iframe
基於安全性和隱私權考量，頂層網頁無法存取 iframe (甚至是同來源 iframe) 中的內容。也就是說，iframe 中的內容成效指標只能透過 iframe 本身評估，而無法透過框架網頁上的 Web API 評估。如果 iframe 內容包含 LCP 元素，或內容會影響使用者體驗的 CLS 或 INP，則 RUM 解決方案 (包括 Google 網頁 Vitals JavaScript 程式庫) 就無法使用這項功能。
不過，Chrome 瀏覽器本身 (而非網頁上的 JavaScript) 評估 CrUX 不會受到這些限制，因此在回報 Core Web Vitals 時，也會評估 iframe 內的指標。這項做法更能準確反映使用者體驗，但對於使用 iframe 的網站來說，這也可能是造成差異的另一個原因。
其中一個具體範例將說明這會造成 CrUX 和 RUM 中 LCP 資料之間的差異<video>。自動播放的 playsinline <video> 元素第一個繪製的框架可視為 LCP 候選項目，但熱門影片串流服務的嵌入項目可能會將這些元素放在 <iframe> 中。CrUX 可處理這項問題，因為它可以存取 <iframe> 內容，但 RUM 解決方案無法。
跨來源資源
來自其他網域的 LCP 媒體不會在 PerformanceObserver API 中顯示算繪時間，除非提供 Timing-Allow-Origin 標頭 (TAO)，因為瀏覽器的安全限制可減少時間攻擊。這會回溯至資源的載入時間，但這可能與內容實際繪製的時間大不相同。
這可能導致在看似不可能的情況下，網頁 API 回報 LCP 的時間比 FCP 早。實際上並非如此，但由於這項安全性限制，因此會顯示為「是」。
再次提醒，CrUX 會回報 Core Web Vitals 的算繪時間資料。建議網站限制會影響 Core Web Vitals 指標的跨來源內容，並在可能的情況下啟用 TAO，以便更準確地評估這項指標。其他跨來源資源可能適用類似限制。
背景分頁
即使網頁未在背景分頁中開啟，仍會透過 Web API 發出指標。不過，由於這些事件的時間點與使用者體驗不一致，因此 CrUX 不會回報這些事件。RUM 解決方案也應考慮忽略這些事件，或至少說明如何處理這些網頁瀏覽事件。
那麼我們該怎麼做呢？
我們已說明為何 CrUX 和 RUM 資料可能會有差異，這可能是因為每種使用的方法不同，或是納入/排除的使用者和網頁瀏覽次數。理想情況下，兩組資料都會代表網站成效，因此仍有參考價值，但您應說明為何兩組資料的數字不可能完全相同。
如果兩者的差異不大，例如回報 LCP 為 2.0 秒與 2.2 秒的差異，這兩個資料集會很有幫助，通常可以視為兩者的同步差異。
如果差異明顯，讓您懷疑資料的準確性，請嘗試瞭解這些差異。是否可以篩選 RUM 資料，讓資料與 CrUX 更為一致 (只查看桌機或行動裝置的 Chrome 使用者，並以 28 天內的第 75 百分位數值為準)，以減少差異？
如果是這樣，且您可以取得更接近的資料，仍應詢問為何整體資料會出現這些差異，以及這代表什麼意思。非 Chrome 使用者是否會對指標造成正面或負面的偏差？這麼做能否讓您深入瞭解在哪些地方有需要優先處理的成效問題？
如果您的非 Chrome 使用者獲得不同的結果，您可以利用這項寶貴的深入分析資料，以不同的方式進行最佳化。舉例來說，某些 API 不適用於某些瀏覽器，但您可以考慮為不支援的瀏覽器提供替代方案，以改善使用體驗。或者，您也可以為使用受限裝置或網路的使用者提供不同的體驗，但成效更佳。CrUX 僅限於 Chrome 資料，但您應考量所有網站訪客的體驗，以便決定改善項目的優先順序。RUM 資料可以彌補這項缺口。
瞭解差異的原因後，這兩項工具都非常實用，可協助您瞭解網站的使用者體驗，並改善相關體驗 (即使數字不一致也沒關係)。使用 RUM 資料補充 CrUX 資料，透過劃分流量來大致深入分析 CrUX 的說法，從而瞭解網站的特定區域或使用者族群是否需要關注。
比起讓兩個資料來源完全一致，建議您查看趨勢，瞭解改善項目是否有助於改善預期成效。如前文所述，RUM 可讓您查看不同時間範圍，預先查看為期 28 天的 CrUX 分數，但若查看的時間範圍太短，可能導致資料雜亂，因此 CrUX 需要 28 天。
這些指標通常沒有「正確」或「錯誤」的答案，只是從不同角度觀察使用者，以及他們如何體驗網站。只要您瞭解這些差異的原因，以及這些差異如何影響決策，就能夠為網站訪客提供更優質的服務。
特別銘謝
縮圖圖片來源：Steven Lelham 在 Unsplash 網站上