WordPress 網站很慢怎麼辦？
從主機層到外掛層的 8 個檢查順序

WordPress 網站很慢的時候，最常見的處理方式是直接加錢換更貴的主機方案，而這通常是八個檢查裡最後才該做的一個。原因很簡單：「慢」這個字底下至少藏著兩件完全不同的事——主機把網頁算出來要多久，以及瀏覽器把畫面畫完要多久。沒有先把這兩段分開，任何調整都是碰運氣。這篇按照「先量、再免費、最後才花錢」的順序，把 8 個檢查項目排好，每一項都寫出在哪裡查、看什麼數字、預期能拿回多少時間。

先講適用範圍：這篇處理的是既有網站變慢的診斷順序。如果你還在挑主機、想知道哪些規格會影響 WordPress 的速度，那是另一個題目，整理在WordPress 主機怎麼選；如果網站是十年前用 PHP 4.x 寫的舊架構、根本不是 WordPress，判斷該修還是該重做請看老網站升級還是重做。

先量兩個數字，把「慢」切成兩半

在動任何設定之前，先取得兩個數字：TTFB（Time To First Byte，主機回應第一個位元組所花的時間）與整頁載入完成時間。前者衡量主機端，後者包含瀏覽器下載與繪製。兩個數字的關係決定你接下來要往哪個方向查：

量法有兩種。開發者工具的「網路」面板點第一筆文件請求，看 Waiting for server response 那一段，就是 TTFB。命令列的量法更適合重複比較，同一行指令多跑幾次看穩不穩：

要有個參照基準。我們在自家主機上對同一台機器的網頁量過三輪，扣掉 TLS 握手之後，主機端把一頁算完並開始送出大約是 2 到 13 毫秒——這是純手寫 PHP、沒有資料庫查詢的頁面，不是 WordPress，這裡只是用來說明「主機硬體本身能給你多少時間預算」。同一台機器上，一個沒有頁面快取的 WordPress 首頁會比這個數字高上一到兩個量級，因為每一次請求都要重新載入佈景與外掛、重跑 PHP、再對資料庫下數十次查詢。這中間的落差，就是後面幾個檢查要拿回來的東西。

主機層的三個檢查：PHP 版本、頁面快取、壓縮

檢查 1：PHP 版本——但效益可能沒有你想的那麼大

「升 PHP 版本網站就會變快」是流傳最廣的一句建議，實際上它只對某些人成立。我們在同一台主機上用同一支測試程式跑過各版本的 PHP，內容是字串處理、關聯陣列查表、浮點運算與雜湊序列化的混合，每版跑三次取最佳值：

讀法是這樣：從 5.x 跨到 7.0 是斷崖式的改善，7.4 之後就進入持平區間，7.4 和 8.5 的差距落在量測誤差範圍內。所以還停在 5.6 或 7.0 的網站，切版本是投報率最高的一步；已經在 7.4 以上的，請把注意力移到檢查 2。要說明的是，這是純 PHP 的微基準，不含資料庫查詢與網路傳輸，不能直接換算成 WordPress 的頁面時間——它回答的是「語言本身的執行速度差多少」，不是「你的網站會快幾秒」。

不過升到 8.x 仍然值得做，理由不是速度而是安全更新與外掛相容性：舊版 PHP 早已停止接收官方安全修補，而越來越多外掛在新版本要求最低 PHP 8.0。切換的做法在 cPanel 的 MultiPHP Manager，以網域或子目錄為單位指定。我們主機上實際並存 15 個 PHP 版本（5.3、5.4、5.5、5.6、7.0 到 7.4、8.0 到 8.5），所以可以先把測試站切上去跑一輪，確認佈景與外掛都正常再動正式站。

檢查 2：頁面快取有沒有真的命中

這是整份清單裡效益最集中的一項。頁面快取的作用是把 PHP 算好的 HTML 存起來，下一位訪客直接拿現成的，不必再跑一次佈景、外掛與資料庫。差別不是百分之幾，而是數量級。

問題在於「有裝快取外掛」跟「快取真的在用」是兩回事。常見的失效原因有：後台開了但規則沒套用到首頁、有外掛在每個頁面呼叫 session_start() 或設了 cookie 導致整站被判定為不可快取、佈景把購物車或會員資訊塞進共用區塊、或是快取被設成只在登出狀態生效但你一直登入著在測。

驗證方式是看回應標頭，不要只看外掛後台的綠燈。用無痕視窗（確保未登入）對同一個網址連續請求兩次：

第一次通常是 miss，第二次應該要看到命中的標記。如果第二次還是 miss，代表快取根本沒生效，先把這件事解決再往下走——因為後面的外掛與資料庫優化，在快取命中的頁面上根本不會被執行到。

我們的 Linux 虛擬主機跑在 LiteSpeed Web Server 上，標準配備含 LiteSpeed Cache（WordPress 外掛端一鍵啟用的伺服器端頁面快取，含圖片壓縮與 WebP 轉檔）與 AccelerateWP（在 cPanel 一鍵開啟物件快取、CSS 與 JS 最佳化、圖片延遲載入）。這兩層各自解決不同的問題：頁面快取處理「同一頁被很多人看」，物件快取處理「同一次請求裡重複查同樣的資料」。兩者能開的範圍與其他主機功能整理在虛擬主機能做到什麼。

檢查 3：壓縮與瀏覽器快取——兩行設定，體積少三分之二

HTML、CSS 與 JS 是純文字，壓縮率極高，而這件事只需要伺服器設定，不必動 WordPress 一行程式。我們對自家一篇文章頁做過對照，同一個網址只換 Accept-Encoding 標頭：

對行動網路的訪客來說，少傳三分之二的位元組是實打實的秒數。檢查方式一樣看回應標頭有沒有 content-encoding: br 或 gzip；沒有的話在 .htaccess 用 mod_deflate 或 mod_brotli 指定要壓縮的 MIME 類型即可。同一個檔案順便設定圖片、CSS、JS 的瀏覽器快取期限，回訪的使用者連下載都省了。

WordPress 層的三個檢查：外掛、資料庫、媒體

檢查 4：外掛——用二分法找出吃掉時間的那一支

外掛數量本身不是重點，重點是「每一次請求各自吃掉多少毫秒」。有些外掛只在後台運作，前台零成本；有些外掛會在每一頁都插入一段外部請求，等到對方伺服器回應才繼續，這種一支就能拖垮整站。

不想再多裝一支分析外掛的話，二分法就夠用了：在測試環境把外掛停用一半，量 TTFB；哪一半改善明顯，就在那一半裡再切一半，四到五輪就能定位到單一外掛。十六支外掛用這個方法四輪就找得出來。找到之後的處理順序是：確認是否有輕量替代品、確認功能是否還在用、確認能否只在需要的頁面載入。

檢查 5：資料庫——autoload 與長年殘留

WordPress 每一次請求都會把 wp_options 裡標記為自動載入的資料整批讀進記憶體。這張表用久了會被外掛塞進大量設定，而外掛移除時往往不會清掉自己寫的資料。在 phpMyAdmin 執行下面幾條查詢，先看數字再決定要不要動手（資料表前綴不一定是 wp_，請改成你自己的）：

幾個判讀要點。第一，autoload 這個欄位的值在不同 WordPress 版本並不相同（早期只有 yes 與 no，較新的版本另有 on、off、auto），所以先用 GROUP BY 看實際有哪些值，再決定條件怎麼寫。第二，自動載入的總量實務上控制在 1 MB 以內比較安全，WordPress 內建的「網站健康狀態」在這個數字偏高時也會出現提示。第三，修訂版本可以在 wp-config.php 用 WP_POST_REVISIONS 限制筆數，不必完全關掉。

清理之前一定要先匯出整份資料庫。這幾條查詢只是 SELECT，跑再多次都安全；真正刪資料的動作沒有回頭路，而且錯刪 wp_options 的關鍵設定會讓網站直接白畫面。我們主機端的資料庫是 MySQL 8.4，在 cPanel 就能直接匯出，花的時間遠比事後救援少。

檢查 6：媒體——上傳原尺寸圖是最常見的單一肇因

這一項通常不需要工程師。用手機或相機直接上傳的照片，一張動輒三到六 MB、寬度五千像素以上，而網頁上實際只會顯示八百像素寬。瀏覽器仍然得把整張下載完再縮小，流量與時間全都浪費掉。首頁放十張這種圖，光圖片就是幾十 MB。

處理原則三條：上傳前先把長邊縮到實際顯示尺寸的兩倍以內；優先輸出 WebP 格式（LiteSpeed Cache 的圖片最佳化可以自動轉）；首屏以外的圖片使用延遲載入。做完這三件事再回去量一次整頁時間，通常是整份清單裡改善幅度第二大的一項，僅次於頁面快取。

最後兩個檢查，以及什麼時候才真的該換規格

檢查 7：wp-cron 與心跳機制

WordPress 預設沒有自己的排程器，它把到期的排程工作掛在「下一位訪客的請求」上執行。流量小的網站感覺不到，一旦排程堆積（定期備份、寄信、外掛的資料同步），倒楣的那位訪客就會等上好幾秒。標準做法是在 wp-config.php 關掉這個機制，改由主機端的排程固定間隔觸發：

另一個是心跳機制：編輯文章的畫面每隔十幾秒就會對 admin-ajax.php 送一次請求做自動儲存與鎖定偵測。一個人開三個編輯分頁，後台就會持續有請求在排隊。降低頻率或只在編輯畫面啟用，後台的操作感受會明顯不同。同理，如果網站沒有用到遠端發文，xmlrpc.php 也是常被自動化程式反覆敲的入口，關掉可以順便減少無謂負載。

檢查 8：第三方腳本與外部字型

這一段主機商幫不上忙，但它常常是「TTFB 明明很低、使用者卻覺得很慢」的答案。分析工具、標籤管理器、線上客服小工具、社群像素、外部載入的網頁字型，每一個都是一次額外的網域解析加連線加下載。開啟開發者工具的網路面板，把請求按網域分組排一次，就會看到有多少位元組其實來自別人的伺服器。

能做的三件事：把確定用不到的追蹤碼移除（通常會留下好幾個歷任廠商裝的）；把網頁字型改成自行放在主機上，順便只保留實際用到的字重；剩下的腳本加上延後載入，不要擋住首屏繪製。

瑪尼國際成立於 2004 年，深耕逾 20 年，服務超過 500 家企業。我們處理 WordPress 變慢的案子時，順序跟上面這份清單是一樣的：先量、再把不用花錢的做完、最後才談規格。會這樣排，是因為多數網站在第 2 項到第 6 項之間就找到答案了。需要有人幫忙從主機端一路查到外掛端，或是希望把網頁設計、主機與長期網站代管交給同一組人負責，我們提供的一條龍服務就是為了避免「設計公司說是主機慢、主機商說是程式寫得不好」這種互踢皮球的狀況。

常見問題