網站速度慢別急著裝外掛：先分流判斷，再決定修哪裡

想像檔期前一周的場景：客服信箱躺著幾封「你們網站在手機上開好久」的回報，主管在會議上問「多久能修好」，你打開測速工具，畫面上是五十幾分和一排紅字。紅字那麼多，該先碰哪一個？這時候最像個選擇的舉動，往往是打開後台、找一款外掛裝上去，能勾的設定一次全勾，先做點什麼再說。

分數是體溫計，不是病歷。它告訴你有在發燒，不會告訴你哪裡發炎；而網站變慢的大頭，常常不是檔案傳不完，是隊伍在排：等連線建立、等伺服器把頁面組好、等資源依序抵達、等腳本把主執行緒還給畫面。能回答「訪客卡在哪一秒」，才有資格開藥方。下面是一套照著走的流程，從測量、判讀、分流修復到驗收，每一步都接著下一個動作。

快速重點：速度問題沒有通用藥方，只有判斷順序。慢的大頭常是等待：等連線、等伺服器、等資源、等畫面輪到渲染。先測基準、判讀慢在哪一段，再分流到伺服器、資源或互動層動手；順序對了，免費工具就修得到關鍵瓶頸，順序錯了，預算燒完只剩好看的分數。

動手之前，先回答三個商業問題

「網站很慢」這四個字不能直接開工，先回答三個問題：慢的是哪些頁面、修到什麼程度算好、這一次由誰來修。三個答案不同，後面的走法就完全不同，花錢的位置也不同。

第一個問題把戰場縮小。轉換頁（商品頁、結帳流程、詢問表單）與流量頁（文章、目錄、分類頁）的慢，代價差得很遠：訪客在結帳第三步離開，與文章讀到一半跳出，是兩種等級的損失，修的優先序也應該分開排。訪客在哪一步走掉、跳出怎麼解讀，可以對照跳出率的分析方法；速度在搜尋裡的位置，網頁速度與排名的關係講得更完整，它是眾多訊號之一，想看整體訊號的組成，再往Google 排名因素解析走一步。

兩種頁面的修法也不同。轉換頁要求「那幾步都要順」：商品頁的大圖、結帳流程的腳本、表單送出的回應，每一項都直接掛著業績；流量頁要求「第一屏快出現」，訪客要的是答案，標題與首段先到位，圖片晚一點無妨。資源有限時，先修轉換頁的第一屏，再修流量頁，這個順序由商業代價決定，不由測速分數決定。

第二個問題定義終點。「修好」不由滿分定義，由門檻與商業指標定義：行動裝置的 LCP 2.5 秒內、INP 200 毫秒內、CLS 0.1 內，是官方給的建議值（見 Core Web Vitals 的定義），再外加一個你真正在乎的數字，例如行動結帳完成率。門檻先寫下來，改完才有得比對，也才知道什麼時候可以停手。

第三個問題決定投入方式，也牽動後面的停損設計。這裡先把一個反直覺的事實放上檯面：慢的大頭常是等待與排隊，不是傳輸，所以加頻寬、換更貴的主機、掛 CDN 這三個反射動作，各只照顧載入旅程裡的其中一段；不先定位就投藥，常投錯層，甚至互相干擾。web.dev 談速度重要性時，重點也放在訪客的去留，不在分數本身。

常見的三管齊下，裝快取、壓圖片、上 CDN 一起來，分數的確會動，卻答不出「哪一個有效」；答不出這件事，下次變慢就只剩再堆一輪一途。這個問題就留給下一節的測量紀律來解。

測量有固定順序：從無痕視窗到瀑布圖的初診流程

一輪初診十五分鐘做得完，順序固定三步：先用自己的瀏覽器實測載入，再看工具的整體評估，接著攤開每個請求的明細。固定順序的理由很簡單，拿不同工具、不同條件到處測，得到的雜訊會比線索多。

第一步，開無痕視窗，打開瀏覽器開發者工具的 Network 面板，勾「停用快取」，重新整理。這個選項停用的是瀏覽器端的快取，你看到的是第一次造訪的訪客眼中的世界：DNS 重查、連線重建、瀏覽器裡的副本一律重新下載；至於伺服器與 CDN 端的快取有沒有命中，要從回應時間的分解另行判斷。多數站長平常測到的是瀏覽器快取命中的版本，第一次上門的訪客走的根本不是那條路，這也是「我自己測明明很快」與「客訴很慢」同時成立的原因。

Network 面板裡還有一個好用的開關：網路節流。把條件設成中階手機的情境再測一次，你會更接近多數訪客的真實體感，桌面電腦的光纖會把許多問題藏起來，一段在光纖上無感的外部腳本，換到節流條件下可能就是白屏多出來的那一段。

記錄的方式愈簡單愈好：一張表格，欄位放日期、頁面、工具、三個指標的數字，每次測完就補一行。這張表後面每一節都會用到，改動有沒有效、停損點該不該啟動、驗收算不算過，看的都是它，不是記憶。

PageSpeed Insights 的報表背後有兩種來源：實驗室模擬在固定條件下執行，可控、可重現，適合比較改動前後；現場資料來自真實訪客的造訪紀錄，要累積到足夠樣本才會顯示。兩種結論衝突時，以現場資料為準，因為它代表的才是真正上門的人；看報表時也以行動裝置那一欄為基準。

第三步，瀑布圖。每個請求畫成一條橫桿，顏色分段標出等待、連線與下載：第一條（HTML 文件）的等待段特別長，問題偏向後端；中段幾條異常肥大的橫桿，問題偏向資源層。工具給的結論要能翻譯成「第幾段、哪個請求」，翻譯不出來的先擺著，別急著動手。各測速工具的口徑差異，測速工具的比較有整理。

瀑布圖上還有一個容易誤讀的地方：綠色不等於沒事。一條橫桿本身不長，但它卡在關鍵路徑上，後面的資源全在等它放行，殺傷力就比它自己的長度大；反過來，一條很長的橫桿若排在頁面可用之後才抵達，對訪客感受的影響就小。看圖要看兩件事：請求本身的重量，與它擋到了誰。

行動裝置會成為基準，有兩個支撐：全球網頁流量來自行動裝置的比例長期過半（Statista 的長期統計），Google 檢索與索引也以行動版內容為主（Google 的行動優先索引公告）。加上手機的處理器、記憶體與網路條件都更緊，同一頁桌機綠燈、手機滿江紅是常態。

測量紀律三條：一次只改一項再複測；每次都記下基準數字；結論以行動裝置口徑為準。一次改三件事再測，分數動了也說不清功勞歸誰，等於白測。

四段旅程的判讀法：同一個慢字，四種意思

同樣一句「很慢」，在載入的不同階段代表不同的麻煩。從按下網址到可以安穩閱讀，頁面會經過四段旅程，後一段要等前一段放行，時間被最長的一段釘死；先說出慢在第幾段，後面每一個決定才會變簡單。

四段裡藏著一份等待的帳，值得算一次（純示意）：每個請求都要付 DNS、TCP、TLS 的來回時間，頁面上若有「下載完 A 才能開始 B」的依賴鏈，來回延遲會乘上鏈的深度，行動網路的來回又比固網慢。頻寬加大壓的是下載段，壓不到排隊付出的時間，這是「網路升級了卻沒變快」常見的解釋。

判讀的起手式，是拿初診三步的結果對照上表：無痕視窗裡白屏很久，指向第一段與第二段；框架出現後內容慢慢補，指向第三段；框架完整卻點不動、會跳，指向第四段。對上哪一段，就走哪一條分流道，接下來三節就是那三條路的走法。

用同樣的框架回頭看開場的客訴也行：「手機上開好久」多半是第一到第三段的總和，「點了沒反應」是第四段，兩者的修法與負責的人可能都不同。把客訴的形容詞換成段號，團隊內部的溝通成本會立刻下降，因為大家討論的不再是感覺，是同一張地圖上的位置。

Core Web Vitals 的三個指標只覆蓋旅程的一部分：LCP 看主要內容的呈現，INP 與 CLS 看互動與穩定，連線段不在管區。所以分數漂亮不代表每一段都沒事，也不該拿工具分數去換算排名分數；三項指標與搜尋之間的關係，Core Web Vitals 的完整討論有說明。

邊際效益也要先想：大圖、阻塞資源、慢查詢這些明顯的問題先修，修完再評估下一筆投入值不值得，不拿固定秒數或滿分取代自己的商業目標。速度之外，把技術 SEO 的整體健檢排進同一輪，常常一次看清更多事。

分流道一：伺服器回應等太久，先查後端再查錢包

先看 TTFB（Time To First Byte，首位元組抵達時間）。它從瀏覽器開始導覽算起，到回應的第一個位元組送達為止，中間可能包含重導向、DNS 查詢、連線建立與伺服器處理；數字偏高只是入口線索，不能直接畫上等號，說成 PHP 組 HTML 太慢。

線索要往下拆。WordPress 沒開頁面快取時，每個請求都要即時執行程式、查資料庫、組出 HTML，這是最慢的一條路；頁面快取把這條路換成「組好就直接回」，把動態計算換成靜態回應，訪客要的頁面早在那裡等他。快取的原理與設定步驟，快取機制的完整說明一步步走過。

花錢之前，有兩個便宜的測試先做。第一，登出狀態連續重新整理首頁，比對 TTFB：第一次特別慢、後面幾次明顯變快，代表快取有做事，慢的是「第一次」；每次都一樣慢，回源運算本身可能就是瓶頸。第二，確認 PHP 版本：還停在已停止支援的版本，就先安排升級，升級前完整備份、確認主題與外掛相容，這一動的成本遠低於換主機。

主機後台也是線索來源。資源用量圖如果有固定的尖峰，尖峰時間又與促購活動、電子報發送、排程備份重疊，代表慢是「忙不過來」，不是「壞了」；用量平平卻依然慢，問題偏向程式與查詢。把這張圖跟瀑布圖擺在一起看，判斷會具體很多。

主機升級的訊號是「證據指向伺服器段」：尖峰時段特別慢、連後台都卡、瀑布圖第一條的等待段長期偏高。共享與管理型主機在資源與支援上的差異，主機類型的比較有整理；先用便宜動作排除快取與版本問題，再談這一筆錢，順序對了錢才不會白花。

還有一個反向訊號值得知道：如果只有特定頁面慢，某個分類頁、某個篩選結果頁，整站其他頁面都正常，問題多半不在主機，在那個頁面特有的東西，一支只在那頁載入的外掛、一個沒走索引的查詢、一張只在那頁出現的巨圖。先把範圍縮小，錢才花得準。

同一條分流道上還有兩個次要檢查項：WordPress 核心、主題與外掛停在很久沒更新的版本，以及即時排行榜、相關文章這類每次載入都下重查詢的功能。它們的症狀與主機不足相似，都是回應變慢，但修法不同，一個是更新與替換，另一個才輪到加資源。

分流道二：頁面出現了、內容卻慢慢浮現

頁面框架出現了，圖和字慢慢補上，這是資源段的症狀。修復順序不由固定清單決定，由瀑布圖決定：按傳輸大小排一次、按花費時間排一次，兩次都排前面的那一項，就是第一個動手的對象。體積要用帳單的語言看，單一檔案多一點沒感覺，乘上整頁的請求數，就是訪客每一步都在付的稅。

順序這件事值得多講一句。固定清單式的建議，先壓圖、再設快取、然後換主機，假設每個站的瓶頸都長得一樣；實際上一個攝影作品站與一個文字內容站的瓶頸完全不同，前者的大頭在圖片體積，後者可能在外掛與資料庫。瀑布圖的價值，就是把你這個站的重量與等待照實排出來，而不是套別人的藥單。

圖片通常是最大宗，工作流有先後。先把尺寸做對：srcset 讓瀏覽器依裝置拿對的尺寸，餵錯尺寸的圖，壓縮救不回來。接著換現代格式，WebP、AVIF 在相近畫質下檔案更小，格式之間的取捨看圖片格式的比較。然後才是壓縮，WordPress 生態有現成工具，例如 Smush 與 ShortPixel，工具差異與挑選，壓縮工具的橫向比較整理過；已經堆了幾百張舊圖的媒體庫可以批次處理，做法參考媒體庫批次瘦身，從上傳到呈現的完整流程另有WordPress 圖片優化專篇。

上傳的源頭也要管。相機與手機的原始檔常有四千像素寬，內容頁實際顯示通常用不到一半；養成「進媒體庫前先裁到實際需要的最大尺寸」的習慣，後面的壓縮、轉檔都輕鬆，媒體庫也不會一年後變成搬不動的倉庫。

延後載入是資源段的另一個槓桿：首屏之外的圖，等訪客捲到附近再載，初始下載量立刻輕一截。但它有例外，首頁主圖、商品主圖這種 LCP 的擔當，不但不該延後，還該優先載入；分寸怎麼拿，延後載入的設定細節有講。

字型常被漏掉。從 Google 伺服器載字型，等於每個頁面多一次跨網域的往返；把字型收回自己主機，少一個外部連線，載入順序也能自己安排，做法看字型在地化。

第三方腳本要用「借來的按鈕最貴」的角度看：社群分享按鈕、客服聊天 widget、設定不當的分析碼，每一個都同時吃三段，連線的來回、下載的體積、主執行緒的執行時間，而且不受你控制，對方伺服器慢，你的頁面跟著慢。盤點的問法很簡單：這份資料有人看嗎？半年沒人打開的報表，對應的碼就可以停用或延後。

要量化第三方腳本的成本，可以走一輪封鎖測試：用開發者工具擋下特定網域的請求，刷新頁面，比對載入與互動前後的差異，那個差距就是它的身價。分析碼想留又怕拖慢，常見的做法是延後到頁面可用之後再載，資料照收，訪客先看到畫面。

分流道三：畫面會跳、按了沒反應，問題在互動層

載入看起來不慢，訪客卻說點不動、版面會跳，這是互動段的領域。瀏覽器只有一條主執行緒，像一位一次只能做一件事的師傅：腳本下載完不等於 ready，解析與執行還在排隊；訪客點下去的那一刻，師傅手上若正忙著重活，畫面就沒有回應。

INP 衡量的就是這種塞車，它取代舊的 FID、標準更嚴格，演進背景看從 FID 到 INP。排查靠對照測試：逐一停用可疑外掛，每次點擊同一個互動、記錄回應時間，肇因多半會現形，常見是某個外掛在點擊瞬間丟出一個很重的 JavaScript 任務，把整條線占住。

實際的操作順序：先錄一段效能，點擊那個卡住的按鈕，看主執行緒上有沒有一整條紅色的長任務；有，就對照停用外掛，一次停一個，每停一次重錄一次；責任落在哪個外掛頭上，再決定換掉、調整或移除。這比憑印象砍外掛快得多，也更不會誤殺。

CLS 看的是整趟造訪累計的非預期位移，不是某一瞬間：捲動後才載入的圖片、首屏測完才插入的廣告、慢半拍才撐開的嵌入內容，都會在檢測工具收工之後才讓版面跳一下。所以別只盯初次載入的分數，內容長的頁面要捲過一遍再下結論。

位移的修法是預留空間：圖片在 HTML 裡寫明寬高，廣告與嵌入區塊先留高度，動態插入的內容也先佔好位子，載入完成只把內容填進格子，不把下面的東西推開。字型載入前後的文字跳動，則可以用預留行高與備用字型的搭配壓低，訪客閱讀的位置不會突然移動。

外掛取捨的原則：功能可以被併進別的工具就移除，寧可用一個做多一點的，不要四個各做一點的。挑選時的體質檢查，外掛挑選原則可以對照。Google 把頁面體驗當成一組訊號（Google 對頁面體驗的說明），互動與穩定都在列，但通過門檻不等於排名保證，這一段的價值在訪客能不能順利完成點擊任務。

這條分流道最常被分數掩蓋：LCP 漂亮的站，INP 仍可能慘烈。驗收時看任務，不看單一分數。

預算怎麼排：快取、CDN、主機升級的花錢順序

要花錢可以，按階梯花。每一階都有成立條件，跳級要有證據，不是因為焦慮；把階梯攤開，錢對應哪一段、解不了哪一段，一眼就看得出來。

階梯的用意是防兩種浪費：瓶頸還在後端就把錢花在頻寬上，以及免費動作沒做完就跳去換主機。每一階做完都回測一次，數字沒動，表示瓶頸不在這一段，往下一階走；數字動了，也順便知道這筆錢或這段工時買到了什麼。

快取要想成三層記憶：瀏覽器一層、邊緣一層、來源站一層，各有各的規則與壽命。命中時近乎直接回，未命中時仍要走完整趟回源運算，兩種情況要分開測、分開判斷，混在一起看就會誤判成效。

CDN 能不能幫上忙，取決於邊緣節點有沒有接到快取：符合規則的圖片、CSS、JS 可以存在邊緣，經設定的 HTML 也行；命中與否看資源類型、回應標頭與快取規則。流量跨地域、可快取內容又多時，它比較有機會減少回源與傳輸延遲，但請求不保證每次走地理上最近的節點，實際改善幅度要測了才算數。

命中與未命中要分開看：命中的資源近乎從邊緣直接回，未命中的仍要回源，來源站的運算一份都沒少。所以 TTFB 偏高時，先把快取命中、網路往返與後端處理拆開，再決定調 CDN、調快取規則，還是動主機；CDN 的原理與適用條件有專篇。

CDN 的適用條件也可以反過來看：網站如果幾乎都是動態內容，會員專區、個人化推薦、即時庫存，能被邊緣快取的比例就低，效益自然有限；靜態資源占比高的站，圖庫、型錄、下載檔案，同樣的費用買到的改善就明顯。先算可快取的流量占比，再決定要不要上，會比看別人用了就跟著用穩。

快取的地雷在「全開不等於設對」。結帳流程被快取住、訪客看到別人的購物車，這類事故都來自動態頁沒有排除：購物車、結帳、會員頁的內容因人而異，快取規則的核心就是把它們劃出去。頁面快取存 HTML、物件快存放查詢結果，是兩回事，前者救回應時間，後者救後端；工具的選擇與設定，快取外掛的比較有整理。

主機升級排在階梯末端。想像一個批發型錄站：平日順順的，週年慶尖峰時段連後台都卡，瀑布圖第一條長期偏紅，快取與 PHP 都已經設對，這時證據指向伺服器段的資源上限，升級才花得有理由。主機與訪客本來就在同一地區時，CDN 與主機升級的改善都要實測，不拿方案價格代替證據。

自己修或找人修：用停損點決定

圖片、快取設定、外掛清理屬於可自修區：工具成熟、可逆、出錯容易還原。自修的隱性成本要算進去，工時、試錯的來回，還有把站弄壞的風險。任何動手之前，完整備份先做一次，備份與還原的工具照著設定。

停損點寫成三個明確訊號：照流程走完一輪、複測兩次關鍵指標沒有改善；問題指向主題結構或資料庫慢查詢這種要動程式的層級；修復動作的風險會碰到營運中的頁面。任何一個訊號出現就停手，把已投入與還要投入的工時換算成成本，再決定要不要交出去。

委外的判斷保持中立：合理的報價會附上前後量測資料與具體查核點，不是只給一張「效能優化」的項目名單；對方能不能說出「你的站慢在第幾段」，比方案金額更能預測這筆錢花得值不值得。查核點可以具體化成三樣：動工前的基準量測、每項變更的前後資料、結案時的驗收口徑，三樣對得上的報價，貴一點通常也值。

速度是技術 SEO 的一環，這輪修完，把SEO 的整體工程排進下一張地圖，會比在速度單點上繼續磨更有效率。

症狀、瓶頸、對策：帶著走的判斷表

三條分流道濃縮成一張表：左欄放可觀察的症狀，接著是量測時看到的線索、對應的瓶頸層，右欄給第一個動作。列序照四段旅程排，收到回報時由上往下對。

表的用法是症狀優先：症狀來自真實回報，量測線索把症狀變成數字，瓶頸層決定走哪條分流道，第一個動作永遠只有一個。想把整套速度工程從判讀走到收尾，速度優化的完整指南與WordPress 提速的實作篇接著看。

這張表不是拿來背的。下次再收到「網站好像變慢了」的回報，先對症狀欄、再對瓶頸欄，第一個動作就有了依據；症狀對到瓶頸、瓶頸對到對策的整套對應關係，整理成下圖。

驗收：確認變快的是訪客，不是只有分數

驗收三原則：單一變數，一次只驗一項改動；前後對比，同一工具、同一條件、行動裝置口徑；現場資料優先於實驗室模擬，改完當天先記錄，觀察期過了再下結論。分數進步但訪客的任務完成率沒變，就回到第一節的三個商業問題重問一次：修的到底是不是訪客真正卡住的那一頁。

任務面的驗收可以做得土法一點：拿一支手機，照訪客的路徑走一遍，搜尋、點商品、加到購物車、結帳，每一步感受一次回應速度，改動前後各走一遍。這種走法粗糙，卻最貼近客訴裡那句「很慢」，也常能抓到儀器看不出來的卡點，例如某個按鈕其實要按第二次才有反應。

複查的節奏固定下來就不花腦筋：每月挑同一個時段，無痕複測首頁與一兩個關鍵轉換頁，看搜尋工具裡的速度報告，數字登進同一張表。連續兩個週期都在門檻內，就把速度從待辦清單拿掉，只留觸發條件：新增外掛、改版面、換主題、大改內容之後，加測一次。

內容持續在長、外掛一直在改版、第三方程式碼也不是靜態的，舊問題本來就會回鍋；該留下的不是一次做完的成績單，是任何時候都能重新判讀的功夫。

回到開場那個檔期場景：別再對著五十幾分發呆，把半小時花在初診三步更划算。下次再被反映慢，應對縮成三句話就夠：對表、判段、修最前面的那一項。