點一下「儲存草稿」，轉圈圈轉了十幾秒；切換到「商品」列表，畫面卡在半空；明明前台訪客逛起來順順的，自己登入後台卻像在踩泥巴。這是很多 WordPress 站長共同的困擾——WordPress 後台變慢，往往比前台慢更折磨人，因為前台可以靠快取硬撐，後台卻是你每天要工作的地方。

問題在於，網路上多數教學一上來就丟給你「十七個加速技巧」，從更新 PHP、裝快取外掛到換主機通通列一遍。技巧本身沒錯，但少了一步：你得先知道「慢在哪一段」，才不會把記憶體調到 512M 卻發現真正的瓶頸是某個外掛每次載入都在對外連線。這篇用排查的角度走一遍，先定位、再對症下藥，把 wp-admin 載入緩慢這件事拆成幾個可以逐一驗證的環節。

wp-admin 為什麼會比前台更容易卡

後台慢的根本原因，是 WordPress 管理區基本上吃不到頁面快取。前台的文章頁、商品頁可以被快取外掛轉成靜態 HTML，訪客拿到的是預先生成好的檔案，伺服器幾乎不用即時運算。但後台不行——你每點一下都在新增、修改、查詢資料，WordPress 必須即時跑 PHP、即時查資料庫，把最新狀態算給你看。這也是為什麼很多人會疑惑「前台明明很快，後台卻很慢」。

這代表後台的速度，直接反映伺服器當下的真實運算能力，沒有快取這層保護墊。只要有任何一個環節吃掉過多資源——PHP 記憶體不夠、資料庫查詢太慢、某個外掛在背景偷跑、伺服器 CPU 被鄰居網站佔滿——後台就會第一個感受到。

把後台一次請求的生命週期拆開來看，大致會經過這幾段：瀏覽器送出請求 → 伺服器接手、PHP 開始執行 → WordPress 載入核心、主題與所有啟用中的外掛 → 查詢資料庫拿資料 → 必要時對外發出 HTTP 請求（例如外掛去驗證授權、抓新聞） → 組合畫面回傳。排查的核心邏輯，就是找出這條鏈裡哪一段拖最久。

動手前先量出後台到底有多慢

排查的第一步不是改設定，而是先取得一個客觀的基準數字，否則改完根本不知道有沒有變快。後台躲在登入畫面後面，GTmetrix、PageSpeed Insights 這類外部工具測不到，得改用瀏覽器內建的開發者工具。

以 Chrome 為例，登入後台後在頁面任意處按右鍵選「檢查」，打開開發者工具，切到「Lighthouse」分頁按「Generate Report」，就能針對當前這個後台頁面跑一份效能分析。報告裡幾個數字特別值得看：

• 首位元組回應時間（TTFB）：從送出請求到收到伺服器第一個位元組的時間。TTFB 偏高，通常代表瓶頸在伺服器端——PHP 執行太久、資料庫查詢太慢，或主機資源不足。
• 渲染受阻資源：哪些 JavaScript、CSS 檔在阻擋畫面顯示。後台外掛塞進來的腳本常是元兇。
• 檔案大小與請求數量：後台載入了多少資源、多少次 HTTP 請求。

另一個更實用的角度是切到「Network」分頁，重新整理一次後台頁面，依「Time」欄位排序，直接看哪一個請求耗時最久。如果是 admin-ajax.php 一直冒出來而且每次都很久，那線索就指向 Heartbeat API 或某個外掛的背景輪詢；如果是某支特定的外掛腳本，那就鎖定那個外掛。

量出基準後，後面每改一項就重測一次，用數字確認改動有沒有效，而不是憑感覺。

用 Query Monitor 找出真正吃資源的外掛

當 TTFB 偏高、後台明顯卡頓時，最該優先安裝的診斷工具是 Query Monitor。它是免費外掛，啟用後會在後台工具列加上一個即時面板，把當前這個頁面背後發生的事全部攤開來——這是判斷「到底是哪個外掛在拖」最直接的方法，比一個一個停用外掛去猜快得多。

裝好後點開工具列上的 Query Monitor，幾個分頁是排查重點：

• Queries by Component：依「元件」分組顯示資料庫查詢，可以按耗時排序。哪個外掛、哪段主題程式碼跑了最多查詢、吃掉最多時間，一目了然。如果某個外掛的查詢時間異常突出，它就是首要嫌疑犯。
• Queries：列出每一條 SQL 查詢與各自耗時。出現大量重複查詢，或單條查詢就跑了幾百毫秒，代表有外掛或主題寫得沒效率。
• HTTP API Calls：這一項常被忽略，卻是後台卡頓的隱藏殺手。有些外掛每次載入後台都會對外發 HTTP 請求——驗證授權、檢查更新、抓取遠端新聞。一旦對方伺服器回應慢，你的後台就跟著被卡在那裡空等。

確認某個外掛是瓶頸後，先暫時停用它再重測一次，看後台是否明顯變快。如果是必要功能，可以聯絡外掛作者回報效能問題，或在外掛庫裡找一個更輕量的替代品；如果根本用不到，直接移除。

排查順序上有個務實做法：先停用全部外掛測一次基準，確認後台確實變快，再一個一個重新啟用、每次都重測，這樣能精準定位是單一外掛還是某幾個外掛疊加造成的。為了不影響線上運作，這類測試最好在測試站（staging）上做，不要直接在正式站上反覆開關外掛。

把 PHP 版本與記憶體調到合理水位

外掛排查完之後，接著檢查執行環境的兩個基礎條件：PHP 版本與記憶體限制。這兩項是後台效能的地基，地基不穩，外掛再精簡也快不起來。

PHP 版本影響很大。WordPress 後台幾乎完全靠 PHP 運算，而新版 PHP 在執行速度上的進步相當明顯——舊的 PHP 5.6 跑起來比 PHP 7.4 慢了好幾倍。目前 WordPress 官方建議至少使用 PHP 8.1 以上的版本。要查看自己網站用的是哪一版，到後台的「工具 → 網站狀態 → 資訊」，展開「伺服器」區段就能看到。

升級 PHP 的方式看主機而定。用 cPanel 的主機可在「MultiPHP Manager」勾選網站、選擇新版本即可切換；台灣很多站長用的寶塔面板，則是先在軟體商店安裝想要的 PHP 版本，再到對應網站的設定裡切換 PHP 版本。要提醒的是，升級前先在測試站確認外掛與主題相容，避免正式站直接踩到不相容的舊外掛。

記憶體限制是另一個常被忽略的點。PHP 記憶體不足時，後台會載入緩慢，嚴重時甚至跳出「Allowed memory size exhausted」的錯誤。一樣在「工具 → 網站狀態 → 資訊」的「伺服器」區段可以查到目前的記憶體限制。如果偏低，可以在網站根目錄的 wp-config.php 檔案裡加上一行：

define( 'WP_MEMORY_LIMIT', '256M' );

一般網站建議至少 256M；外掛較多或跑 WooCommerce 的站，拉到 512M 會更從容。要注意的是，部分主機會在伺服器層級限死記憶體上限，這時 wp-config.php 改了也沒用，得透過 cPanel 的 MultiPHP INI 編輯器調整 memory_limit，或直接請主機商協助。

從資料庫層面解掉後台的慢查詢

如果 Query Monitor 顯示時間大量耗在資料庫查詢上，或者網站已經營運好幾年、累積了大量資料，問題很可能出在資料庫本身。後台的列表、儀表板、各種設定讀取都仰賴資料庫，資料表一旦肥大或結構沒優化，每一次後台操作都會被拖慢。這一層的優化往往是 WordPress 後台變慢最容易被跳過、卻最有效的環節。

幾個值得逐一檢查的重點：

精簡 wp_options 的 autoload 資料。WordPress 每次載入頁面（含後台）都會自動把 wp_options 裡標記為 autoload 的資料一次全部讀進來。問題是，許多外掛在移除時不會主動清掉自己寫入的設定，留下大量「孤兒設定」，這些殘留資料每次都被預設載入，白白拖慢速度。可以用 Query Monitor 或資料庫工具檢視 autoload 資料的總量，找出異常龐大的項目清掉。

替 autoload 欄位建立索引。當 wp_options 資料量大時，替 autoload 結構建索引能加快讀取。在 phpMyAdmin 執行下列 SQL 即可：

CREATE INDEX autoload ON wp_options(autoload, option_name);

處理過於肥大的 wp_postmeta。自訂欄位、ACF 等工具對文章中繼資料的操作都會寫進 wp_postmeta，時間一久資料量相當可觀。在確認 meta_key 欄位內沒有長度超過 191 字元的資料前提下，可以調整欄位長度以改善索引效率：

ALTER TABLE wp_postmeta MODIFY meta_key varchar(191);

清掉過期的暫存資料（transients）與多餘的文章修訂版本。外掛會把臨時資料以 transient 形式塞進資料庫，過期後常常賴著不走；WooCommerce 尤其容易累積大量過期 transient。文章修訂版本則是每次儲存都生一份快照，多作者或長文站很快就堆出龐大資料量。可以在 wp-config.php 限制修訂版本數量：

define( 'WP_POST_REVISIONS', 5 );

加上這行後，WordPress 每篇文章只保留最近 5 個修訂版本，較舊的會在下次儲存時清掉。既有的清理可以用 WP-Optimize、WP-Sweep 這類資料庫優化外掛處理過期 transient、垃圾留言與多餘修訂版本。

動資料庫前務必先完整備份。刪錯資料或改錯結構可能讓網站出狀況，備份是唯一的後路。不熟 SQL 的話，優先用外掛的圖形介面操作，風險低很多。

啟用持久物件快取，補上後台缺的那層快取

既然後台吃不到頁面快取，那能幫上忙的是另一種快取——持久物件快取（persistent object cache）。它快取的不是整頁 HTML，而是 WordPress 反覆查詢的資料物件。後台每次載入都要重複問資料庫同樣的問題，物件快取把這些常用資料放進記憶體，下次直接拿，省掉重複查詢，對資料庫負擔重的後台特別有感。

要用持久物件快取，主機得支援 Redis 或 Memcached。如果主機有提供，啟用後再搭配對應的 WordPress 外掛接上即可。對於資料量大、查詢頻繁的網站——例如商品數眾多的 WooCommerce 店——物件快取常常是單一改動裡提升幅度最明顯的一項。

要釐清一個常見誤會：一般的快取外掛（如 WP Super Cache、W3 Total Cache、WP Rocket）主要加速的是前台靜態頁面，預設並不會、也不應該快取後台動態內容。它們對後台的幫助是間接的——把前台運算負擔降下來，等於釋放出更多 CPU 與記憶體給後台用。真正直接加速後台的，是上面說的物件快取，這兩者不衝突，可以並用。

馴服 Heartbeat 與自動儲存這些背景請求

如果 Network 分頁裡看到 admin-ajax.php 頻繁冒出、而且後台在多人協作時特別卡，問題大概出在 Heartbeat API 與自動儲存這兩個背景機制。它們本身是有用的功能，只是預設頻率對資源有限的主機來說太密集。

Heartbeat API 讓瀏覽器與伺服器定期通訊，用來自動儲存草稿、鎖定他人正在編輯的文章、即時推送通知等。預設每 15 到 60 秒就發一次 AJAX 請求，每次都要跑 PHP、可能還觸發資料庫查詢。當多位編輯同時上線，這些請求疊加起來會明顯增加伺服器負擔，共享主機甚至可能因為 CPU 佔用過高而限制你的網站。

解法不是把它整個關掉（那會失去自動儲存與編輯鎖定的保護），而是調慢頻率。可以用 Heartbeat Control 這類外掛，把後台與文章列表頁的心跳頻率拉長，例如改成每 100 到 120 秒一次，而在文章編輯器裡保留較高頻率以確保草稿不丟。

自動儲存是另一個可調的背景程序。WordPress 預設每 60 秒自動儲存一次正在編輯的文章，撰寫長文時這些儲存動作會累積成負擔。在 wp-config.php 加一行可以拉長間隔：

define( 'AUTOSAVE_INTERVAL', 120 );

這會把自動儲存改成每 2 分鐘一次。數字依需求調整，但別調得太長，以免電腦或瀏覽器意外關閉時損失太多內容。

關掉用不到的儀表板小工具與後台累贅

後台首頁那些儀表板小工具，有些每次載入都在對外抓資料，是看似無害卻實際拖慢速度的累贅。「快速草稿」「WordPress 活動及新聞」這類小工具，許多人從來不看，而新聞類的小工具還會去呼叫外部 API 抓內容，外部回應一慢，整個儀表板就跟著等。

最簡單的清法是在後台首頁右上角展開「螢幕選項」，取消勾選用不到的小工具。同樣的「螢幕選項」也能在文章、商品等列表頁調整顯示的欄位數量。

順帶一提列表的筆數。WordPress 預設每頁顯示 20 筆文章、留言或自訂內容類型（包含 WooCommerce 訂單），如果你之前為了少翻頁把數字調高，後台載入這些列表就會變慢。覺得列表頁卡的話，在「螢幕選項」把每頁筆數調回合理範圍會有幫助。

外掛若需要更全面地關閉後台累贅功能，也有像 Disable Bloat 這類外掛能一次處理 WordPress 與 WooCommerce 用不到的功能。原則是：後台只留真正會用到的東西，每多一個常駐功能，就多一份載入成本。

經營電商時 WooCommerce 後台的額外負擔

跑 WooCommerce 的網站，後台還會多扛一些電商特有的負擔，排查時值得單獨看一眼。商品、訂單、客戶資料會隨營運不斷累積，加上 WooCommerce 自身與相關外掛產生的暫存資料，資料庫膨脹的速度比一般部落格快得多，後台的商品列表、訂單管理頁因此特別容易卡。

幾個可以著手的方向：用「螢幕選項」關掉 WooCommerce 在儀表板放的統計小工具與商品頁不需要的欄位；定期清理 WooCommerce 累積的過期 transient 與排程任務殘留；確認商品與訂單列表的每頁筆數沒有被調得過高。資料庫膨脹的部分，同樣回到前面資料庫優化那一節的做法處理，但動手前一定要先完整備份整站，電商資料出錯的代價遠比部落格高。涉及金流的設定本身不影響後台速度，這裡不展開，重點放在資料量與背景任務對後台的拖累。

該優化到什麼程度，又該在什麼時候換主機

把上面的環節都跑過一輪，後台還是慢，那瓶頸大概不在設定，而在主機本身。前面所有調整的本質，都是在「降低需求端的資源消耗」，但這有上限——當網站規模成長到一定程度，需求終究會超過廉價主機能提供的供給。

判斷是否該換主機，可以看幾個訊號：外掛已經精簡、PHP 與記憶體都調到合理水位、資料庫也清過，TTFB 卻依然偏高；後台在流量高峰時段特別慢，平時還好；或者你用的是基礎共享主機，卻跑著流量不低的網站或商品數眾多的 WooCommerce 店。共享主機把資源分給眾多網站，鄰居一忙，你的後台就被連累，這種情況靠自己端的優化很難根治。

要換的話，往 VPS、雲主機或專門的 WordPress 代管方案升級，能拿到更穩定、更充裕的運算資源。挑選時留意三件事：支援最新版 PHP、提供測試站環境讓你安全地測試外掛與主題、有可靠的技術支援能在出狀況時找得到人。

回到最開始的排查邏輯：後台變慢不是「裝個外掛就好」的單點問題，而是一條從瀏覽器、PHP、資料庫到外部請求的完整鏈路。先用開發者工具與 Query Monitor 量出慢在哪一段，再針對那一段下手——是外掛就換掉、是資料庫就清理、是環境就升級——比起照著清單盲目全做，這樣既省時間，也能真正把卡頓的根源解掉。下次後台又開始轉圈圈時，先別急著動設定，打開 Network 分頁看一眼，答案通常就在那裡。