網站速度測試要分兩步：先用 PageSpeed Insights 看單一頁面的現場資料與實驗室診斷，再用 Search Console 的 Core Web Vitals 報告找出一批頁面的共同問題。
改善時不要只追一個分數，先處理影響範圍大的問題，再按 LCP、INP、CLS 的成因安排工程工作。若還不熟三指標的定義，可先看站內的Google Search Console 教學。
先分清楚：你測到的是哪一種資料
網站速度測試容易誤判的地方，是把一次測試結果當成所有訪客的體驗。PageSpeed Insights 同時提供 field data 與 lab data：前者來自 Chrome User Experience Report 的真實使用資料，後者由 Lighthouse 在固定條件下模擬載入。
網站需要穩定的新文章？
想持續更新網站，又沒有時間每篇從頭準備？文開花替你安排選題、撰稿與檢查。先看示範內容，再判斷適不適合你的生意。
看看文開花怎麼做 →兩組數字不同，不代表工具壞掉，而是回答不同問題。你在測試紀錄裡要把資料類型一起寫下來，否則下一次比較時，可能拿現場資料與模擬資料互相比較。
Field data 適合回答「訪客實際遇到什麼」。它會把裝置、網路與使用情境造成的差異納入，適合拿來決定優先修哪一類問題。
Lab data 適合回答「這次載入卡在哪裡」。它能提供瀑布圖、資源與主執行緒診斷，適合在改程式前定位原因。Google 的PageSpeed Insights 說明也提醒，實驗室資料不一定代表真實使用者的瓶頸。
先看 field data 的三項狀態，再用 lab data 定位診斷原因；即使已有 field data，lab data 仍能協助拆解載入與互動瓶頸。不要因為一次模擬測試變好，就直接宣稱所有頁面都已改善。
測試前先固定三個條件
第一個條件是 URL。首頁、文章頁、商品頁與結帳頁的資源組成不同，不能用首頁分數代表整個網站。先列出會帶來流量或轉換的頁型，每一種頁型選一個代表頁，再查同模板的其他問題頁。
第二個條件是裝置。Search Console 會把行動版與桌機版分開呈現，PageSpeed Insights 也要分別執行。行動版低分時，先確認是不是圖片、字型或 JavaScript 的負擔集中在小螢幕載入路徑；桌機版正常不能推論行動版也正常。
第三個條件是時間與改動。每次記錄測試日期、頁面、裝置、field 或 lab、三項數值與改了什麼。一次同時改 CDN、圖片、第三方腳本與版面配置，結果變好時就很難知道哪一項真正有效。
三個工具怎麼分工
| 工具 | 適合看的問題 | 使用方式 |
|---|---|---|
| PageSpeed Insights | 單一 URL 近期收集期間的 field data 與 lab data | 貼入 URL，先看行動版，再看桌機版；展開 LCP、INP、CLS 的診斷項目。 |
| Search Console Core Web Vitals | 網站內一群相似 URL 的真實使用狀態 | 按裝置與問題分組，從受影響的 URL 群挑代表頁測試。 |
| Chrome DevTools／Lighthouse | 瀏覽器載入與互動過程卡在哪裡 | 在修改前後測同一頁、同一情境，觀察瀑布圖、長工作與版面位移來源。 |
Search Console 的報告以真實使用資料呈現 URL 群，並依行動版或桌機版分開查看；它不是一份逐頁即時監控清單。對特定頁面要查原因，從報告的代表 URL 連到 PageSpeed Insights，再回到程式碼或內容設定處理。
PageSpeed Insights 的 field data 是前一段收集期間的歷史資料；Google 文件寫明，這組 CrUX 資料涵蓋前 28 天。因此剛改完頁面時，lab data 可以先看方向，field data 則要等資料累積後再評估。
門檻只拿來分流，不是單一總分
Core Web Vitals 的判斷看 LCP、INP、CLS 三項。Google 以頁面載入的第 75 百分位作為良好體驗的判斷基準；換句話說，報告中的數字不是某一次訪客的最快或最慢紀錄。現行門檻如下，完整定義可參考Google Search Central。
| 指標 | 良好門檻 | 看到問題時先問什麼 |
|---|---|---|
| LCP | ≤ 2.5 秒 | 主要內容或最大圖片何時被瀏覽器發現？伺服器回應、資源下載、渲染哪一段拖慢？ |
| INP | ≤ 200 毫秒 | 點擊、輸入或開啟選單後，是否有長時間 JavaScript 工作阻塞畫面更新？ |
| CLS | ≤ 0.1 | 圖片、廣告、嵌入內容或字型載入時，有沒有先保留版面空間？ |
門檻的用途是分流。三項都良好，不等於網站每一頁的轉換路徑都順；其中一項落在需要改善，也不代表只要壓低總分就能解決。把「指標不良」翻成「哪個使用情境被拖慢」，才有下一個可執行的工程任務。
讀值時不要只看良好或不良
若 LCP 接近門檻，先看它是所有裝置都慢，還是只在行動版慢。前者要檢查共用的伺服器與首屏資源，後者要檢查行動版載入的圖片、字型與 JavaScript；兩者的修正範圍不同。
若 INP 只有互動頁面出現問題，請把測試焦點放在搜尋、篩選、加入購物車或送出表單等動作。讀者感受到的是「按下去後多久有回應」，所以單看初次載入的 lab 分數，可能找不到真正的卡點。
若 CLS 只在特定內容模組出現，先找那個模組載入前後的版面差異。圖片、影片、廣告與嵌入內容都要先決定顯示區域，再讓內容填入；這個順序比載入完成後才調整高度可靠。
若三項都落在良好範圍，仍可用轉換流程做一次人工走查：首頁到內頁、內頁到表單、表單到完成頁。Core Web Vitals 是重要的效能訊號，但它不會替你檢查文案是否清楚、按鈕是否容易找到或表單是否能順利送出。
改善順序：先找影響面，再找最短路徑
第一步看 Search Console 的裝置分布與 URL 群。行動版與桌機版分開處理，因為同一個模板在不同裝置上可能有不同的網路、處理器與互動路徑。先挑同一模板下受影響的代表頁，確認問題是共用元件、伺服器回應，還是單頁內容造成。
第二步看哪個指標最差，再把它拆成原因。LCP 先看 TTFB、主要內容資源的發現時間、下載時間與渲染延遲；若最大內容是圖片，確認 LCP 資源能及早被瀏覽器發現，並檢查尺寸與載入優先級。Google 的 LCP 指南把「讓 LCP 資源提早被發現」列為起手式，這比先壓縮頁面上每一張圖片更直接。
INP 先找互動發生時的長工作：例如點擊按鈕後，同一段 JavaScript 同時做大量計算、更新整個列表或等待不必要的請求。把不急著完成的工作拆開、延後，讓輸入事件先得到畫面回應，再測同一個互動流程。
CLS 先查沒有尺寸的圖片、廣告、iframe 與動態插入內容。修法不是把內容移走，而是先在版面上保留它需要的空間，讓載入完成後不必把讀者正在看的內容推開；這項處理方向可參考web.dev 的 CLS 指南。字型替換造成的位移也要納入同一次檢查。
網站需要穩定的新文章？
想持續更新網站，又沒有時間每篇從頭準備？文開花替你安排選題、撰稿與檢查。先看示範內容，再判斷適不適合你的生意。
看看文開花怎麼做 →一次完整測試怎麼做
- 先記錄頁面與裝置。固定測試 URL，分開記行動版與桌機版；同一輪不要一邊換 URL、一邊換問題。
- 看 field data 的狀態。記下最差指標、URL 群與 75 百分位數值；若沒有資料，標記為「尚無現場基準」，不要把 lab data 當成 field data。
- 用 PSI 或 Lighthouse 定位。把建議分成伺服器、關鍵資源、JavaScript、版面配置四類，先處理與最差指標直接相關的項目。
- 每次只改一組原因。例如先處理首屏圖片發現時間，再處理非必要 JavaScript，方便知道哪個改動造成差異。
- 重跑同一頁，再回看現場資料。lab data 用來確認方向；Search Console 與 PSI 的 field data 用來確認真實訪客是否改善。
修完後不要只看分數顏色。把改善前後的 URL、裝置、指標、測試時間與改動項目留在同一份紀錄裡，才能分清楚是資源變快、互動變短，還是測試條件改變。
把診斷報告改寫成工程任務
報告列出的建議不必全部同時處理。先問它是否直接對應最差指標：LCP 的任務應落在首屏 HTML、主要圖片、字型或伺服器回應；INP 的任務應落在事件處理、長工作與第三方腳本；CLS 的任務應落在尺寸預留、動態插入與字型替換。
以文章頁為例，若 LCP 的最大元素是首圖，先確認 LCP 資源能及早被瀏覽器發現，再檢查圖片是否被延後載入；若 INP 只在開啟篩選器時變差，先錄下該互動的長工作，不要先改整站所有 JavaScript；若 CLS 發生在廣告出現後，先替廣告容器保留空間。
這種拆法能讓開發、內容與基礎設施各自接到清楚任務。圖片、伺服器回應與互動卡頓，可由內容、前端、後端、主機與其他相關團隊協作處理。任務完成後，再用同一個 URL 和裝置重測，才知道修正是否命中原因。
交付任務時，把「問題畫面」與「要觀察的指標」一起寫進去。不要只說網站很慢，而要寫成「行動版文章頁的 LCP 卡在主要圖片發現」或「表單送出後 INP 變差」。主詞、頁型、裝置與指標都清楚，修正者才不用重新猜測測試意圖。
三種頁面情境的排查起點
文章頁先看首屏圖片、字型與嵌入內容。若圖片放在內容前段，也可能載入分享工具、留言模組或影片嵌入；這些內容若沒有尺寸或載入順序，會同時影響 LCP 與 CLS。先把首屏真正需要的資源列出來，再把非首屏功能延後。
表單頁先看互動路徑。輸入欄位、驗證、日期選擇器與錯誤提示都可能觸發 JavaScript；不要只測頁面剛打開的時間，還要實際操作最重要的按鈕。若操作後畫面沒有及時更新，再從長工作與事件處理找原因。
商品或服務介紹頁先看圖片與第三方元件。輪播、評論、聊天工具與追蹤腳本可能在首屏同時啟動；先確認哪一個是轉換流程必要內容，再安排其餘元件的載入時機。這樣的判斷能避免為了追速度而刪掉真正需要的功能。
三個常見誤區
第一個誤區是只追 Lighthouse 分數。分數是實驗室測試的綜合結果，不能取代真實使用資料；頁面在模擬環境變好，field data 仍可能被特定裝置或網路拖慢。
第二個誤區是把所有問題都交給前端。LCP 可能卡在伺服器回應或資源發現，CLS 可能來自內容模組沒有預留空間，INP 則可能來自第三方腳本與互動流程。先按成因分工，修正才不會在不同團隊間來回。
第三個誤區是改完立刻判定 Search Console 已通過。Search Console 的資料是現場資料與 URL 群組結果，修正後要用 PSI／Lighthouse 先確認技術方向，再持續觀察報告變化。
若你也在整理收錄與效能問題，可以把本篇與站內的網站健檢 SEO 稽核教學一起使用；收錄檢查與速度診斷要分成兩條工作線。
最後檢查清單
- 是否先看 field data，再用 lab data 找原因？
- 是否分開檢查行動版與桌機版？
- 是否把最差指標拆成可執行的資源、程式或版面問題？
- 是否每次只改一組原因，並保留改善前後紀錄？
- 是否回到 Search Console 與 PSI 的 field data 檢查真實使用結果？
網站速度測試的終點不是拿到一個漂亮分數，而是知道哪一群訪客在哪一個操作被拖慢，並能把問題交給正確的修正工作。先確認資料種類，再按影響範圍與成因排序，測試結果才會變成可執行的改善清單。
最後更新：2026-09
常見問題
網站剛上線沒有 Core Web Vitals 資料，還要不要做速度測試？
要，先用 PageSpeed Insights 的 lab data 找明顯瓶頸，再把它當成初始基準。Search Console 的報告需要足夠的真實使用資料，沒有資料時不代表頁面一定良好或一定很慢。
PageSpeed Insights 的行動版分數很低，桌機版正常，先修哪一版？
先修與主要訪客和轉換流程相關的裝置版本；若沒有明確優先級，先從行動版的 field data 與代表 URL 開始。兩種裝置要分開看，不能用桌機結果替代行動版問題。
改完 LCP 後，為什麼 Search Console 的狀態沒有立刻改變？
因為 Search Console 使用真實使用資料與 URL 群組結果，不是改檔後即時重算的單頁檢查。先用 PSI 或 Lighthouse 確認修改方向，再等待新的現場資料累積。
只修一個 Core Web Vitals 指標，頁面就算合格嗎？
不一定。LCP、INP、CLS 分別反映載入、互動與版面穩定性，頁面仍要看三項的現場狀態；只修一項，另外兩項的問題仍可能影響整體體驗。
網站需要穩定的新文章？
想持續更新網站，又沒有時間每篇從頭準備？文開花替你安排選題、撰稿與檢查。先看示範內容，再判斷適不適合你的生意。
看看文開花怎麼做 →