網站速度測試工具推薦：5 大免費檢測平台比較

讀者還沒看到第一段就離開，問題不一定只在內容，網站速度也是要查的環節。若 GA4 顯示工作階段偏短、跳出率偏高，應把裝置、流量來源、頁面意圖與載入體驗分開檢查，不能只憑兩個平均值就認定元兇。

不少網站把心力投進關鍵字、外部連結與結構化資料，卻沒有量過首頁和主要流量頁的實際載入狀況。這篇會把網站速度測試講清楚：該用哪些工具、它們各自量到什麼，以及測完後怎麼把數字轉成動作。

重點摘述：測速工具不是越多越好，重點是分清楚「實驗室資料」與「真實使用者資料」的差別。先用 PageSpeed Insights 看 LCP、INP、CLS，再用 GTmetrix 或 WebPageTest 找瓶頸，接著用 Chrome DevTools 的 Lighthouse 在固定條件下回測。Core Web Vitals 是使用體驗指標，在排名中只占小幅訊號，不是排名分數。

網站速度為什麼值得你認真看待

先回答最根本的問題：速度到底影響什麼？一是使用者體驗與轉換，二是 Google 頁面體驗中的小幅排名訊號。兩者不能混為一談：網站慢可能讓人離開，但分析工具裡的停留時間與跳出率不是可以直接換算成名次的分數。

先看使用者那端。根據 Statista 的長期統計，手機占全球網站流量的比例長年維持在六成上下。手機的網路、CPU 與記憶體條件較不穩定，桌機上感覺「還行」的速度，到手機上可能明顯變慢。Google 的 web.dev 文件也指出，速度會影響使用者滿意度與留存。

頁面遲遲沒有主要內容，使用者可能直接離開，這會傷害留存與轉換。不過，不能把「跳回搜尋」或分析工具裡的跳出率直接當成 Google 排名訊號，也不能推論速度慢必然造成排名下滑。速度與 SEO 的關係要分開看真實使用體驗、Core Web Vitals 與其他排名因素。

速度可能影響電商與服務型網站的轉換，但幅度會因受眾、頁面與工作流程而異。載入延遲可能增加結帳或填表的阻力，因此應用實際轉換資料和效能指標交叉判讀，而不是套用固定的「每慢一秒損失多少」公式。

再看搜尋那端。Google 在 2021 年把 Core Web Vitals（核心網頁體驗指標，簡稱 CWV）納入頁面體驗考量，2024 年 3 月則以 INP 取代 FID，衡量互動回應。官方文件把 CWV 放在整體頁面體驗脈絡中；它只是眾多排名訊號中的小幅一環，內容相關性仍然更重要（見 Google Search Central 的 Core Web Vitals 說明與 web.dev 的指標文件）。如果你對這套指標還不熟，可以先讀 Core Web Vitals 的完整攻略。

換句話說，測速關係到 SEO 與轉換率兩條命脈，重要性遠超過工程師的個人興趣。地基不穩，上面蓋再多內容都是搖晃的。

測速之前：先分清楚兩種資料來源

這是多數人最容易搞錯、也最值得單獨拉出來講的一點。市面上那些測速工具，量到的其實是兩種本質不同的資料，把它們混為一談，就是怎麼測都測不到真正問題的原因。

Lab Data（實驗室資料）

Lab Data 是工具在一個「受控環境」裡模擬載入你的網頁所得到的數字。它會指定一組固定的裝置條件（例如 4 倍 CPU 降速、模擬行動網路）、固定一個地點的伺服器、跑一次或幾次載入，然後把過程拆開給你看。Lighthouse、GTmetrix、WebPageTest 的核心分數，多半屬於這一類。

它的優點是可重現、可診斷。同一個環境跑兩次，數字會接近，你可以拿來比較「改了之後到底有沒有變快」，也能看到 waterfall（瀑布圖）裡每一個請求是怎麼拖慢頁面的。缺點是它不代表真實使用者。你的訪客可能用三年前的中階手機、在訊號一格的捷運上開你的網站，那種體驗 Lab Data 模擬不出來。

Field Data（現場資料 / 真實使用者資料）

Field Data 是從符合條件的 Chrome 使用者實際瀏覽經驗彙整而來的效能資料，形成 Chrome UX Report（簡稱 CrUX）。PageSpeed Insights 與 Search Console 的 Core Web Vitals 報表會使用這類資料；它是 28 天彙整資料，不等於所有訪客或單次瀏覽的完整紀錄（見 Chrome UX Report 官方文件）。

它的優點是來自真實使用環境。缺點是需要足夠樣本，資料量不足的頁面可能不會顯示網址層級數字；而且它是彙整後的百分位數，看不到單次載入細節，不容易直接拿來找瓶頸。Core Web Vitals 會用到這類真實使用資料，但在整體排名系統中只占小幅訊號。

面向	Lab Data（實驗室）	Field Data（真實使用者）
資料來源	工具在固定環境模擬載入	真實訪客瀏覽器回報
與排名訊號的關係	用於診斷，不是排名資料	用於評估 CWV；整體影響有限
可重現性	高，適合 A/B 比較	低，受真實環境變動影響
能否診斷單一瓶頸	能（瀑布圖、分項計時）	不能（只有匯總百分位數）
低流量頁面	仍可測	常無資料
代表工具	Lighthouse、GTmetrix、WebPageTest	CrUX、PageSpeed Insights 的欄位資料

挑工具時可以記住：找問題用 Lab，看真實體驗用 Field。Lighthouse 分數和 Search Console 裡的欄位資料可能不同，因為兩者的測試環境、時間範圍與資料來源並不相同。

五大免費網站速度測試工具橫向比較

進入工具本身。下面五個工具都有公開可用的測試入口或方案，但額度與功能可能調整，使用時仍要查看當期限制。與其說哪個「最好」，不如說它們各自回答不同的問題。

一、PageSpeed Insights：同時看實驗室與真實使用資料

PageSpeed Insights（簡稱 PSI）是 Google 官方的測速工具，也是少數把 Lab Data 與 Field Data 放在同一份報表裡的工具（見 官方說明）。你輸入網址，它會給你兩個區塊：上面是「實際使用者體驗」的 LCP、INP、CLS（來自 CrUX，需要足夠流量才會有數字），下面是「模擬載入」的 Lighthouse 跑分與逐項建議。

PSI 之所以排在第一位，是因為它會把實驗室診斷與可取得的 CrUX 欄位資料放在一起。Search Console 的 Core Web Vitals 報表也使用 CrUX 資料，但分組與呈現方式不同；PSI 顯示紅色代表該指標的真實使用體驗需要改善，不代表能直接判定某個排名下滑就是它造成。想了解速度與 SEO 的完整關係，可以再看 網頁速度與 SEO 排名的關係。

二、Lighthouse：藏在 Chrome 裡的診斷引擎

Lighthouse 是 PSI 實驗室評分所使用的工具之一，也可以直接在 Chrome DevTools 裡執行，不必另開測速網站（見 Chrome Developers 的 Lighthouse 概觀）。打開 DevTools（F12 或右鍵檢查），切到 Lighthouse 分頁，勾選行動裝置或桌面模式，再產生報告。頁面與第三方資源仍可能需要網路連線，不能把 DevTools 執行等同於離線測試。

它的最大價值在本地、可重複、不佔外部額度。你在改程式碼、調快取、壓圖片的過程中，可以反覆跑 Lighthouse 看分數有沒有進步，而不必每次都排隊等雲端工具。報告裡的「Diagnostics」和「Opportunities」分類會直接告訴你「這張圖可以省多少 KB」「這個 JS 可以延後載入」，非常具體。如果你想更熟練地用開發者工具檢查 SEO 與效能問題，瀏覽器開發者工具的 SEO 用法可以一併參考。

三、GTmetrix：瀑布圖愛用者的好朋友

GTmetrix 是第三方測速平台，會提供 Lighthouse 相關分數、瀑布圖與載入過程資訊。可選的測試地點、瀏覽器、連線速度與保留紀錄會依當下方案而異，使用前要看方案限制。

實務上特別看重它的影片回放功能。瀑布圖告訴你「哪個資源慢」，影片回放告訴你「使用者什麼時候才看到畫面」，兩者對照，就會更清楚某個第三方追蹤碼到底讓使用者多等了多久。GTmetrix 適合用來找特定資源的載入順序問題，例如字體、廣告碼、分析碼誰先誰後。

四、Pingdom：最快拿到一個數字

Pingdom 的 Website Speed Test 是這幾個裡最輕量的。輸入網址、選地點，幾秒內給你頁面大小、載入時間、請求數、以及一個依大小排序的資源清單。

它不會給你 CWV 分數，也沒有那麼細的診斷建議。但它快、直覺、適合快速健檢。當你只是想知道「這個頁面大概多大、有多少請求、載入時間落在哪裡」，Pingdom 是最省事的入口。實務上通常會把它當成第一眼的體檢，再用其他工具深入。

五、WebPageTest：進階診斷的重砲

WebPageTest（WPT）是這五個裡功能最深、也是門檻最高的一個。你可以指定非常細的測試條件：地點、裝置、連線類型（包括 cable、4G、3G）、跑幾次、要不要錄影、要不要模擬廣告阻擋。跑完之後給你的，是一份密密麻麻、可以逐毫秒檢視的載入過程紀錄。

First View 與 Repeat View 的對照，可以協助觀察重複造訪時快取是否帶來差異。兩次結果接近不一定代表快取失效，也可能是頁面主要成本無法快取或測試變異；這時再到 網站快取設定逐層檢查回應標頭與命中狀態。WebPageTest 適合用來處理需要細看請求時序的問題。

工具	主要資料類型	最大強項	適合場景
PageSpeed Insights	Lab + Field	診斷並查看可取得的 CrUX 資料	確認 CWV 狀態與改善方向
Lighthouse（DevTools）	Lab	本地可重複、不佔額度	開發與優化過程反覆驗證
GTmetrix	Lab	瀑布圖＋影片回放	找資源載入順序問題
Pingdom	Lab	快速、輕量	第一眼體檢
WebPageTest	Lab	測試條件極細、First/Repeat 對照	進階疑難雜症診斷

講到這裡，你可能會問：那到底該用哪一個？建議依當下需求決定。如果你只想快速確認「過不過關」，先用 PageSpeed Insights；如果你正在改東西、需要反覆驗證，Lighthouse 在 DevTools 裡最順手；如果你被一個搞不定的慢卡住、需要看見每一毫秒發生了什麼事，就上 WebPageTest。日常輪巡用 Pingdom 做體檢，找載入順序問題用 GTmetrix 看瀑布圖。五個工具各有擅場，沒有誰能完全取代誰，把它們想成工具箱裡不同尺寸的扳手，依工作挑選就好。

Core Web Vitals 三大指標怎麼判讀

工具會給你一堆數字，Core Web Vitals 則把載入、互動與視覺穩定性收斂成三個核心指標。它們只占排名訊號的一小部分，學會判讀的主要目的，是看懂報表裡的紅黃綠與使用體驗問題。

LCP（Largest Contentful Paint，最大內容繪製）

LCP 衡量的是「頁面最主要的那塊內容什麼時候畫出來」，通常是首屏的大圖、Hero banner、或最大的文字區塊。Google 的及格標準是 2.5 秒以內，超過 4 秒就是不及格。LCP 慢，最常見的元兇是大圖片沒壓縮、首屏被大型 JS 擋住、或伺服器回應（TTFB）太慢。

INP（Interaction to Next Paint，互動至下一次繪製）

INP 是 2024 年取代 FID 上場的新指標，衡量的是使用者與頁面互動（點擊、輸入、按鍵）後，畫面多久才更新。及格是 200 毫秒以內，超過 500 毫秒就是差。INP 慢，多半是 JavaScript 太肥、主執行緒被佔住、或第三方腳本（廣告、追蹤、聊天外掛）搶資源。一個要注意的細節是，PageSpeed Insights 與 Search Console 裡顯示的 INP 是所有互動的「第 75 百分位數」，也就是說它反映的是偏慢的那一群使用者的體驗，這個數字比平均值更貼近真實的痛點；想讓這個數字變綠，你得照顧到那些在最慢裝置上操作的人，而不只是桌機上一切正常的自己。這個指標的來龍去脈，可以看 FID 換成 INP 的完整說明。

CLS（Cumulative Layout Shift，累積版面位移）

CLS 衡量的是「頁面載入過程中，畫面元素跳動的程度」。你一定有過這種經驗：點了一個連結，結果在它載入到一半時畫面跳了一下，你點到的是另一個東西。及格是 0.1 以內，超過 0.25 就是差。CLS 的兇手通常是圖片或廣告沒有預留高度、字體載入造成文字重新排列、或動態插入的內容把原本的元素擠開。

這三個指標剛好對應使用者體驗的三個維度：看得見（LCP）、點得動（INP）、不亂跳（CLS）。把它們記成這三句話，判讀報表時就不會迷失在數字裡。一個常見的陷阱是，三個指標會互相牽制：你為了讓 LCP 快而把圖片延後載入，結果反而讓 CLS 變差（圖片區域一開始是空的，後來才跳出來把版面擠開）。所以優化時要三個一起看，不能只盯著一個數字。

測速環境怎麼設，數字才可信

同一個網頁，用不同的裝置、地點、網路條件測，可以測出截然不同的結果。如果你今天用桌機配光纖測、明天用手機配 4G 測，然後拿這兩個數字互相比較，那就像用不同的尺量同一張桌子，結論一定亂掉。要讓測速數字有意義，你得先把測試環境固定下來。

第一個要固定的是裝置與網路設定。Lighthouse 的行動裝置測試會套用模擬裝置與節流設定，實際參數可能隨版本調整；做前後比較時，要記錄並沿用相同環境。GTmetrix 與 WebPageTest 可選的地點與連線條件依方案而異，同一輪比較也應固定設定，避免環境差異蓋過修改效果。

第二個要固定的是測試地點。伺服器在哪、測試節點在哪，會直接影響網路往返時間。你選了一個距離主機很遠的測試節點，TTFB 自然偏高，但那只代表測試節點離它遠，未必代表你的主機真的慢。挑一個跟你多數訪客地理位置接近的節點，數字才有參考價值。

第三個要留意的是登入狀態與快取。WordPress 與很多會員制網站在登入狀態下會載入額外的工具列與腳本；帶著舊快取的瀏覽器測出來的數字則會異常地快。一致的作法是：用無痕視窗、登出狀態、每次測試前清除快取，這樣你量到的才是「一個全新訪客第一次抵達」的真實體驗。

把這三個前提顧好，你的測速數字才有資格被拿來做前後比較。環境不一致的測速，比完全不測還危險，因為它會給你一套錯誤的信心。

速度慢的六大常見元兇：把測試報告翻譯成根因

工具丟給你一份報告，上面寫著「Reduce unused JavaScript」「Serve images in next-gen formats」，這些是症狀，不是根因。實務上最常拖慢網站的六類問題整理如下，讓你看到報告時能直接對應到該動手的地方。

1. 圖片沒壓縮又太大。這是 LCP 與整體載入時間的頭號兇手。一張手機拍的 4MB 直出照片，直接丟上首頁 banner，就是謀殺速度。解法是壓縮、改用 WebP 或 AVIF 格式、並設定正確尺寸。圖片壓縮工具的選擇與圖片格式挑選有完整整理，這部分值得單獨花時間做對。
2. 第三方腳本太多。廣告碼、分析碼、聊天外掛、社群按讚按鈕、A/B 測試工具，每一個都會塞一包 JS 進來，而且很多會在頁面一開始就搶主執行緒。這是 INP 變差的主因之一。你能延後載入的就延後，能按需載入的就按需，能砍掉的就砍掉。
3. 快取沒接上。每次造訪都像第一次，伺服器與瀏覽器都在做白工。從伺服器端頁面快取、瀏覽器快取、到 CDN 邊緣快取，這三層顧好，重複造訪才會快。CDN 與網站速度的關係會把邊緣快取那層講清楚。
4. 主機回應太慢（TTFB 高）。HTML 回應在不同地點與多次測試都偏慢時，再檢查網路延遲、快取命中、PHP 處理與資料庫查詢。若瓶頸持續落在伺服器端，才比較主機資源或架構調整。
5. 字體載入策略不當。遠端字體可能增加連線與下載成本；font-display、preconnect、preload 與備用字設定不當，也可能延後文字顯示或造成版面位移。是否影響 LCP，要看字體與最大內容元素的實際載入關係。
6. CSS 與 JS 阻塞首屏。一大包沒有拆分的樣式表或程式庫在頁面頭部同步載入，瀏覽器得先把它們全部解析完，才有辦法畫出第一個畫面。這會讓使用者盯著白屏發呆。

看到這裡你會發現，網站速度慢的修復方向其實有跡可循：先確定是「傳輸慢」（圖片、主機、快取）還是「執行慢」（JS、第三方腳本），再決定從哪裡下手。把症狀翻譯成這六類根因，你的優化才有焦點。

實務上怎麼用：一套可重複的速度診斷工作流

工具會用了，指標也懂了，接下來是把它們串成一個流程。以下把實務上反覆使用的診斷順序整理出來，你可以直接拿去套用。這不是什麼獨門秘技，而是一個讓你不漏掉盲點、也不浪費時間在錯誤的數字上的紀律。

1. 先用 PageSpeed Insights 看 Field Data。這一步回答真實使用資料裡的 LCP、INP、CLS 落在哪個區間。如果三項都綠，代表這一組指標通過門檻，但不等於所有效能與頁面體驗問題都已解決；如果有紅燈，記下是哪一項，再往對應瓶頸排查。
2. 用 Lighthouse 在 DevTools 跑一次 Lab Data。針對剛剛那個紅燈指標，看 Lighthouse 的 Opportunities 與 Diagnostics。它會列出可改善的項目與預估節省時間，例如「移除未使用的 JavaScript」「適當調整圖片大小」。把前三名記下來。
3. 用 GTmetrix 或 WebPageTest 看瀑布圖。瀑布圖會告訴你到底是哪個資源在拖。常見的發現是：某個第三方聊天外掛載入了一整包 JS、首頁輪播圖每一張都是沒壓縮的 PNG、或字體從遠端載入還沒有快取。
4. 對應到六大根因，動手修一項。把剛剛找到的瓶頸對應到前面那六類元兇，選一個動手。修一項，跑一次 Lighthouse 確認數字有改善，不要一次改五項然後搞不清楚是哪一項有效。
5. 回頭驗證 Field Data。修改完先用固定條件的實驗室測試確認方向，再持續觀察 PSI。CrUX 使用最近 28 天的彙整資料，變化會逐步反映，不能承諾修改後固定幾週就轉綠。
6. 建立基準，定期追蹤。把你修完的數字記下來當基準，每個月用同一組工具、同一組條件重測一次。網站會一直長大，新的圖片、新的外掛、新的追蹤碼都會悄悄把速度吃掉，不定期量就會回到原點。

這個流程的價值在於「先看真實使用資料、再找瓶頸、改完驗證、定期追蹤」的循環。測完若沒有後續動作，數字很快就失去用途；固定記錄測試條件與修改內容，才有辦法判斷哪個動作真的有效。

WordPress 站長測速時要特別留意的事

whoops.tw 的讀者有不少是用 WordPress 架站的，因此接著針對 WordPress 多講兩句。WordPress 本身不慢，慢的是「被外掛與主題養胖的 WordPress」。測速時有幾個地方跟一般自製網站不同，搞清楚會幫你省下大量冤枉時間。

第一，外掛數量與品質直接決定基線。同一個站，裝五個外掛跟裝三十個外掛，速度可以差好幾倍。你可以在測速時用 Lighthouse 看「Transfer Size」與「Script Treemap」，找出哪幾個外掛貢獻了最多的 JS 與 CSS。真的會影響前台呈現的外掛才該留，純後台管理的可以考慮只在需要時啟用。

第二，快取外掛幾乎是必裝，但不是裝了就好。你需要正確設定頁面快取、物件快取（建議搭配 Redis 或 Memcached）、以及瀏覽器快取的過期標頭。如果你不知道該挑哪一套，WordPress 快取外掛的比較有完整的實測；想把速度優化做得更系統，WordPress 速度優化的專門指南會把設定邏輯講得更清楚。

第三，主機資源會限制可達到的效能。快取與外掛無法消除不足的 PHP 處理能力、磁碟 I/O 或資料庫瓶頸；共享主機是否撐得住流量，也取決於資源配置與站點工作負載，不能只看方案名稱。若多次測試都指向伺服器端，再比較適合 WordPress 工作負載的代管環境與資源規格。挑選時可以參考虛擬主機類型比較。

第四，測速要連登入與未登入狀態都測。WordPress 在管理員登入時通常會載入額外的工具列與腳本，這會讓測出來的數字失真。一律用無痕視窗、登出狀態測，你看到的才是真實訪客會遇到的體驗。

不同類型網站，速度優化的優先順序不同

工具與指標都講完了，但有一件事多數文章沒提：不同類型的網站，拖慢它的元兇不一樣，你該優先動手的地方也就不同。用錯方向努力，是另一種浪費。以下把三種常見網站的優先順序整理出來，讓你對號入座。

內容型網站（部落格、媒體、知識站）常要先檢查圖片、廣告與追蹤碼是否讓頁面變重。除了 LCP 與 CLS，也要實測 INP；有留言、搜尋、選單、廣告與同意管理工具時，內容站仍可能出現互動延遲。

電商網站的挑戰更全面。商品頁常塞滿多角度圖片、評價區、推薦商品、庫存查詢、加購提示，每一項都是額外的請求與腳本。結帳流程尤其敏感，任何延遲都可能讓已經打算付款的顧客縮手。電商站要同時盯三個指標：LCP 決定顧客願不願意留下，INP 決定他能不能順利操作篩選與加購，CLS 決定他會不會在點按鈕時被跳動的版面氣走。優先順序是先讓商品主圖與結帳按鈕飛快出現，再處理推薦區與評價的延後載入。

服務與名單型網站（顧問、律師、診所、在地商家）頁面通常較輕，速度問題常出在主機與表單。這類站的轉換發生在聯絡表單或預約按鈕上，如果表單背後接了沉重的 CRM 腳本或驗證服務，點下去要等好幾秒才有反應，名單當場就流失。優先確保主機回應快、表單互動順暢，比追求極致的 Lighthouse 滿分更有商業意義。

對號入座之後，你會發現優化變得有焦點。通用建議聽起來什麼都涵蓋了，真正能幫你的是「針對你這類網站，先動哪一刀」的具體判斷。

一次性測試與長期監控：你需要兩種工具搭配

前面介紹的五個工具，都是「你輸入網址、它跑一次給你看結果」的單次測試。這類測試適合找問題、驗證修改，但它有一個盲點：它只代表「測試那一刻」的狀態。你的網站速度會隨著主機負載、流量尖峰、第三方服務的連線狀況而波動，單次測試抓不到這種波動，有時候你以為修好了，其實只是剛好測到一個運氣好的瞬間。

要補上這個盲點，你需要的是「長期監控」。長期監控可以分成兩種思路。第一種是定期跑單次測試並記錄趨勢，例如每週固定用同一組條件跑一次 PSI 或 GTmetrix，把分數記進試算表，再畫成趨勢圖。這個做法免費、門檻低，缺點是手動、容易忘，得靠紀律撐著。

第二種是Real User Monitoring（真實使用者監控，簡稱 RUM）。RUM 通常透過網站腳本收集真實瀏覽環境的效能資料，再彙整成儀表板；實際抽樣比例、可切分欄位、隱私與同意管理，會依工具和設定而異。它跟 CrUX 都是實際使用資料，但自有 RUM 通常能提供更即時、更多站內維度的分析，也要承擔程式效能、資料治理與維運成本。

把這兩層搭配起來：用單次測試找問題、驗證修復，用長期監控盯趨勢、抓衰退。只靠任何一層都不夠。只做單次測試，你不知道常態長什麼樣；只看監控儀表板，你知道變慢了卻不知道為什麼。兩者各司其職，你的速度優化才會從被動救火，升級成主動預防。

常見的測速誤區與陷阱

接下來談幾個實務上反覆出現、而且會讓人做出錯誤判斷的測速誤區。這些都是會讓人白忙一場的實際陷阱，不是冷知識。

只看 Lighthouse 分數，不看 Field Data。Lighthouse 的實驗室分數適合除錯與前後比較，不能取代真實使用資料；反過來說，Field Data 是 28 天彙整結果，若樣本不足也可能不顯示。判斷是否達到 Core Web Vitals 門檻以可取得的 Field Data 為主，找原因與驗證修改則要搭配 Lab Data。

只測首頁。首頁通常是優化最用心的地方，但它不見得是你流量最大的頁面。把你 Google Search Console 裡曝光或點擊最高的那幾個網址拿出來測，那才是真正會影響你排名與營收的頁面。如果你的重要文章頁載入一堆首頁用不到的重型元素，那些才是要處理的。

用一次的結果下定論。Lab Data 會受到測試當下的網路與伺服器負載影響，單次結果可能失真。重要的決策，至少跑三次取中間值，或用不同地點交叉驗證。WebPageTest 可以一次跑多個 run，正好適合這個用途。

把快取或 CDN 當萬靈丹。快取能解的是「重複造訪」與「靜態資源傳輸」的問題，它解不了「第一次造訪時伺服器就要三秒才回應」或「首屏圖片 5MB」這種本質問題。先用工具定位瓶頸，再決定動作，順序反了就會一直撞牆。

追求滿分，忘了商業目的。Lighthouse 100 分很爽，但如果你的頁面因為過度優化（例如把所有圖片壓到糊掉、移掉了能帶來轉換的功能），反而傷害了使用者體驗與轉換，那就本末倒置了。速度是手段，留住讀者、促成行動才是目的。

如果想了解業界整體的速度現況，HTTP Archive 的公開報表會彙整大量網站資料，可用來觀察大方向。這類宏觀資料不能直接判定單一網站是否夠快，但能協助設定合理目標，避免只盯著滿分。

從今天開始的網站速度行動清單

讀到這裡，你應該已經對測速工具有完整的認識了。知識不落地就是空的，接著提供一份今天就能動手的清單：

1. 挑出三個關鍵頁面。不要貪多，從 Search Console 裡曝光最高的三個網址開始。它們是你網站的門面，也是速度投資回報最高的地方。
2. 用 PageSpeed Insights 跑一次。把三個頁面的 LCP、INP、CLS 記下來，標出哪些是紅燈。這是你的起點基準。
3. 針對每個紅燈，用 Lighthouse 找前三名可改善項。把建議的項目與預估節省時間列出來，這就是你的待辦清單。
4. 每週修一項，修完用 Lighthouse 驗證。不要一次全改，否則你會搞不清楚什麼有效。一次一項，看到數字動，再換下一項。
5. 持續回 PSI 看 Field Data。CrUX 是最近 28 天的彙整資料，不會在修改後立刻換色。觀察趨勢時也要確認樣本與頁面群組是否相同；沒有改善，再回頭檢查瓶頸或修改效果。
6. 把這套流程固定下來。每個月用同樣的工具、同樣的條件重測一次，建立你自己的速度趨勢圖。網站會自己長胖，不盯著它就會退化。

想要更系統化的優化路線圖，網站速度優化完整指南會把從主機到前端的各個環節串起來，適合在跑完上面這份清單之後接著讀。想再往上一層，把速度放進技術性 SEO 的全貌裡看，那篇則是完整的入口。

速度優化需要持續維護。新增外掛、首頁圖片或追蹤碼，都可能改變效能。建立固定條件的定期量測與回歸檢查，數字異常時再追查近期變更，比偶爾追一次滿分更有用。

網站速度不需要每個人都成為效能工程師，但需要建立「測量、定位、修復、驗證」的紀律。這套流程能讓改善有依據，也比較不會因為一次開啟太多設定而製造新的問題。

現在就打開 PageSpeed Insights，把你流量最高的那個網址貼進去吧。第一步永遠是最難的，但一旦看到那張報表，你就知道下一步該做什麼了。