網站速度測試工具推薦：5 大免費檢測平台比較與效能優化實戰
網站速度測試的真正價值，是用對工具回答你手上那個具體的問題。把問題先講清楚，工具的選擇就跟著底定：想知道會不會被排名訊號扣分，看 PageSpeed Insights 的真實用戶數…
網站速度測試：用對工具，回答對的問題
網站速度測試的真正價值，是用對工具回答你手上那個具體的問題。把問題先講清楚，工具的選擇就跟著底定：想知道會不會被排名訊號扣分，看 PageSpeed Insights 的真實用戶數據；想知道到底是哪個檔案把網站拖慢，用 GTmetrix 或 Pingdom 的瀑布圖；想知道不同地區、不同網速的人體驗如何，用 WebPageTest。Google 自 2021 年將 Core Web Vitals 正式納入排名訊號，並公開建議頁面載入壓在 3 秒內（[來源：〈web.dev — Core Web Vitals〉〈https://web.dev/articles/vitals〉〈2026〉]），行動版 LCP 只要超過 2.5 秒就會被判斷為體驗不佳（[來源：〈web.dev — Core Web Vitals〉〈https://web.dev/articles/vitals〉〈2026〉]）。要理解這些門檻從何而來，得先回到 網頁速度的本質，看懂速度構成哪些環節。而不同工具測出的分數會分歧，原因是它們量測的東西本來就不同，這點搞懂了，後面 5 款工具的選擇就不會再迷路。
重點先看：別把 5 款工具全跑一遍。Google 建議頁面載入壓在 3 秒內，行動版 LCP 門檻是 2.5 秒、INP 是 200 毫秒（[來源：〈web.dev — Core Web Vitals〉〈https://web.dev/articles/vitals〉〈2026〉]），多數站長用 PageSpeed Insights 加一款檔案層級工具就夠。
網站速度為什麼影響 SEO 與轉換率
會，而且影響是同時發生在排名、跳出率與轉換率三條線上。Google 自 2021 年起把 Core Web Vitals 正式納入排名訊號（[來源：〈Google Search Central — Core Web Vitals〉〈https://developers.google.com/search/docs/appearance/core-web-vitals〉〈2026〉]），這代表速度從此是會直接影響你在 搜尋引擎優化 排名的條件之一。載入時間每多一秒，使用者離開的機率就明顯上升，Google 公開建議把頁面載入壓在 3 秒內（[來源：〈web.dev — Core Web Vitals〉〈https://web.dev/articles/vitals〉〈2026〉]）。
速度慢會連帶拖慢爬蟲抓取效率，影響索引與收錄，甚至吃掉你的 爬取預算。當搜尋引擎發現一個網站 跳出率 偏高、停留時間短，會把它解讀為內容或體驗不佳，排名自然往下掉。所以 技術性 SEO 把速度列為基礎健檢項目。行動裝置速度尤其關鍵，因為 Google 採行行動優先索引（mobile-first indexing），手機版的表現才是它優先衡量你的依據。這一點有公開資料佐證：行動裝置在 2026 年第一季已佔全球網站流量的 52.27%（[來源：〈Statista — Share of mobile web traffic worldwide quarterly 2015-2026〉〈https://www.statista.com/statistics/277125/share-of-website-traffic-coming-from-mobile-devices/〉〈2026-04-28〉]），也就是說過半數訪客是用手機來的，手機版速度直接決定過半流量的第一印象。
速度與生意的連動，在第三方案例裡也很具體。Vodafone 把 LCP 改善 31% 後，銷售額隨之提升 8%；The Economic Times 在通過 Core Web Vitals 門檻後，整體跳出率改善了 43%（[來源：web.dev〈Why does speed matter?〉 https://web.dev/articles/why-speed-matters 2026]）。同一份資料來源還記錄了日本電商 Rakuten 24：投入 Core Web Vitals 優化後，每位訪客營收提升 53.37%、轉換率提升 33.13%；印度訂票平台 redBus 在改善 INP 後，銷售額提升 7%（[來源：web.dev〈Why does speed matter?〉 https://web.dev/articles/why-speed-matters 2026]）。這組數字說明的正是前面那條邏輯：載入變快、LCP 提早到位、互動回應變順，使用者願意留下、也願意完成動作，跳出率與轉換率才會同步往好的方向走。所以把速度顧好，不只是為了排名訊號，也是直接守住了每一次到訪的成交機會。
這裡要先把一個常見誤解說清楚：Core Web Vitals 不是一個分數，而是三個各自獨立的指標。很多人看到工具給出一個 0 到 100 的總分就以為那就是「網站體驗核心指標」，其實 Google 用來判斷排名訊號的是 LCP、INP、CLS 三個門檻是否通過。對這組指標還很陌生的話，可以先讀一篇 網站使用體驗核心指標的入門說明 把觀念打底，再來對著工具看數字會更有感。把它們的標準一次列清楚，比記一個總分有用得多。
| 指標 | 衡量什麼 | 良好門檻 | 說明 |
|---|---|---|---|
| LCP（最大內容繪製） | 主要內容載入完成的時間 | ≤ 2.5 秒 | 頁面裡最大的文字或圖片多久被畫出來 |
| INP（互動到下一次繪製） | 使用者互動的回應速度 | ≤ 200 毫秒 | 2024 年 3 月起取代 FID 成為互動指標（[來源：〈web.dev — INP 成為 Core Web Vitals〉〈https://web.dev/blog/inp-cwv〉〈2024〉]） |
| CLS（累計版面位移） | 視覺穩定度 | ≤ 0.1 | 頁面元素跳動的程度，愈低愈穩定 |
INP 取代 FID 是近年最大的規則變動。在 2024 年 3 月之前，互動指標用的是 FID，只量測第一次互動的延遲；INP 改成量測整個工作階段所有互動中最差的表現，標準嚴格很多（[來源：〈web.dev — INP 成為 Core Web Vitals〉〈https://web.dev/blog/inp-cwv〉〈2024〉]）。想把這段切換的來龍去脈一次看懂，可以讀 INP 與 FID 的差異解析，會更清楚為什麼舊分數不能直接沿用。如果你的網站在 INP 上線前分數還不錯，現在反而變紅，原因多半在這裡。要不要回頭處理？答案是看真實用戶數據，而不是看單次實驗室跑分。具體該怎麼排查，可以對照 網站速度優化全攻略 裡的 INP 節落。
理解這三個門檻後，要留意 Google 的判斷用的是第 75 百分位的真實用戶數據。也就是說，它看的不是平均值，而是「75% 的訪客體驗是否都在良好門檻內」。這代表少數極端慢的訪客拉高了平均，未必會讓你被判紅燈；反過來說，若超過 25% 的訪客體驗在「需要改善」區間，就算平均分數好看也會被標記為問題。實務上這意味著你的優化要對著「最差的那四分之一使用者」使力，而不是只顧平均跑分。對百分位數概念不熟的站長，可以把目標簡化成「讓多數訪客都通過門檻」這個直覺標準來抓方向。
速度對生意的影響其實很直接：速度慢，客人還沒看到你寫了什麼就走了，排名再好的內容也救不回那次離開。做 站內 SEO 之前先確認網站沒有明顯的速度地雷，會比事後補救省事，因為 搜尋演算法 對體驗差的站只會更不客氣。
5 款網站速度測試工具總覽與選擇邏輯
沒有一款工具能回答所有問題。選擇取決於你想知道什麼：看真實用戶數據用 PageSpeed Insights、看實驗室瓶頸用 Lighthouse、看檔案層級細節用 GTmetrix 或 Pingdom、看地區與網速差異用 WebPageTest。理解所有工具分數差異的關鍵，在於 Lab data（實驗室數據）與 Field data（真實用戶數據）的區別，這兩者測出來的分數本來就不會一樣。
Lab data 是工具在一台模擬的手機或電腦上、用設定好的網速跑出來的單次結果，每次跑都會浮動。Field data 則是 Google 從裝了 Chrome 的真實使用者那邊蒐集來的匿名資料（稱為 CrUX，Chrome UX Report），反映過去 28 天的真實表現（[來源：〈Chrome UX Report 官方文件〉〈https://developer.chrome.com/docs/crux/〉〈2026〉]）。PageSpeed Insights 是少數同時給你這兩種數據的工具，這也是它的核心價值所在。
Lab 與 Field 兩種數據各有擅長的場景。Lab data 的長處是穩定、可重現、能立刻驗證你剛改的東西有沒有效，因為測試環境是固定的；它的短處是一台模擬機器永遠代表不了千千萬萬個真實使用者的裝置、網路與行為。Field data 的長處是真實，反映的是真實流量、真實裝置、真實地區的長期表現；它的短處是會延遲，畢竟統計的是過去 28 天，而且流量太低的頁面根本累積不到足夠樣本，會顯示「無資料」。把這兩組特性記住，之後看到任何一個分數，你都能立刻判斷它代表什麼、又漏掉了什麼。
| 面向 | Lab data（實驗室數據） | Field data（真實用戶數據） |
|---|---|---|
| 資料來源 | 模擬環境單次跑分 | CrUX 真實 Chrome 使用者 28 天累積 |
| 即時性 | 當場出結果，改完可立刻驗證 | 延遲反映，過去 28 天平均 |
| 穩定度 | 每次跑會浮動 | 趨勢穩定，但單日波動看不到 |
| 低流量頁面 | 可測 | 樣本不足會顯示無資料 |
| 主要用途 | 定位可改善的技術問題 | 判斷是否會被排名訊號扣分 |
用「問題導向」的方式來評選，會比把 5 款工具並列介紹完叫你全部都試更務實。評選標準有三條：能不能回答你實際會問的問題、免費功能夠不夠日常使用、報告容不容易看懂。用這個標準回頭看，多數站長其實只需要 PageSpeed Insights 加上一款檔案層級工具就夠了。新手若不知道從哪類工具著手，先翻一份 對新手友善的 SEO 工具推薦清單 比較容易抓到方向。這張決策表把問題對應到最適合的 1 到 2 款工具。
| 你想回答的問題 | 最適合的工具 | 原因 |
|---|---|---|
| 我的網站會被排名訊號扣分嗎？ | PageSpeed Insights | 唯一同時給 CrUX 真實用戶數據與門檻判斷的工具 |
| 到底是哪個檔案把網站拖慢？ | GTmetrix / Pingdom | 把每個請求的大小與耗時攤開，定位單一檔案瓶頸 |
| 不同地區、不同網速的人體驗如何？ | WebPageTest | 可鎖定地區、瀏覽器、連線速度做測試 |
| 開發中想快速反覆檢查？ | Lighthouse | Chrome 內建，不用切換工具即可即時執行 |
把工具用少、用對，比收集一堆報告有用地多。我常看到站長把 5 款工具分數全截圖存下來，結果連「到底該先改哪個檔案」都回答不出來。工具的目的是協助決策，不是製造焦慮。底下會逐款說明它們各自擅長回答什麼問題；想跨類別一次看清完整生態，可參考整理過的 SEO 軟體總覽，而 其他 SEO 工具 的選擇邏輯也是同樣道理。
PageSpeed Insights 該怎麼看：Google 官方的 Core Web Vitals 檢測
PageSpeed Insights 是 Google 官方的免費工具，同時給你 Lab data 與 Field data，是唯一能直接看到真實用戶 Core Web Vitals 表現的工具，也是判斷「是否會被排名訊號扣分」的依據。報告直接標示 LCP、INP、CLS 是否通過門檻，並分成手機版與桌面版兩份（[來源：〈PageSpeed Insights 官方說明〉〈https://developers.google.com/speed/docs/insights/v5/about〉〈2026〉]）。
它最獨特的地方在於同時顯示實驗室數據與 CrUX 真實用戶數據（[來源：〈Chrome UX Report 官方文件〉〈https://developer.chrome.com/docs/crux/〉〈2026〉]）。上面那塊「了解您實際使用者的體驗」是過去 28 天真實 Chrome 使用者累積的資料，下面那塊「診斷效能問題」則是工具當場用模擬環境跑出來的單次結果。要判斷排名風險，看上面那塊；要找出當下可以改的問題，看下面那塊。兩者不要混為一談。
報告針對每個問題都會給出具體的優化建議，並附上預估節省時間，比方說「移除阻塞渲染的資源」旁邊會標示「可節省約 1,200 毫秒」。這個預估值是實驗室跑出來的參考值，不是保證，但拿來排優先順序很實用。報告分為手機版與桌面版，兩個都要看，尤其手機版，因為 Google 用行動優先索引衡量你。
- 唯一同時顯示實驗室數據與 CrUX 真實用戶數據的工具
- 直接標示 Core Web Vitals（LCP、INP、CLS）是否通過門檻
- 報告分手機版與桌面版，需兩者皆檢查
- 針對每個問題給出具體優化建議與預估節省時間
讀 PageSpeed Insights 報告有個常見順序錯誤：先看那個 0 到 100 的分數，再被分數牽著走。比較穩的讀法是先看 Field data 那一塊三個指標的燈號，確認有沒有排名風險；再看 Lab data 的分數與診斷建議，找可以動手的項目。若 Field data 是綠燈、Lab data 分數偏低，代表你的真實用戶體驗沒問題，只是模擬環境跑得難看，這時不必過度焦慮分數。反過來，若 Field data 是紅燈，就算 Lab data 分數高，你還是得把紅燈那個指標當第一優先。簡單說，判斷優先級看燈號，找解法看診斷建議。
它的優點是權威、免費、資料來源就是 Google 自己；缺點是不能選測試地區，跑出來的 Lab data 節點位置你無法控制。想知道 Core Web Vitals 該往哪裡使力，PageSpeed Insights 永遠是第一站；深入作法可參考 Core Web Vitals 核心指標優化。如果你才剛開始做 WordPress 架站與 SEO，把它的報告看懂，會比追一堆第三方工具更有效率。
配套上，Google Search Console 也會在「體驗」分頁彙整 Core Web Vitals 的問題頁面，兩邊可以對著看；想再把它接上分析工具，可參考 Site Kit 串接 GA4 與 GSC，把檢測與監控串在同一個後台。速度之外的曝光與品牌討論聲量變化，也能透過 Ahrefs Brand Radar 指標解讀 持續追蹤。
開發時即時檢查用 Lighthouse
Lighthouse 跟 PageSpeed Insights 有什麼不一樣？簡單講，兩者本質上共用同一套實驗室檢測引擎，分數邏輯一致，差別只在 Lighthouse 直接在你當前開的頁面即時執行，不用另開網站、不用貼網址（[來源：〈web.dev — Lighthouse 概觀〉〈https://developer.chrome.com/docs/lighthouse/overview〉〈2026〉]）。它適合在開發或調整過程中快速反覆檢查。
操作方式很直覺：用 Google Chrome 開啟要檢查的頁面，按右鍵選「檢查」開啟開發人員工具，切到「Lighthouse」分頁，按下「分析網頁載入作業」，不到一分鐘就跑出報表。這組 瀏覽器開發者工具的操作技巧 是檢視原始碼與網路請求的同一套入口，熟了之後改 CSS、看 console 都用得上。因為它就是 PageSpeed Insights 那套 Lab data 引擎，跑出來的效能分數與診斷建議幾乎一模一樣。
Lighthouse 最大的限制是它只提供實驗室數據，看不到真實用戶的 CrUX 表現。也就是說，它能告訴你「這台模擬手機跑起來哪裡慢」，但無法告訴你「真實使用者過去 28 天是不是也這麼慢」。要回答後者，還是得回到 PageSpeed Insights。所以與其說 Lighthouse 取代 PageSpeed Insights，不如說它是開發流程裡的快速檢查工具。
- 與 PageSpeed Insights 的 Lab data 同源，分數邏輯一致
- 直接在目標頁面按右鍵檢查即可執行，不需切換工具
- 除效能外，也稽核無障礙、SEO、最佳實踐等項目
- 只提供實驗室數據，看不到真實用戶的 CrUX 表現
Lighthouse 還有一個常被忽略的進階用法：CLI 模式。在終端機執行 lighthouse https://你的網址 --output html --output-path report.html，就能把報告存成檔案，方便比對不同版本、留作改版前後的紀錄。搭配 --throttling 參數可以自訂 CPU 與網路限速條件，重現特定裝置的體驗。會用命令列的站長，把這條指令寫進部署流程，每次發版自動跑一次，能避免「改 A 壞 B」的速度回歸。對自動化檢測流程有興趣的人，這是一個把人力省下來的具體切入點。
因為 Lighthouse 還會稽核無障礙與 SEO 項目，做 常見 SEO 優化地雷 的健檢時，順手跑一次能把一些 meta、alt 文字缺漏一起抓出來。若想連 結構化資料標記 是否正確一併檢查，也能透過同一份報告快速定位，配合 WordPress SEO 外掛 修補更省事。
對剛摸 WordPress 架站、或是想 提升 Google 排名 的人來說，這是個成本低、資訊密度高的檢查方式。會寫一點程式的站長，還能搭配 Codex AI 程式助理 自動化跑檢測、批次調整前端資源，把反覆測試的人力省下來。不過要記得，它跑出來的分數會浮動，多跑幾次取中間值比較準。
定位單一檔案瓶頸：GTmetrix 與 Pingdom
想知道「到底是哪個檔案把網站拖慢」該用什麼工具？答案是 GTmetrix 或 Pingdom。這兩款都會把頁面每個請求（圖片、CSS、JS、字型）的大小、載入順序與耗時攤開給你看，是定位單一檔案造成瓶頸最直接的工具，且都能切換測試地區。
GTmetrix 採用 A 到 F 等級評分，A 最高、F 最低，報告會列出 LCP、TBT 等 Core Web Vitals 相關指標（[來源：〈GTmetrix 官網〉〈https://gtmetrix.com/〉〈2026〉]）。登入帳號後能選擇測試地區與瀏覽器，若你的主客群在亞洲，選亞洲的伺服器位置測出來會更接近真實。付費版可追蹤歷史趨勢，掌握每小時、每天、每週或每月的表現，並能設定告警，網頁表現異常時自動通知（定價以 GTmetrix 官網為準）。
Pingdom 原本是瑞典的網站監控服務公司，現屬 SolarWinds，官網提供免費網頁速度測試（[來源：〈Pingdom Website Speed Test〉〈https://tools.pingdom.com/〉〈2026〉]）。它最實用的部分是報告會列出各類型檔案的大小與請求次數，你可以一眼看出到底是圖片、字型還是 CSS 檔案把頁面撐大。兩者都建議選亞洲地區伺服器，讓測試更接近你的真實客群。
| 比較項目 | GTmetrix | Pingdom |
|---|---|---|
| 評分方式 | A 到 F 等級 | 0 到 100 分 |
| 最擅長 | 歷史趨勢追蹤、告警（付費） | 各類型檔案大小與請求次數分類 |
| 測試地區 | 可選（含亞洲節點） | 可選（含亞洲節點） |
| 免費版 | 夠日常檢測用 | 夠日常檢測用 |
| 適合時機 | PageSpeed Insights 點出問題後，定位具體檔案 | 想快速看哪類檔案（圖片／字型／CSS）過大 |
讀這兩款的報告，有個實用的看圖順序。先看瀑布圖（waterfall），找出最長的那幾條橫條，它們代表耗時最久的請求，通常就是兇手。再看報告的分類摘要，確認這些長條屬於哪一類資源：若是圖片，多半要壓縮或換格式；若是字型，可能要考慮本機託管或減少字重；若是第三方腳本（廣告、追蹤碼、社群按讚），就要評估能不能延後載入或移除。最後看主機回應時間那一條（TTFB），若它本身就很長，問題往往出在主機或後端，再怎麼調前端也壓不下來。
這兩款最適合在 PageSpeed Insights 點出問題之後使用。流程是：先用 PageSpeed Insights 確認有沒有排名風險，再用 GTmetrix 或 Pingdom 把問題拆到檔案層級，看是不是某張沒壓縮的 hero 圖、或某個 CDN 沒接好的字型在拖累。看到具體檔案，行動才會具體。看 GTmetrix 分數時要記得一個觀念：它的 A 到 F 是綜合評等，衡量的是整體載入效率，Core Web Vitals 門檻看的則是 LCP、INP、CLS 三個特定指標的第 75 百分位，兩套尺不能直接換算，別拿 GTmetrix 的 A 級去跟 PageSpeed Insights 的綠燈畫等號。
WebPageTest：模擬不同地區、瀏覽器與網速
WebPageTest 跟其他工具有什麼獨特之處？它最大價值在於可以鎖定特定地區、瀏覽器與網路速度（例如 4G、Chrome、亞洲節點）來測試，讓你看到不同使用者條件下的真實載入行為，是進階診斷地區性速度問題的首選（[來源：〈WebPageTest 官網〉〈https://www.webpagetest.org/〉〈2026〉]）。
它可以指定測試節點、瀏覽器、裝置與連線速度，組合彈性是 5 款工具裡最高的。產出的瀑布圖把每個資源的載入時序視覺化，你能看到哪個檔案在哪一毫秒開始下載、又卡了多久。報告也完整列出 FCP、LCP、CLS 等 Core Web Vitals 指標，免費即可查看完整內容，適合需要深度優化的人。
- 可指定測試節點、瀏覽器、裝置與連線速度
- 產出瀑布圖，視覺化每個資源的載入時序
- 完整列出 FCP、LCP、CLS 等 Core Web Vitals 指標
- 免費即可查看完整報告，適合深度優化需求
它的代價是介面資訊量大，對非工程背景的站長會有一點門檻。如果你只是想知道網站算不算慢，用 PageSpeed Insights 就好；但若你懷疑是「某個地區的人特別慢」或「4G 用戶體驗很差」，WebPageTest 是唯一能精準重現這個情境的工具。能不能測特定地區？可以，它支援多個亞洲節點。學習曲線雖然陡一點，但回報的資訊顆粒度也最完整。
WebPageTest 還有兩個進階功能值得知道。第一是「filmstrip（影格檢視）」，它會把載入過程切成每 0.1 秒一格的畫面，你能像看逐格動畫一樣，親眼看到使用者在每個時間點實際看到什麼，這對判斷「上面那一塊為什麼那麼晚才出現」非常直觀。第二是「content breakdown（內容組成）」，它把頁面所有位元組按類型與來源分類，讓你一眼看出第三方資源（廣告、分析、字型服務）到底吃掉多少頻寬。這兩個功能配合 waterfall 一起看，能拼出最完整的載入全貌。
換個角度想，一般報告找不到原因、需要往細節鑽的時候，WebPageTest 的資訊顆粒度無可取代，這也是進階玩家會把它留在身邊的原因。搭配 Search Console 實戰技巧 找出問題頁面，再用 WebPageTest 重現載入情境，是排查地區性速度問題的標準動作。這類串接多套工具的工作流程，Ahrefs 搭配學習的陪跑班 也有系統化的拆解，適合想把分析與檢測一條龍串起來的人。
看懂分數：從單一分數到完整評分卡
跑完測試最常出現的困擾，是看著一堆數字不知該信哪一個。Lighthouse 給一個 0 到 100 的分數、GTmetrix 給一個 A 到 F 的等級、PageSpeed Insights 給一組紅黃綠燈號、WebPageTest 給一堆毫秒，彼此還對不上。把這些資訊整理成一張「評分卡」，用同一套尺來判斷網站速度到底好不好，會比逐一分數糾結更有效率。
一張實用的評分卡至少包含四個欄位：要看的指標、目前的數值、目標門檻、改善動作。以 Core Web Vitals 為例，LCP 的目標是 2.5 秒、INP 是 200 毫秒、CLS 是 0.1；這組門檻來自 Google 官方，是判斷排名風險的硬標準。把工具量到的數值填進去，立刻就能看出哪一項離門檻最遠，那一項就是第一優先。把這張表存下來，每次改完重測再填一次，幾週後就能看到數字往門檻收斂的軌跡，這比追單一分數踏實得多。
| 指標 | 我的數值 | 目標門檻 | 狀態 | 改善動作方向 |
|---|---|---|---|---|
| LCP（手機版） | 填入 PSI 數值 | ≤ 2.5 秒 | 待判斷 | 壓縮 hero 圖、預載主要資源、檢查主機 TTFB |
| INP（手機版） | 填入 PSI 數值 | ≤ 200 毫秒 | 待判斷 | 拆長任務、延後第三方腳本、減少主執行緒阻塞 |
| CLS（手機版） | 填入 PSI 數值 | ≤ 0.1 | 待判斷 | 圖片與嵌入框預留尺寸、字型載入避免位移 |
| TTFB | 填入 GTmetrix 數值 | ≤ 0.8 秒 | 待判斷 | 升級主機、啟用快取、檢查資料庫查詢 |
| 頁面總體積 | 填入 Pingdom 數值 | 1.5 MB 以內 | 待判斷 | 壓縮圖片、移除多餘外掛、合併資源 |
填這張卡時有幾個原則。Core Web Vitals 三項要以 PageSpeed Insights 手機版的 Field data 為準，因為那是 Google 用來判斷排名訊號的數據。TTFB 與頁面總體積這類技術性指標，用 GTmetrix 或 Pingdom 的單次跑分即可，因為它們是給你看「現在能改什麼」用的，不需要 28 天的累積。狀態欄位用三色標示：通過門檻標綠、接近門檻標黃、明顯超標標紅，視覺上一眼就能分出輕重。把這張卡當作每個月的定期檢查表，比臨時起意跑一堆工具更能掌握長期趨勢。
用一個具體情境把這張卡的操作方式走一遍，會比空談原則更有感。假設有一個流量主要來自手機的內容站，每月到訪約數萬人次，PageSpeed Insights 手機版 Field data 顯示 LCP 3.8 秒（紅）、INP 180 毫秒（綠）、CLS 0.05（綠），GTmetrix 跑出 TTFB 1.2 秒、頁面總體積 3.2 MB。多數人的直覺是「三項裡只有一項紅燈，應該還好」，但評分卡會把焦點直接逼到 LCP：它是唯一紅燈，也是 Google 唯一會扣分的項目，所以第一優先就是它。再看 LCP 為什麼紅，TTFB 1.2 秒已經超過 0.8 秒門檻，代表主機回應本身就慢了一截，光是壓圖未必夠；而頁面 3.2 MB 也偏高，圖片很可能是另一個拉高 LCP 的兇手。於是行動順序會很清楚：先升級主機或開快取壓 TTFB，再壓 hero 圖與整體體積，做完重測看 LCP 是否回到 2.5 秒內。INP 和 CLS 既然已經綠燈，這一輪就不必花力氣。這就是評分卡相對於單一分數的價值：它不只告訴你「慢」，還把「慢在哪、先動哪、可以放過哪」一次排好。
測完之後：網站速度優化的優先順序
測完發現網站慢，第一個該改什麼？答案是先處理影響人數最多、成本最低的項目：壓縮圖片、啟用快取、清理多餘外掛，做完再回頭看 Core Web Vitals 哪個指標沒過。順序錯了，會把時間花在邊際效益最低的地方。
決定優先順序時，可以用一個簡單的二維原則來排序：把每個待改項目依「對使用者的影響人數」和「動手成本」兩個軸分類。高影響、低成本的項目（壓縮圖片、啟用快取）排第一波；高影響、高成本的（換主機、重構前端）排第二波，但要先確認第一波做完仍不夠；低影響、低成本的（清理少用外掛）順手做；低影響、高成本的（為了 1 分去拆第三方腳本）通常可以擱置。這個原則能避免你花一週改一個只影響 5% 人的問題，卻漏掉一張拖慢全站的首圖。
圖片通常是頁面體積最大宗（[來源：〈HTTP Archive — Web Almanac〉〈https://httparchive.org/reports/state-of-the-web〉〈2026〉]），壓縮圖片是 CP 值最高的第一步。一張沒壓縮的 hero 圖可能佔掉好幾 MB，壓完常常能省掉一半以上的頁面體積，而且對畫質影響有限。可以挑一套 圖片壓縮工具 批次處理，或乾脆在 WordPress 上裝 Smush 圖片壓縮外掛 自動化。
若想更進一步，把圖片轉成 WebP 圖片格式 還能再省一截。WordPress 圖片優化 與 圖片 SEO 兩個方向一起推進，體積降下來，速度與搜尋曝光往往同步受益。
啟用網站快取可以加速重複訪問，但對首次載入無效。快取的原理是把第一次下載的資源暫存起來，第二次訪問直接從暫存讀，省下重新下載的時間。要記得它的限制：它只幫助「曾經來過的人」，對第一次造訪的新訪客沒有用，所以別以為裝了快取就一勞永逸。想知道原理可以看 網站快取是什麼，實際挑工具則參考 WordPress 快取外掛實測比較 與 WP Rocket 快取外掛設定教學。
主機等級直接影響 TTFB（第一個位元組時間），是根本性的速度瓶頸。再好的優化都救不回一台反應太慢的主機。挑選時可參考 WordPress 主機深度評測 與 Cloudways 雲端主機教學，依照預算與流量需求選。
不懂主機類型差異的人，先讀 虛擬主機類型比較 與 虛擬主機挑選指南，VPS 主機完全攻略 也是常見選項，會比較知道哪種規格適合自己。
想看單家實測，SiteGround 主機實測 與 A2 Hosting 主機評價 都能對照參考，Bluehost 主機評價 也是常被拿來比較的選項。
過多外掛會增加伺服器負擔，同類型外掛留一個就好，裝多不但不會互補，還可能彼此衝突。整理 WordPress 必裝外掛清單 時，把用不到的清掉，是免費又有效的提速動作。想找一條龍解法，可參考 WordPress 效能優化外掛。
網域與憑證設定卡住的話，DNS 網域指向設定 與 SSL 憑證與 SEO 影響 可以一併排查；若還沒把網站從 HTTP 換成 HTTPS，也順手處理，避免混合內容拖慢載入。
對憑證與安全協定還不熟悉的人，先讀一篇 HTTPS 基礎認識 會比較知道該檢查哪些環節，再回頭對著工具調設定才不會卡關。
縮小 CSS 與 JS、啟用 延遲載入 能進一步壓低載入時間。如果你的網站 LCP 一直壓不下來，多半出在主機或大圖，這時讀 網站速度慢的診斷與解法 對照症狀會比較快。
行動版特別慢的人，也可以考慮 AMP 加速行動頁面 或 本機託管 Google Fonts 加速 這類針對性行動。佈景主題本身吃資源的話，換一套輕量的 WordPress 佈景主題 也是治本做法。
測速時最常踩的坑與疑難排解
知道用什麼工具、知道怎麼排序，不等於測速過程不會出錯。以下是站長在實際操作時最常踩的幾個坑，每一個都會讓你對著錯的數字白忙一場。把這些前置作業做對，測出來的數字才有意義。
測的是有快取的頁面，卻以為是首次載入
很多工具或瀏覽器會把剛跑過的頁面資源暫存起來，第二次測的時候直接讀暫存，跑出來的分數會異常漂亮。要測真實的首次載入表現，請在測試前清除瀏覽器快取、關閉瀏覽器擴充功能（尤其是廣告阻擋器，它會擋掉第三方腳本讓分數虛高），並使用無痕視窗。PageSpeed Insights 與 GTmetrix 的伺服器端測試本身會模擬全新訪客，問題不大；用 Lighthouse 本機跑時要特別留意這點。
只測首頁，漏掉真正出問題的內頁
首頁通常是被優化最多的頁面，分數好看不代表整站都快。真正吃流量的往往是文章頁、分類頁、產品頁，它們可能載了首頁沒有的圖片、嵌入影片或第三方小工具。建議把流量最大的前幾個頁面都測一遍，尤其是 Google Search Console「體驗」分頁點名為問題頁面的那些。測對頁面，才有機會測出真正的問題。
用單次跑分下定論
Lab data 每次跑都會浮動，單次分數可能受到測試節點當時的負載影響。看到一個差強人意的分數先別緊張，同一個頁面多跑幾次（建議至少三次），看中間值與趨勢，比看單次極端值可靠。若三次都紅燈那才值得動手；若忽紅忽綠，多半是測試環境的雜訊，先觀察幾天再判斷。
把不同工具的分數拿來直接比
Lighthouse 的 85 分、GTmetrix 的 B、PageSpeed Insights 的黃燈，三者量測條件不同，沒有換算公式，硬比只會更混亂。正確做法是每個工具各看它擅長的那一塊：PageSpeed Insights 看 Field data 燈號、GTmetrix 看檔案層級、Lighthouse 看開發中的即時變化。讓每個工具回到它設計目的，分數才會說話。
測出問題卻找不到負責的檔案
PageSpeed Insights 告訴你「移除未使用的 CSS」，卻沒說是哪個檔案；這時要往下接 GTmetrix 或 Pingdom 的瀑布圖，把佔體積最大、載入最久的 CSS 或 JS 挑出來。若是 WordPress 站，常見的元兇是佈景主題與外掛各自塞了一包沒用到的樣式表。關掉外掛逐一比對、或用查詢每個資源來源的功能，能逐步把責任歸屬找出來。找不到具體檔案就動手改，往往改錯地方。
建立定期測速的工作流程
速度優化不是做一次就結束的事。外掛更新、新增內容、換圖、第三方服務改版，任何一個變動都可能讓原本通過門檻的指標悄悄退步。把測速納入固定的維護節奏，才能在排名掉下來之前先發現問題。底下是一個可以照著做的月度工作流程。
- 第一步，看 Search Console 體驗分頁：確認有沒有新增的問題頁面，這是 Google 自己告訴你哪些頁面被扣分的入口。
- 第二步，跑 PageSpeed Insights 手機版：針對流量最大的幾個頁面與 Search Console 點名的頁面，看 Field data 三個燈號有沒有變色。
- 第三步，記錄評分卡：把當月的 LCP、INP、CLS、TTFB 數值填進前面那張評分卡，與上個月比對，留意是否有悄悄惡化的項目。
- 第四步，有紅燈才往下挖：用 GTmetrix 或 Pingdom 針對變紅的頁面定位具體檔案，用 WebPageTest 重現特定地區或網速情境。
- 第五步，動手並驗證：依高影響低成本的順序改善，改完重測確認燈號轉綠，再回到第一步等待下個月。
這個流程的好處是它有明確的觸發條件：有紅燈才往下挖，沒有紅燈就只做例行記錄，不會無謂地消耗時間。對流量大的電商或內容站，可以把頻率拉高到雙週；對流量穩定的小站，每月一次通常足夠。把這個流程寫進 年度內容更新流程 裡排程執行，速度檢測就會從臨時起意變成穩定的維護習慣。
長期追蹤成效，也能透過 WordPress 安裝 GA 觀察跳出率與停留時間的變化，速度優化的成果會直接反映在 GA4 工作階段 的數字上。把檢測數字與行為數字擺在一起看，才能確認「分數變好」真的轉成了「使用者留得更久」。
網站速度測試常見問題（FAQ）
站長測速時最常遇到的疑問，集中在「分數不一樣怎麼辦」「手機版要不要跟電腦版一樣快」「免費版夠不夠用」「INP 是什麼」這幾題。底下逐一給出可以操作的判斷方式。
- 分數分歧是正常的：Lab 與 Field 數據來源不同，加上測試節點不同，分數本來就不會一致
- 行動版與桌面版分開看：行動版通常較慢，Google 採行動優先索引，以行動版為準
- 免費版夠用：多數站長日常檢測免費即可，付費適合需長期監控者
- INP 已上線：2024 年 3 月起接手 FID，成為 Core Web Vitals 的互動指標
網站速度測試要使用什麼工具？
多數站長用 Google 官方的 PageSpeed Insights，再加一款檔案層級工具（GTmetrix 或 Pingdom）就能應付日常檢測。要深入排查地區與網速差異，才動用 WebPageTest。
PageSpeed Insights 分數多少才算合格？
真正決定排名訊號的是 LCP ≤ 2.5 秒、INP ≤ 200 毫秒、CLS ≤ 0.1 三個門檻有沒有通過（[來源：〈web.dev — Core Web Vitals〉〈https://web.dev/articles/vitals〉〈2026〉]），那個 0 到 100 的總分只供參考。門檻才是判斷依據。
GTmetrix 與 PageSpeed Insights 測出來分數不一樣怎麼辦？
這是正常的。兩者量測的東西不同：PageSpeed Insights 同時給真實用戶 CrUX 資料，GTmetrix 是單次實驗室跑分且可選節點。別把它們的分數拿來直接比，而是各取自己需要的資訊。
網站載入速度幾秒內才算正常？
Google 公開建議把頁面載入壓在 3 秒內（[來源：〈web.dev — Core Web Vitals〉〈https://web.dev/articles/vitals〉〈2026〉]）。更實際的標準是看 LCP 是否在 2.5 秒內，載入時間拉長，跳出率會明顯上升。
手機版網站速度比電腦版慢正常嗎？
正常。行動裝置的運算能力與網路條件通常較弱，所以行動版分數偏低是普遍現象。但因為 Google 採行動優先索引，你應該以行動版的表現為準來優化。
WebPageTest 可以測特定地區的速度嗎？
可以。WebPageTest 支援指定測試節點、瀏覽器、裝置與連線速度，包含多個亞洲節點，能精準重現某個地區、某種網速下的載入情境（[來源：〈WebPageTest 官網〉〈https://www.webpagetest.org/〉〈2026〉]）。
網站速度慢最常見的原因是什麼？
前三名通常是圖片沒壓縮、主機反應太慢（TTFB 過高）、外掛裝太多。圖片常佔掉頁面最大宗體積，主機等級決定根本性的回應速度，過多外掛則增加伺服器負擔。
測完網站速度後，第一步該優化什麼？
先做影響人數最多、成本最低的三步：壓縮圖片、啟用快取、清理多餘外掛。做完再回頭看 Core Web Vitals 哪個指標沒過，才不會把時間花在邊際效益最低的地方。
GTmetrix 免費版跟付費版差在哪？
免費版夠日常檢測用；付費版多了歷史趨勢追蹤、監控告警與更多監測位置。需要長期監控網站表現、或想接到自動化流程的站長，才需要考慮升級（定價以 GTmetrix 官網為準）。
INP 指標是什麼時候取代 FID 的？
2024 年 3 月。INP 量測整個工作階段所有互動中最差的回應速度，比只看第一次互動的 FID 嚴格，所以不少網站在切換後分數反而變差（[來源：〈web.dev — INP 成為 Core Web Vitals〉〈https://web.dev/blog/inp-cwv〉〈2024〉]）。
Field data 顯示「無資料」怎麼辦？
這代表該頁面真實流量太低，CrUX 還沒累積到足夠樣本。這時改用 Lab data（Lighthouse 或 PageSpeed Insights 的診斷區塊）來判斷技術狀況即可。等到頁面流量成長、樣本累積夠了，Field data 自然會出現。低流量頁面本來就不是排名訊號的主要戰場，過度在意它的 Field data 沒有意義。
改善速度後多久才會看到排名變化？
Core Web Vitals 的 Field data 反映過去 28 天的累積表現，所以你今天做的改善，最快要等到新數據蓋過舊數據、約一個月後才會在 Field data 上穩定呈現；排名端的回應又更慢，因為速度只是眾多排名訊號之一。把時間軸抓在「改善後一到三個月觀察」，比較符合實際節奏，也不會因為隔週沒動靜就誤以為優化無效。
第三方腳本（廣告、追蹤碼）拖慢速度該怎麼辦？
先用 GTmetrix 或 Pingdom 的瀑布圖確認是哪幾個第三方網域吃掉最多時間。能延後載入的（如社群按讚按鈕、追蹤碼）就設成延後或條件觸發；非必要的就移除。廣告碼通常無法完全移除，但可以限制只在使用者捲動或互動後才載入，降低對首次載入的衝擊。每一次新增追蹤碼都會在瀑布圖上多一條，定期審視並砍掉沒在用的，是長期維持速度的關鍵習慣。
回顧一下，網站速度測試的真正價值，是用對工具回答對的問題。先想清楚自己在問什麼：是擔心排名風險、想知道哪個檔案拖慢、還是懷疑某個地區特別慢？答案不同，該開的工具就不同。把 PageSpeed Insights 看懂、再配上一款檔案層級工具，已經能解決多數站長的疑問。
測完之後依「影響人數最多、成本最低」的順序動手：壓縮圖片、啟用快取、清理外掛，做完再回頭對 Core Web Vitals 的門檻。工具少但用對，勝過工具多卻看不出下一步。把測速納入固定的月度維護節奏，規則年年都在微調，把速度檢測寫進 年度內容更新流程 裡定期複檢，才不會等到排名掉了才回頭補。