網站慢到爆怎麼辦？速度瓶頸診斷與優化解法

網站被反映很慢時，常見的第一個動作是登入後台，裝一個快取外掛，把所有能勾的選項全部打開。分數看起來漂亮了一點，過一陣子再測，問題卻還在。

沒有先診斷就一次開啟多項快取、合併與延後載入設定，確實可能讓網站更慢，甚至弄壞結帳流程。問題不在努力不夠，而在還沒搞清楚「慢」發生在哪一段，就急著開藥方。

快速重點整理：網站速度不是一個分數，是一段旅程。真正會優化的人，先做診斷、再動手。這篇會把「慢」拆成四段，用三個免費工具在十分鐘內抓出兇手，然後針對不同瓶頸給你第一刀該砍哪裡。先診斷、後優化，這個順序一旦搞錯，你做再多都是白工。

為什麼大部分的人「優化速度」反而越弄越慢

先說一個反直覺的事實：速度優化的第一步，不是裝外掛，而是測量。

很多站長一聽到「網站很慢」，反射動作就是：裝快取、壓圖片、再加一個 CDN。三管齊下之後，分數的確動了，但你問他「到底是哪一個動作讓它變快的」，他答不出來。更尷尬的情況是，三個外掛互相衝突，購物車的結帳頁被快取住了，使用者重新整理後發現購物車是空的，訂單直接蒸發。

這不是特例。當你不帶診斷地堆疊優化手段，你其實是在盲測，根本沒有真的在修問題。Google 自己在 web.dev 上就講得很明白：速度之所以重要，是因為它直接影響使用者的去留。換句話說，速度優化的終點是「人」，不是「分數」。一旦你把目光從分數轉回真人體驗，你就會開始問對的問題。

那個對的問題是：你的訪客，究竟是在哪一秒鐘被卡住的？

把「慢」這個字拆開：速度其實是四段旅程

大多數人對「網站慢」的理解是扁平的，就是「點下去到跑完，總共花了幾秒」。這個理解會害死你，因為同樣是「五秒」，卡在前一秒和卡在後一秒，兇手完全不同、解法也完全不同。

一個網頁從你按下 Enter 到畫面完整呈現，可以拆成四段旅程：

階段	在發生什麼事	卡住的典型症狀
1. DNS 與連線	瀏覽器找出伺服器在哪、建立連線（TCP、TLS 握手）	白屏很久，但一旦開始載入就很快
2. 伺服器回應（TTFB）	伺服器把 HTML 組好、送回第一個位元組	頁面框架遲遲不出現，進度條卡在最前面
3. 前端資源載入	瀏覽器下載 CSS、JS、圖片、字型	框架出來了，但圖片、字體慢慢浮現
4. 視覺穩定與互動	頁面渲染完成、可以點、不會亂跳	畫面會突然位移，點按鈕沒反應

這四段對應的速度指標不同。第一段是網路與 DNS 層，第二段是伺服器與後端程式層，第三段是前端資源層，第四段可用 Core Web Vitals 檢查載入、互動與視覺穩定性。如果不知道卡在哪一段，裝再多快取外掛也救不回第一段的 DNS 或連線問題。

這也是為什麼「網站很慢」這句話，本身是個壞問題。它太模糊，模糊到沒有人能給你正確答案。好的問法是「網站是在第幾段慢」，這個問題一旦能回答，解法就自動浮現了。整篇文章的核心，其實就是在教你怎麼把「很慢」翻譯成「第幾段、卡在哪個資源」這種可以行動的語言。

效能優化常有邊際效益遞減的情況，但每個網站的瓶頸與改善成本不同。先處理大型圖片、阻塞資源或慢查詢等明顯問題，再用實測判斷更進一步的投入是否值得；不要用固定秒數或工具滿分取代商業目標。

換句話說，診斷的本質就是一句話：先定位，再治療。下面的工具組合，就是用來做定位的。

現場診斷用的三個免費工具組合

實務上不會丟出十個工具讓你自己挑。下面這個小組合，足以先判斷問題偏向真實使用資料、主機回應或前端資源：

1. PageSpeed Insights：同時看實驗室模擬與有足夠資料時才會出現的真實使用者數據。LCP、INP、CLS 可用來檢查 Core Web Vitals，但它們只屬於眾多排名訊號中的小幅一環，不要把工具分數當成排名分數。
2. WebPageTest（或 GTmetrix）的 Waterfall 瀑布圖：這是最被低估的診斷神器。一張瀑布圖把每個請求的「等待、連線、下載」時間攤開來，誰是兇手一目了然。PageSpeed 給你結論，瀑布圖給你證據。
3. 瀏覽器開發者工具的 Network 面板：用無痕視窗打開你的站，按 F12，切到 Network，勾「停用快取」，再重新整理。你會看到網站在「沒有快取」的真實狀態下，到底是哪一個請求拖了兩秒。這一步非常重要，因為很多站長測的都是「已經被快取過的爽快版本」，真實訪客第一次進站根本不是那個速度。

這三個工具各有分工：第一個看 Google 的判斷、第二個看資源的先後順序、第三個看你自己機器上的真實載入。如果你想要更完整的測速工具橫評，可以參考 網站速度測試工具推薦。但請記得一件事：工具本身不會幫你變快，會幫你變快的是你看懂工具告訴你的事。

接著把「看懂」這件事講具體一點。打開一張瀑布圖，你會看到一條一條橫向的長條，每一條代表一個資源請求（一張圖、一支 CSS、一支 JS）。長條的長度代表它花了多少時間，長條的顏色區段代表不同階段：淺色是等待、深色是下載。你要找的，是那些「顏色區段特別長」的異常值。

判讀順序可以從最上面第一條，也就是 HTML 文件本身的等待時間開始，那是 TTFB 的重要組成。若這段在多次測試、不同地點都偏高，再往伺服器處理、快取與網路延遲排查，不能只憑單次超過一秒就斷定主機有問題。如果 HTML 很快，但中間有幾項資源特別久、又卡在其他請求前面，多半是關鍵路徑上的資源在拖累首屏，例如阻塞渲染的大型 CSS；圖片請求多且檔案大，則要先查圖片傳輸。

這套判讀邏輯，本質上就是把你前面學的「四段旅程」對應到一張圖上。當你能從一張瀑布圖直接說出「問題出在第幾段」，你就不需要再盲裝外掛了。

伺服器回應慢，是最常被忽略、也最致命的瓶頸

第一個要點名的瓶頸，是 TTFB（Time To First Byte，第一個位元組的回應時間）。這個數字代表你的伺服器花多久才把 HTML 拼好、送出第一個位元組。

為什麼說它致命？因為後面所有的前端優化，都建立在 HTML 已經送達的前提上。你的伺服器如果花了一秒二才回應，你就算把圖片壓到極致、把 JS 砍到剩一條線，整個載入時間的天花板就已經被釘死在那裡。前端再快，也快不過一個還沒出發的起跑線。

TTFB 沒有適用所有網站與地區的單一門檻。比較可靠的做法，是固定地點與網路條件重測，觀察自身基準與尖峰差異；數值持續偏高時，再從以下幾個方向排查：

• 主機資源與位置：共享環境的資源上限、超售與尖峰負載可能拉高 TTFB；資料中心離主要訪客較遠，也會增加網路往返時間。實際影響要用不同時段與地點的測試確認，不能只看主機類型或價格。
• PHP 版本過舊：新版 PHP 通常包含效能與安全性改善，但實際差異會受程式碼與主機環境影響。切換版本前先確認主題和外掛支援，做好 備份並在測試環境驗證，不能把升級視為低風險的一鍵操作。
• 資料庫查詢太肥：某些外掛會在每次載入時對資料庫下非常複雜的查詢，尤其是即時算排行榜、即時算相關文章的那類功能。開啟查詢監控類外掛，你會震驚於一個「看起來無害」的功能可以拖慢整個頁面。
• 沒有頁面快取：WordPress 預設每次請求都要即時執行 PHP、查資料庫、組 HTML，這是最慢的路徑。頁面快取把組好的 HTML 存起來直接回傳，等於把動態工作變成靜態回應。這是 TTFB 的特效藥，觀念與設定可以看 快取 Cache 完整教學，外掛選擇可以參考 WordPress 快取外掛實測。

講白一點，在 WordPress 站裡，首頁壓著一張 4、5MB 英雄圖的情況，比你想像中多太多。但比圖片更常見的，是一個根本沒開頁面快取、還跑在 PHP 5.6 上的站。這種站，你不用碰前端，光是把快取出來、把 PHP 升級，TTFB 就能砍掉一半。

圖片，前端的第一大兇手，而且幾乎每個站都中

解決完伺服器端，接下來進入第三段旅程：前端資源。而在這裡，圖片是壓倒性的第一名兇手，沒有之一。

這個問題之所以普遍，是因為「圖片慢」是一種沉默的成本。一張圖多 200KB，單獨看不痛不癢，但一個首頁有十五張這種圖，加上輪播、加上產品縮圖，總下載量可以輕易衝破 8MB。在光纖網路下你感覺不到，但在手機的 4G、尤其是在室內訊號差的環境，那就是地獄。

而手機，已經不是「次要裝置」了。根據 Statista 的統計，全球行動裝置佔網頁流量的比例，長期超過五成，而且在持續上升。你用桌機測出來的漂亮分數，遮不住手機訪客的真實痛苦。

圖片優化固定會做這幾件事，缺一不可：

• 壓縮：上傳後自動壓縮，無損或有損要依畫質需求選擇。WordPress 有多種圖片壓縮外掛可用，例如 Smush 與 ShortPixel Image Optimizer。想看完整比較可以參考 圖片壓縮工具實測。
• 換格式：把 JPG/PNG 換成 WebP 或 AVIF，同樣畫質檔案可以再縮小一截。格式的選擇與相容性處理，可以看 WebP、JPG、PNG 格式深度比較。
• 延遲載入（Lazy Loading）：首屏之外的圖片，等使用者往下捲才載入。這個動作可以瞬間把初始載入量砍掉一大半，觀念與實作看 Lazy Loading 實戰指南。WordPress 後來版本已內建基本的延遲載入，但進階控制還是要靠外掛。
• 給對的尺寸：不要在手機上餵一張 4000px 寬的原圖。用 srcset 讓瀏覽器依裝置挑選合適尺寸，這個細節很多人漏掉。

除了這四件事，還有一個觀念比任何外掛都重要：上傳前的源頭管控。很多站長習慣把相機或手機拍的原始大圖直接拖進媒體庫，再指望壓縮外掛來救。但壓縮外掛是事後補救，不是萬能的。更好的習慣是，在圖片進 WordPress 之前，先把它裁切成實際需要的最大尺寸（例如內容圖壓在 1600px 寬以內），再上傳。源頭就把檔案控制住，後端的壓縮負擔也小、轉檔也快。這個習慣一旦建立，你的媒體庫就不會變成一座越長越肥的胖子。

圖片優化的完整體系，站上另有 WordPress 圖片優化指南 一篇可參考，這裡就不重複展開。你只要記得：圖片是前端最容易見效、也最容易懈怠的一環。定期回去檢查媒體庫，是基本功。

那些看起來無害的第三方腳本，正在偷走你的速度

講完圖片，接著點名一個更陰險的兇手：第三方腳本。

什麼是第三方腳本？Google Analytics、Facebook Pixel、Google Tag Manager、Hotjar、那些浮動客服聊天外掛、社群分享按鈕、A/B 測試工具、廣告聯播程式碼。這些東西每一個看起來都「小小一個」，但你把它們全裝上去之後，它們會在你的頁面上疊加出一座冰山。

第三方腳本特別毒的地方在於：它們不受你控制。它們的伺服器慢、你跟著慢；它們改版、你的頁面跟著抖。常見的情況是，一顆客服聊天按鈕就可能吃掉快一秒的載入時間，而那個按鈕一整個月可能只有個位數的使用者點過。這不是優化，這是浪費。

面對第三方腳本，處理原則有三條：

原則	具體做法
能不裝就不裝	每一個追蹤碼都問一句「這個資料真的有在看嗎？」如果半年沒開過那張報表，砍掉。
能延後就延後	非必要的腳本（追蹤、聊天）用延後載入或只在需要時才注入，不要讓它們擋在首屏渲染前面。
用伺服器端代管	進階做法是把分析腳本改用伺服器端代管（server-side），減少對第三方網域的依賴，同時也對隱私更友善。

如果你想實際量化第三方腳本的影響，最快的方法是「封鎖測試」。在開發者工具裡把某個網域的請求擋掉，重新整理，看看載入時間差多少。那個差距，就是那個腳本的真實成本。你會很訝異，一個你以為「沒多少」的腳本，到底值不值得它吃掉的那幾百毫秒。

在管理層面上，如果你手上同時有 Analytics、Pixel、各種再行銷碼，建議統一透過 Google Tag Manager 來發派，避免把一堆程式碼片段直接貼進主題。好處有兩個：第一，你可以集中控制每個腳本的觸發時機，把非必要的延後到頁面載入完成之後；第二，未來要新增或移除追蹤碼，不用動到主題檔案，降低弄壞網站的風險。記得，再好的工具，如果設定方式讓你不敢動它，那它的價值就打折了。

這裡還有一個特別陰險的第三方腳本地雷值得點名：自動播放的影片背景、嵌入的社群動態牆、以及某些「免費」的頁面小工具。它們看起來只是裝飾，實際上每一個都在背景持續下載資源、執行腳本。一個首頁放滿這類元素的站，就算你把圖片壓到完美、把快取開到最滿，載入速度還是被這些裝飾品拖在地上。裝飾之前，先問一句：這個元素，值得它吃掉的速度嗎？

WordPress 站長的兩難：外掛不能不裝，又怕越裝越慢

如果你是用 WordPress 架站，你一定聽過這句話：「外掛裝越多，網站越慢。」

這句話對，也不對。真正精確的版本是：外掛的「數量」不是重點，外掛的「品質」與「它在每次載入時做了什麼」才是。一個寫得乾淨的聯絡表單外掛，跟一個會在每個頁面注入一堆腳本、又即時查資料庫的「多功能」外掛，影響天差地遠。

實務上評估一個外掛會不會拖慢網站，看三件事：

• 它是否在「前台每一頁」都載入它的 CSS/JS，還是只在需要的那一頁？會全域注入的外掛，是速度的大敵。
• 它是否會留下大量的資料庫選項（options）或瞬息快取（transients）？有些外掛解除安裝後不會清乾淨，長期下來資料庫越來越肥，連帶拖慢查詢。
• 它有沒有定期更新、是否相容於目前的 PHP 與 WordPress 版本？很久沒更新的外掛往往是效能與資安的雙重地雷。

選外掛時可參考WordPress 外掛推薦清單，並依主機既有快取、網站功能與測速結果判斷。速度外掛可以集中處理頁面快取與部分資源優化，但不是萬靈丹；若問題出在慢查詢、過重圖片或第三方指令碼，仍要回到診斷結果逐項處理。

還有一個常被略過的小坑：字型。Google Fonts 預設是從 Google 的伺服器載入，等於每個頁面都要額外連一次外部網域。把字型改成本機託管，可以少一個外部連線、又能兼顧隱私法規，做法看 WordPress 本機託管 Google Fonts。

快取不是萬靈丹：裝了反而更慢的地雷區

前面一直強調頁面快取是 TTFB 的特效藥，但這裡要補一個但書：快取設定錯誤，比不開快取還危險。這是最常見、也最讓人心碎的優化事故之一。

快取的本質，是把「每次都要重新算」的動態頁面，存成「可以直接回傳」的靜態版本。這個機制對公開的內容頁完美，但對「因人而異」的頁面卻是災難。哪些頁面絕對不能被快取？把清單列出來：

• WooCommerce 結帳頁、購物車頁：一旦被快取，下一位訪客看到的會是上一位的購物車內容，結帳金額錯亂，訂單直接出問題。
• 會員專屬頁、登入後顯示不同內容的頁面：快取會讓所有人看到同一個版本，會員功能形同失效。
• 表單確認頁、帶有個人化資訊的頁面：這些頁面的內容每次都不同，快取會導致資訊錯置。

正規的快取外掛都會預設排除這些動態頁面，但前提是你用的是設定正確的外掛、而且沒有手動覆蓋那些規則。常見的狀況是：站長為了「最大化快取命中率」，自作主張把所有頁面都加進快取範圍，結果購物車頻頻出錯、訂單流失，甚至賠上客戶信任。一個以為聰明的勾選，代價可能十分慘痛。

還有兩個快取的隱形坑，也順便提醒你。第一是「物件快取」（object cache）與「頁面快取」是兩回事：頁面快取存的是完整 HTML，物件快取存的是資料庫查詢結果，網站變大之後物件快取（例如 Redis）對後端速度的幫助很顯著。第二是快取外掛開太多「最小化、合併、延後載入 JS」的選項，有時反而會打破某些外掛的相依性，導致功能壞掉或 INP 變差。每動一個選項，都請重新測試一遍核心功能與速度，不要一口氣全開。

原則只有一句話：快取要開，但要精準地開。

CDN 與主機：錢要花在刀口上，不是花在最貴的方案

很多站長一發現網站慢，第一個念頭是「換更貴的主機」或「裝 CDN」。這兩個動作都可能是對的，但也可能是純粹浪費錢。關鍵在於：你的瓶頸到底在不在它們能解決的那一段。

先說 CDN。CDN（內容傳遞網路）的原理，是把你的靜態資源（圖片、CSS、JS）快取在世界各地的邊緣節點，讓訪客從離自己最近的節點抓取，縮短網路往返時間。它對「跨地域」的問題非常有效，例如你的主機在台灣、卻有大量海外訪客。但如果你的訪客絕大多數都在本地、主機也在本地，CDN 對 TTFB 的幫助就有限，因為資料往返本來就不遠。

換句話說，CDN 解的是「網路距離」，不是「伺服器算得慢」。如果你 TTFB 偏高是因為 PHP 太舊、沒開快取，你裝全世界最貴的 CDN 也壓不下來，因為它根本不碰那段。CDN 的原理與適用情境，可以看 CDN 完整解析。

主機升級也是同樣的邏輯。共享主機可能因資源政策與其他租戶負載而出現效能波動，但 TTFB 偏高也可能來自 PHP 程式、資料庫、快取或網路路徑。先完成低成本檢查，並用瀑布圖與伺服器監控確認瓶頸；證據指向主機資源時再升級。主機類型的差異可以看主機類型比較。

講白了，效能優化的花費應該是「由低到高」的階梯：先把不花錢的做完，再把小錢的做完，最後才考慮大筆投資。順序顛倒，就是花大錢解小問題。

Core Web Vitals：三個真實使用體驗指標

講到這裡，我們要進入第四段旅程：視覺穩定與互動。而這一段，正是 Google 用來衡量「頁面體驗」的 Core Web Vitals 所在（見 官方說明）。

Core Web Vitals 不是一個分數，是三個指標，各自代表一種「使用者痛苦」。

指標	它衡量什麼	使用者的痛苦	主要解法方向
LCP（最大內容繪製）	頁面最大那塊可見內容畫完的時間	「畫面怎麼還沒出來？」	首屏圖片與字型優先、預載入關鍵資源
INP（互動到下一次繪製）	使用者點按後，畫面多久有回應	「我點了啊，怎麼沒反應？」	砍掉阻塞主執行緒的長任務、拆解 JS
CLS（累計版面位移）	頁面載入過程中，元素亂跳的程度	「我才要點，按鈕就跑掉了！」	圖片與廣告區塊預留高度、避免動態注入

這三個指標裡，INP 是相對晚加入、卻讓最多站長踢到鐵板的一個。它取代了舊的 FID，衡量標準更嚴格。很多站 LCP、CLS 都過關，卻死在 INP 上，原因往往是某個外掛在使用者點擊的瞬間，丟了一個很重的 JavaScript 任務到主執行緒，把畫面更新卡住了。

針對這三個指標，各自最務實的第一動如下：

• LCP 太高：先檢查首屏那張最大的圖或最大的文字區塊。圖片太大就壓、就換 WebP；如果是字型導致，就預載入關鍵字型、或改本機託管。常見的地雷是首頁英雄圖沒做延遲載入以外的處理，直接吃掉了 LCP。
• INP 太高：開啟開發者工具的「效能」錄製，點一下頁面，看主執行緒有沒有一條又紅又長的任務。那就是兇手。解法是把非關鍵的 JS 延後載入、拆解長任務，或乾脆移除那個會在點擊時做太多事的外掛。
• CLS 太高：常見來源包括圖片、廣告與嵌入內容沒有預先留好空間。瀏覽器載入時不知道區塊會佔多大，等內容下載完才撐開，下面的東西就會被往下推。給圖片明確的寬高、替廣告區塊保留適當空間，再用實測確認 CLS 是否改善。

Core Web Vitals 的主要價值，是把載入、互動與視覺穩定性變成可量測的使用體驗指標。它們在排名中只扮演小幅訊號，而且三項通過也不代表網站所有體驗都良好。想深入優化細節，可以看 Core Web Vitals 完整攻略。

手機才是真正的主戰場

前面提過行動流量已經過半，這裡要把這件事的後果講清楚。

Google 已全面採用行動優先索引（mobile-first indexing），主要使用手機版內容進行檢索與索引（見 2023 年的 官方公告）。這是索引方式，不是手機速度直接決定排名；手機版仍要保留與桌機版相當的主要內容，也要檢查行動裝置的真實效能。

但手機的處境比桌機嚴苛太多。CPU 弱、記憶體少、網路不穩、螢幕小導致前端渲染更吃力。同一個頁面，桌機測出來綠燈，手機測出來可能滿江紅。所以建議是：用 PageSpeed Insights 的「行動裝置」那一欄當你的真正基準，不要看桌機那一欄。每次優化前後，都以手機分數為準來衡量。

這也牽動一個更廣的策略選擇：行動版的設計不該是「把桌機版縮小」，而該是「為手機重新思考」。首屏放什麼、圖片用多大、哪些功能要藏進漢堡選單、哪些腳本在手機上根本可以拿掉，這些都值得重新檢視。速度從來不只是技術問題，它也是設計問題。

速度也會影響留存與轉換，但不能把分析工具裡的跳出率直接當成 Google 排名訊號。跳出率如何解讀，可以看 跳出率完整解析；網頁速度對 SEO 的整體影響，則可以參考 網頁速度與 SEO 與 技術性 SEO 指南。

症狀對照表：你的站是哪一種慢？

講了一輪診斷觀念，把它收斂成一張你可以直接帶走的決策表。先看症狀，再往回推可能的原因，最後決定第一刀砍哪裡。

你最明顯的症狀	最可能的原因	第一刀該砍哪裡
點下去後白屏很久，才開始跑內容	DNS 解析慢、或伺服器主機太遠/太忙	查 DNS 託管商、考慮 CDN、或升級主機
頁面框架出現了，但進度條還卡在最前面	TTFB 過高（無頁面快取、PHP 太舊）	開啟頁面快取、升級 PHP 版本
框架出來了，圖片與字型慢慢浮現	圖片未壓縮、未延遲載入、資源太多	壓圖、換 WebP、開 Lazy Loading
頁面看起來載完了，但會突然亂跳	CLS 過高（圖片/廣告沒留高度）	為圖片與嵌入區塊預留尺寸
點按鈕要等一下才有反應	INP 過高（JS 阻塞主執行緒）	拆解長任務、延後非關鍵 JS
桌機很快、手機很慢	沒有針對行動最佳化、腳本太多	以手機版為基準重新檢視資源
裝了快取外掛反而更慢、或功能壞掉	快取設定錯誤（快取到動態頁）	排除結帳、會員、表單頁，再測試

這張表的價值，在於它逼你「先想清楚症狀，再行動」。大多數人優化失敗，就是因為跳過了「辨識症狀」這一步，直接把所有聽過的手段全倒上去。那不是優化，那是祈禱。

如果你想從更系統性的角度，把整個網站的速度工程從頭到尾走一遍，可以搭配 網站速度優化指南 與 WordPress 速度優化 兩篇一起看。CDN 與主機選擇前面章節已經點過相關資源，這幾篇是同一套知識的不同切面，合起來就是一份完整的速度地圖。

十分鐘速度健檢：今天就能做完的行動清單

在進入行動清單之前，先打掉幾個最常見的速度迷思。這些觀念一旦卡在腦裡，會讓你把力氣浪費在錯的地方。

常見迷思	實際情況
「分數越高，網站就越快。」	分數只是工具在特定條件下的評分模型，真正要看的是實際載入過程與真實使用者資料。同一個站用不同工具、地點或測試條件，分數可能差不少。
「外掛裝越少越好，最好歸零。」	重點不在數量，在外掛品質。一個乾淨的快取外掛，能幫你省下遠多於它自身成本的時間。
「換了貴主機就一定快。」	主機只解決伺服器端那一段。前端沒壓圖、沒除腳本，換再貴的主機也救不回來。
「優化做一次就一勞永逸。」	速度是持續保養。內容增加、外掛更新、第三方程式碼改版，三個月前快的站現在可能又慢了。
「桌機測起來快就沒問題。」	桌機與手機的裝置、網路條件不同，兩邊都要測；行動優先索引不等於 Google 只看一個行動版效能分數。

觀念講完了，接著是一份今天就能動手的清單。不用全部做完，但請至少做完前三項，你會立刻感覺到差別。

1. 用 PageSpeed Insights 測一次你的站，只看行動裝置那欄。把 LCP、INP、CLS 三個數字記下來，這是你的起點。
2. 確認頁面快取有沒有開。沒開的話，這是你能最快拿到的一次性大幅改善。排除結帳頁、會員頁等動態頁面，再啟用。
3. 把 PHP 版本升到主機支援的最新穩定版。升級前務必完整備份，並確認主題與外掛相容。
4. 依測試結果處理圖片。若瀑布圖與 Lighthouse 顯示圖片占用大量傳輸或延後 LCP，可壓縮媒體庫既有圖片、使用合適格式與尺寸，並只對非首屏圖片啟用延遲載入。
5. 盤點第三方腳本。逐一問「這個有在看嗎？」，沒有的就停用或延後載入。
6. 用瀑布圖抓出最慢的請求。針對那個最慢的資源，決定是壓縮、延後、還是直接移除。
7. 兩週後回來再測一次。把數字跟起點比對，確認改動真的有效，不要只憑感覺。

這份清單刻意設計成「由低成本的排到高成本的」。前三項幾乎不花錢，只需要你願意花半小時動手；中間幾項要動一點設定，但風險都很可控；最後的回測，則是確保你沒有白忙一場。很多人優化失敗，多半是因為做了一堆事之後從來沒有回頭驗證，到頭來根本不知道哪個動作有效、哪個動作反而有害。

速度優化是一場沒有終點的保養，不是一次性的工程。你的內容會增加、外掛會更新、第三方程式碼會改版，今天快的站，半年後可能又慢了。所以你真正該建立的，不是「做過一次優化」，而是「隨時能診斷」的能力。當你學會先問「慢在哪一段」，你就再也不會把力氣浪費在錯的地方。

網站速度服務的對象是人，不是跑分工具。先讓主要內容穩定、快速地出現，再處理真正影響互動的瓶頸，比追求滿分更實際。

也別忘了，速度最終是為了留住訪客、促成轉換。一個會等的訪客，是一個對你還有興趣的訪客；一個被你用速度趕走的訪客，大概不會再回來。如果你想在更廣的層面上，把速度、體驗、轉換串成一條線來思考，SEO 完整指南 與 Google 排名指南 會是延伸閱讀的好起點。

現在，打開你的站，先測一次吧。從今天起，做一個會診斷的站長，別再只會裝外掛。