網站速度測試最簡單的做法，是用 Google PageSpeed Insights 輸入網址，同時看行動版與桌面版的表現，再從 LCP、INP、CLS、TTFB 這幾個指標判斷網站到底慢在哪裡。測完之後，再用 GTmetrix 或 WebPageTest 看資源載入瀑布圖，鎖定是圖片、主機、JavaScript 還是快取的問題。
真正的重點不是那個總分好不好看，而是把分數轉成「該先修哪裡」的行動方向。很多人卡住的地方，是測完拿到一堆紅字黃字，卻不知道哪些真的要處理、哪些可以先放著。這篇會把工具、指標、問題來源與改善順序整條串起來，讓你測完就知道下一步。
網站速度測試怎麼做？三步驟先跑一遍
網站速度測試的基本流程是：先選對要測的頁面，再用 PageSpeed Insights 測 Core Web Vitals，最後用資源分析工具找出拖慢的環節。
第一步是選頁面，不要只測首頁。首頁通常經過特別設計與快取，速度往往比實際帶流量的內頁好看。真正該測的是主要服務頁、流量最高的文章頁、商品頁、聯絡表單頁與結帳頁，這些才是使用者實際會停留、也會影響轉換的頁面。
第二步是用 PageSpeed Insights 測行動版與桌面版，先看 Core Web Vitals 有沒有通過，再看 LCP、INP、CLS、TTFB 哪一項最明顯異常。這一步的目的不是拿高分，而是找出「哪個指標在拖後腿」。
第三步是用 GTmetrix 或 WebPageTest 看載入瀑布圖，觀察圖片大小、請求數量、JavaScript 與 CSS 的載入順序。瀑布圖能讓你看到「時間到底花在哪」，這是單看分數看不出來的。
跑完這三步，你手上就會有兩種資訊：一是 Google 觀點的指標表現，二是實際資源載入的細節。接下來的排查與改善，都是建立在這兩者之上。
網站速度測試要看哪些指標？別只盯著總分
測速報告最容易誤導人的地方，就是那個大大的總分。分數只是入口，真正要判讀的是背後這幾個指標，因為它們才直接對應到「網站慢在哪一層」。
Core Web Vitals 是 Google 用來衡量實際使用者體驗的一組指標，涵蓋載入效能、互動性與視覺穩定性三個面向。換句話說，它關心的不是機器跑得多快，而是使用者感覺順不順。
| 指標 | 白話說明 | 常見問題方向 |
|---|---|---|
| LCP | 最大內容元素載入時間，影響使用者覺得「頁面出來了沒」 | 圖片太大、主機慢、CSS/JS 阻塞 |
| INP | 使用者點擊或互動後，頁面回應夠不夠快 | JS 太重、第三方腳本、主執行緒阻塞 |
| CLS | 頁面載入時版面會不會亂跳 | 圖片未設尺寸、廣告插入、字型載入 |
| TTFB | 伺服器開始回應的時間 | 主機慢、後端查詢慢、快取沒開 |
| 頁面大小 | 網頁下載的資源總量 | 圖片、影片、字型、JS/CSS 太多 |
| 請求數 | 網頁需要載入多少個檔案 | 外掛、追蹤碼、第三方工具過多 |
判讀的重點是：不同指標對應不同的問題層。TTFB 高，問題通常在伺服器端；LCP 差，多半卡在首屏的大圖或阻塞資源；INP 差，要往 JavaScript 和第三方腳本查；CLS 差，代表版面在跳動，多半是圖片沒設尺寸或廣告、字型造成。看懂這個對應關係，測速報告才會從「一堆專有名詞」變成「明確的排查清單」。
網站速度測試工具怎麼選？各有適合的用途
沒有哪一個工具「永遠最準」，正確的說法是不同工具適合不同目的。與其糾結哪個分數才對，不如依照你的目的挑工具。
| 工具 | 適合用途 | 定位 |
|---|---|---|
| PageSpeed Insights | 檢查 Google 指標、Core Web Vitals、行動版與桌面版 | 主工具，適合一般網站經營者 |
| Lighthouse | 技術檢測、效能與可及性檢查 | 適合工程師或進階使用者 |
| GTmetrix | 查看資源載入瀑布圖、頁面大小與請求數 | 適合排查圖片、JS、CSS、第三方資源 |
| WebPageTest | 自訂測試地點、裝置、連線條件的深入分析 | 適合進階診斷 |
| Pingdom | 快速檢查載入時間與可用性 | 適合簡單監測 |
| Search Console 核心網頁指標 | 觀察整站實際使用者體驗問題 | 適合 SEO 與長期監控 |
真正的選擇重點是：PageSpeed Insights 拿來當第一站，看 Google 怎麼看你的網站；發現問題後用 GTmetrix 或 WebPageTest 深挖資源細節；而 Search Console 的核心網頁指標報告則適合長期監控整站、找出有問題的網址群組。這三種角色是互補的，不是互相取代。
為什麼不同工具結果不一樣？
同一個網站用不同工具測，分數不同是正常現象，不代表哪個工具壞掉。差異主要來自測試地點、網路狀態、裝置模擬方式、評分模型與資料來源的不同。
更關鍵的一點是實測資料與實驗室資料的差別。PageSpeed Insights 會同時呈現兩種資料：一種是實際使用者的體驗資料（欄位資料，反映過去一段時間真實使用者的載入情況），一種是在模擬環境下跑出來的實驗室資料。前者告訴你使用者實際遇到什麼，後者用來重現與診斷問題。搞混這兩者，就很容易誤判。
所以正確的用法不是比較哪個工具分數高，而是看趨勢與問題類型。多測幾次、測不同頁型、觀察穩定的方向，比執著於單次某個數字有意義得多。
PageSpeed Insights 分數低該緊張嗎？
分數低通常代表網頁在載入、互動或視覺穩定性上有改善空間，但不等於所有使用者都覺得你的網站很慢。這是最常見的分數焦慮來源，值得先講清楚。
PageSpeed Insights 的實驗室分數是在特定模擬條件下跑出來的，會受到裝置模擬、網路設定與測試當下狀態影響。如果只看這個數字就斷定「SEO 完蛋了」，往往是過度反應。比較踏實的判斷方式，是同時參考三件事：實際使用者資料（欄位資料）、不同頁面的測試結果，以及報告裡具體列出的診斷項目。
換個比喻會更清楚：測速分數比較像體檢報告上的紅字，它提示你哪裡可能有狀況，但要不要立刻處理、有多嚴重，還是得看具體是哪個項目、影響多大。分數本身是線索，不是最終結論。
網站速度會影響 SEO 嗎？
網站速度與 Core Web Vitals 屬於網頁體驗的一部分，Google 建議網站擁有者改善這些指標，以提供良好的使用者體驗。這個關聯是存在的，但要小心別把它講得太滿。
比較準確的說法是：速度是影響 SEO 與使用者體驗的因素之一，而不是「速度變快，排名就一定上升」。搜尋排名受非常多因素影響，內容品質、相關性、連結、整體體驗都在其中，速度只是其中一環。把測速當成改善使用者體驗的手段，而不是拉排名的保證，心態會健康很多。
實務上更值得在意的是速度對「跳出率」與「轉換」的影響。頁面遲遲不出現、按鈕點了沒反應、結帳流程卡頓，這些會直接讓使用者離開。改善速度真正的價值，往往先反映在這裡，而不是排名的短期波動。
網站速度慢有哪些常見原因？照層排查
網站慢很少只有單一原因，但可以照「層」來拆解。與其亂槍打鳥，不如依指標判斷問題落在哪一層，再對症下藥。
| 拖慢原因 | 常見表現 | 優先處理方向 |
|---|---|---|
| 主機效能不足 | TTFB 高、後台也慢、尖峰時段更慢 | 升級主機、開啟伺服器快取、檢查 PHP/資料庫 |
| 圖片太大 | LCP 差、頁面大小過大 | 壓縮圖片、改 WebP、設定圖片尺寸、Lazy Load |
| 快取未設定 | 每次載入都很慢 | 設定頁面快取、瀏覽器快取、物件快取 |
| JS/CSS 過多 | INP 差、主執行緒阻塞 | 延遲非必要 JS、移除未使用 CSS |
| 外掛或主題肥大 | 頁面載入資源過多 | 檢查外掛載入、移除不必要功能、換輕量主題 |
| 第三方追蹤碼太多 | 首屏慢、互動慢 | 精簡追蹤碼、延遲載入非核心腳本 |
| 字型載入不當 | 畫面閃爍或延遲顯示 | 減少字重、預載重要字型、本機化 |
| 資料庫肥大 | 後台慢、查詢慢 | 清理修訂版本、暫存與垃圾資料 |
| CDN 設定不當 | 跨區載入慢或快取失效 | 檢查 CDN 快取規則、節點與靜態資源 |
這張表的用法是「反查」：先從測速結果看到哪個指標異常，再回來對照可能的原因。TTFB 高就往主機、後端、資料庫、快取查；LCP 差就查首屏大圖與阻塞資源；INP 差就查 JS 與第三方腳本；CLS 差就查圖片尺寸、廣告與字型。這樣排查才有方向，而不是每個項目都改一遍。
CDN 和刪外掛不是萬靈丹
有兩個常見誤解要特別提醒。第一，裝了 CDN 不一定會變快。CDN 主要改善靜態資源與跨區載入，如果你的瓶頸是主機 TTFB、資料庫查詢或前端阻塞，CDN 幫不上太多忙。第二，外掛越少不代表網站越快。真正的關鍵是外掛的品質、它在前台載入了多少資源、產生多少資料庫查詢，而不是單純的數量。刪掉一個輕量外掛，不會比優化一個吃資源的外掛更有效。
WordPress 網站速度慢要先查什麼？
WordPress 網站速度慢，建議先查主機與 TTFB，再依序檢查快取、圖片、外掛、主題、第三方碼與資料庫，不要一開始就盲目裝更多優化外掛。
WordPress 常見的拖慢原因有幾個：主機規格不足、外掛過多或品質不佳、主題本身太肥、圖片沒壓縮、快取沒設定、資料庫累積太多修訂版本與暫存資料、第三方追蹤碼過量。過時的核心、外掛或主題也可能同時帶來效能與安全上的問題。
排查的順序建議是這樣：先確認主機回應（TTFB）是否偏高，這是地基；接著開啟頁面與物件快取；再處理圖片壓縮；然後檢查哪些外掛真的在前台載入資源；最後才動到資料庫清理與主題調整。一次只動一類，改完重新測，才知道到底是哪一步有效。
要特別小心的是，WordPress 網站常掛著購物車、預約表單、會員登入這些功能。延遲 JS、合併檔案、啟用快取都可能不小心弄壞這些流程，所以改動前一定要備份，改動後一定要實測關鍵功能還能不能正常運作。
測完之後，改善順序怎麼排？
拿到測速結果後，最忌諱的是看到分數低就一口氣裝快取外掛、上 CDN、壓縮所有檔案。正確的做法是先確認瓶頸，再照優先順序處理，而且每次只改一類。
一個比較穩健的改善順序是：先備份網站，接著檢查主機與 TTFB，開啟快取，壓縮圖片並改用 WebP，清理不必要的外掛與追蹤碼，延遲非必要的 JavaScript，移除未使用的 CSS，檢查字型與第三方資源，然後對不同頁型重新測試，最後持續用 Search Console 觀察 Core Web Vitals 的長期趨勢。
這個順序背後的邏輯是「從地基往上修」。主機和快取是地基，圖片和前端資源是中層，程式碼與第三方腳本是細節。地基沒處理好，光壓縮圖片也救不了一個回應很慢的伺服器。
關於「自己做還是找人做」，可以這樣分：
| 情況 | 建議 |
|---|---|
| 圖片壓縮、設定快取外掛、清理明顯多餘的外掛 | 通常可以自己處理 |
| 主機升級、伺服器快取、TTFB 過高 | 找主機商或工程師協助 |
| 程式碼優化、前端渲染、資料庫調整 | 建議交給專業處理 |
判斷重點在於：牽涉到伺服器層級、程式碼或資料庫的問題，動錯地方風險比較高，找專業協助比較安全；而圖片、基本快取這類相對安全的優化，自己上手學會反而更有效率。
常見問題 FAQ
網站速度測試工具哪一個最適合新手？
PageSpeed Insights 最適合新手當起點。它直接呈現 Google 的 Core Web Vitals 指標與具體診斷建議，介面也相對直覺。等看懂指標後，再進階用 GTmetrix 看資源細節即可。
PageSpeed Insights 分數多少才算正常？
分數沒有一個絕對的合格線，重點是先看 Core Web Vitals 有沒有通過，而不是追求某個特定數字。與其執著把分數衝到 90 以上，不如確認 LCP、INP、CLS 這些實際體驗指標在合理範圍內。
為什麼手機版分數比桌面版低很多？
這通常是正常的。行動裝置的處理能力、網路條件與模擬設定，本來就比桌面嚴苛，效能問題在手機上更容易暴露。也因為如此，行動版反而更值得優先關注。
網站速度測試每次結果不同，該相信哪一次？
不要只看單次。測速結果會受測試地點、網路狀態、伺服器負載、快取狀態與工具評分模型影響。正確做法是多測幾次、觀察穩定趨勢，並優先參考實際使用者資料，而不是抓某一次數字當定論。
網站速度慢一定會影響 SEO 嗎？
速度是網頁體驗的一環，Google 建議改善這些指標以提供良好體驗，但它只是眾多排名因素之一，不能保證「變快就一定上升」。速度對跳出率與轉換的影響，往往比對排名的影響更直接可見。
WordPress 網站速度慢一定是外掛太多嗎？
不一定。外掛數量不是唯一重點，關鍵在於哪些外掛在前台載入資源、產生資料庫查詢或引入第三方腳本。一個吃資源的外掛，可能比五個輕量外掛還拖慢網站。
網站速度測試要測首頁還是每個頁面都測？
不要只測首頁。首頁常經過特別優化，速度不代表整站。建議測主要服務頁、流量最高的文章頁、商品頁與結帳頁這些重要頁型，因為它們才影響實際流量與轉換。
網站速度測試分數高，但實際打開還是慢，可能是什麼原因？
分數是在特定測試條件下跑出來的，可能沒完全反映你當下的網路、裝置或伺服器負載狀態。也可能問題出在互動延遲或特定資源，而不是整體載入。這時建議搭配實際使用者資料與不同頁型再確認一次。
下一步：網站速度測試檢查清單
如果你準備現在就動手，可以照這份清單走一遍：
先列出要測的重要頁型，至少包含首頁、主要服務頁、流量最高的內頁與結帳或表單頁。每一頁都用 PageSpeed Insights 測行動版與桌面版，記下 Core Web Vitals 是否通過，以及 LCP、INP、CLS、TTFB 哪一項最異常。接著用 GTmetrix 或 WebPageTest 看瀑布圖，找出最大的圖片、最重的腳本與最多的請求來自哪裡。
有了這些資料，再對照拖慢原因表反查問題層：TTFB 高先查主機與快取，LCP 差先查首屏圖片與阻塞資源，INP 差先查 JS 與第三方腳本，CLS 差先查圖片尺寸與版面元件。改善時記得先備份、一次只改一類、改完重測關鍵功能，並持續用 Search Console 觀察長期趨勢。
把測速當成定期的網站健檢，而不是一次性的考試。分數會浮動，但只要你養成「看指標、找瓶頸、照順序修」的習慣，網站速度就會慢慢往穩定的方向走。