網站速度測試分析與優化指南

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Gemini Grok

網站速度測試做錯了，優化方向就跟著錯，裝了一堆外掛反而更慢。

TL;DR — 測速不是打開工具按一下就結束。你需要搞懂快取狀態、測試節點位置、多次取樣，以及 HTTP 標頭透露的真相。本文從實務角度拆解完整的測速流程，讓你不再「測了半天卻不知道測到什麼」。

測速之前，先搞清楚你的網站「處於什麼狀態」

這是最多人忽略的一步。你的 WordPress 網站在測速當下的狀態，會直接決定測出來的數據代表什麼意義。隨便測一個數字就拿來當基準，跟閉著眼睛射箭再畫靶心沒兩樣。

底下三個問題，每次測速前都該先回答。

快取外掛開了沒？這是第一個要確認的事

如果你用的是共享主機或 VPS，裝一套 WordPress 快取外掛是基本操作。但很多人測速時忘記確認快取到底有沒有生效，結果測到的其實是「未快取」的原始回應時間。這個數字看起來當然很糟，但它反映的不是你網站真正的問題，而是你的測試方法有漏洞。

判斷快取是否生效的方法很簡單：用瀏覽器開發者工具（F12）打開 Network 面板，重新整理頁面，檢查回應標頭。如果你用的是 WP Rocket，正常命中快取的頁面會在標頭看到相關快取標記；如果是 SG Optimizer，則會看到 x-proxy-cache: HIT。看不到這些標記，代表快取沒有生效，測出來的數據不能當基準。

要注意的是，快取外掛之間通常不能同時啟用。同時開兩套頁面快取外掛可能互相衝突，反而讓速度變更慢，甚至產生頁面顯示錯誤。測試時請確保同一時間只有一套快取外掛處於啟用狀態。

CDN 有沒有正常運作？別讓測速工具繞過它

Cloudflare 是最廣泛使用的免費 CDN 方案。它不只提供 DNS 代管和免費 SSL 憑證，更重要的是透過全球邊緣節點快取你的靜態資源，讓訪客從最近的節點取得檔案，不用每次都連回你的原始伺服器。這對於主機在海外、讀者卻集中在亞洲的網站來說，改善幅度尤其明顯。

測速時要特別注意：有些測速工具的請求可能不經過 CDN，或是你的 DNS 尚未完全指向 Cloudflare，導致測出來的結果根本沒有反映 CDN 的加速效果。正確的做法是先在瀏覽器打開網站，用開發者工具的 Network 面板確認回應標頭中有 cf-cache-status 欄位，且值不是 BYPASS 或 MISS，確認 CDN 確實在運作，再拿工具去測。

如果你想量化 CDN 對速度的實際幫助，可以在 Cloudflare 後台暫時停用 CDN 功能，用同一個測速節點各跑三次做 A/B 對照。通常啟用 Cloudflare 免費方案後，亞洲地區的 TTFB 就能改善 100 到 300 毫秒，取決於你的主機位置和 CDN 節點覆蓋情況。

主機端快取也要納入考量

某些主機商會在伺服器層級實作額外的快取機制，這一層是快取外掛和 CDN 都管不到的。例如 Hostinger 會在安裝 WordPress 時自動啟用自家快取外掛，跟主機端的 LiteSpeed 快取做搭配。SiteGround 則透過 SG Optimizer 與主機端快取整合，在 Nginx 層級就先攔截並快取動態頁面。這種多層快取架構的好處是速度快，壞處是清除快取的時機如果沒拿捏好，訪客可能會看到過期的內容。

如果你是用 VPS 自行架設環境，搭配 Varnish 這類反向代理快取，那更需要精確設定清除規則。VCL（Varnish Configuration Language）設定寫錯一個條件，就可能讓整個快取機制形同虛設，或者讓登入中的管理員看到快取版本的頁面而誤以為修改沒生效。建議每次調整後都用 UpdraftPlus 先備份一次網站，養成好習慣。

測速工具怎麼選？別只依賴一種

市面上測速工具一大堆，每種的評測標準、請求來源、呈現方式都不一樣。只用一種工具就下定論，就像只看一家的體檢報告就決定要不要開刀，風險很高。底下介紹幾個常用的工具，以及它們各自擅長的場景。

Pingdom 是做基礎測試的首選。它的介面乾淨，測試速度快，最實用的是它會清楚顯示頁面大小、請求數量、以及按資源類型分類的載入時間。Pingdom 的測試節點分布在全球幾個主要城市，讓你可以模擬不同地區訪客的實際體驗。不過 Pingdom 的評分標準比較寬鬆，拿到 90 分不代表你的網站真的很快，只能說「在 Pingdom 的標準下還可以」。

GTmetrix 是做深度分析的首選。它的瀑布圖比 Pingdom 更詳細，每一個請求的連線時間、等待時間、下載時間都分開顯示，讓你可以精確定位瓶頸。GTmetrix 同時整合了 Google Lighthouse 的評分和自己的瀑布圖分析，兩個維度一起看，診斷能力比單一工具強很多。免費版有限制測試節點和每日次數，但對一般使用者來說已經夠用。

Google PageSpeed Insights 是另一個必測的工具，因為它提供的 Core Web Vitals 數據（LCP、INP、CLS）是 Google 實際從 Chrome 使用者那裡收集到的真實資料，不是模擬的。截至 2026 年 5 月，Core Web Vitals 的三個指標分別是：LCP（Largest Contentful Paint，最大內容繪製）衡量載入效能，INP（Interaction to Next Paint，互動到下一次繪製）衡量互動回應速度，CLS（Cumulative Layout Shift，累計佈局偏移）衡量視覺穩定性。如果你的網站流量不夠大，PageSpeed Insights 可能會顯示「資料不足」，這時候就只能參考 Lighthouse 的實驗室數據。但只要網站有一定流量，PageSpeed Insights 的實地數據遠比任何模擬工具更有參考價值。

如果你想要持續監控網站速度的長期趨勢而不只是一次性的快照，SimpleOps 這類監控工具能定期記錄效能數據，讓你看到速度隨時間的變化曲線，在速度異常惡化時及時發現問題。

測試節點選哪裡？跟你的讀者走就對了

每一個測速工具都會讓你選擇發出請求的地點，而這個選擇會大幅影響結果。如果你的主要讀者在台灣，主機放在美國西岸，結果你選了一個歐洲的節點來測，測出來的 TTFB 當然會很難看。但這個難看的數字對你真正的讀者來說一點參考價值都沒有，因為你的讀者根本不會從歐洲連過來。

正確的做法很直覺：你的主要客群在哪裡，測試節點就選離那裡最近的位置。如果你是剛開站還不清楚客群分布，可以先用 Cloudflare Speed Test 或 nPerf 測一下從不同地區連到你的主機的延遲，建立一個基本的地理位置效能地圖。你也可以從 Google Analytics 或 Search Console 確認你的主要流量來源地區，再決定測試節點。

另一個常見的錯誤是，今天用日本節點測，明天用美國節點測，然後把兩組數據拿來比較，結論是「速度變慢了」。這其實毫無意義，因為你改變了測試條件。正確的追蹤方式是每次都用同一個節點、同一個工具，數據才有可比較性。

一次測速絕對不夠，至少跑三次再下結論

這是很多人犯的錯誤：開啟工具，輸入網址，按一次測試，看到數字就開始慌。但那個數字可能代表的是你剛剛才清除快取後的冷啟動結果，也可能是 CDN 節點剛好正在更新的瞬間，或者是測速工具自身伺服器網路塞車。任何單一數據點都不該成為你下結論的依據。

比較可靠的做法是連續測試三次，然後觀察 HTTP 回應標頭。在 Pingdom 的測試結果頁面下方，點開任何一個請求就能看到完整的 HTTP Headers。如果你看到 x-proxy-cache 的值是 MISS，代表這次請求沒有命中快取，你測到的其實是伺服器重新產生頁面的時間，通常會比正常瀏覽慢上一倍以上。如果值是 HIT，才是真正代表訪客日常瀏覽時會體驗到的速度。

一個空白 WordPress 網站在快取 MISS 的狀態下 TTFB 大約 0.8 秒，快取 HIT 之後降到 0.4 秒左右，差距將近一倍。如果你的網站內容更多、外掛更複雜，這個差距只會更大，從 2.5 秒降到 0.6 秒的案例也不少見，改善幅度超過 75%。這也是為什麼在 WordPress 速度優化技巧當中一直強調快取是投資報酬率最高的優化手段，沒有之一。

建議的做法是：第一次測試之後，不要急著看分數，先捲到下方確認快取狀態。如果是 MISS，就再測一次。等到連續兩次都顯示 HIT，再把那個數字記錄下來當作基準值。這個小動作可以幫你避免很多不必要的誤判。

看懂瀑布圖，才能找到真正的瓶頸

測速工具給你一個總分和總載入時間，但那只是表象。真正有價值的資訊藏在瀑布圖（Waterfall Chart）裡面。瀑布圖會按時間軸列出每一個 HTTP 請求，讓你看到哪個資源載入最久、哪些請求之間有依賴關係、有沒有被第三方資源阻塞。學會看瀑布圖，是從「會用測速工具」進階到「會診斷速度問題」的關鍵一步。

舉個實際的例子。你在瀑布圖裡面看到一條長長的綠色橫條，那是某個 JavaScript 檔案在下載。再往上追，你可能會發現這個 JS 是 Google Analytics 或 Facebook Pixel 這類第三方追蹤程式帶進來的。這類問題不是裝快取外掛就能解決的，需要從追蹤程式的載入方式著手。一個常見的做法是用 async 或 defer 屬性讓這些腳本非同步載入，不阻塞主要內容的呈現。

又或者你看到圖片檔案佔了大部分的載入時間，那就要回頭檢查圖片是否經過壓縮、是否使用了 WebP 格式、有沒有啟用延遲載入（Lazy Load）。很多時候，光是把圖片做好最佳化，整體載入速度就能改善 30% 以上。一張 2MB 的 JPEG 如果轉成 WebP 並適當壓縮，可能只剩 200KB，體積減少 90%，但視覺品質幾乎沒有差異。

如果你想知道是否該啟用GZIP 壓縮來減少傳輸量，瀑布圖也能給你答案。看看那些 HTML、CSS、JS 檔案的實際傳輸大小，如果發現未經壓縮的純文字檔案動輒幾十 KB 甚至上百 KB，啟用 GZIP 通常能壓縮掉 60% 到 75% 的體積。大多數現代主機預設都會啟用 GZIP，但如果你用的是老舊的共享主機或自己管理的 VPS，這可能是被遺漏的設定。

主機等級決定速度天花板，別在爛主機上做微調

做了一大堆優化，最後才發現主機本身就是瓶頸，這種狀況很常見。如果你的主機回應時間基準線就已經是 1.5 秒以上，不管你怎麼調快取、壓圖片、啟用 CDN，效果都很有限。就像一棟地基沒打好的房子，你在裡面換再漂亮的水晶燈也不會讓結構變得更穩。

在 WordPress 主機完整評價當中測試過超過 17 家主機商，速度表現的差距非常大。Bluehost 在新手友善度和WordPress 安裝流程上表現不錯，適合剛起步的站長。SiteGround 在速度與客服品質兩個維度上都是前段班。如果你的預算充足，Kinsta 提供的管理型 WordPress 主機在效能和穩定性上都有很高的水準。

如果你不確定自己目前的主機水準在哪，可以先參考虛擬主機類型的選擇指南，搞清楚共享主機、VPS 和管理型主機的差異，然後用本文的方法測一下現在的速度。如果基準線實在太差，與其花時間做微調，不如認真考慮換一台效能更好的主機。換主機帶來的速度提升，往往比你花一個月做各種微調還要顯著。

一個完整的測速 SOP，照著跑就對了

把上面講的觀念整合成可執行的流程，就是底下這七個步驟。每次做速度優化前後都跑一次，你就能用數據說話，而不是憑感覺判斷。

1. 確認環境狀態：記錄你目前使用的主機、是否啟用快取外掛、是否有使用 CDN（例如 Cloudflare）、是否有主機端快取。建議用一個簡單的試算表記下來，方便日後追蹤。
2. 選定測試節點：根據你的主要讀者所在地，選擇最近的測試節點，之後每次都用同一個節點。不要今天測日本、明天測美國，這樣數據無法比較。
3. 第一次測試（冷啟動）：清除所有快取後立刻測一次，記錄 TTFB 和總載入時間。這代表「最差情況」，也就是第一次造訪你網站的使用者會體驗到的速度。
4. 第二和第三次測試（快取命中）：不動任何設定，連續再測兩次。觀察 HTTP 標頭中的快取狀態是否從 MISS 變成 HIT。這才是回訪者的日常體驗。
5. 交叉驗證：換一種測速工具（例如從 Pingdom 換到 GTmetrix），用同一個節點再跑一次，確認趨勢一致。如果兩個工具的結論完全相反，就需要進一步調查原因。
6. 分析瀑布圖：找出耗時最長的資源請求，判斷是圖片、JavaScript、CSS、還是第三方服務造成的瓶頸。這一步決定了你後續的優化方向。
7. 記錄基準值：把快取命中後的 TTFB、FCP（首次內容繪製）、LCP（最大內容繪製）、CLS（累計佈局偏移）、INP（互動到下一次繪製）記錄下來，當作後續優化的比較基準。每次優化後重複步驟三到六，確認數據確實有改善。

這個流程跑一次大約 15 到 20 分鐘，但你能拿到的是一組可靠的、可重現的數據，而不是一個不知道代表什麼的單一數字。如果你同時管理多個網站，可以搭配 SimpleOps 做自動化監控，設定警報閾值，速度異常時第一時間收到通知，不用等到讀者跟你抱怨才發現問題。

實際操作中的幾個坑，踩過才知道痛

底下分享幾個在幫人看網站速度時經常遇到的問題，這些通常是工具本身不會告訴你的，需要靠實務經驗累積才能學到。

第一，Google Fonts 是隱形殺手。很多 WordPress 自行架站的用戶，佈景主題預設會載入 Google Fonts，有些一載就是兩三組字型，每組還包含好幾個字重。這些外部請求加起來可能吃掉你 200 到 400 毫秒的載入時間，而且在瀑布圖裡面特別顯眼。如果你不用特殊字型，建議直接在佈景主題設定裡關掉，改用系統字型。現在大部分現代瀏覽器對系統字型的渲染效果已經很好了，一般讀者根本分不出差異。

第二，外掛裝太多是效能毒藥。很多站長看到推薦某個外掛不錯就裝來試試，結果裝了 30 幾個外掛，其中 20 個從來沒在用。每個外掛就算沒啟用，也可能在資料庫裡留下選項記錄，增加 wp_options 資料表的查詢負擔。有些甚至在停用狀態下還是會被 WordPress 的自動更新機制掃描，消耗伺服器資源。定期清理不需要的外掛，是免費就能做到的優化，效果可能比花錢買付費外掛還要好。

第三，過度優化的反面教材。追求 PageSpeed Insights 滿分不是壞事，但如果為了分數把所有 CSS 和 JavaScript 全部延遲載入，導致選單打不開、表單送不出、輪播圖不動，那就本末倒置了。追求分數沒有錯，但如果犧牲了使用者體驗，那分數再高也沒意義。速度優化的終極目標是讓讀者覺得「這個網站很好用」，不是讓工具覺得「這個網站分數很高」。

第四，忽略行動裝置速度。很多人只測桌面版速度，但現今超過六成的流量來自行動裝置。Google 的 Core Web Vitals 也是以行動裝置的數據為主要評估標準。測速時務必同時測試行動版，並且特別注意 LCP 和 CLS 這兩個指標。CLS 常見的元凶是廣告區塊、沒有設定固定長寬的圖片、以及動態插入的內容，這些在桌面版可能不明顯，但在行動版的小螢幕上會造成明顯的頁面跳動。

第五，把 PageSpeed Insights 的分數當成唯一目標。這個工具的分數是基於一套固定的標準來評估，但你的網站可能有一些合理的技術選擇會被扣分。例如你有必要使用某個較大的 JavaScript 函式庫，或者頁面需要載入互動式元件。這些情況下分數可能不高，但使用者的實際體驗可能很好。與其盲目追求高分，不如把重點放在實際的使用者體驗指標上：網站是不是能在 3 秒內呈現主要內容？互動是不是流暢？頁面載入過程中會不會亂跳？這些才是真正影響使用者感受的因素。

適合誰 / 不適合誰

三個立即可以做的下一步

1. 用 Pingdom 跑一次完整測試：選擇離你主要讀者最近的節點，連續測三次，確認快取狀態是 HIT 之後記錄 TTFB 和總載入時間當基準。預期結果：你會拿到一組可靠的基準數據，知道目前的真實速度水準。
2. 用 PageSpeed Insights 檢查 Core Web Vitals：輸入你的網址，查看行動版的 LCP、INP、CLS 是否都在合格範圍內（LCP < 2.5 秒、INP < 200 毫秒、CLS < 0.1）。如果有指標不合格，回到本文對應的段落找解法。
3. 確認你的快取和 CDN 都正常運作：打開瀏覽器開發者工具的 Network 面板，重新整理頁面，檢查回應標頭中是否有快取命中的標記（x-proxy-cache: HIT 或 cf-cache-status: HIT）。如果沒有，先解決快取問題再測速，否則測出來的數據不具參考價值。

常見問題

Pingdom、GTmetrix、PageSpeed Insights 到底該用哪個？

三個都測最好，它們各有長處。Pingdom 偏向實際載入體驗的模擬，介面直覺，適合快速確認整體狀況。GTmetrix 的瀑布圖最細緻，適合做瓶頸分析。PageSpeed Insights 是 Google 官方的 Core Web Vitals 數據來源，如果你的網站有足夠流量，它提供的實地資料比任何模擬都更有參考價值。交叉使用才能得到完整的輪廓，不要只看一個工具的分數就下結論。

為什麼同一個工具每次測出來的數據都不一樣？

因為你的網站不是在真空環境裡運作。伺服器當下的負載、CDN 節點的快取狀態、測速工具自身伺服器的網路狀況，都會造成波動。在共享主機上這個問題更明顯，因為你跟其他網站共用同一台伺服器，別人流量的尖峰可能剛好就是你測速的時候。這也是為什麼至少測三次取中位數，而不是只看單次結果。波動在 100 毫秒以內都算正常範圍，超過這個範圍才需要進一步調查。

我的 PageSpeed Insights 行動版分數很低，該怎麼辦？

先看是哪個指標不及格。如果是 LCP 過高，通常是圖片或伺服器回應時間的問題，可以從圖片格式最佳化和TTFB 優化下手。如果是 CLS 過高，檢查是不是廣告、圖片或動態載入的元素沒有預留空間，在 HTML 中給圖片設定明確的 width 和 height 屬性通常就能解決。如果是 INP 過高，代表 JavaScript 的互動回應太慢，需要檢查前端腳本的執行效率，可能要拆分或延遲載入某些互動元件。

裝了快取外掛後，為什麼有時候文章更新了但前台還是舊內容？

這是多層快取沒有正確同步的症狀。你的網站可能同時有瀏覽器快取、CDN 快取、主機端快取、WordPress 外掛快取這四層，每一層清除的時機和方式都不一樣。更新內容後，你需要確認所有層級的快取都被正確清除。大部分好的快取外掛會在發佈或更新文章時自動清除相關快取，但如果你的主機端或 CDN 端有額外快取，可能需要手動清除。建議在清除快取後，用無痕模式或清除瀏覽器快取的方式確認前台顯示的是最新內容。

測速工具的分數多少算合格？

一般標準是：TTFB 在 200 毫秒以內算優秀，200 到 500 毫秒算及格，超過 600 毫秒就需要認真處理。總載入時間（Fully Loaded Time）則看你的頁面複雜度，一個內容豐富的文章頁面在 2 秒以內載入完畢就算是很好的表現。Core Web Vitals 方面，LCP 在 2.5 秒以內是合格標準，CLS 在 0.1 以內，INP 在 200 毫秒以內。但分數只是參考，真正重要的是使用者的實際感受。與其追求滿分，不如確保網站在大部分情況下都能在 3 秒以內完成主要內容的呈現，互動操作都能在可接受的時間內回應。