WordPress 外掛目錄裡，能同時衝到 700 萬次啟用、還維持 4.8 顆星評價（來自 2,768 則評論）的外掛沒有幾個，LiteSpeed Cache 就是其中一個。多數同類型的付費快取方案，才做得到讓伺服器直接吐出現成頁面、不用每次都重新跑一遍 PHP 與資料庫查詢的伺服器級快取，LiteSpeed Cache 卻把這一整套功能包進一個完全免費、開源的外掛裡。只是這個免費有個前提，不是裝上去就每個功能都能用。
它同時具備兩種身分：一是伺服器級的頁面快取，二是一整套最佳化工具，涵蓋圖片壓縮、CSS 與 JavaScript 精簡、CDN 整合到資料庫清理。多數對手只做快取這一件事，它把快取和最佳化一次做齊，這也是為什麼它常被拿來跟其他快取外掛比較，卻總是顯得功能特別多。裝了它，網站能加速到什麼程度，關鍵不在外掛本身，而在你的主機搭不搭得上。
先搞懂哪些功能你的主機真的用得到，再往下配置，才不會設定半天卻發現最核心的快取功能根本沒啟動。
LiteSpeed Cache 是什麼？免費的伺服器級快取與全站最佳化外掛
LiteSpeed Cache，官方全名是 LiteSpeed Cache for WordPress，簡稱 LSCWP，是一款免費開源的全站加速外掛。它同時做兩件事：一是提供伺服器級的頁面快取，二是內建一整套最佳化工具，包括圖片壓縮、CSS 與 JavaScript 精簡、CDN 整合，還有資料庫清理。多數外掛只挑一種做到深，LSCWP 把兩種都做進同一套設定介面。
要用它，網站至少要跑在 WordPress 6.0 以上、PHP 7.4 以上的環境。目前的穩定版本是 7.9.1。這些系統需求會隨版本演進調整，安裝前先確認自己的主機環境對得上，才不會裝了卻卡在相容性問題。
在 WordPress 官方外掛目錄裡，LSCWP 累積超過 700 萬次啟用，評價落在 4.8 分（滿分 5 分），評論數來到 2,768 則，是目錄裡裝機量最高的快取類外掛之一。只是免費跟完整是兩回事，它真正能發揮到什麼程度，取決於主機類型搭不搭得上。
主機類型決定這款外掛的功能完整度
外掛把功能明確分成兩組：一般功能，任何主機都能用；LiteSpeed 專屬功能，得搭配特定的伺服器元件才會生效。當中最核心的伺服器級頁面快取，恰好就落在後面那一組。搞懂這條界線，才知道自己裝了這個外掛之後，真正能拿到多少加速效果，也才不會對著一堆設定選項卻怎麼點都沒反應。
一般功能不限主機類型都能用
一般功能不挑主機，不管網站架在 Apache、Nginx 還是 LiteSpeed 上都能開。這一組涵蓋的範圍其實已經很廣：免費的 QUIC.cloud CDN 快取、物件快取（支援 Memcached、LSMCD、Redis）、圖片最佳化（有損與無損兩種模式）、CSS/JS/HTML 最小化與合併、自動產生關鍵 CSS、圖片與 iframe 延遲載入、回應式圖片佔位符、多組 CDN 支援、CSS 異步載入、JS 延遲與延緩載入、瀏覽器快取、資料庫清理與最佳化，以及含核心網頁指標的頁面速度最佳化。
除此之外還有幾項比較偏維運面的：OPcache 支援、伺服器支援時的 HTTP/2 Push、DNS 預先查詢、Cloudflare API 串接、單站與多站台支援、設定值匯出入、AVIF 與 WebP 格式支援，還有 Heartbeat 心跳頻率控制。換句話說，就算你的主機是最普通的共享虛擬主機，光靠這一組功能也能做出圖片變小、程式碼變精簡、資料庫變乾淨的實質改善，只是拿不到最關鍵的整頁快取。
LiteSpeed 專屬功能限定主機才能用
LiteSpeed 專屬功能的門檻高一些，得搭配以下其中一種環境才能用：具備 LSCache 模組的 LiteSpeed Web Server（版本 5.0.10 以上）、OpenLiteSpeed（1.4.17 以上）、LiteSpeed WebADC（2.0 以上），或是申辦 QUIC.cloud CDN 服務。這一組功能圍繞著自動頁面快取展開，也是整支外掛最核心的加速能力，包括依事件自動清除相關頁面、給已登入使用者的私有快取、WordPress REST API 呼叫快取、桌面與行動裝置分開快取、排程清除指定網址、WooCommerce 與 bbPress 支援、WordPress CLI 指令、快取整合 API、依網址、分類、標籤、Cookie 或使用者代理排除快取、支援 SEO 網站地圖的智慧預先爬取蟲、HTTP/2 與 HTTP/3（QUIC）連線協定，還有邊緣包含（ESI）。ESI 這一項 OpenLiteSpeed 不支援，得用到商用版的 LiteSpeed 產品才有。
快取功能一定要靠伺服器才能跑，原理很單純，外掛本身只是溝通橋樑，真正負責存快取、判斷什麼時候該清除的是伺服器端的快取引擎，外掛的角色是把 WordPress 產生的頁面遞給這個引擎，自己不負責儲存。這也是為什麼裝了 LSCWP 卻發現快取功能怎麼設都沒用，多半是主機本身不具備這個條件，不是設定錯了。
沒有 LiteSpeed 主機也不是完全無解。官方提供的 QUIC.cloud CDN 服務，讓跑在 Nginx 或 Apache 上的網站，也能間接體驗到接近伺服器級快取的加速效果。這一點值得先記住，若你的主機是 LiteSpeed 架構，接下來每一項快取功能幾乎都能直接開；若不是，快取這塊要靠 QUIC.cloud 補，其他最佳化功能則完全不受影響。
外掛安裝、啟用與 Domain Key 綁定
確定自己的主機屬於哪一種之後，接下來就是實際動手裝。外掛安裝完，預設所有功能都是關閉狀態，得自己一項項打開。好消息是只要打開最基本的頁面快取，多數網站就能感受到明顯的加速效果，不必一開始就把每個進階選項都摸過一輪。
一般主機與 LiteSpeed 主機安裝後啟用的分頁不同
從外掛市集搜尋 LiteSpeed Cache 安裝並啟用之後，接下來該點哪個分頁，依主機類型分成兩條路。
沒有 LiteSpeed 主機的話，快取功能用不到，直接進「LiteSpeed Cache」底下的「Page Optimization」分頁，把想要的最佳化功能逐一開啟就好，這個路徑完全不牽涉快取。
有 LiteSpeed 主機的話，第一步是先確認伺服器端已經裝好對應元件，可能是含 LSCache 模組的 LiteSpeed Web Server Enterprise、含快取模組的 OpenLiteSpeed（免費），或者已經申辦 QUIC.cloud CDN。裝好外掛之後，先進「Cache」分頁把「Enable LiteSpeed Cache」打開，這是啟動整套快取機制的總開關，開完再依需求逐一打開其他分頁的功能。
Domain Key 綁定是串接 QUIC.cloud 雲端服務的前提
外掛裡有一批功能靠雲端運算，圖片最佳化、關鍵 CSS 產生、部分 CDN 服務都架在 QUIC.cloud 這個雲端平台上，要用到它們，得先在「General」分頁完成 QUIC.cloud 服務啟用，這個步驟綁定的識別碼就是 Domain Key。
這一步很容易被跳過，因為介面上看起來像選填，實際上沒完成綁定，圖片優化按下去就是沒反應，關鍵 CSS 也做不出來。值得說明的是，完成這個啟用動作不代表一定要另外去 QUIC.cloud 官網申請帳號，外掛內建的 General 分頁就能把服務啟用做完，帳號是進階操作或查看用量時才需要。
Presets 套用預先調校好的設定組合
外掛內建 LSCache Profiles（也叫 Presets），是一組事先調校好的設定組合，專為最佳化任何使用 LiteSpeed Cache 的網站設計。官方建議一般網站選「Basic」或「Advanced」其中一種，這兩組不太需要額外微調就能用。
對不想逐項摸索每個開關的人，這是求有再求好的捷徑，套用某一組 Preset，外掛會先把目前的設定備份起來，再替換成新的組合，不會憑空覆蓋掉你原本改過的東西。套用的操作在「Toolbox」分頁完成，即使套錯了，也能靠備份切回原本的設定。
頁面快取讓伺服器直接吐出現成的靜態頁面
主機條件確認清楚、外掛也裝好之後，真正決定網站快不快的，是頁面快取這個核心機制。它做的事情簡單說，是把 WordPress 動態產生的 HTML 頁面存成一份靜態快照，下次有人造訪同一頁時，直接把這份現成的快照送出去，不用再重新跑一次資料庫查詢跟 PHP 運算。
管理這份快取的是伺服器本身的快取模組，實際的快取檔案存放在伺服器端，不在 WordPress 的檔案結構裡。這也是它比一般 PHP 層級的快取外掛快的原因，一般快取外掛還是得靠 WordPress 載入、跑一遍 PHP 才能把快取頁面吐出來，伺服器級快取直接在伺服器這一層攔截請求，連 PHP 都不用啟動。
快取沒命中要先產生頁面，命中就直接送出
訪客第一次造訪某個頁面時，伺服器的快取物件裡還沒有這一頁，這時會回傳「快取未命中」的狀態。WordPress 得照正常流程動態產生 HTML，這位訪客得等這個產生過程跑完才看得到頁面，伺服器把頁面送出去的同時，也順手把這份靜態頁面存成快取物件。
之後不管誰再造訪同一頁，伺服器在快取物件裡找得到，會回傳「快取命中」，直接把存好的靜態頁面送出去，完全不用再等 WordPress 重新產生。這個狀態會一直維持，直到快取物件過期為止。第一位訪客等於先幫後面所有人跑過一次，後面的人享受的是幾乎瞬間載入的體驗。
已登入會員也有專屬快取，公開版與私有版分開存
一般的快取外掛遇到會員登入的內容常常整頁跳過快取，因為每個登入者看到的內容可能不一樣，像是帳戶資訊、購物車、專屬折扣，直接套用同一份公用快取會出錯。LSCWP 的做法是額外做一種私有快取，公開快取跟私有快取都是伺服器級頁面快取的功能，只是後者是替個別登入者各自保留一份對應的快取內容。
這代表已登入的會員，一樣能享受到接近訪客的加速效果，不必因為登入身分就被排除在快取機制之外。這項功能屬於 LiteSpeed 專屬功能，一般主機用不到。
桌面與行動裝置分開儲存的快取版本
如果網站的桌機版跟手機版顯示的內容不完全一樣，例如手機版精簡了某些區塊、換了不同的排版邏輯，單一份快取就會出問題，手機使用者可能看到桌機版快取，或反過來。
Cache Mobile 這項設定解決的正是這個問題，讓桌面與行動裝置的瀏覽版本各自存一份快取，兩邊互不干擾。對響應式設計、桌機手機版位其實一致的網站來說，這項設定的差別感受不大，但只要網站有明顯的裝置差異化內容，開啟它能避免使用者看錯版本的困擾。
文章發布或更新時自動觸發的智慧清除
編輯或發布一篇文章之後，如果快取沒有跟著更新，訪客看到的可能還是舊內容。LSCWP 處理這件事的方式不是只清掉被編輯的那一頁，而是連帶清除跟它有關的頁面，像是首頁、分類彙整頁、標籤彙整頁跟日期彙整頁，因為這些頁面上通常都會出現這篇文章的摘要或連結，只清單一頁反而會留下不一致的殘影。
也有需要手動清除單一頁面的時候，比如只是想強制重新整理某一頁的快取。操作方式是先登入 WordPress，在前台瀏覽該頁面，把滑鼠移到黑色管理列上的 LiteSpeed Cache 圖示（一個鑽石加閃電的符號），點選「Purge this page – LSCache」，這一頁就會被清除快取並重新載入。
依網址、分類或使用者代理排除快取的規則
有些頁面天生不該被快取，購物車、結帳頁面是最典型的例子，這些頁面的內容因人而異，快取住反而會讓使用者看到別人的購物車或錯誤的結帳資訊。外掛已經考慮到這一點，預設就會自動排除 WooCommerce 的我的帳戶、結帳與購物車頁面，不需要自己動手設定。
如果站上還有其他頁面需要排除，可以到「LiteSpeed Cache」底下的「Cache」分頁，找到「Excludes」子分頁，把網址加進「Do Not Cache URIs」清單。LiteSpeed 專屬功能裡還支援更細緻的排除條件，可以依分類、標籤、Cookie 或使用者代理來決定哪些內容不進快取，適合有特殊動態內容區塊的網站。
物件快取與瀏覽器快取各自加速資料庫查詢與靜態檔案
頁面快取處理的是整頁 HTML，接下來這兩層加速的對象不一樣。物件快取管的是資料庫查詢結果，瀏覽器快取管的是靜態檔案在訪客端的留存，兩者都屬於一般功能，只要主機環境有支援就能用，不需要 LiteSpeed 伺服器。
Redis 和 Memcached 兩種物件快取方式的差異
物件快取做的事情是把資料庫查詢的結果暫存起來，下次同樣的查詢再發生時，直接從暫存拿結果，不用再重新查一次資料庫。這對後台操作跟一些動態查詢特別有感，因為 WordPress 後台本身就會頻繁對資料庫發出重複的查詢請求。
這個功能靠的是外部的物件快取服務，Memcached 或 Redis 二選一，決定要用哪一種、以及安裝設定服務本身，是伺服器管理員的工作，外掛端只負責提供設定介面把外掛跟已經裝好的服務串接起來，不負責安裝服務本身。換句話說，如果主機沒有先裝好 Redis 或 Memcached，光在外掛這邊打開開關是沒用的，得先確認主機有沒有提供這項服務。
瀏覽器快取的有效期限設定
瀏覽器快取管的是靜態檔案，像圖片、CSS、JS 這類內容，在使用者第一次造訪時被存到自己裝置的本機儲存空間。之後這位使用者再回到同一個網站，這些靜態檔案會直接從本機讀取，不用重新向伺服器下載，直到瀏覽器快取到期為止。
這一層加速跟前面兩層不太一樣，受益的不是所有訪客，而是回訪的同一位使用者。對常常回來逛的老讀者、或是同一使用者在站內多頁瀏覽的情境，瀏覽器快取能明顯減少重複下載的流量與載入時間。設定的重點在於有效期限拉多長，設太短等於沒開，設太長又可能讓使用者在網站更新後看到舊版的靜態檔案。
影像最佳化透過 QUIC.cloud 雲端服務壓縮與轉檔
外掛的圖片最佳化不是在自己的主機上運算，而是把圖片送到 QUIC.cloud 雲端壓縮，處理完再拉回來，這樣才不會佔用主機本身的運算資源。要提醒的是，圖片不會自動被最佳化，除非把「Image Optimization」分頁裡的「Auto Request Cron」設定打開，否則得手動送出優化請求，才會真正進到這套流程。
標準佇列免費無上限，進階佇列快但每月有額度限制
送出優化請求後，圖片會排進兩種佇列的其中一種。標準佇列完全免費，用量沒有上限，代價是處理速度比較慢。進階佇列處理速度快，但只有每個月固定的免費額度，額度用完之後想繼續用，得另外購買額度，購買這件事需要一個 QUIC.cloud 帳號才能操作。
有一點要特別留意，圖片最佳化跟 WebP 產生透過標準佇列就能免費使用，但 AVIF 格式只能透過進階佇列處理，代表要拿到 AVIF 版本的圖片，勢必得動用到有額度限制的那條路徑，標準佇列辦不到。
有損與無損兩種壓縮模式的取捨
JPG 跟 PNG 圖片在最佳化時，預設用的是有損壓縮，這種模式壓縮率高，但會犧牲一點畫質。如果對畫質比較講究，可以把選項切換成無損壓縮，能維持較高的品質，代價是壓縮後的檔案會比有損壓縮大一些。
另外一項會被順手處理掉的，是圖片裡的 EXIF 或 XMP 資料，這些資訊記錄拍攝時用的相機設備等細節，因為佔用額外空間，最佳化流程預設就會把這些資料一併移除。對多數網站來說，這些中繼資料留著也沒有實際用途，移除掉純粹是省空間。
WebP 與 AVIF 格式的自動轉換與替換
開啟「Next-Gen Image Format」這個設定之後，之後的每一次圖片最佳化請求，都會額外產生 WebP 版本或 AVIF 版本的圖片。往後有支援這些格式的瀏覽器造訪網站時，伺服器會把 WebP 或 AVIF 版本換上去取代原本的 JPG 或 PNG；遇到不支援的舊版瀏覽器，則會照樣送出原始格式，不會讓頁面顯示壞掉的圖片。
新一代格式的效果有多明顯，官方給過一組實測數字：一張原始 JPG 檔案大小 9.1K，經過一般優化後降到 8.6K，再轉成 WebP 格式後只剩 6.0K，換算下來比優化後的 JPG 又少了約 30% 的檔案大小。對圖片量大的網站，這個差距累積起來對載入速度的影響相當可觀。
原始檔案備份讓優化後的圖片仍可還原
最佳化圖片是有回頭路的。系統預設會留一份原始檔案備份，如果對優化後的結果不滿意，可以透過「Use Original Files」這個連結，把圖片切回原始版本，之後想再切回優化過的版本也可以，這個操作沒有次數限制，只要兩個版本都還存在伺服器上，就能隨時切換。
真正不可逆的動作是主動刪除備份，一旦執行「Remove Original Image Backups」，官方特別標註這個動作無法復原，備份刪除之後就再也拿不回優化前的原始檔案。對還在測試優化效果的人來說，這個備份機制值得留意，不急著刪備份，才有反悔的空間。
頁面最佳化精簡並延後載入 CSS 與 JavaScript
前面談的是快取，讓頁面不用每次重算；頁面最佳化做的是另一個層次的加速，讓頁面本身變得更輕量。這個分頁下的設定官方特別提醒，正式上線前要先徹底測試，改動之後記得執行「Purge All」清除全部快取。這個分頁裡的每一項設定預設都是關閉的，得一項項主動打開，不會擅自幫你套用。
CSS、JS 與 HTML 檔案的最小化與合併
最小化做的事情是把檔案裡多餘的空白字元、換行字元跟註解全部去掉，讓檔案體積變小，但不改動程式本身的功能。合併則是把多個獨立的 CSS 或 JS 檔案併成一個檔案，減少瀏覽器要發出的請求數量。
這兩項設定改動後，務必先在正式站以外的環境測試過，有些主題或外掛的程式碼寫法比較特殊，合併或最小化之後可能造成版面跑掉。官方也提到一個排查訊號，如果啟用 CSS Combine 或 JS Combine 之後硬碟空間快速增加，很可能是主題在 CSS 或 JS 檔案裡插入了隨機字串，導致每次合併都產生新檔案卻沒清掉舊的，遇到這種情況要回頭檢查主題本身的寫法。
關鍵 CSS 與未使用 CSS 的自動產生
「Load CSS Asynchronously」這項設定打開後，CSS 跟 HTML 會同時載入，而不是等 CSS 全部下載完才開始渲染頁面。為了避免頁面在 CSS 還沒載入完的空檔跑版，外掛會自動產生關鍵 CSS，也就是首屏內容正常顯示所需要的那一小部分樣式，直接內嵌進 HTML 裡先套用。
這項功能得透過 QUIC.cloud 的頁面最佳化服務處理，用到雲端運算，超過免費額度需要額外付費。另外還有一個相關功能叫未使用 CSS，通常搭配 CSS Combine 一起用，作用是替網站的每一個頁面各自產生一份只包含該頁實際用得到的樣式的精簡 CSS 檔案，因為不同頁面用到的樣式本來就不完全一樣，這樣處理能進一步縮減每頁載入的 CSS 體積。
JavaScript 延遲載入與延緩載入的差異
這兩種模式都會讓 JavaScript 的執行往後延，等 HTML 載入完才開始處理，差別在於延到什麼時候。延遲是等 HTML 載入完就馬上執行，這是延遲載入 JS 的標準做法。延緩更晚，得等偵測到使用者有實際互動，比如按了一個鍵或移動了滑鼠，才會開始執行。
延緩模式對速度分數的改善效果更明顯，因為它等於把 JS 完全排除在頁面速度分數的計算範圍之外，計算分數的那個時間點，使用者可能根本還沒動作。但這也代表使用者體驗上有取捨，某些依賴 JS 才能運作的互動功能，在使用者還沒有動作前可能暫時沒反應。官方也建議先在自己的網站測試過延緩模式的實際效果，再決定要不要正式啟用。
圖片與 iframe 延遲載入及可視區域圖片的例外
延遲載入圖片跟 iframe 的邏輯很直覺，只有捲動到看得見的範圍時才真正載入，其餘部分等使用者實際捲到那裡才會開始下載。這樣能避免頁面一開始就把所有圖片全部載入，拖慢首次載入的速度。
問題是，如果一開始就在畫面範圍內、使用者不用捲動就看得到的圖片，也被排進延遲載入的隊伍，反而會讓這些理應優先顯示的圖片被延誤。可視區域圖片這項服務就是用來解決這個矛盾，QUIC.cloud 會針對送出去的每篇文章網址，偵測哪些圖片在頁面載入時會出現在可視範圍內，把這些圖片從延遲載入名單裡排除，反而給予優先權，成為頁面生命週期裡最早載入的素材之一。使用這項服務的前提是「Lazy Load Images」要先打開，兩者是搭配著用的關係。
CDN 整合把靜態資源與整站快取送到全球節點
外掛支援串接多組 CDN，這是一般功能，任何主機都能設定。但官方自家的 QUIC.cloud CDN 比較特別，跟多數只快取靜態檔案的 CDN 不一樣，它連動態產生的 HTML 頁面本身都能在 CDN 節點上快取，也是唯一能讓非 LiteSpeed 主機間接體驗到伺服器級整站快取效果的途徑，呼應前面提過的替代路徑。
QUIC.cloud 與其他 CDN 服務的接法
外掛的「Multiple CDN Support」屬於一般功能，能接上市面上大部分常見的 CDN 服務，這條路徑不牽涉 LiteSpeed 的快取技術，單純是把靜態資源分散到全球節點加速傳輸。
QUIC.cloud CDN 是另一條路。多數 CDN 只處理靜態內容，像圖片、CSS、JavaScript 這類檔案，QUIC.cloud CDN 卻是直接用 LiteSpeed 技術把整個網站，包括動態產生的 HTML 頁面，都快取進 CDN 節點裡。原本只有 LiteSpeed 主機用戶才享受得到的快取體驗，透過 QUIC.cloud，跑在 Nginx 或 Apache 上的網站也能拿到接近完整的效益。
CDN 額度隨主機類型不同的分級
QUIC.cloud 的服務是用額度計費的，每個服務項目每個月都有固定的免費額度可以用。這裡有個關鍵差異，如果網站主機本身就是 LiteSpeed 架構，拿到的免費額度會比用 Apache 或 Nginx 的主機更多，這也再次呼應前面提過的核心前提，主機類型決定你能免費用到多少。
CDN 這一項服務的計費方式又跟其他服務不太一樣，不是用請求次數計算，而是用頻寬計算，每個月會有一定額度的免費頻寬可以用於 CDN 傳輸，實際能拿到多少免費頻寬，則依網域所在的等級而定。
資料庫清理與最佳化的修訂版本上限設定
這項功能自 LSCWP 1.2.1 版起就內建在外掛裡，操作介面會用勾號跟紅叉標記出每個清理項目目前的狀態，一眼就能看出哪些已經清過、哪些還沒動。資料庫用久了會累積不少歷史包袱，定期清理能讓查詢效率維持在比較好的狀態。
一鍵清理涵蓋修訂版本等九個項目
「Clean All」這個一鍵清理功能，一次會清掉九個項目：文章修訂版本（只保留目前發佈的版本，清掉之後會失去回復舊版內容的能力）、已刪除文章留下的孤立中繼資料、自動儲存的草稿、垃圾桶裡的文章與頁面、被標記為垃圾的留言、垃圾桶裡的留言、引用通知與 Pingback、已過期的暫存資料，以及全部的暫存資料。
按下去之前，最該有心理準備的是文章修訂版本這一項，官方明確說明清掉之後就不能再回頭復原那些舊版內容。如果平常有回頭比對文章舊版的習慣，先確認清理範圍再動手比較保險。另外要提醒的是，Clean All 執行的是以上這九個項目，並不包含資料表最佳化，那是另外一個獨立的按鈕。
資料表最佳化不是刪資料，而是重新整理儲存結構
Optimize Tables 是跟 Clean All 分開的另一個按鈕，作用不是刪除資料，而是重新整理資料表的實體儲存結構跟索引，效果類似 phpMyAdmin 裡本來就有的資料表最佳化功能，一般得透過命令列或 phpMyAdmin 才能執行的動作，外掛把它整合進同一個介面裡，不用另外跳出去操作。
除了一鍵清理跟資料表最佳化，外掛也能自訂修訂版本要保留幾份，不是只能全刪或全留。Revisions Max Number 用來指定每篇文章最多留幾個舊版本，例如設成 1，代表每篇文章都留一個舊版本；Revisions Max Age 則是用天數畫一條線，指定天數內的修訂版本一律不清，例如設成 30，代表最近 30 天內產生的版本都會被保留下來。這種折衷做法，讓需要回顧近期編輯歷程的人，不用完全放棄修訂版本功能，也能享受到清理帶來的資料庫瘦身效果。
智慧預先爬取讓快取隨時保持有效
快取有個天生的矛盾，快取物件過期之後，下一位造訪那個頁面的訪客會撞上快取未命中，得等 WordPress 重新產生頁面，體驗到的其實是沒開快取時的速度。爬取蟲這個功能解決的正是這個空窗期，它會主動在網站裡走一輪，把已經過期或還沒被存進快取的頁面事先造訪一遍，等真正的訪客上門時，快取早就備妥，幾乎不會遇到需要等待的第一次慢載入。
這項功能不是裝好外掛就自動運作，得先由伺服器管理員在伺服器層級或虛擬主機層級開啟，之後才輪到在「LiteSpeed Cache」底下的「Crawler」分頁，把「General Settings」裡的 Crawler 設為開啟。它也支援依照 SEO 網站地圖規劃爬取路徑，確保涵蓋到真正該預熱的頁面，而不是亂槍打鳥。
爬取蟲還能模擬不同的訪問角色，預設是以未登入的訪客身分執行，如果站上有登入後才看得到的內容，也能設定額外模擬登入會員的瀏覽視角，預先把這些頁面的快取也準備好。基於安全考量，從第 7 版開始，爬取蟲不能模擬編輯者以上權限的角色，而且僅限於伺服器本機的 IP 執行，避免被濫用來冒充高權限使用者存取後台。
官方也老實提醒，爬取本身是相對耗費資源的過程，不是所有主機都允許使用這項功能。如果網站架在資源有限的共享主機上，開啟爬取蟲前最好先確認主機商是否允許，避免因為爬取程序佔用過多資源而影響網站本身的正常運作，甚至被主機商警告或限制。
心跳控制與匯出入等維運工具
外掛的工具箱裡還收了幾項比較偏維運面的功能，多數是一次設定好之後就不太需要回頭再調整的項目。工具箱裡也附了環境報告，需要聯繫官方技術支援時，可以用這份報告提供的編號協助對方快速掌握你的環境狀況。
心跳控制降低後台與編輯畫面的資源消耗
WordPress 內建的 Heartbeat API，會定時透過 AJAX 請求跟伺服器保持聯繫，用來支援自動儲存、文章鎖定提醒、外掛通知這類即時功能。它的預設頻率不低，如果同時有多人在後台操作，或是網站本身資源有限，頻繁的心跳請求會實際佔用掉伺服器的處理資源。
心跳控制這項功能屬於一般功能，任何主機都能用，不限 LiteSpeed。它能分別針對前台、後台、文章編輯畫面三種不同情境，各自設定心跳頻率，甚至個別完全關閉某個情境下的心跳請求。對資源有限的主機、或後台同時上線人數多的網站，適度調降心跳頻率能實際減輕伺服器負擔，不需要犧牲太多即時功能的體驗。
換主機或搬家時，設定值匯出入就能派上用場
設定值匯出入同樣屬於一般功能。它能把目前調校好的一整組外掛設定匯出成一個檔案，換主機、搬家，或是要幫旗下其他網站套用同一套設定時，直接把檔案匯入就好，不用把每一項設定重新點過一遍。
這個功能特別適合管理多個網站的情境，把一套已經調校穩定的設定當成範本，套用到新架的網站上，能省下不少重複設定的時間，也能確保多個網站維持一致的最佳化水準。
外掛完全免費、只有進階雲端服務才計費
外掛本體的定位很清楚，LSCWP 會永遠保持免費且開源，這是官方明確的承諾，不是限時免費或閹割版試用。真正牽涉到費用的地方分成兩塊，而且都不是外掛本身的錢。
第一塊是伺服器端。快取功能得靠 LiteSpeed 伺服器才能運作，部分 LiteSpeed 伺服器版本本身是收費產品，這筆費用付給的是伺服器供應商，跟外掛沒有關係，外掛永遠不用另外付費。第二塊是 QUIC.cloud 提供的進階雲端服務，CDN 服務、圖片最佳化、關鍵 CSS 產生、低品質圖片佔位符這幾項，超過每個月的免費使用額度之後才需要付費，實際的收費標準跟各項服務的免費額度，可以在 QUIC.cloud 的帳號後台查看。
再次呼應前面提過的規則，網站主機如果本身就是 LiteSpeed 架構，拿到的免費額度會比用 Apache 或 Nginx 的主機更多。換句話說，主機類型不只決定了能不能用到最核心的頁面快取，連帶也影響到每個月能免費用多少雲端運算資源，這也是為什麼一開始就先確認主機類型，會是用好這支外掛最值得花時間的第一步。
回頭看，一支外掛能同時做到免費、開源又功能齊全並不常見，LiteSpeed Cache 做到這件事的方式，其實就是老實把需要伺服器配合、跟任何主機都能用的功能分成兩組攤開來講，不刻意模糊界線。真正決定這支外掛能替網站爭取多少速度的，從來不是把每個選項都打開，而是先弄懂自己的主機屬於哪一種，再把對應的功能一項項調到位。剩下的交給時間去驗證，速度這種事，最終還是得看實際的載入數字說話。