作者：Jacks｜JRM Web Design 顧問・英國生醫碩士・前保健品牌資深數位行銷 最後更新：2026-09
你是不是也遇過：客人傳訊息說「你們網站好慢喔」，你用公司電腦打開卻覺得還好？或是廣告費一直砸，點進來的人卻沒幾個留下？
殘酷的是，網站慢的時候，客人通常不會抱怨，他只會默默按返回鍵，去點下一家。
這篇一次講清楚兩件事：網站速度為什麼會變慢，以及你不用懂程式，也能自己測出網站健康狀況的方法。最後附一張分流表，告訴你哪些自己改就好、哪些一定要找工程師。
網站速度為什麼重要？
網站速度決定客人願不願意留下，也是 Google 排名會參考的網頁體驗訊號之一。
對客人：三秒定生死
Google 的研究指出，53% 的手機造訪，會在網頁超過 3 秒還沒載入時被放棄（Google, 2016）[1]。這份數據有點年紀了，但大家手機越用越兇，耐心可沒有跟著變多。
翻成老闆的語言：兩個客人點進你的網站，可能有一個還沒看到產品就走了，而那次點擊的廣告費，你照樣要付。
對 Google：網頁體驗是排名訊號
Google 官方文件寫得很直接：Core Web Vitals 會被排名系統使用。但同一份文件也提醒，報表分數好看，不保證就能排到第一名，為了 SEO 硬拚滿分也不一定值得（Google Search Central, 2026）[2]。
💡 一句話結論：速度是「及格門檻」，不是「加分神器」。太慢會被扣分，但就算飆到 100 分，也救不了空洞的內容。
Core Web Vitals 是什麼？老闆版三項成績單
Core Web Vitals 是 Google 用來評估網頁體驗的三項真實使用者指標：LCP、INP 和 CLS。
把它想成網站的三張成績單：主畫面多快出現、按下去多快有反應、畫面會不會亂跳。
Core Web Vitals 三項指標的良好門檻
| 指標 | 白話意思 | 良好 | 差 | 常見元兇 |
| LCP（最大內容繪製） | 主畫面（大圖或標題）多快出現 | ≤ 2.5 秒 | > 4 秒 | 大圖沒壓縮、主機回應慢 |
| INP（互動到下一次繪製） | 按下按鈕後，畫面多快有反應 | ≤ 200 毫秒 | > 500 毫秒 | 第三方程式碼、JavaScript 塞車 |
| CLS（累計版面位移） | 畫面會不會突然跳動、害你按錯 | ≤ 0.1 | > 0.25 | 圖片沒設尺寸、浮窗突然插入 |
資料來源：web.dev 官方說明 [3][4][5][6]
另外兩個重點：
- Google 看的是「第 75 百分位」：不是看你網站最快的那一次，而是每 4 位客人裡，至少 3 位的體驗要達標 [3]。
- INP 在 2024 年 3 月 12 日正式取代舊指標 FID [7]。如果你看到的教學還在講 FID，那篇已經過期了。
測速分數 vs 真實數據：Google 到底看哪一個？
PageSpeed 的 0 到 100 分是模擬測試，真實訪客過去 28 天的數據才是 Google 評估體驗的依據。
這是很多老闆最常搞混的地方。Google 官方的 PageSpeed Insights 同時給你兩種資料 [8]：
| 實驗室數據（上面那個分數） | 真實數據（Core Web Vitals 評估） | |
| 從哪來 | Google 伺服器模擬跑一次 | 真實 Chrome 使用者的造訪紀錄（CrUX） |
| 用途 | 找問題、除錯 | 反映客人實際感受 |
| 更新頻率 | 每按一次測試都會變 | 近 28 天滾動統計 |
| 要不要緊張 | 分數上下跳很正常 | 這個才是要盯的 |
實驗室分數的判讀：90 分以上算良好，50 到 89 分需要改善，50 分以下偏差 [8]。
所以常有人問：「我明明改完了，為什麼 Google 還說不及格？」答案是真實數據要累積 28 天，改完要給它一點時間。
用 Search Console 看全站的真實體驗
PageSpeed 一次只能測一頁。想看整個網站，就用 Google 的免費後台 Search Console：
- 登入 Search Console，選擇你的網站。
- 左側選單點「體驗」→「Core Web Vitals」。
- 分成「行動裝置」和「電腦」兩份報告，先看手機。
- 點進「不佳」或「需要改善」，會看到是哪一群網址出問題。
報告會把相似的網頁分成一組，而整組的狀態取決於表現最差的那一項指標 [9]。流量很小的新網站，可能會顯示資料不足，這時就先用 PageSpeed Insights 單頁檢查。
網站變慢的 6 大原因
網站速度變慢通常不是單一兇手，而是主機、第三方程式碼、外掛、圖片和快取好幾個問題疊在一起。
網站變慢的 6 大原因檢查表
1. 主機在國外：台灣客人要繞半個地球
很多人架站時為了便宜，直接選美國的主機。問題是，你的客人在台灣，每開一次網頁，資料都要跨過太平洋再回來。
測速報告裡有個指標叫 TTFB（伺服器回應第一個位元組的時間），可以把它想成「按門鈴到有人應門」的時間。PageSpeed 的真實數據區也會顯示它 [8]。主機離客人越遠，應門就越慢，網站速度自然被拖累。
解法有兩個方向：客人在台灣，就選亞洲機房；或是加上 CDN（內容傳遞網路），也就是把網站的檔案複製到世界各地的「分店倉庫」，客人從最近的倉庫取貨。Cloudflare 就有提供免費方案可以先試。
2. LINE 浮窗、追蹤碼、地圖影片：台灣網站最常見的隱形拖油瓶
這一點幾乎沒有教學在講，但卻是台灣中小企業網站最常見的問題。你的網站上是不是也有這些？
- 右下角的 LINE 官方帳號按鈕或線上客服聊天視窗
- Meta（FB）像素、GA4、Google 廣告轉換追蹤碼
- 嵌入的 Google 地圖、YouTube 影片
- 評價小工具、倒數計時器、跳出式優惠視窗
每一個都要從別人的伺服器載入程式碼。單一個看起來無害，全部疊在一起就是塞車，而且特別容易拖垮 INP（按了沒反應）。
🛠️ 解法：①只留下真的有在用、有在看數據的；②地圖和影片改成「點了才載入」，先放一張預覽圖；③追蹤碼集中到 Google 代碼管理工具（GTM）統一管理，避免重複安裝。
3. 外掛太多，還互相打架
WordPress 外掛就像手機 App，裝越多越吃資源。更麻煩的是，不同來源的外掛可能功能重複、彼此衝突。定期清掉沒在用的外掛，功能類似的只留一個。
4. 佈景主題和頁面編輯器太肥
華麗的佈景主題、一頁疊滿動畫和輪播，看起來很厲害，代價是載入變重。選輕量的佈景主題，版面追求乾淨，通常比加一堆特效更能留住客人。
5. 圖片沒壓縮、尺寸太大
最常見的狀況：手機拍的照片直接上傳，一張好幾 MB。解法很簡單：
- 上傳前先壓縮，或轉成 WebP 這種較新的圖片格式
- 圖片寬度不要超過網頁實際顯示的寬度（部落格內文通常 1200 像素就很夠）
- 開啟「延遲載入」（lazy loading）：滑到哪，圖片才載入到哪
6. 沒有設定快取
快取（cache）就像把常用的東西先放在門口，客人下次來就不用再到倉庫慢慢找。沒設定快取，每位客人都要從頭把整個網頁載入一次。WordPress 可以用快取外掛處理，但設錯可能讓版面跑掉，建議交給熟悉的人設定。
免費測速工具怎麼用？4 個工具比一比
先用 PageSpeed Insights 看 Google 怎麼評你，再用 GTmetrix 或 Pingdom 找出是哪個檔案在拖慢網站速度。
PageSpeed Insights：第一站，看 Google 的評價
- 打開 PageSpeed Insights，貼上你的網址。
- 先看「行動裝置」分頁，手機才是大多數客人的入口。
- 上半部「探索實際使用者的體驗」：看 Core Web Vitals 評估有沒有通過（這是真實數據）。
- 下半部「診斷效能問題」：看分數和 Google 給的改善建議（這是實驗室數據）。
小技巧：不要只測首頁。首頁、最重要的服務或產品頁、流量最高的一篇文章，這三種頁面各測一次。
GTmetrix：用瀑布圖抓出兇手
GTmetrix 最好用的是瀑布圖（Waterfall）：把網頁每個檔案排隊載入的順序和時間畫成一張表，哪一個檔案最慢、最肥，一眼就看得出來。註冊免費帳號後，還能使用更多測試設定。
Pingdom：四步驟快速看總覽
Pingdom 介面最簡單，適合想快速看總覽的人：
- 進入 Pingdom 網站測速工具頁面。
- 輸入完整網址，記得以 https:// 開頭。
- 選擇測試地點：目前沒有台灣節點，亞洲選項是「Asia – Japan – Tokyo」，離台灣最近 [10]。
- 按下「Start Test」，幾秒鐘後就會出報告。
報告重點看四個數字：效能評級（Performance grade）、網頁大小（Page size）、載入時間（Load time）、請求數（Requests）。往下捲到「依檔案類型的內容大小」，就能看出是圖片、字型還是程式碼最肥。
WebPageTest：模擬手機網路的進階選項
WebPageTest 可以選測試地區、瀏覽器，還能模擬 4G 等較慢的網路，適合想做進階比較的人。報告比較技術，新手先從前面三個開始就好。
| 工具 | 適合誰 | 優點 | 限制 |
| PageSpeed Insights | 所有人的第一站 | Google 官方，有真實使用者數據 | 不能選測試地點 |
| GTmetrix | 想找出兇手的人 | 瀑布圖清楚 | 部分功能需註冊或付費 |
| Pingdom | 想快速看總覽的人 | 介面最簡單 | 沒有台灣節點 |
| WebPageTest | 想做進階比較的人 | 可模擬網速和地區 | 報告較技術 |
⚠️ 不同工具的分數本來就不會一樣，測試地點和計算方式都不同。建議固定用同一個工具，看的是趨勢，不是單次分數。
優化分流表：自己能做 vs 找工程師
網站速度優化先做低風險、老闆自己就能動手的項目；換主機、改程式碼這類高風險項目，交給工程師。
| 優化項目 | 難度 | 誰來做 | 改錯的風險 |
| 圖片壓縮、轉 WebP | 低 | 自己 | 低 |
| 移除沒在用的追蹤碼、浮窗 | 低 | 自己＋行銷人員 | 低 |
| 刪除沒在用的外掛 | 低 | 自己（先備份） | 中 |
| 地圖、影片改成點擊才載入 | 中 | 自己或工程師 | 低 |
| 安裝與設定快取外掛 | 中 | 建議工程師 | 中（版面可能跑掉） |
| 開啟 CDN（例如 Cloudflare） | 中 | 工程師 | 中 |
| 升級或搬家主機 | 高 | 工程師 | 高 |
| 清理 CSS／JS、延遲載入腳本 | 高 | 工程師 | 高 |
🔒 任何改動前，先備份整個網站。這是唯一不能省的步驟。
WordPress 網站要特別注意什麼？
WordPress 網站速度變慢，多半是外掛、佈景主題和頁面編輯器組合出的問題，不是 WordPress 本身。
JRM 自己的做法是用 Elementor 搭配 Crocoblock 一整套外掛建站。我們的經驗是：選同一家開發、設計上彼此相容的外掛組合，比東拼西湊十幾個不同來源的外掛，更容易控制衝突和網站重量。
另外三個習慣：
- 更新前先備份，有測試站的話先在測試站更新（延伸閱讀：WordPress 7.1 更新總整理）
- 頁面編輯器通常有內建的效能選項，開啟前後各測一次速度，確認有效又沒破版
- 一頁不要疊太多動畫、輪播和特效，乾淨的版面本身就是最好的優化
用 Shopify、SHOPLINE、Wix 架站怎麼辦？
開店平台幫你代管主機，所以能調整網站速度的地方比較少，重點放在圖片、App 數量和第三方程式碼。
- 你能做的：壓縮圖片、少裝 App、移除沒在用的追蹤碼和浮窗、選較輕量的佈景主題。
- 通常做不到的：自己換主機、改伺服器設定、深度調整底層程式碼（依各平台和方案而定）。
如果能做的都做了，網站速度還是明顯影響生意，那就值得認真評估平台是否適合你現在的階段。想了解換平台或重做網站大概要花多少，可以參考這篇：2026 網頁設計費用怎麼算？
常見問題
網站速度要多快才算及格？
以 Google 的標準，手機版要做到主畫面 2.5 秒內出現（LCP）、按下去 200 毫秒內有反應（INP）、版面位移 0.1 以下（CLS），而且每 4 位訪客至少 3 位要達標。先顧好手機版，因為大多數客人用手機上網。
PageSpeed 分數一定要 90 分以上嗎？
不用。那個分數是模擬測試，更重要的是上方的真實使用者數據有沒有通過 Core Web Vitals 評估。Google 也說明，為了 SEO 硬拚滿分不一定值得，把時間花在內容上通常更划算。
為什麼我已經優化了，Search Console 還是顯示不佳？
因為真實數據是用過去 28 天的訪客資料滾動計算，改完後需要一段時間才會反映。改完先用 PageSpeed 的實驗室數據確認有進步，再等真實數據慢慢跟上。
手機版分數比電腦版低很多，正常嗎？
正常。測試工具會用較慢的網路和手機效能來模擬，所以手機分數通常比較低。不過要優先處理手機版，因為那才是多數客人的真實體驗。
網站速度優化要花多少錢？
壓縮圖片、刪外掛、移除沒用的追蹤碼這類項目，自己做幾乎不用錢。換主機、改程式碼則依網站狀況報價，落差很大。建議先做一次健檢，確認問題在哪裡，再決定要花在哪裡。
想知道你的網站卡在哪裡？
JRM 提供免費網站健檢：幫你看 Core Web Vitals 真實數據、找出拖慢速度的外掛和第三方程式碼，並整理成「自己能做」和「要找工程師」兩份清單。👉 預約免費網站健檢
參考資料
[1] Google（2016）。The need for mobile speed. Google Ad Manager Blog. https://blog.google/products/admanager/the-need-for-mobile-speed/
[2] Google Search Central（2026）。Understanding page experience in Google Search results. https://developers.google.com/search/docs/appearance/page-experience
[3] web.dev。Web Vitals. https://web.dev/articles/vitals
[4] web.dev。Defining the Core Web Vitals metrics thresholds. https://web.dev/articles/defining-core-web-vitals-thresholds
[5] web.dev。Interaction to Next Paint (INP). https://web.dev/articles/inp
[6] web.dev。Cumulative Layout Shift (CLS). https://web.dev/articles/cls
[7] web.dev（2024）。Interaction to Next Paint becomes a Core Web Vital on March 12. https://web.dev/blog/inp-cwv-march-12
[8] Google for Developers。About PageSpeed Insights. https://developers.google.com/speed/docs/insights/v5/about
[9] Search Console 說明中心。Core Web Vitals report. https://support.google.com/webmasters/answer/9205520
[10] Cloudways。Pingdom Speed Test Tool（測試地點列表）. https://cloudways.com/blog/pingdom-speed-test-tool
🔄 資料以各官方來源為準，擷取日期 2026-09。發現需要更新的地方，歡迎來信告訴我們，查證後會更新並標註日期。
