Core Web Vitals 實地資料
CrUX 才算數，實驗室資料只供除錯
CrUX 實地資料像餐廳的真實顧客評分，實驗室資料像米其林密探的單次造訪——裝修建議聽密探的，招牌好壞看顧客的。
03為什麼是現在學
速度優化最常見的溝通災難：工程師拿 Lighthouse 98 分交差，實際使用者的 CrUX 還是紅的——兩種資料的用途沒分清楚。
04白話理解（對客戶簡報可直接引用）
分清楚兩種資料：實地（CrUX，真實使用者的 p75）——這是 Google 排名參考的、也是你該當 KPI 的；實驗室（Lighthouse）——單次模擬，拿來除錯找原因用。正確流程：用 CrUX 定目標與驗收，用 Lighthouse 找哪裡要修。CrUX 更新慢（28 天滾動），改完要有耐心等曲線動。
05工具箱
- ▸PSI（同頁顯示兩種資料） — 上面實地下面實驗室，別看混
- ▸GSC Core Web Vitals 報表 — 全站分組的實地資料
06怎麼做 · SOP 3 步（每步標產出物）
- 1以 CrUX p75 建立三指標基準線→ CWV 基準
- 2用 Lighthouse 定位問題→修復（t14–t16）→ 修復紀錄
- 328 天後驗收實地曲線→ 前後對照
07場景應用（實戰經驗）
- ◆驗收條款要寫對：「Lighthouse 90 分」是錯的驗收標準（一台快電腦就能刷出來），「CrUX 行動版三指標綠燈」才是真驗收。
08⚠️ 常見誤區
- ✕低流量頁面沒有 CrUX 資料——這不是錯誤，是樣本不足；用同頁型的整體資料替代判讀。
口訣
「實地定生死，實驗室找病因。」
10里程碑 · 完成標準（可驗證）
- ☐以 p75 實地資料為 KPI
- ☐GSC CWV 報表綠燈比例上升
學習者勾自己的進度；顧問勾客戶專案的交付——同一份標準，兩種用法。
12檢核方式與依據出處
程式自動判定：輸入網址，掃描引擎自己爬、自己打 API、自己判定。
- 🟢 官方明文web.dev：實地資料與實驗室資料的差異 ↗
依據等級決定計分權重（🟢×3／🔵×2／⚠️×1）——權重量的是「依據有多硬」， 不是「我們覺得多重要」。查無權威文件的判準，誠實標「業界慣例」。