前言：兩個分數，兩個世界

身為一個長期經營網站的人，你一定看過這種場面：Google PageSpeed Insights 跑出 95 分，信心滿滿；但實際訪客回饋卻是「打開好慢」。是分數在騙人嗎？不一定——問題在於你看的可能是兩種完全不同的數據。

Lighthouse 是實驗室數據（Lab Data），在標準化環境下跑測試；而 CrUX（Chrome User Experience Report）是真實用戶數據（Field Data），記錄的是全球真實用戶在真實網路下的實際體驗。這兩者的差距，往往就是網站效能問題被忽略的原因。

一、Lighthouse 與 CrUX：兩套數據，兩個世界

Lighthouse 是實驗室，CrUX 是真實戰場

Lighthouse 跑的是模擬環境：固定網速、標準設備、穩定延遲。這讓它在不同時間、不同機器上跑出來的結果相對一致，適合開發階段做基準測試。但問題來了——你的用戶可能在台北的 4G 基地台、印度的 3G 網路、或者東京的光纖上打開你的網站。這些情境 Lighthouse 完全涵蓋不到。

CrUX 的做法是透過 Chrome 瀏覽器匿名收集真實用戶的效能數據，把這些全部平均下來，就是 CrUX 回報給你的數字。

Google 在 2024 年將 CrUX 納入排名信號，意味著你網站在 CrUX 上的表現，會直接影響搜尋排名。但多數網站經營者只看 Lighthouse 分數，根本不知道自己 CrUX 數據長什麼樣子。

實測：我們網站的分數對比

Lighthouse 分數：桌面 98 分、行動 87 分，數字很漂亮。

CrUX 資料（過去 28 天真實用戶）：LCP 中位數 3.2 秒（超過「良好」的 2.5 秒門檻）、CLS 0.12（良好範圍）、INP 240ms（中等）。

表面上看起來還行，但當我們把視角切換到「第 75 百分位」（25% 用戶的體驗比這個數字更差），LCP 變成 4.8 秒——已經進入「需要改善」的範圍。

這就是 CrUX 的價值：它告訴你真實用戶中最差的 25% 經歷了什麼，而不是只報告平均值。

二、Core Web Vitals 在 CrUX 裡的真正意涵

LCP：用户看到主要內容要多慢

LCP 記錄的是用戶進入頁面後，看到最大圖片或文字區塊所需的時間。良好是 2.5 秒以內，2.5 到 4 秒需要改善，超過 4 秒就是差。

我們的某篇技術文章頁面，CrUX LCP 中位數 2.1 秒（良好），但第 95 百分位是 6.3 秒。這代表 5% 的用戶要等超過 6 秒才看得到主要內容。對這些用戶來說，你的網站就是「慢」。

CLS：頁面有沒有「跳一下」

CLS 測量的是頁面載入時，元素位置變動的幅度。良好是小於 0.1，超過 0.25 就是差。CLS 高的網站，用戶體驗會非常挫折——可能手指正要點連結，文字突然往上跳，結果點到別的按鈕。

INP：點了要有反應

INP 是 2024 年才加入 Core Web Vitals 的指標，測量的是使用者互動（點擊、輸入）到視覺回饋之間的延遲。良好是小於 200ms，超過 500ms 就是差。INP 高的頁面，用戶操作時會明顯感到「卡卡的」。

三、案例：如何用 CrUX 找到 Lighthouse 看不到的問題

三月初，我們的某篇技術文章跳出率突然從 45% 飆升到 70%。一開始以為是內容不夠好，但改寫了段落、增加了圖片之後，跳出率依然維持在高點。

後來我們去看 CrUX 數據，才發現問題根本不在內容，而是技術效能：該頁面的 LCP 在行動裝置上，第 75 百分位是 4.2 秒。該頁面嵌入了一個外部 Font Awesome 圖示庫，而這個圖示庫在某些地區的載入時間超過 3 秒。

Lighthouse 在實驗室環境下測試時，這個圖示庫剛好是快取狀態，所以只顯示 0.5 秒的載入時間。真實用戶第一次到訪時，這 3 秒多的時間全部要等。

找到問題之後，我們把 Font Awesome 改成 SVG inline 嵌入，移除外部依賴。兩週後，CrUX LCP 第 75 百分位降到 2.6 秒，跳出率跟著降到 52%。

Lighthouse 告訴你的是「最佳情況」的速度，CrUX 告訴你的是「用戶實際遇到」的速度。

四、改善 CrUX 數據的八個實際做法

1. 最小化第三方腳本

每多一個外部腳本，就多一個可能拖慢速度的變數。先盤點每個腳本是否有存在的必要，不必要的果斷移除或延遲載入。

2. 圖片尺寸預先宣告

在 img 標籤上明確宣告 width 和 height 屬性，讓瀏覽器提前知道圖片大小，防止 CLS。

3. 使用 Brotli 或 Zstd 壓縮

比 Gzip 壓縮率更高，對文字類資源（HTML、CSS、JS）效果顯著。

4. 預先載入關鍵資源

用 <link rel="preload"> 提前告知瀏覽器即將需要的資源，特別是 LCP 圖片和關鍵字體。

5. 讓 JavaScript 不阻塞渲染

把非必要的 JavaScript 加上 defer 或 async，讓 HTML 解析時不會停下來等它下載執行完才繼續。

6. 使用 CDN 並啟用邊緣快取

使用 Cloudflare 或類似的 CDN，把靜態資源快取在全球邊緣節點上。

7. 監控並控制 INP

INP 高的常見原因是主執行緒被長任務佔用。用 Chrome DevTools 的 Performance 面板可以錄製並找出這些長任務。

8. 建立 CrUX 監控而不是只看 Lighthouse

每週固定檢查 CrUX 數據，把第 75 百分位設為主要指標。

五、結語：CrUX 是你的真實使用者體驗分數

Lighthouse 分數高不代表用戶體驗好。真正影響跳出率、轉化率、和搜尋排名的，是 CrUX 裡那些真實用戶數據。特別是第 75 百分位和第 95 百分位，這些數字告訴你「中等程度用戶」和「最差情況用戶」各自經歷了什麼。

fordige 相關文章：

• 網站載入太慢？2026 年加速網站的 8 個方法