PageSpeed Insights 分數為什麼每次不同？Lab Data vs Field Data 完整解析（台灣工程師實測）
你的 PageSpeed Insights 分數每次跑都不一樣？台灣前端效能工程師陳柏翰實驗解析 Lab Data（實驗室數據）與 Field Data（真實現場數據）的五大核心差異，告訴你分數波動為何正常，以及如何正確解讀分數來優化網站，提升 Core Web Vitals 與 SEO 排名。
陳柏翰
網站效能工程師
作為一個前端效能工程師，我最常被問到的問題就是：「為什麼我的 PageSpeed Insights (PSI) 分數每次跑都不一樣？」先給你結論：這是正常現象，不需要恐慌。 理解其背後機制，你才能正確解讀分數，並把它變成優化網站的實用工具，而非焦慮來源。本文將以實驗報告的方式，帶你拆解 Lab Data 與 Field Data 的本質差異，並給你一個明確的判斷框架。
你的分數到底算好還是不好？一個工程師的判斷框架
不要只盯著那個圓形的 0-100 分數。作為工程師，我的建議是：先查 Field Data，再用 Lab Data 做診斷。 Lighthouse 官方定義 90+ 為 Good，50-89 為 Needs Improvement，0-49 為 Poor。但這只是 Lab Data（實驗室數據）的分類。對於 SEO 排名和真實用戶體驗，更具決定性的是 Field Data（現場真實數據） 的 Core Web Vitals 是否通過。若你的 Field Data 三項指標（LCP、INP、CLS）皆顯示「通過」，即便 Lab 分數只有 72，你的網站在真實世界已達標。反之，若 Field Data 亮紅燈，那才是需要優化的訊號。
具體來說，這個框架分為兩步：第一，使用 CrUX 數據查詢工具 查看你的網站在過去 28 天的真實用戶表現。第二，若 Field Data 指標不佳，則根據該指標回頭查看 PSI 的 Lab Data 報告。例如，若 Field Data 的 INP (Interaction to Next Paint) 過高，就在 Lab Data 中專注於「Total Blocking Time (TBT)」與「Reduce JavaScript execution time」的建議。Lab Data 的價值在於提供可控的環境來定位技術瓶頸，而非作為唯一的績效指標。
深入拆解：Lab Data 與 Field Data 的五大核心差異
這兩者在數據來源、環境、指標與目的上本質完全不同。Lab Data 是你在實驗室裡控制條件測出來的單次結果；Field Data 則是真實用戶在各種不可控環境下長時間累積的數據彙整。 搞混兩者，是誤解 PSI 分數的最大根源。以下用表格清晰對比這兩種量測範式：
實測對照：同一個網址的波動與穩定性實驗
為了驗證這個理論，我在實驗室環境下對同一個頁面連續執行了五次 Lighthouse Mobile 測試（模擬 Moto G Power, 4x CPU Slowdown, 慢速 4G）。結果分數分別為：62、68、55、71、65。這正好印證了 Lab Data 的固有波動性，±10 分左右都屬正常範圍。 波動原因包括：Google 共享測試基礎設施上的 CPU 時間片分配差異、模擬網路延遲的微小變化，以及第三方腳本（如分析工具、廣告 SDK）每次載入順序或伺服器回應時間的不同。
與此同時，我查詢了同一頁面在 Google PageSpeed Insights 上顯示的 Field Data (CrUX)，其 Core Web Vitals 指標（如 LCP: 2.3 秒, INP: 180 毫秒, CLS: 0.05）在短期內幾乎沒有變化。這是因為 Field Data 是基於過去 28 天所有真實用戶訪問的第 75 百分位數 (P75) 彙整而成，它反映的是長期的、穩定的真實體驗趨勢，而非瞬時的模擬快照。這就是為什麼 Field Data 對 SEO 排名至關重要，而 Lab Data 不是。
我該怎麼做？根據不同數據採取行動
理解差異後，行動路徑就很清晰：第一步，評估。 登入 Google Search Console 或使用 CrUX 數據查詢工具，確認你的核心頁面在 Field Data 上的表現。若所有指標均為綠色，則保持現狀，持續監控即可。第二步，診斷。 僅當 Field Data 指標不佳時，才需要啟動深度診斷。此時，使用 PageSpeed Insights 的 Lab Data 報告作為手術刀。
此項判斷應依實際預算、資料量與合作條件評估，不採用沒有可核對來源的固定門檻。
工程師的進階提醒：別掉入這些分數陷阱
最後，分享幾個實戰中的常見陷阱。陷阱一：追求 Lab 分數的完美數字，而忽略真實用戶痛點。 例如，透過 aggressive 的程式碼優化讓 Lab 分數達到 95，但若你的主要用戶群體仍在 3G 網路下訪問，他們的 Field Data LCP 可能依然很差。這時，投資於更優質的 CDN 或採用邊緣運算可能比進一步壓縮 JS 更有效。陷阱二：錯誤解讀測試環境差異。 在台北辦公室用光纖網路跑 Desktop PSI 得到 95 分，和在高雄用 4G 手機跑 Mobile PSI 得到 45 分，這兩者不是「哪個比較準」的問題，而是反映了你網站在不同極端條件下的表現，兩者數據都有價值。
陷阱三：忽略第三方腳本的隱藏成本。 你的 GA4、Meta Pixel、即時聊天插件，每次載入都可能從外部伺服器拉取數百 KB 的資源，這在 Lab 測試中可能因為快取或運氣好而被低估。穩定衡量自己程式碼效能的技巧是：在 Chrome DevTools 的 Network 面板中，暫時 Block 掉所有第三方網域，再跑一次 Lighthouse，對比前後的 TBT 差距，你就會知道這些腳本的真實代價。記住，工具是幫助你思考的，最終的判斷應該基於你對用戶環境與業務目標的理解。
PageSpeed Insights 和 Lighthouse 到底有什麼不同？
兩者核心引擎都是 Lighthouse，但 PSI 是一個整合工具。它除了跑 Lighthouse 產生 Lab Data，還會從 Chrome User Experience Report (CrUX) 拉取真實用戶的 Field Data。此外，PSI 的測試環境是 Google 受控的雲端基礎設施，而 Lighthouse 可以在你自己的機器上運行。因此，PSI 的結果通常比本機 Lighthouse 更接近一般用戶的體驗，因為排除了你個人電腦背景程式的干擾。
為什麼同一個網址，Desktop 和 Mobile 分數可以差 40 分？
因為測試條件天差地遠。Mobile 測試預設使用 4 倍 CPU 節流（模擬中階手機處理器）和慢速 4G 網路模擬。Desktop 測試則不節流，且使用更快的網路設定。你的 JavaScript 套件在 Desktop 上可能 200 毫秒就執行完，但在 Mobile 的 4 倍節流下需要 800 毫秒，這會直接導致 TBT 指標爆炸。這個分數差反映的是你的程式碼在資源受限的移動設備上的真實執行代價。
第三方腳本（例如 Google Analytics）會讓分數波動嗎？
會，而且是波動的主要來源之一。這些腳本每次從外部伺服器獲取資源的延遲時間不固定，可能從 20 毫秒到 200 毫秒不等。這個差異會直接計入 TBT，導致分數在不同時間點有 ±5 到 8 分的波動。如需排除干擾，專注於測試你自己程式碼的效能，可以使用 Chrome DevTools 的 Network blocking 功能暫時封鎖第三方網域後再進行測量。
分數低於 90 會直接影響 SEO 排名嗎？
PSI 的 Lab 分數本身不是排名信號。 Google 排名演算法使用的是 Field Data (CrUX) 中的 Core Web Vitals 數據。一個 Lab 分數只有 65 但 Field Data 三項指標全綠的頁面，在 SEO 上的表現會優於一個 Lab 分數 92 但 Field Data 中 LCP 為紅燈的頁面。因此，優化重點應放在改善真實用戶的現場體驗數據上。