網站效能檢測的做法，是先用 PageSpeed Insights 與 Search Console 的 Core Web Vitals 報告，確認實際使用者的體驗有沒有達標，再用 Lighthouse 的實驗室數據找原因。實際使用者數據來自 Chrome 使用者體驗報告（CrUX），以過去二十八天、第七十五百分位數判斷 LCP、INP、CLS；實驗室數據是在固定裝置與網路條件下模擬載入，適合重現問題、比較修改前後，但分數會波動，不宜拿單次結果下結論。
檢測前先選定頁型、裝置與紀錄欄位
Search Console 會把使用者體驗相似的網頁歸成同一個網址群組，檢測時也可以照頁型挑代表網址，不要只測首頁：
- 首頁、主要服務頁與商品分類頁：訪客常見的入口。
- 文章或知識頁：內容長、圖片多。
- 表單、預約或結帳頁：互動多，要留意 INP。
- 放了影片、地圖、客服聊天或廣告的頁面：第三方內容可能拖慢載入。
裝置要分開測。web.dev 建議以第七十五百分位數為門檻，並分別分析行動裝置與桌面裝置；同一個網址可能在行動裝置良好、在電腦需要改善。紀錄欄位先訂好：日期、網址、裝置、工具、資料類型、各指標數值，以及期間改過哪些地方。
PageSpeed Insights 的檢測步驟
- 開啟 PageSpeed Insights，輸入完整網址，按「分析」。
- 報告分別呈現行動裝置與電腦的結果，兩邊都要看、分開記錄。
- 先看實際使用者資料：Core Web Vitals 評估是否通過，以及各指標的數值。
- 確認資料範圍：網址的資料不足時會改用整個來源的資料，記錄時要註明。
- 再看 Lighthouse 實驗室資料：效能分數與 FCP、LCP、總封鎖時間（TBT）、CLS、Speed Index。
- 展開稽核項目，記下和不及格指標有關的建議，連同報告連結存檔。
實驗室資料由 Lighthouse 模擬產生，行動裝置模擬中階手機、電腦模擬有線網路，官方說明數值可能和實際資料不同。
實際使用者數據：第七十五百分位數與二十八天
PageSpeed Insights 回報過去二十八天收集期間的實際資料，取第七十五百分位數，也就是四分之三的造訪體驗等於或優於這個數值。門檻如下：
- LCP：二點五秒以內良好，超過四秒不良，中間為需要改善。
- INP：兩百毫秒以內良好，超過五百毫秒不良。
- CLS：零點一以下良好，超過零點二五不良。
三項指標的第七十五百分位數都良好，才算通過評估；INP 資料不足時，LCP 與 CLS 的第七十五百分位數都良好即可通過；LCP 或 CLS 資料不足時則無法評估。剛發布或樣本太少的網頁可能沒有資料，這時改看整個來源。網頁也必須能公開找到、造訪量達到門檻，才會納入資料集。因為是滾動資料，修改上線後要過一段時間才會完整反映。
實驗室數據：Lighthouse 分數的組成與波動
效能分數九十分以上為良好、五十至八十九分需要改善、四十九分以下為不良，由 FCP、Speed Index、LCP、總封鎖時間、CLS 加權計算，總封鎖時間的權重大於其他四項。改善建議與診斷項目不直接計分，但處理後可能改善指標；官方也說明滿分非常難達成，也不是預期目標。
很多波動並非來自 Lighthouse 本身，例如 A/B 測試、投放的廣告改變、網路路由變化。官方文件建議：
- 同一網址多測幾次，用中位數比較。
- 不要在同一台電腦同時跑多份報告。
- 排除防毒軟體與擴充功能的影響；本機環境難控制時，改用 PageSpeed Insights 這類代管環境。
在 Chrome 開發人員工具執行時，開啟要測的網頁與開發人員工具，切到「Lighthouse」分頁，按「分析網頁載入作業」，開發人員工具會列出稽核類別，保持全部啟用後按「執行稽核」，約三十到六十秒產生報告；這種方式也能測本機網站。INP 需要真實互動，實驗室看的是替代指標總封鎖時間。
Core Web Vitals 報告的判讀步驟
Search Console 的 Core Web Vitals 報告同樣用實際數據，但以整個網站為範圍，適合找出哪一類頁面有問題：
- 在行動裝置或電腦的圖表旁按「開啟報告」。
- 切換「不良」「需要改善」「良好」分頁標籤，看各狀態的網址數量。
- 從「未將網址視為優質網址的原因」表格點進問題。
- 在「示例」表格點選網址，查看該群組的群組 LCP、INP、CLS。
- 挑範例網址到 PageSpeed Insights 找原因，交給工程人員修正。
- 修正後按「開始追蹤」，系統監控二十八天，期間任一網址仍有問題就標為未修正；失敗時可按「要求重新驗證」。
注意：報告只顯示已建立索引的網址，列的是範例而非完整清單，群組狀態以表現較差的那項指標為準，資料量不足的群組不會顯示。Google 建議先修正「不良」的網址，並優先處理影響網址多或影響重要網頁的問題。
實際數據和實驗室數據對不上怎麼判斷
web.dev 說明兩種數據都有時，應以實際數據為優先，實驗室數據用來重現與除錯：
| 情況 | 可能原因 | 下一步 |
|---|---|---|
| 分數高，實際數據未通過 | 真實裝置與操作更多樣；INP 只能從真實互動量到 | 以實際數據為準，檢查未通過指標對應的元素或互動 |
| 分數低，實際數據良好 | 實驗室通常以冷快取載入，真實訪客可能已有快取 | 不必只為分數重做，當成慢速網路使用者的參考 |
| 沒有實際數據 | 網頁太新、樣本太少或未達門檻 | 參考來源層級資料，用多次測試的中位數追蹤 |
| 單頁通過，群組仍不良 | 範例網址只代表部分網頁 | 多測幾個同群組網址，裝置分開檢查 |
| 上線後數據沒變 | 實際數據是二十八天滾動資料 | 先用實驗室數據確認有效，再持續觀察 |
檢測報告的寫法與檢測頻率
能拿來追蹤的檢測報告，每個代表網址建議包含：
- 基本資料：日期、網址、頁型、裝置，以及和上次相比改過什麼。
- 實際數據：三項指標的第七十五百分位數與狀態，註明是網址或來源層級。
- 實驗室數據：多次測試的分數中位數與各指標數值。
- 問題與負責人：不及格指標、相關建議、由誰處理、何時重測。
改版、上線新功能、更換主機或外掛、加入追蹤碼與第三方程式之後，立即用實驗室數據比對前後；平時定期查看 Core Web Vitals 報告，例如每月一次觀察趨勢。找到問題後怎麼處理圖片、快取與腳本，可參考網站速度優化的做法。
常見問題
需要登入的會員頁或後台怎麼檢測？
先登入，再用 Chrome 開發人員工具裡的 Lighthouse 執行稽核，官方說明這種方式能測試需要驗證的網頁。這類頁面無法公開找到，不會有實際使用者數據，要搭配實際操作判斷。
為什麼 iPhone 使用者覺得慢，報告卻顯示良好？
實際使用者數據只來自符合條件的電腦版與 Android 版 Chrome 使用者，iOS 上的 Chrome 不在其中。iPhone 訪客多的網站，建議另外用實機測試主要頁面。
效能分數可以寫進網站驗收條件嗎？
可以，但要寫清楚測試條件，例如哪些頁型、哪種裝置、用哪個工具、測幾次取中位數。只寫分數門檻容易因環境波動各說各話，上線後再以實際數據觀察。
網站加了廣告或客服聊天外掛，檢測要注意什麼？
第三方內容每次載入可能不同，Lighthouse 也把廣告改變列為分數波動的原因。加入前後各測幾次比較，紀錄中註明當時啟用的第三方程式，避免誤判成網站本身的問題。
效能檢測要由行銷人員還是工程師來做？
可以分工。行銷或網站負責人定期查看報告、整理紀錄；建議項目牽涉程式、主機或第三方腳本時，排好順序交給工程人員處理與重測。
本文由京采數位科技整理。我們自 2005 年起提供官網設計、系統開發與 Google SEO 服務，實際案例可見成果與案例。
想直接討論你自己的網站狀況，或需要一份初步的搜尋機會評估？
相關主題
下一步
建議先列出主要頁型，各挑一個代表網址，用 PageSpeed Insights 分別測行動裝置與電腦，再對照 Core Web Vitals 報告，建立一份檢測基準。如果稽核項目牽涉主機、程式或第三方腳本，京采的技術 SEO 與網站健檢服務可以協助判讀報告、排出修正順序並陪同驗證；想先討論網站現況，歡迎與我們聯絡。
