瞭解監控網站體驗核心指標指標所回報數據的差異，以及如何解讀這些差異。
Google 提供多項工具，協助網站擁有者監控網站體驗核心指標的分數。這些工具主要分為以下兩大類：
- 回報研究室資料的工具：在受控環境中收集的資料，並提供預先定義的裝置和網路設定。
- 回報「現場資料」的工具：從造訪網站的實際使用者收集到的資料。
問題是，研究室工具回報的資料，可能與現場工具回報的資料稍有不同。您的研究室資料可能顯示網站效能良好，但現場資料顯示有需要改善。或者，您的欄位資料可能表明所有網頁都沒問題，但實驗資料可能會報告極低的分數。
以下由 web.dev 提供 PageSpeed Insights 報告的實際範例。在某些情況下， 所有 Core Web Vitals 指標的研究室和現場資料可能會有差異：
工具之間的差異能讓開發人員容易理解。本文將說明造成這些差異的主要原因 (包括每項網站體驗核心指標指標的具體範例)，以及發現網頁差異時的處理方式。
實驗資料與實際現場資料
如要瞭解研究室和現場工具回報的值不同的原因，即使是同一個網頁也是如此，您必須瞭解研究室和實際資料之間的差異。
實驗資料
研究室資料是藉由在設有預先定義的網路與裝置條件的受控管環境中載入網頁來確定。這些條件稱為「研究室」環境，有時也稱為「合成」環境。
回報研究室資料的 Chrome 工具通常會執行 Lighthouse。
這項研究室測試的目的在於盡可能控管更多因素，讓執行結果 (盡可能) 一致，可在執行期間重現結果。
欄位資料
實際資料將監控所有造訪網頁的使用者，並評估每位使用者個別體驗的特定成效指標組合。由於欄位資料是以使用者實際造訪為依據，因此會反映出使用者的實際裝置、網路條件及地理位置。
欄位資料通常稱為即時使用者監控 (RUM) 資料，這兩項字詞可互換。
一般而言，會回報現場資料的 Chrome 工具會從 Chrome 使用者體驗報告 (CrUX) 取得這些資料。此外，網站擁有者也常自行收集現場資料，因為這種做法可以提供更多可做為行動依據的洞察資料，而非只使用 CrUX。
關於欄位資料最重要的是，它不只是一個數字，而是數字的分佈。也就是說，有些訪客的網站訪客載入速度可能非常快，但有些訪客的載入速度可能非常緩慢。 網站的「欄位資料」是向使用者收集的所有成效資料。
舉例來說，CrUX 報表會顯示 28 天內，實際 Chrome 使用者的成效指標分佈情形。當您查看幾乎任何 CrUX 報告時，會發現部分造訪網站的使用者可能享有良好的體驗，而其他網站的使用者體驗可能不佳。
如果工具確實針對特定指標回報一個數字，通常代表分佈中的特定點。回報 Core Web Vitals 的工具得分使用第 75 個百分位。
透過上方螢幕截圖中的欄位資料，您可以看到以下的分佈情形：
- 88% 的造訪率顯示 LCP 為 2.5 秒以下 (良好)。
- 8% 的造訪次數介於 2.5 到 4 秒之間 (需要改善)。
- 4% 的造訪次數中，使用者看到 LCP 超過 4 秒 (不佳)。
在第 75 個百分位數，LCP 為 1.8 秒：
相同網頁的研究室資料顯示 LCP 值為 3.0 秒。雖然這個值大於欄位資料中顯示的 1.8 秒，但仍然是該網頁的有效 LCP 值，這是構成載入體驗完整分佈的眾多值之一。
實驗室和現場資料不一致的原因
如上一節所說明，研究室資料和現場資料實際上測量的數值大不相同。
欄位資料包含各種網路和裝置條件，以及各種不同類型的使用者行為。也包含任何其他會影響使用者體驗的因素，例如瀏覽器最佳化 (例如往返快取 (bfcache)，) 或平台最佳化 (例如 AMP 快取)。
相較之下，研究室資料則會刻意限制要涉及的變數數量。實驗室測試包含：
- 單一裝置...
- 已連線至單一網路...
- 都是在一個地理位置放送
任何研究室測試的具體細節不一定會正確呈現特定網頁或網站欄位資料的第 75 個百分位數。
如要在部署至實際工作環境前對問題或測試功能進行偵錯，研究室的受控管環境會相當實用，但當您控制這些因素時，並不明確表示在現實世界中，您在各種網路、裝置功能或地理位置中看到的變化。您通常也不會擷取使用者實際行為 (例如捲動、選取文字或輕觸頁面上的元素) 對效能的影響。
除了研究室條件與大多數實際使用者狀況之間可能有些落差，除此之外，還有一些較不明顯的差異。請務必瞭解這些差異，以便有效理解研究室和現場資料，以及所發現的任何差異。
以下各節將詳細說明最常見原因，其中最常見的原因可能是各 Core Web Vitals 指標的研究室資料和實際資料之間存在差異：
LCP
不同的 LCP 元素
研究室測試中發現的 LCP 元素，可能與使用者造訪您網頁時看到的 LCP 元素不同。
如果您針對指定網頁執行 Lighthouse 報表，則每次都會傳回相同的 LCP 元素。但是，查看同一網頁的欄位資料時，您通常會發現各種不同的 LCP 元素，而這些元素取決於每次造訪的特殊情況。
舉例來說，下列因素都可能造成系統判定相同網頁的不同 LCP 元素：
- 不同的裝置螢幕大小會導致可視區域中顯示不同的元素。
- 如果使用者已登入，或以某種方式顯示個人化內容，LCP 元素對使用者的意義可能大不相同。
- 與前一點類似，如果網頁執行 A/B 測試，就可能顯示非常不同的元素。
- 使用者系統上安裝的字型集會影響網頁上的文字大小，進而影響 LCP 元素。
- 研究室測試通常是在網頁的「基準」網址上執行，不加上任何查詢參數或雜湊片段。不過在現實生活中，使用者通常會分享含有片段 ID 或文字片段的網址，因此 LCP 元素實際上可能位於網頁中間或底部 (而非「不需捲動位置」)。
請注意，欄位中的 LCP 計算方式為網頁所有使用者造訪的第 75 個百分位數，因此如果大部分使用者的 LCP 元素都非常快載入 (例如使用系統字型轉譯的一段文字)，那麼即使部分使用者呈現載入速度緩慢的大型圖片，即使他們的 LCP 元素載入速度緩慢，也不會影響該網頁的分數。
或者，相反的也可能是 true。研究室測試可能會將文字區塊識別為 LCP 元素，因為它模擬的 Moto G4 手機所模擬的可視區域相對較小，且網頁的主頁橫幅初始顯示畫面不在畫面中。不過，您的欄位資料可能包括大部分螢幕較大的 Pixel XL 使用者，因此載入速度緩慢的主頁橫幅「是」其 LCP 元素。
快取狀態對 LCP 的影響
研究室測試通常會使用冷快取載入網頁，但使用者造訪某個網頁時，該網頁可能已快取一些資源。
使用者初次載入網頁時，載入速度可能會很慢，但如果網頁已設定適當的快取設定，使用者下次返回頁面時，可能會馬上載入。
雖然部分研究室工具支援對同一網頁多次執行 (模擬回訪者的體驗)，但實驗室工具無法得知新使用者和回訪者在實際造訪環境中所佔的百分比。
如果網站的快取設定已經過最佳化，且許多回訪者大多都會發現，實際使用時的最大內容速度會比研究室資料更快許多。
AMP 或 Signed Exchange 最佳化
透過 AMP 或 Signed Exchange (SXG) 建立的網站，都可以由 Google 搜尋等內容集結網站預先載入。這可能會大幅改善使用者透過這些平台造訪您網頁時的載入速度。
除了跨來源預先載入，網站本身還可以預先載入網站上後續網頁的內容，從而改善這些網頁的 LCP。
研究室工具不會模擬這些最佳化作業帶來的效益，即使評估工具確實如此，也無從得知有多少百分比的流量來自 Google 搜尋等平台。
bfcache 對 LCP 的影響
從 bfcache 還原頁面後，載入體驗幾乎就會即時執行，因此您的現場資料會納入這些體驗。
研究室測試不會使用 bfcache，因此如果您的網頁適合使用 bfcache，或許能加快實際呈現的 LCP 分數。
使用者互動對 LCP 的影響
LCP 會識別可視區域中最大圖片或文字區塊的轉譯時間，但當網頁載入時，或是新內容動態新增至可視區域時，該最大的元素可能會變更。
在研究室中，瀏覽器會等到網頁完全載入後，才能判定 LCP 元素為何。但在欄位中，當使用者捲動頁面或與頁面互動後，瀏覽器就會停止監控較大的元素。
這很合理 (也是必要的)，因為使用者通常會等到網頁「顯示」後，才與網頁互動，而這正是 LCP 指標的目標是偵測的。此外，在使用者互動後加入可視區域加入的元素並不合理，因為這些元素可能「因為使用者操作」而可能才載入。
但這種做法的優點是，各網頁的欄位資料會根據使用者在該網頁上的行為，回報較快 LCP 時間。
FID
FID 需要使用者的實際操作
FID 指標會評估網頁對於使用者互動的反應，也就是使用者實際選擇與網頁互動的當下。
語句的第二部分就非常重要，因為研究室測試 (即使是支援指令碼使用者行為的測試) 也無法準確預測使用者選擇與網頁互動的時機，因此無法準確評估 FID。
未考量使用者行為
總封鎖時間 (TBT) 研究室指標可將 FID 問題量化，用來量化網頁載入期間主執行緒遭封鎖的數量，因此有助於診斷 FID 相關問題。
這是因為如果網頁含有大量同步 JavaScript 或其他密集的算繪工作，那麼在使用者首次互動時，更有可能造成主執行緒遭到封鎖。不過，如果使用者等到 JavaScript 執行完畢後才與網頁互動，FID 就可能非常低。
使用者選擇與網頁互動的時機，主要取決於網頁是否「外觀」是互動性質，而且無法以待定時間評估。
未考量輕觸延遲
如果網站未針對行動裝置瀏覽進行最佳化，瀏覽器在執行事件處理常式前，會在輕觸動作後加上 300 毫秒的延遲時間。原因在於，使用者必須先判斷使用者是否嘗試輕觸兩下進行縮放，才能觸發滑鼠或點擊事件。
這類延遲會計入頁面的 FID，因為會影響使用者體驗的實際輸入延遲時間。但從技術層面來說，此延遲並非「長時間工作」，因此不會影響頁面的待定。這表示網頁即使 TBT 分數很高，但 FID 還是品質不佳。
快取狀態和 bfcache 對於 FID 的影響
就像正確快取能改善欄位的 LCP 一樣，也可以改善 FID。
實際上，使用者可能已在快取中儲存網站的 JavaScript，因此處理網站的時間會縮短，並造成更短的延遲時間。
從 bfcache 還原的網頁也是如此。在這種情況下，JavaScript 會從記憶體還原，因此可能相當短，甚至完全沒有處理時間。
CLS
使用者互動對 CLS 的影響
在研究室中測量的 CLS 只會考慮在折疊位置和載入期間發生的版面配置位移，但這只是 CLS 實際測量的其中一部分。
在欄位中，CLS 會考量整個網頁生命週期內發生的所有非預期版面配置位移，包括在使用者捲動畫面時移動，或是因使用者互動後網路要求速度緩慢而發生的版面配置位移。
舉例來說，網頁常常會延遲載入圖片或不含尺寸的 iframe，而且這可能導致使用者捲動至頁面各部分時，版面配置的位移。但這些變動可能只有在使用者向下捲動時才會發生，在研究室測試中通常不會捕捉到這一點。
個人化內容
個人化內容 (包括指定廣告和 A/B 測試) 會影響網頁上載入的元素。這也會影響載入方式的方式，因為個人化內容通常會在稍後載入，並插入網頁的主要內容中，導致版面配置位移。
在研究室中，網頁通常會載入沒有個人化內容，或是包含一般「測試使用者」的內容，而這不一定能觸發實際使用者看到的變化。
由於欄位資料包含所有使用者的使用體驗，因此任一指定頁面中的版面配置位移數量和程度，都取決於載入的內容。
快取狀態和 bfcache 對 CLS 的影響
版面配置在載入期間發生版面配置位移的最常見原因為兩個是不含尺寸的圖片和 iframe (如上文所述) 和載入網路字型速度緩慢。此外，如果快取是空，則在使用者首次造訪網站時，這兩個問題就更有可能影響使用者體驗。
如果網頁的資源是快取的，或是網頁本身是從 bfcache 還原，瀏覽器通常可以立即轉譯圖片和字型，完全不必等待下載。這可能會導致欄位中的 CLS 值低於研究室工具回報的內容。
結果出現差異時的處理方式
一般來說，如果特定網頁同時含有欄位資料和研究室資料，您應使用欄位資料排定工作的優先順序。欄位資料代表實際使用者所體驗的情況，因此最準確的方式可以瞭解使用者遇到的難題，以及需要改善的地方。
另一方面，如果欄位資料在整體上呈現良好的分數，但您的研究室資料顯示仍有改善空間，建議您瞭解該如何進一步進行最佳化。
此外，雖然欄位資料確實掌握使用者的實際體驗，但只有成功載入您網站的使用者會受到影響。實驗資料有時可協助找出拓展網站觸及範圍的機會，讓網路速度較慢或裝置較低的使用者更容易存取網站。
整體而言，研究室資料和現場資料都是有效成效評估的重要部分。這兩者都有優點和限制，如果只使用一種平台，可能會錯失改善使用者體驗的機會。