不同的測速工具用不同的方式測量網站速度，結果也不會完全相同，這對站長優化時的決策會造成困擾。比較三大測速工具的差異、了解影響測速結果的變數、學會解讀核心指標，才能從測速報告真正找到優化方向。
Google PageSpeed Insights 怎麼看
Google PageSpeed Insights（PSI）是 Google 自家工具，結合真實使用者數據（CrUX）與合成測試。每次測試會模擬行動與桌面兩種環境分別評分，速度分數與 Core Web Vitals（核心網頁指標）並列呈現。
PSI 最大的特色是整合了 Chrome User Experience Report 的真實訪客數據。報告開頭「評估本頁面的真實體驗」段就是 CrUX 數據，反映過去 28 天內真實使用者的訪問情況；下方合成測試則是固定條件下的實驗室環境測試。站長一定要看真實數據，因為真實用戶的網路、裝置、位置都比實驗室環境複雜得多。PSI 之所以被信賴，就在這兩類數據互補。PSI 預設測試桌面版時用的是較快的網路與較好的裝置，行動版預設是 Slow 4G 與中階手機，這些設定都可自行調整。
GTmetrix 的選題性強在哪
GTmetrix 是加拿大團隊出的付費測速工具，預設用 Lighthouse 測試演算法。它最實用的地方是可選擇測試地點（溫哥華、香港、倫敦、孟買等約 10 個地點），適合判斷不同地區訪客的加載體驗，特別是跨境電商常需了解各地表現差異。另一個特色是「瀑布圖」（Waterfall）詳細列出每個資源的載入順序與耗時，比起其他工具能更清楚看出誰在拖後腿——像是第三方腳本、廣告網路、分析工具各佔多少加載時間。
GTmetrix 也會給出 Lighthouse 評分，但額外補上自己的一套「Page Speed Grade」評分系統，兩套分數有差異時能幫助站長判斷評分標準的不同。付費版本還能設定監控排程、追蹤歷史趨勢，適合定期維護的大型網站。
WebPageTest 給進階站長的視角
WebPageTest（WPT）是開源的專業測速工具，選項最複雜、可客製程度最高。它可以自選測試地點（遠比 GTmetrix 多）、瀏覽器版本、網路模式（不只 Slow 4G，可自訂具體頻寬），甚至可在測試前後執行自訂腳本。WPT 的影片回放功能很獨特，能看見頁面載入過程中每一幀的渲染速度，特別適合調查「為什麼這 3 秒內體驗這麼差」這類細微問題。
WPT 的出發點是「測試環境要儘可能接近真實使用情境」，所以複雜性高；但如果你要驗證特定網路狀況下的表現（比如「台灣 4G 使用者看我網站要多久」），WPT 幾乎是唯一選擇。另外 WPT 也支持 Core Web Vitals 但呈現方式與 PSI 不同，需習慣各工具的報告格式差異。
三大工具的量尺不同在哪
Google PageSpeed Insights 快速、免費、整合真實數據，但無法選地點；GTmetrix 平衡好用性與細節，多地點選擇適合跨境評估；WebPageTest 最靈活但上手陡峭，適合鑽研細節的開發者。選哪一個取決於你的優先順序——只想快速掌握站點狀況用 PSI，需要地域差異對比選 GTmetrix，追求完全客製選 WPT。
測試結果為何差這麼大
同一個網站用三個工具測，分數往往不同，最常見的原因是測試地點不同。台灣站用美國主機，從台灣測與從美國測的延遲（TTFB）可能差 200ms 以上，光這項就能拉低 LCP 幾秒鐘。PSI 預設用 Google 伺服器（位置不明確），GTmetrix 需手選，WPT 選項最多；如果沒注意到地點差異，會誤判「為什麼 PSI 說快 GTmetrix 說慢」。
第二個常見差異是快取狀態。大多測速工具預設清空瀏覽器快取（cold cache），每次重新下載所有資源，但訪客第二次進站時會用上快取。如果網站主要問題其實是伺服器回應時間（TTFB），而你的快取外掛沒有正確命中，那測 cold cache 會看到真相，但測 warm cache 會遮掩問題。PSI 的 CrUX 數據反映的是真實使用者（混合 cold 與 warm），合成測試可切換，GTmetrix 與 WPT 也都支持。
第三是測試環境的網路與裝置規格。PSI 行動測試用 Slow 4G + 中階手機，GTmetrix 有自己的預設，WPT 可完全自訂。如果你的網站在快網路上已最佳化，但訪客多數用 3G 或不穩定的行動網，Slow 4G 測試會更準。反過來若真實訪客多半在 Wi-Fi，用 Slow 4G 測就容易過度優化。
最後是指標計算方式細節。LCP（最大內容繪製）定義一樣，但如果頁面有動態載入內容，什麼時刻算作 LCP 完成各工具會有詮釋差異；INP（下一次繪製的互動延遲）測的時間窗口長度也不同。了解這些細節後你會明白，「測速報告分數差異」本身就是資訊——告訴你在不同環境下體驗會差多大。
LCP、CLS、INP 數值怎麼解讀
核心網頁指標（Core Web Vitals）是 Google 評判頁面體驗的三個實驗室指標，2026 年的通過門檻是，LCP（最大內容繪製）2.5 秒以內、INP（下一次繪製的互動延遲）200 毫秒以內、CLS（累積版面漂移）0.1 以下。
LCP 量的是訪客看到頁面「有實質內容」的時間。網站上最大的圖片或文字區塊渲染完成時就是 LCP，通常發生在 0.5 至 3 秒之間。LCP 慢多半是因為伺服器回應時間長（TTFB）或 JavaScript 阻擋了內容渲染。優化順序是先檢查 TTFB（快取、伺服器，甚至換主機），再看是否有大圖沒優化、第三方腳本沒延遲載入。2.5 秒聽起來不長，但換位想像當你點擊一個連結，等超過 2 秒才看到內容，會覺得很慢。
INP 是新興指標，量的是使用者「按下按鈕到看見反應」的總延遲。打字、點選、捲動都計算在內，測的是全頁面在用戶交互時的響應性。200 毫秒的標準是根據人體感知研究訂的——超過 200ms 訪客會感覺有延遲。INP 慢通常代表主執行緒被長任務佔用（像是大型 JavaScript 運算、複雜 DOM 操作），優化方式是分割長任務、延遲非必需腳本、考慮用 Web Workers。
CLS 量的是頁面在加載過程中「視覺上的移位」。最常見的場景是圖片沒設定尺寸、廣告遲到、字型切換導致文字突然變寬——訪客正在閱讀卻突然行數被往下推，或原本要點的按鈕移位了。CLS 0.1 以下意思是整個加載過程中，頁面內容位置不應該超過畫面高度的 10%。優化最直接，圖片與影片加上 width 和 height、為廣告預留空間、使用 font-display: swap 避免字型閃爍。
快取狀態如何改變測速結果
快取分三層。第一層是瀏覽器快取——訪客的電腦記住了你上次下載的圖片和 CSS，第二次進站時不用重新下載。第二層是伺服器端快取，如果網站啟用頁面快取外掛（WP Rocket、LiteSpeed Cache），伺服器會把生成好的 HTML 直接發送給訪客，省去資料庫查詢。第三層是 CDN 快取，資源分散在世界各地的邊緣伺服器，訪客從最近的節點下載。
測速工具默認清空瀏覽器快取（cold cache），模擬新訪客體驗。如果你的網站沒啟用伺服器快取或 CDN，cold cache 測試會很慢；啟用後、或用 warm cache（保留快取）測試時會快很多。這就是為什麼有些站長說「PSI 測速很慢，但用戶反饋頁面很快」——因為訪客大多是回訪（用快取），PSI 測的是新訪客（無快取）。
如果你的優化重點是「新訪客首次進站要快」，就該重視 cold cache 測試；如果網站流量以回訪為主，warm cache 的測試結果其實更代表真實使用者體驗。頁面快取與 CDN 是這個取捨的關鍵——裝上它們後 cold cache 和 warm cache 的落差會明顯縮小。
測試地點為什麼會影響那麼多
網路延遲（Latency）決定了資料從伺服器到訪客電腦要多久。如果網站主機在美國機房、測試地點也在美國，延遲可能只有 20–50ms；但從台灣連接美國主機，跨太平洋光纖延遲就是 150–200ms。所以同一個網站，台灣測和美國測的 TTFB（伺服器首位元組回應時間）會差 150ms 以上。
LCP 包含了 TTFB 加上後續的資源下載與渲染，所以延遲高的地點，LCP 很自然就會拉高。這也是為什麼跨境電商要用 CDN——把資源複製到訪客附近的伺服器，大幅降低延遲。如果你用 PageSpeed Insights，預設測試地點是 Google 伺服器，未必在你的目標市場；GTmetrix 多地點選項就能讓你實測各地表現。
實驗室環境再完美，也不如真實用戶數據準。如果 PSI 的 CrUX 數據顯示「台灣訪客的真實 LCP 中位數 3 秒」，那你的優化目標應該是根據這個數據，而不是假設所有用戶都在美國。
最常見的測速後優化切入點
看完測速報告，站長通常會問「我該優化什麼」。最實用的優先順序是
第一優先，伺服器回應時間（TTFB）。如果 TTFB 超過 1 秒，其他優化的效果會被延遲掩蓋。檢查點是主機規格（CPU、RAM 足否）、資料庫查詢（是否有慢查詢）、頁面快取（是否啟用）、CDN（是否用上）。快取是最快見效的，次要才考慮換主機。
第二優先，圖片優化。大多數網站的資源載入時間中，圖片佔 50% 以上。檢查是否壓縮（WebP/AVIF）、尺寸（是否下載了 4K 解析度給行動裝置看）、延遲載入（Lazy Load，圖片捲入視野才載入）。一次改好圖片，LCP 與 CLS 都會改善。
第三優先，JavaScript 延遲。測速報告會列出哪些腳本最肥、執行最久。分析師外掛、聊天小工具、追蹤工具、廣告網路常常是兇手，檢查是否真的需要、能否延遲到使用者互動後再載入、或用異步加載。
第四優先，CSS 與字型。很多主題載入未使用的 CSS，字型檔案也會拖累速度，可用 Critical CSS 或字型優化外掛改善。
後續的優化（預連接、預載、ServiceWorker）是錦上添花。如果你的網站還在「圖片全是 5MB 的原始檔、沒裝快取外掛、TTFB 2 秒」的狀態，這些進階優化不會有感。