※本記事には広告・アフィリエイトリンクが含まれています。
LiteSpeed Cacheは高機能ですが、チェックを全部ONにすれば速くなるプラグインではありません。CSS/JS最適化、画像最適化、Object Cache、CDN、ページキャッシュが1つの画面に並ぶため、既存のCloudflareやサーバーキャッシュと役割が重複しやすいからです。全体の重複整理は138のキャッシュ設計を先に確認してください。
LiteSpeed Cacheで最初に確認すること
| 環境 | ページキャッシュ | 最適化機能 |
|---|---|---|
| LiteSpeed Enterprise + LSCache | 利用可 | 利用可 |
| OpenLiteSpeed + cache module | 利用可 | 利用可 |
| Apache/nginx | 原則LSCacheページキャッシュ不可 | CSS/JS等は利用可 |
| Apache/nginx + QUIC.cloud | CDN側構成で利用可能 | 利用可 |
WordPress.orgの公式プラグイン説明でも、LiteSpeedサーバーなしではキャッシュ機能が利用できず、最適化機能だけを使えると整理されています。まず自分のホスティングのWebサーバーを確認してください。
2026年9月時点ではLiteSpeed Cache 7.9.1以降を使う
LiteSpeedは2026年9月、特定のQUIC.cloud構成で影響するSSRF（CVE-2026-84761）と、ESI＋コメント等の条件で影響するXSS（CVE-2026-76579）をv7.9.1で修正しています。LiteSpeed公式はいずれも7.9.1以上への更新を案内しているため、速度設定より先にプラグイン更新とバックアップを確認します。
Cloudflareと併用するときの原則
APOの有無を確認し、HTMLを両方で持つならPurge経路を決める
Cloudflareを使うだけで必ずHTMLが二重キャッシュになるわけではありません。通常のCloudflare利用で画像・CSS・JSなど静的資産をedge cacheし、HTMLはLiteSpeed側だけで持つ構成なら役割は分かれます。
注意が必要なのはAPOやCache RulesでHTMLまでCloudflareへ保存する場合です。この時はLiteSpeedとCloudflareの両方がHTMLを保持するため、WordPress更新時にどちらを、どの順でPurgeするかを決めます。LiteSpeed CacheのCloudflare連携でPurgeを同期する場合も、片方だけ古いHTMLが残らないか実際に確認してください。
LiteSpeed公式のThird Party資料では、CloudflareはAPOを使っていなければ互換と整理され、APO利用時はduplicate caching / optimizationが注意点です。静的ファイルだけをCloudflareへ任せる構成と、HTMLまでedge cacheする構成を分けて考えます。
CloudflareとLSCacheの担当表を作る
| 役割 | LiteSpeed側 | Cloudflare側 |
|---|---|---|
| Origin page cache | LSCache | 通常は担当しない/設計次第 |
| Edge cache | なし/QUIC.cloud | Cloudflare cache/APO |
| Browser cache | 設定可 | Header上書きに注意 |
| Purge | WordPress更新と連動 | API連携で同期可能 |
| 画像/CDN | QUIC.cloud等 | Cloudflare Image/Cache機能 |
この表を自分のサイト用に埋めると、二重キャッシュの原因を見つけやすくなります。特にHTMLをLiteSpeedとCloudflareの両方で長時間保持する場合、更新時に片方だけpurgeされて古いページが残らないか確認します。
おすすめの導入順
- 現在のキャッシュ経路を確認
- 他のフルページキャッシュを停止
- LiteSpeedサーバーならLSCacheページキャッシュだけ有効
- 表示とログイン状態を確認
- 画像最適化
- CSS/JS最適化を1項目ずつ
- 必要ならCloudflare purge連携
ヘッダーでキャッシュを確認する
LiteSpeedのキャッシュはレスポンスヘッダーやLSCache Check Toolで確認できます。「プラグインを入れたから効いている」と思い込まず、HIT/MISS相当の状態を実際に確認します。
Cache設定は「公開ページ」と「ログイン後」を分ける
公開記事は長めにキャッシュできても、ログイン後の管理バー、会員ページ、カートなどはユーザーごとに内容が違います。LiteSpeed Cacheはvaryや除外ルールを持ちますが、初期設定のまま全ページ同じ扱いにしないことが重要です。
最適化機能は1項目ずつONにする
Guest Mode、JS delay/defer、CSS combine/minify、UCSS/CCSS、画像最適化を一度に変えると、表示崩れの原因を特定できません。1項目ずつ有効化し、シークレットウィンドウ、ログイン状態、PC/スマホ、フォーム、広告・計測タグまで確認します。
PageSpeedのラボスコアだけで合否を出さず、メニュー、スライダー、Cookie同意、問い合わせ、GA4など実際の利用動線が壊れていないことを優先します。
WooCommerce・会員サイトの注意
カート、マイアカウント、決済、ログイン後ページは利用者ごとに内容が変わるため、公開記事と同じHTMLキャッシュ方針を使えません。LiteSpeed Cache側の除外・vary cookieなどの仕組みを理解し、テスト注文まで確認します。
Cloudflare API連携を使う時の安全設計
LiteSpeed CacheからCloudflare cacheをPurgeできると便利ですが、API Tokenは対象Zoneと必要権限だけに絞ります。Global API Keyより限定Tokenを優先し、WordPress側の侵害がCloudflareアカウント全体へ波及する範囲を抑えます。LiteSpeed画面からCloudflare操作をする必要がなければ、API連携自体をOFFのままにする選択もあります。
スコアではなく実ページを優先する
PageSpeedのラボスコアが上がっても、初回クリックでメニューが反応しない、フォーム送信が遅れる、広告計測が欠落するなら失敗です。INPや実ユーザー行動、問い合わせ受信、GA4計測まで含めて合否を出します。
キャッシュ不具合の切り分け
- Cloudflare Development ModeまたはbypassでEdgeを外す
- LiteSpeed page cacheをpurge
- 最適化CSS/JSを一時OFF
- シークレットで再確認
- 原因層が分かったら1項目ずつ戻す
「全部Purgeして直った」で終わらず、どの層に古いキャッシュが残っていたかを記録すると再発時の対応が速くなります。
LiteSpeedサーバーかどうかの確認
プラグイン画面だけでなく、ホスティング公式仕様やレスポンスヘッダーで確認します。サーバーがApache/nginxなのにLSCache page cacheが効いていると思い込むと、実際は別機能だけが動いている状態になります。
LiteSpeed Cacheが向く人・向かない人
| 状況 | 判断 |
|---|---|
| LiteSpeed採用サーバー | 有力候補 |
| 既にCloudflare APOでHTMLキャッシュ | 役割重複を整理してから |
| nginx/Apacheで最適化だけ使う | 他の最適化プラグインとも比較 |
| 設定を触りたくない | サーバー標準キャッシュを優先 |
LiteSpeed目的でサーバーを変える前の購入判断
今のサーバーでPHP・DB・バックアップ・管理画面速度に不満があり、さらにLiteSpeed系のserver cacheも使いたいなら比較価値があります。いまのサイトが十分速いなら、LiteSpeed Cacheを使うためだけの移転は不要です。149の性能要件を先に決めてから候補を比較してください。
WordPressの土台から見直す場合
LiteSpeed Cacheを使うためだけに移転するのではなく、PHP・DB・バックアップ・キャッシュ方式まで現在の環境で不足している場合だけサーバー候補を比較してください。
ロリポップ！の最新条件を見る
／ エックスサーバーの最新条件を見る
／ ConoHa WINGの最新条件を見る
／ シンレンタルサーバーの最新条件を見る
公式情報・参考資料
- LiteSpeed Cache – WordPress.org
- LiteSpeed Cache Documentation: Installation
- LiteSpeed Cache Documentation: CDN / Cloudflare
- LiteSpeed Cache Documentation: Third Party Compatibility
- LiteSpeed Security Update: CVE-2026-84761
- LiteSpeed Security Update: CVE-2026-76579
まとめ
LiteSpeed Cacheは「全部入り」だからこそ、役割整理が重要です。LiteSpeed serverならページキャッシュ、Cloudflareならエッジ、Redisなら145のobject cacheとして層を分け、Purge経路まで決めるとトラブルを減らせます。
コメント