網站效能測試指標指南：Core Web Vitals 與改善優先序

網站效能測試報告有很多數字，但總分變好，客戶仍可能覺得網站慢。企業需要知道每個指標描述哪一段體驗，才能判斷問題、安排改善與驗收成果。LeadsTech 可協助網站效能診斷與優化規劃，一併釐清指標、訪客任務及驗收條件。本文從核心網頁指標、載入過程及測試條件出發，說明如何把效能報告轉成可執行的工作清單。

摘要

網站效能測試應同時觀察內容載入、互動回應與版面穩定性，不能只用一個分數判斷網站品質。核心網頁指標提供共同的體驗衡量方式，其他指標則協助定位等待發生在哪裡。企業應結合實驗室與真實使用資料，記錄頁型、裝置及期間，再依業務影響安排改善。驗收除了比較數值，也要確認訪客能順利完成重要任務。

1. 網站效能測試指標應回答什麼問題

從客戶任務看數字

訪客進入企業網站，可能要確認產品規格、尋找服務範圍或提交詢問。畫面何時出現、按鈕何時回應，以及內容會不會突然移位，都會影響這些任務。

效能報告的價值，是把「感覺很慢」拆成可觀察的現象。若主要內容很晚出現，應追查載入路徑；若畫面已完整但操作卡住，則需要分析互動期間的工作。

因此，測試前先列出代表頁型及操作。首頁、產品詳情、文章、站內搜尋和表單可能有不同瓶頸，單一首頁數字不能代表所有訪客體驗。

分清結果指標與診斷指標

結果指標接近訪客實際感受，例如主要內容出現時間與互動回應。診斷指標則協助解釋原因，例如初始回應、資源大小或執行緒被占用的時間。

可用性與錯誤率則補充另一個角度：即使頁面很快，服務請求失敗仍會中斷任務。企業應先定義哪些操作算成功，以及分母包含哪些嘗試，讓報告中的成功率可被一致解讀。

兩類指標應一起使用。發現大圖片不代表它必然是主要瓶頸；看到伺服器回應較慢，也不代表調整主機就是唯一解法，仍需確認完整載入與渲染路徑。

報告最好把每項數字連到一個問題、一項證據及下一步，而不是只羅列工具建議。這樣業務與技術團隊才容易討論優先序。

2. Core Web Vitals 的三個體驗面向

Core Web Vitals 是核心網頁指標，用來衡量載入表現、互動反應及視覺穩定性。三項指標關注的體驗不同，不能互相代替，也不應把數值直接相加。

LCP：主要內容何時出現

Largest Contentful Paint，簡稱 LCP，觀察可見範圍中最大內容元素的繪製時間。良好門檻為不超過 2.5 秒，適合用來判斷訪客等待主要內容的情況。

閱讀報告時，應先確認被量測的元素是什麼。不同螢幕或頁面版本可能對應圖片、影片或較大文字區塊，改善前需要知道真正影響數值的內容。

LCP 偏慢時，可依序檢查初始回應、資源發現、下載與顯示的等待。圖片壓縮只是可能方法之一，若主要延遲發生在其他環節，就需要不同處理。

INP：互動後多久看到回饋

Interaction to Next Paint，簡稱 INP，評估點擊、觸控或鍵盤操作後，頁面回應到下一次繪製的延遲。良好門檻為不超過 200 毫秒。

企業應重現重要互動，例如開啟選單、切換產品規格、使用搜尋或按下表單按鈕。使用者看見頁面，不等於當下能順暢操作。

分析時可區分等待處理、事件執行及畫面更新。若大量程式工作占用主執行緒，畫面可能暫時無法及時回饋；需要先定位工作，再決定如何減少或拆分。

CLS：版面是否意外移動

Cumulative Layout Shift，簡稱 CLS，描述非預期版面位移的程度，良好門檻為不超過 0.1。這是沒有時間單位的分數，不是載入秒數。

常見觀察情境包括圖片出現後推動文字、嵌入內容插入頁面，以及字型替換改變排版。應查看實際位移紀錄，避免只憑畫面印象猜測來源。

穩定性也要涵蓋瀏覽過程。訪客捲動到表單或展開資訊後，仍可能遇到移動，因此測試不能只停在剛開啟頁面的瞬間。

圖 1：三個互補的體驗面向，需要各自的指標與診斷證據。

3. 載入速度還需要哪些輔助指標

TTFB 與 FCP 協助找出等待位置

Time to First Byte，簡稱 TTFB，是收到第一個回應位元組前的等待時間。它可用來檢查初始回應環節，並不等於整個頁面載入完成時間。

First Contentful Paint，簡稱 FCP，是首次內容繪製，反映畫面開始出現文字或影像等內容的時間。FCP 快但 LCP 慢，表示已有內容出現，主要內容仍可能讓訪客等待。

企業可把這些時間放在同一條載入路徑上理解，但不要把它們當成可直接相加的獨立工序。很多工作會重疊，也可能受到快取、網路與渲染安排影響。

TBT 與資源紀錄提供診斷線索

Total Blocking Time，簡稱 TBT，是實驗室常見的總阻塞時間指標，用來觀察長任務對載入期間回應能力的影響。它能協助找到程式負擔，但不能直接取代真實互動的 INP。

下載容量、請求數、資源瀑布圖與程式執行紀錄，也有助於追查原因。需要看資源是否必要、何時載入及是否阻塞重要內容，而不是單純要求請求愈少愈好。

對影片、圖庫或互動功能較多的頁面，應保留必要體驗並調整資源安排。移除重要資訊換取較漂亮的分數，未必能改善客戶完成任務的能力。

4. 如何讀懂實驗室與實地測試結果

實驗室測試適合比較改動

實驗室資料來自受控條件，方便重現問題及比較版本。測試人員可以固定裝置、網路、地區及快取狀態，再觀察某項調整是否改變對應指標。

同一頁也應執行多次，保留典型表現與波動。不能只選最好的一次當作成果，也不宜在條件不同時直接比較兩張報告截圖。

一般載入型測試可能沒有執行客戶的操作路徑。若問題發生在使用篩選器之後，就需要補上互動測試，而不是反覆重新載入頁面等待問題出現。

實地資料反映一段期間的真實體驗

PageSpeed Insights 可同時提供實驗室與實地資料。實地資料使用 Chrome 使用者體驗報告的樣本，常見呈現範圍為過去二十八天，涵蓋不同訪客條件。

修改上線後，實驗室結果可能先改變，滾動期間的實地數據則仍混合先前訪問。因此驗收需要分開記錄部署時間與資料窗口，避免認為新版本立即無效。

還要確認看到的是特定網址還是來源層級資料。當工具改用更廣範圍的資料，不能把它當成該網址的直接證據；樣本不足也不等於網站一定通過。

第七十五百分位不是平均值

核心網頁指標常以第七十五百分位判讀，代表約四分之三的觀測值達到該數值或更好。這能避免只看平均而忽略部分較差體驗，但仍不能代替完整分佈。

報告應保留行動與桌面等分組，必要時再檢查地區及頁型。若網站整體看起來良好，但重要市場的手機訪客較慢，企業仍有值得改善的問題。

5. 如何把數值轉成改善優先序

同時看業務影響、訪問範圍與證據

先判斷問題是否阻礙重要任務，例如查看規格、登入或提出詢問。其次看受影響的頁型及訪問範圍，再確認問題能否重現、原因是否有足夠證據。

共用模板的缺陷可能影響多個產品頁，修正價值較高；某個短期活動頁雖然數量少，也可能承擔重要流量。優先序需要結合業務安排，而不是只看網址數量。

對證據不足的項目，先安排有限診斷。對已確認原因的項目，再估計修正、回歸測試與部署工作，避免把猜測寫成承諾。

圖 2：以影響、範圍與證據決定先處理哪些網站效能問題。

優先清單還需加入相依關係與改動風險。若修正共用元件會影響多個語言版本，就要預留代表樣本的回歸測試；若原因來自外部服務，則需明確安排供應商協作，不能只把工作交給網站編輯人員。

以假設情境說明判讀方式

假設一家工業設備供應商的產品頁在手機上載入慢，訪客也反映切換規格時停頓。這是假設情境，並非實際客戶成果；團隊需要分別建立載入及互動的證據。

若測試顯示主要內容等待與互動長任務屬於不同原因，就應分開安排修正。不能只壓縮圖片後，便宣稱切換規格的問題也已解決。

驗收可追蹤代表頁型的 LCP、相關互動延遲、功能成功率及表單完成情況。業務數字還會受流量與內容影響，應記錄比較條件，不把所有變化都歸因於速度。

6. 效能測試報告與驗收要保留什麼

用一致條件建立前後對照

報告應列出網址、版本、裝置、網路、地區、測試日期及資料期間。初次訪問和已有快取的結果應分開，登入、同意選項或第三方工具狀態也要記錄。

每項改動需對應預期影響。例如調整主要圖片，應觀察相關載入路徑；拆分互動工作，應重測對應操作。只有總分變化，通常不足以證明原因已處理。

部署後應確認正式環境內容及設定與測試條件一致。若快取仍提供舊版本，或外部服務在不同時段行為不同，需要先釐清再判讀。

讓功能驗證與效能驗證並行

速度改善不能以功能失效為代價。表單送出、錯誤提示、下載、語言切換與追蹤事件，應由適當負責人檢查，尤其是調整程式載入順序之後。

企業可以建立一份簡短驗收清單，每次部署重用：

• 代表頁型及重要操作已列入範圍。
• 前後版本使用可比較的測試條件。
• 各項指標與資料期間都有記錄。
• 問題原因有可追查的證據。
• 功能、表單與必要事件均可使用。
• 未解決事項及後續負責人已確認。

7. 如何持續監測而不只追逐分數

將基準與監測責任放進日常網站更新流程。新增圖片、影片、行銷標籤或程式版本時，檢查代表頁面是否退步，並保留與變更時間對應的紀錄。

監測目標可依重要頁型制定，不必讓所有頁面套用同一套資源限制。重點是讓異常可被辨認，並知道下一步由誰調查，而不是增加沒有人處理的警示。

當數值突然改變，先檢查訪客組成、測試條件及版本，再決定是否需要修正。流量地區或裝置比例改變，也可能影響整體結果。

監測看板可以保留一層管理摘要與一層診斷細節。管理摘要說明受影響任務、目前狀態與下一步，細節則保留樣本、測試設定與版本，讓決策者和執行人員都能找到需要的資訊。

對接近門檻的頁面，應看持續表現及波動，不把一次越界當作完整結論。若改善需要移除重要功能，就應評估替代設計與業務取捨。

良好核心網頁指標有助於使用體驗，但不保證搜尋排名。企業仍需提供有用內容、清楚結構與可完成的流程，把效能當成整體網站品質的一部分。

8. 常見問題（FAQ）

9. 結語

網站效能測試指標的用途，是協助企業找出等待、定位原因及驗證改善。先分清指標與條件，再結合業務任務安排工作，才能讓數字轉成實際體驗提升。

LeadsTech 可協助企業討論網站效能測試及優化需求，從代表頁型、問題診斷與驗收安排建立工作範圍。

了解網站效能測試及優化服務

如需釐清目前報告中的問題，可整理重要網址、訪客環境與已知操作情境，與我們討論下一步。

聯繫我們，討論你的企業需求

10. 延伸閱讀

• CMS 如何影響 SEO？網站內容管理系統優化指南

  了解內容管理、網站結構與 SEO 表現之間的關係。

• 如何選擇 SEO／GEO 顧問與服務商？完整評估指南

  延伸評估外部顧問的交付、驗證與合作範圍。