Cloudways 還能更快？調校完整手冊，榨乾每一滴主機效能！
☰ 目錄 table-of-contents.md
Cloudways 還能更快？資深工程師的終極調校手冊，榨乾每一滴主機效能
結論先講：用了 Cloudways 不代表網站就自動「快到極致」。原廠設定為了相容各種規格機器，傾向保守通用，真正的效能潛力得靠你手動調校才能釋放。最快見效的順序是——先升級 PHP 8.x，再開啟 Varnish 頁面快取與 Redis 物件快取，最後補上 CDN 與資料庫瘦身。本文會把每一步的原理、操作位置與常見陷阱講清楚，讓你照著做就能把網站從「還不錯」推到「快到讓競爭對手懷疑人生」。
很多客戶用了 Cloudways 之後，以為從此高枕無憂，網站速度就此原地起飛。這句話只說對了一半。Cloudways 確實提供了非常棒的基礎設施和極度便利的管理介面，但它就像一輛剛出廠的性能跑車：性能潛力無窮，但原廠設定總是偏向保守。要讓它在賽道上跑出極限速度，你得親自打開引擎蓋，動手調校一番。
最該優先做的三件事是什麼？
如果你只想花最少力氣換最大效益，照這個優先順序做就對了。後面章節會逐項展開細節。
- 升級 PHP 版本到最新穩定版——風險最低、效益最直接。
- 啟用 Varnish 頁面快取——後台一鍵開關，立刻加速未登入訪客的頁面載入。
- 啟用 Redis 物件快取——大幅減輕資料庫負擔，動態頁面與後台特別有感。
這三項都做完，多數網站的回應速度就會有明顯躍升；之後再進場處理 CDN 與資料庫，屬於「錦上添花、長期維護」的層次。
地基打穩：伺服器層級的關鍵設定
網站效能就像蓋大樓，地基沒打穩，上層再怎麼裝潢都沒用。在 Cloudways，伺服器層級的設定就是你的地基，這裡調對了，後面事半功倍。
PHP 版本不是裝飾品，為什麼要立刻升級？
這點我要特別囉嗦。每次接手客戶的 Cloudways 主機，登入後台看到 PHP 版本還停在 7.4，我的心就在淌血。這不只是「舊了點」的問題，而是安全性與效能的巨大鴻溝。
關鍵差異在於：PHP 8.x 導入了 JIT（Just-In-Time）即時編譯器等重大改進。對 WordPress 這種大量執行動態腳本的應用來說，新版本在語言層級就把指令執行得更有效率，效能提升往往是肉眼可見的。更現實的一點是——舊版 PHP 過了官方安全支援週期後就不再收到漏洞修補，繼續用等於把網站暴露在已知風險裡。
這大概是所有優化項目裡 CP 值最高、操作最簡單的一項，動動滑鼠就能完成：
- 前往
Server Management > Settings & Packages - 點擊
Packages頁籤 - 在 PHP 選項，把它升級到最新的穩定版（例如 PHP 8.2 或 8.3）
升級前記得先確認外掛和主題都相容。不過時至今日，還不支援 PHP 8.x 的外掛，你該擔心的恐怕不是相容性，而是那個外掛的作者還在不在維護了。建議的安全做法是：先在測試（staging）環境升級驗證，確認沒有錯誤再套用到正式站，Cloudways 本身就提供 staging 功能，別跳過這一步。
PHP-FPM 與記憶體該怎麼設定？
Cloudways 預設的 PHP-FPM（FastCGI Process Manager）設定相當保守，這是為了確保各種規格的機器都能穩定運行。但對於流量稍大、或有複雜外掛（例如 WooCommerce、LMS 學習系統）的網站，預設值很快就會撞到天花板，導致網站變慢甚至出現 504 Gateway Timeout。
你可以在 Application Management > Application Settings > PHP FPM Settings 找到這些關鍵參數：
| 參數 | 作用 | 調整建議 |
|---|---|---|
max_execution_time | 單一 PHP 腳本的最長執行時間 | 預設 300 秒通常夠用；有複雜匯入匯出、報表生成功能時，可適度調高到 600。 |
memory_limit | 每個 PHP 程序可用的最大記憶體 | WordPress 至少給 256M；用 WooCommerce 或頁面編輯器（Elementor／Bricks）時，512M 更穩妥。 |
別在記憶體上小氣——記憶體不足是很多奇怪問題的根源。對於更進階的調校，你可以透過 SSH 連線到主機，修改 PHP-FPM 的 pool 設定檔（通常在 /etc/php/8.x/fpm/pool.d/ 目錄下）。
裡面的 pm.max_children 參數決定了能同時處理多少個 PHP 請求，是影響網站併發能力的關鍵。它的調整邏輯很單純：每個 PHP 子程序都會吃掉一塊記憶體，子程序數量上限基本上受限於「可用記憶體 ÷ 單一程序平均記憶體用量」。設太低，流量一來請求就排隊；設太高，記憶體被吃乾，伺服器反而會因為 OOM 而崩潰。沒有經驗的話，先從 Cloudways 介面提供的選項著手，觀察實際負載後再微調，不要一次拉滿。
快取的藝術：Varnish + Redis 雙劍合璧
如果伺服器設定是地基，那快取就是大樓的電梯。沒有快取，每個使用者都要自己從一樓慢慢爬到頂樓；有了快取，就能一鍵直達。在 Cloudways，我們擁有 Varnish 和 Redis 這兩大神器，而且它們解決的是不同層級的問題。
Varnish 是什麼？為什麼電商開了卻沒效？
Varnish 是一個 HTTP 反向代理快取，你可以把它想像成一個記憶力超群的門衛。當第一個訪客來訪，WordPress 辛苦產生頁面後，Varnish 會把完整的 HTML 頁面複製一份存在記憶體裡。下一個訪客訪問同一頁面時，Varnish 直接把記憶中的副本丟出去，請求根本不會碰到後端的 PHP，速度當然快到飛起。
在 Cloudways 啟用 Varnish 非常簡單，到 Application Management > Application Settings 一鍵啟用即可。但 Varnish 有個關鍵特性：它對 Cookie 非常敏感。只要請求中帶有特定 Cookie（例如 WordPress 後台登入、WooCommerce 購物車），Varnish 就會認定這是個人化內容而「Bypass」（跳過快取），直接把請求交給後端。
這正是很多電商網站開了 Varnish 卻感覺無效的原因——購物流程天生帶 Cookie，整站都被判定為個人化。解法是透過 Varnish 的快取規則（VCL）精細地告訴它哪些 Cookie 可以忽略，把真正屬於「公開、人人相同」的頁面留在快取裡，這能大幅提升快取命中率（Cache HIT rate）。
Redis 物件快取如何替資料庫減壓？
如果說 Varnish 處理的是「頁面」快取，那 Redis 處理的就是「物件」快取。一個 WordPress 頁面的生成，背後可能包含數十甚至數百次資料庫查詢：取得網站標題、讀取選單項目、抓取文章內容、獲取使用者資訊……這些重複的查詢正是拖慢網站的主因。
Redis 物件快取會把這些查詢結果暫存在高速記憶體中。下次需要同樣的資料時，WordPress 就不用再麻煩資料庫，直接從 Redis 拿，速度是天壤之別。這裡有個重要前提：物件快取主要加速的是「同一次或後續請求中重複出現的查詢」，因此對會員網站後台、或任何資料庫負載較重的動態應用來說，效能提升最為顯著。
啟用步驟：
- 在
Server Management > Settings & Packages安裝 Redis。 - 在 WordPress 後台安裝並啟用「Redis Object Cache」外掛。
- 點擊外掛設定中的「Enable Object Cache」即可。Cloudways 環境下通常會自動抓到設定，非常方便。
Varnish 和 Redis 有什麼不同？需要兩個都開嗎？
需要，而且最好兩個都用，因為它們守的是不同關卡：
- Varnish（頁面快取）：儲存整個渲染好的 HTML，適合給未登入訪客，命中時速度最快、最省後端資源。
- Redis（物件快取）：儲存資料庫查詢結果，加速後台、會員中心等無法整頁快取的動態內容。
Varnish 擋下大量公開流量，Redis 為剩下那些「非快取不可避免」的動態請求減壓——兩者組合起來才是 Cloudways 調校的精髓，務必都啟用。
最後一哩路：內容傳遞與資料庫瘦身
CDN 是標配還是選配？
講到速度，絕對不能忽略使用者端的感受。CDN（Content Delivery Network）的原理是把網站的靜態資源（圖片、CSS、JS 檔案）複製到全球各地的伺服器節點。當使用者瀏覽網站時，會從地理位置離他最近的節點下載資源，大幅減少網路延遲（latency），對目標客群遍佈全球的網站尤其重要。
Cloudways 有自家的 CloudwaysCDN，整合方便、一鍵啟用。這點投資對於使用者體驗以及網站載入體驗的提升，絕對值得，應視為標配而非選配。
肥大的資料庫如何拖慢網站？
隨著網站營運時間拉長，資料庫會像一個沒整理的倉庫，堆滿各種垃圾：成千上萬的文章修訂版本、過期的 Transients 快取、被標為垃圾的留言……這些都會拖慢查詢效能。
我強烈建議安裝像 WP-Optimize 這樣的外掛，設定排程每週自動清理一次資料庫。
尤其要注意 wp_options 這張表裡的 autoload 資料。所謂 autoload，是指被標記為 yes 的選項會在每一次頁面載入時都被自動讀進記憶體。很多外掛和主題會把一堆設定塞進來並設為 yes，導致每個請求都被迫讀取這些可能根本用不到的資料，這對伺服器回應時間（TTFB）是個隱形殺手——尤其是那些已經停用、卻把設定留在表裡的舊外掛。
你可以用以下 SQL 查詢，揪出佔用空間最大的 autoloaded options：
SELECT option_name, LENGTH(option_value) AS option_value_length
FROM wp_options
WHERE autoload = 'yes'
ORDER BY option_value_length DESC
LIMIT 20;看到一些已停用外掛的設定還賴在裡面嗎？這就是你該動手清理的時候了。動手前務必先備份資料庫，確認某筆 option 確實不再使用，再刪除或將其 autoload 改為 no。
小結
Cloudways 是一個潛力無限的平台，但它需要你這位駕駛員去細心調校。把 PHP 升級、Varnish、Redis、CDN 與資料庫瘦身這套組合做完，你的網站效能將會提升到全新層次。別再讓你的跑車只在市區慢行，是時候讓它上高速公路了。
如果你在實作這些調校的過程中遇到任何問題，或希望由專業團隊為網站做一次完整的健康檢查與效能調校，浪花科技隨時準備好提供協助。我們處理過各種複雜的效能瓶頸，能為你量身打造最適合的解決方案。
延伸閱讀
常見問題
用了 Cloudways，WordPress 網站就會自動達到最快速度嗎？
在 Cloudways 上優化 WordPress 效能應該優先做哪三件事？
為什麼應該盡快把 PHP 升級到 8.x？
Varnish 和 Redis 物件快取有什麼不同？需要兩個都開嗎？
為什麼有些電商網站開了 Varnish 卻感覺沒效果？
訂閱免費電子報
把 AI 自動化、企業系統設計與 WordPress / Laravel 開發的真實案例和可直接照做的技巧，整理成電子報寄給你。只寄精選內容、不灌垃圾信，一鍵就能退訂。