前言
WordPress 站點在未登入時，通常可以靠全頁快取跑得很快；但只要進入登入狀態，很多頁面就會繞過快取，速度立刻掉下來。這件事如果又發生在 WooCommerce、WPML、Redis、WP Rocket、Cloudflare 同時存在的站點上，效能問題通常不是單一原因，而是多個環節一起疊加。
這篇文章整理的是我在實際主機上做過的一輪效能調校，目標不是把整站變成死快取，而是讓登入狀態下的 WordPress 頁面盡量接近秒開。示範站可以先看 iambigd.tw。
先確認慢在哪一段
做 WordPress 效能調校，第一步不是直接換主機，也不是先猜資料庫壞掉，而是先確認慢的是哪一段。
- 第一次開頁是不是特別慢
- 登入後是不是比未登入慢很多
- 第二次開同一頁是否明顯變快
- 是首頁慢、商品頁慢，還是會員頁慢
- TTFB 是否偏高
如果是「第一次慢、第二次快」，通常代表快取有幫上忙，但首訪回源成本還是太高。
我實際先做的三件事
1. 關掉不必要的背景工作
WordPress 預設的 WP-Cron 很常被忽略，但它其實是登入狀態下首訪延遲的常見來源之一。WP-Cron 的特性是「有訪客進站時順便執行」，如果剛好那一瞬間觸發排程，就可能讓頁面多卡幾秒。
我實際做法是在 wp-config.php 加上：
define( 'DISABLE_WP_CRON', true );再改用系統層級的 cron 去執行 WordPress 排程，避免訪客進站時被背景任務拖慢。
2. 把快取分層理解
很多人以為有裝快取外掛就夠了，但 WordPress 實際上有好幾層快取：
- 全頁快取
- Object Cache
- Redis
- 瀏覽器快取
- Cloudflare edge cache
- Fragment cache
未登入狀態可以大量依賴整頁快取，但登入後通常需要把重點放在區塊快取與物件快取上。也就是說，不要試圖讓整頁每次都完全不動，而是把真正會變的內容縮到最小。
3. WooCommerce + WPML 要特別看
WooCommerce 會增加 session、購物車、訂單、商品變體與會員相關查詢；WPML 則會讓語言切換、翻譯資料與查詢 join 更複雜。這兩個一起出現時，登入狀態的頁面很容易比一般 WordPress 站更吃資源。
所以如果站點是 WooCommerce + WPML，調校方向通常不是只看資料庫索引，而是要一起看：
- 背景任務是否干擾首訪
- 快取命中率是否夠高
- 哪些區塊其實可以做 fragment cache
- 哪些查詢其實可以先被 Redis 吃掉
Redis 要用在對的位置
Redis 很有幫助，但它不是頁面快取的萬靈丹。它的價值通常在於減少重複 SQL、重複物件讀取、重複設定查詢，以及一些不太會變的資料。
如果頁面組裝本身太重，Redis 只能減輕負擔，不能完全消除問題。這也是為什麼有些站雖然已經開了 Redis，登入後還是覺得慢。
資料庫先看慢點，不要一開始就猜索引
我一開始也先懷疑是不是 wp_options 太肥，結果實測後發現它不是主因。像下面這種查詢：
SELECT option_name, option_value FROM wp_options WHERE autoload = 'yes';如果筆數不多、查詢很快，通常就可以先排除 wp_options 是主要瓶頸。接著再去看：
wp_postmetawp_icl_translationswp_woocommerce_sessions- 慢查詢 log
- 某些外掛是否每次都打 DB
區塊快取比整頁快取更適合登入狀態
登入後的頁面不一定整頁都要動態。很多內容其實可以拆成局部處理，例如：
- Header
- Footer
- 選單
- 語言切換器
- 商品卡片
真正會變的，只保留：
- 使用者資訊
- 購物車數量
- 會員專屬內容
- 少量個人化區塊
這種做法通常比硬追求整頁秒開更實際，也更符合 WooCommerce + WPML 的使用情境。
這次實測有用到的工具
在整理這次效能優化流程時，我也試了幾個工具與外掛，這些都很適合 WordPress 使用者參考：
- OPcache Manager：用來管理與檢查 OPcache，適合先確認 PHP 快取是否正常。
- Disable Cart Fragments：如果 WooCommerce 的購物車碎片更新拖慢前台，可以先評估是否需要關閉。
- Disable Dashboard for WooCommerce：減少後台 WooCommerce 儀表板相關的額外載入與通知。
- rocket-nginx：讓 Nginx 更好地配合 WP Rocket 的快取規則。
- Index WP MySQL For Speed：用來補齊資料庫索引，對 WooCommerce + WPML 這類站點很值得優先評估。
這些工具不是每個站都一定要全開，但如果你的站點同時有 WooCommerce、WPML、登入狀態與多層快取，這些確實是很實際的排查方向。
實際結果
這次的調整做完後，首訪速度有明顯改善，實測體感大約快了 2 秒左右。最有感的不是第二次開頁，而是第一次載入終於沒那麼卡。
對 WooCommerce + WPML 站點來說，這種改善其實很重要，因為使用者通常就是在第一個頁面決定要不要繼續看下去。首訪順很多，整體體驗就差很多。
結論
WordPress 登入狀態下的效能調校，不是單靠一個快取外掛就能解決。比較有效的方法通常是：
- 把背景工作移出首訪流程
- 讓 Redis 發揮 object cache 的價值
- 降低 WooCommerce 和 WPML 的動態查詢成本
- 把不變的內容改成 fragment caching
- 用合適的工具輔助排查，而不是盲目猜測
如果方向對了，登入後的頁面也可以從「明顯卡頓」改善成「體感順很多」。如果你的目標是接近秒開，這些調校就是很值得優先處理的地方。
