WordPress 效能優化

定義

透過系統性的診斷和調校，改善 WordPress 網站的載入速度和回應時間。核心方法是「先診斷再治療」：用 WP-CLI、Lighthouse CLI 等工具精確找到效能瓶頸，而非盲目安裝快取外掛。

診斷分成後端與前端兩條路徑，靠三個數字分流：Root document 回應時間高走後端（WP-CLI），TBT 或 CLS 高走 JavaScript 與版面方向，兩者皆為 0 但 FCP／LCP 慢則走前端載入（Lighthouse CLI）。

關鍵數據點（附來源）

後端路徑

• 啟用 Redis + Nginx 快取 + 停用無用外掛，前台 TTFB 從 4 秒降到 0.67 秒，改善 83%（wp-cli-wordpress-performance-audit）
• Redis 快取命中率 96%（wp-cli-wordpress-performance-audit）
• 42 個外掛中 WPForms Lite 掛了 1,518 個通知接收器但網站根本沒在用它（wp-cli-wordpress-performance-audit）
• 126,830 個通知接收器在每次載入時全部觸發一次，外掛執行佔 67% 載入時間（wp-cli-wordpress-performance-audit）

前端路徑

• 一支 232KB 的 Google Fonts CSS 造成 12.2 秒渲染阻塞，同站伺服器回應僅 80ms（lighthouse-cli-website-speed-diagnosis）
• 字型改成非阻塞載入後，FCP 從 13.8s 降到 1.3s、Performance 55 → 84（同上）
• 前 15 大網路請求中 12 個是字型檔，佈景主題一次載三套字型七種字重（同上）

來源差異：兩組數據來自不同案例。前者的瓶頸完全在後端（外掛與快取），後者的瓶頸完全在前端（字型），同一支診斷工具在兩站會得到相反結論。可移植的是判讀路徑，不是修復清單。

前提與局限性

• WP-CLI 需要 SSH 權限，共享主機使用者可能無法使用
• 優化效果高度依賴站點的外掛組合和流量模式
• 效能改善是持續性工作，每次新增外掛或更新都可能改變效能表現
• 瓶頸會移動：修掉最大的一項之後，下一項就浮上來（本案首屏修好後，瓶頸轉為未轉 WebP 的圖片）
• Lighthouse 是模擬環境的 lab data，不等於真實使用者的 field data；分數提升不等於 Core Web Vitals 達標
• 速度與排名不是因果關係：Core Web Vitals 是同分時的判準（見 [[SEO 結構基礎]]）

衝突標記

無。

關聯概念

• [[WP-CLI 工具]]
• [[快取策略]]
• [[WordPress 生態系統]]
• [[關鍵渲染路徑]]
• [[除錯排查方法論]]
• [[SEO 結構基礎]]
• 方法論：[[WP-CLI 效能診斷流程]]、[[Lighthouse CLI 前端效能診斷流程]]