小規模サイトの表示速度改善メモ：第５回　共用サーバでCDNやサーバーキャッシュを使うときの注意点

小規模サイトの表示速度改善メモ：第５回　共用サーバでCDNやサーバーキャッシュを使うときの注意点

共用サーバでは、毎回CMSを動かさない工夫が重要

「小規模サイトの表示速度改善メモ」第5回は、共用サーバでキャッシュを使うときの判断基準と、設定時に注意したいポイントについてです。

第1回では、「WordPressを毎回動かさないためのキャッシュの考え方」について触れました。

共用サーバでも、キャッシュ機能やCDNをうまく使えば、アクセスのたびにWordPressやCMSを毎回動かす負担を減らせます。
ただし、キャッシュは「有効化すれば終わり」ではなく、フォーム・確認画面・会員ページなど、キャッシュしてはいけないページを除外し、実際にキャッシュが効いているか確認することが重要です。

今回の記事では、第1回の内容を軽くおさらいしつつ、共用サーバでCDNやサーバーキャッシュを使うときの注意点について触れていきます。

CDN・サーバーキャッシュ・ページキャッシュの違いをざっくり整理する

小規模な企業サイトやブログでは、WordPressなどのCMSを共用レンタルサーバで運用しているケースも多いです。

共用サーバは低コストで使いやすい一方、サーバの混雑や同居サイトの影響を完全には避けられません。

そのため、サーバを強化するだけでなく、通常閲覧時にできるだけキャッシュ済みの内容を返すことが重要になります。

キャッシュには以下のような種類があります。

  • ページキャッシュ： WordPressなどが生成したHTMLを保存し、次回以降はそのHTMLを返す仕組み。
  • サーバーキャッシュ： レンタルサーバ側の仕組みで、PHPやCMSの処理を減らすキャッシュ。
  • CDN： サイトの前段にある配信ネットワークから、画像・CSS・JSなどの静的ファイルや、設定によってはHTMLを返す仕組み。

これらは完全に別々のものというより、キャッシュする対象や場所が違うものです。たとえば、生成済みHTMLを保存して返すページキャッシュを、WordPressプラグイン側で行う場合もあれば、レンタルサーバ側の機能やCDN側で行う場合もあります。
「生成済みHTMLをどこで保存し、どの段階で返すか」の違いとして考えると分かりやすいです。

LiteSpeed Cache：使える環境なら有力なWordPress向けキャッシュ

利用している共用レンタルサーバがLiteSpeed環境なら、LiteSpeed Cacheは有力です。

WordPressでサイトを構築しているなら、「LiteSpeed Cache for WordPress」プラグインを組み合わせることで、LiteSpeed Web Serverの組み込みページキャッシュと連携して表示速度を改善できます。
WordPress.orgのプラグインページでも、LiteSpeed Cacheを有効化し、Cache設定でキャッシュをONにする手順が案内されています。

このタイプのキャッシュは、WordPressの処理後にHTMLを保存するだけの仕組みよりも、サーバ側のキャッシュと連携できる点が強みです。
条件が合えば、WordPressのPHP処理に入る前に、キャッシュ済みのHTMLを返すことができます。

LiteSpeed Cache / LiteSpeed Web Serverの利用を公式に確認でき、実務上でも候補に挙がりやすいのは、以下のサーバです。

サーバ 対応状況 補足
ColorfulBox LiteSpeed採用 / LiteSpeed Cache利用可 公式サイトでLiteSpeed採用を明記。サポートでもLiteSpeed Cache導入手順あり。 (ColorfulBox カラフルボックス)
mixhost LiteSpeed Cache利用可 公式ヘルプで「LiteSpeed CacheをはじめとするWordPress高速化機能」を利用可能と案内。 (mixhostヘルプ＆サポート)
ロリポップ！ 一部プランでLiteSpeed対応 公式でLiteSpeed採用を明記。対応プランはハイスピード / エンタープライズ。 (ロリポップ！レンタルサーバー)
ABLENET レンタルサーバー LiteSpeed / LiteSpeedCache利用可 公式で「WebサーバにLiteSpeedを使用、さらにLiteSpeedCacheも利用可能」と記載。 (ABLENET)
ラッコサーバー LiteSpeed Cache利用可 公式ナレッジでLiteSpeed Cacheの使い方を案内。cPanelのLiteSpeed Web Cache Managerにも言及。 (ラッコサーバー)

実際に利用する際は、LiteSpeedに対応しているかだけではなく、以下も注意して確認してください。

  • 利用プランがLiteSpeed対応か
  • サーバのコントロールパネルなどで、LiteSpeed Web Cache Managerが使えるか
  • x-litespeed-cache: hit などで、実際にキャッシュヒットを確認できるか
  • フォーム、会員機能、検索結果などのキャッシュ除外設定ができるか

LiteSpeed Cacheは、CSS/JavaScript/画像最適化なども含みます。
ですが、CSS結合・JS遅延・HTML圧縮・遅延実行系は、フォームやGTMやレイアウト崩れの原因になりやすいです。
最初からすべてONにせず、まずはページ単位のキャッシュが正しく効くかを中心に見ると良いでしょう。
その後に画像、最後にCSS/JS最適化、といった段階を踏んで利用すると安全です。

ロリポップ！アクセラレータ：低価格帯でも使いやすいサーバ側キャッシュ

ロリポップ！レンタルサーバーが提供しているキャッシュ機能です。

公式では、Webサイトの表示内容をキャッシュサーバに一時保存し、同じサイトへのアクセス時にキャッシュサーバから応答する機能として説明されています。WordPress、EC-CUBE、baserCMS、独自動的アプリケーション、静的サイトなどで効果が期待でき、画像・CSSなどの静的ファイルのみに適用するモードも用意されています。(ロリポップ！レンタルサーバ)

対応プランは、ライト、スタンダード、ハイスピード、エンタープライズです。

仕様面では、wp-admin や wp-login.php、WordPressログインCookie、コメント投稿者Cookie、パスワード保護Cookieなどはキャッシュ対象外になるよう案内されています。(ロリポップ！レンタルサーバ)
利用する前に、公式マニュアルでキャッシュ対象外となるURLやCookieの条件を確認しておくと安心です。

小規模サイトや、低価格帯のWordPress案件なら現実的です。
ただし、ロリポップ！ハイスピードプランではLiteSpeed Cacheも選択肢になりますが、ロリポップ！アクセラレータとは併用できません。どちらを使うかは、サイトの構成や管理しやすさを見て判断する必要があります。

さくらのコンテンツブースト：レンタルサーバで使えるCDN機能

さくらのレンタルサーバでは、コンテンツブーストというCDN機能を利用できます。

CDNとレンタルサーバを自動連携する仕組みになっており、WordPressなどの表示安定化・アクセス集中対策として採用しやすいCDNです。

契約プランによって無料枠が用意されており、ライト・スタンダードは月100GBまで、ビジネス以上・マネージドサーバは月300GBまで無料です。無料枠超過後は、利用停止するか、1GBあたり5円で継続するかを選べます。(コンテンツブースト（CDN機能） - レンタルサーバはさくらインターネット)

小規模な企業サイト、採用サイト、ブログ、お知らせ中心のWordPressなら、相性は良いと思います。

注意点として、初期設定では全コンテンツを自動的に300秒キャッシュする仕様です。
EC、会員ページ、マイページ、個人情報を含むページでは除外設定が必要です。

ConoHa WINGのコンテンツキャッシュ：管理画面から設定しやすいが動的ページに注意

ConoHa WINGは、管理画面の「高速化」からコンテンツキャッシュを設定できます。公式サポートでは、Webサイトのページをキャッシュして表示を高速化できる機能と説明されており、デフォルトでは「ON（すべてのコンテンツ）」が設定されるとあります。wp-admin 配下はキャッシュされないとも案内されています。(コンテンツキャッシュ機能を使う | ConoHa WINGサポート)

注意点は、公式にも「動的なページもキャッシュされるので注意」と書かれていることです。
問い合わせフォーム、会員ページ、検索結果、Cookieで表示が変わるページがある場合は、挙動確認が必須です。

Cloudflare：サーバを変えずに使えるが、設定管理の影響範囲は広い

Cloudflareは、サーバを変えずにCDNや前段キャッシュ、WAFなどを導入できる選択肢です。

Cloudflareを使う場合は、ドメインのネームサーバをCloudflareに変更し、Cloudflare側のDNSレコードで共用サーバをオリジンとして指定します。静的ファイルのCDN配信に使えるほか、WAFやDDoS対策なども含むため、セキュリティ対策とキャッシュをまとめて検討したい場合の候補になります。

WordPress向けには、Cloudflare APOのように、WordPressサイトの静的・動的コンテンツをCloudflareネットワークから配信し、オリジンサーバとの往復を減らす仕組みもあります。(WordPressサイト高速化 | ページ読み込み速度改善 | Cloudflare)

ただし、Cloudflareはレンタルサーバの標準キャッシュ機能とは性格が異なります。DNS、SSL/TLS、キャッシュ、WAF、IPアドレスの扱いなど、サイト全体の通信経路に関わるため、設定ミスやサーバ側の制限との相性によって、想定外の不具合が出ることがあります。

たとえば、サーバ側から見るアクセス元IPがCloudflareのIPになる場合があり、アクセス解析、WAF、海外IP制限、ログ確認、フォームのスパム対策などに影響することがあります。実際の訪問者IPを扱うには、サーバやアプリケーション側で CF-Connecting-IP などのヘッダーを考慮する設定が必要になる場合があります。

また、HTMLまでキャッシュするにはCache RulesやAPOなどの設計が必要です。設定をミスすると、フォーム・ログイン・プレビュー・会員ページなどで古い内容が表示されたり、正常に動作しなくなったりする場合があります。

一方で、ユーザーごとに表示内容が変わる動的コンテンツは、静的ファイルよりもキャッシュ設計に注意が必要です。(Caching Static and Dynamic Content | How Does It Work?)

Cloudflareは強力な選択肢ですが、小規模サイトで気軽にONにする機能というより、DNSやキャッシュルール、サーバ側のアクセス制御まで含めて管理できる場合に検討したいサービスです。単に表示速度改善だけが目的なら、まずは利用中のレンタルサーバが用意しているキャッシュ機能やCDN機能から確認する方が安全です。

キャッシュ機能の比較

ここまで、共用サーバでも採用しやすい主要なサービスに触れてきました。
サイトの仕様や管理体制、利用中のサーバによっても変わるので、どれが一番良い、というものではありません。
使っているサーバに合っているか、管理できる範囲・除外設定のしやすさで選びましょう。

機能 向いているケース 注意点
LiteSpeed Cache LiteSpeed対応サーバでWordPressを使う場合 対応サーバが限られる。最適化機能を盛りすぎない
ロリポップ！アクセラレータ ロリポップ！で低コストにキャッシュを使いたい場合 LiteSpeed Cacheと併用不可
さくらのコンテンツブースト さくらのレンタルサーバでCDN機能を使いたい場合 利用条件、無料枠、除外設定に注意
ConoHa WING コンテンツキャッシュ ConoHa WING利用中で管理画面から設定したい場合 動的ページのキャッシュに注意
Cloudflare DNS・WAF・CDNまで含めて管理できる場合 影響範囲が広く、IPアドレスの扱いやサーバ側制限との相性確認が必要

キャッシュしてはいけないページを先に決めておく

第1回の記事でも触れたとおり、キャッシュは何にでも使えばよいわけではありません。

本来ユーザーごとに変わる内容まで保存してしまうと、誤表示やフォーム不具合につながる可能性があります。

特に注意したいのは、ユーザー固有の情報を含むページです。
確認画面や会員ページなどで、特定のユーザー向けに生成されたHTMLがキャッシュされ、それが別のユーザーに表示される状態は避けなければいけません。
氏名、メールアドレス、ユーザーID、購入履歴、お問い合わせ内容などが含まれるページでは、キャッシュ対象にしない設計が必要です。

なお、各サービス側で wp-admin やログインCookieなどを自動的にキャッシュ対象外にしている場合でも、それだけで十分とは限りません。

問い合わせフォーム、確認画面、送信完了画面、会員ページ、検索結果などは、サイトやプラグインによってURLや動作が異なります。標準の除外条件に任せきりにせず、自分のサイトでキャッシュしてはいけないページを先に洗い出しておくことが重要です。

また、ユーザーからの入力を受け付けるフォーム類では、Cookieやセッション、nonceやCSRFトークンが埋め込まれることもあります。
こういった仕組みはキャッシュとの相性が悪く、正常に動かなくなる可能性があるほか、条件によってはユーザー固有の情報を含めキャッシュされてしまう場合があり、原則としてキャッシュの対象から外す方が安全です。

たとえば、次のようなページではページキャッシュの使用に注意が必要です。

  • お問い合わせフォーム
  • 確認画面
  • 送信完了画面
  • ログインページ
  • 会員ページ
  • マイページ
  • カート・決済
  • 検索結果
  • プレビュー
  • パスワード保護ページ
  • Cookieで表示が変わるページ
  • nonceを使うページ
  • ユーザーごとに表示が変わるページ

また、ページ内に次のような要素がある場合も、キャッシュとの相性を確認する必要があります。

  • ランダム記事
  • 今日の日付
  • 現在の空き状況
  • リアルタイム在庫
  • 閲覧数ランキング
  • ユーザー別おすすめ

キャッシュを使うときは、このページは誰が見ても同じ内容でよいかを確認することが大切です。

キャッシュが効いているか、効いていないかを確認する

キャッシュ機能をONにしても、実際に効いているとは限りません。
設定後は、必ずキャッシュが効いていること、キャッシュしてはいけないページでは無効になっていることを確認することが重要です。

シークレットウィンドウで確認するほか、体感ではなくレスポンスヘッダーで見た方がいいです。

Chrome DevToolsなら、

  • Networkタブを開く
  • 対象ページをリロード
  • HTMLドキュメントのリクエストを選ぶ
  • Response Headersを見る

で確認できます。

curlで確認する場合は、以下のようにレスポンスヘッダーを確認します。

curl -I https://example.com/

キャッシュが効いていれば、次のようなレスポンスが返ります。

x-litespeed-cache: hit
cf-cache-status: HIT
x-cache: HIT

MISS や miss ならキャッシュ未使用、HIT や hit ならキャッシュから返っている可能性が高いです。
1回目は MISS、2回目以降は HIT になることもあるので、念のため2回確認すると良いでしょう。

どのヘッダーが出るかは、利用しているサーバやCDNによって異なります。大事なのは、未ログイン状態で通常ページがキャッシュされ、フォームや会員ページがキャッシュされていないことを確認することです。

また、キャッシュが効いていることだけでなく、更新後にキャッシュが適切に削除・更新されるかも確認しておきましょう。

WordPressの記事や固定ページを更新したあと、未ログイン状態のブラウザで新しい内容が表示されるかを確認します。サーバ側のキャッシュ、CDN、ブラウザキャッシュが重なっている場合、管理画面上では更新できていても、公開画面では古い内容が残ることがあります。

Cookieがあるとキャッシュが除外されることがあるため、WordPressサイトならログインCookieが無い状態での検証が必要です。

まとめ：キャッシュは有効化よりも、除外と確認が大事

共用サーバでも、CDNやサーバーキャッシュをうまく使えば、WordPressやCMSを毎回動かす負担を減らせます。

ただし、キャッシュは「ONにすれば速くなる便利機能」ではありません。問い合わせフォームや会員ページなど、キャッシュしてはいけないページを除外し、通常ページではキャッシュが効いていることを確認する必要があります。

小規模サイトでは、難しいチューニングよりも、まず安全にキャッシュを使うことが現実的な表示速度改善につながります。

特にCloudflareのようにDNSやWAFまで関わるサービスは、表示速度だけでなく、アクセス制限やログ、フォーム、SSL/TLS設定にも影響するため、設定内容を管理できる体制があるかを確認してから導入することが大切です。

第6回では、「ブラウザの戻る・進むを邪魔しない。bfcacheを意識した実装」について触れていきます。

シリーズ記事

このブログの人気の投稿

WordPressプラグインのサプライチェーン攻撃から考える、日々のセキュリティ運用

イメージ
WordPressサイトの安全性を保つうえで、WordPress本体だけでなく、プラグインの更新はとても重要です。 しかし近年、単に「更新していれば安全」とは言い切れない事例も出てきています。 その一つが、2026年4月に報告されたWordPressプラグインのサプライチェーン攻撃です。 何が起きたのか 今回の事例では、もともと正規に公開されていた複数のWordPressプラグインが、第三者に買収された後、不正なコードを含む状態に変更されていたと報告されています。 対象となったのは、Essential Plugin系の30件以上のプラグインです。 これらのプラグインは以前からWordPress.orgで公開され、多くのサイトで利用されていたものですが、事業・プラグイン群が売却された後、新しい所有者によって不正な処理が仕込まれたとされています。Anchor Hostの記事では、30件以上のプラグインが影響を受け、31件がWordPress.orgによりクローズされたと報告されています。( Anchor Hosting ) この不正なコードは、すぐに目立つ被害を出したわけではありません。 2025年8月にバックドアが仕込まれ、その後しばらく潜伏し、2026年4月5日〜6日ごろに悪用されたとされています。つまり、問題が表面化するまで約8カ月かかっていたことになります。 どのような被害があったのか 報告によると、不正なコードは外部サーバーと通信し、WordPressサイト内の重要ファイルである wp-config.php に不審なPHPコードを追加していました。 このコードにより、検索エンジン向けにスパムページや不正なリンク、リダイレクトなどを表示する仕組みが作られていたとされています。 ここで厄介なのは、サイト管理者が普通にブラウザで見ても異常に気づきにくい点です。 不正な表示はGooglebotなど検索エンジン向けに出され、一般の閲覧者や管理者には見えにくい形だったと説明されています。 つまり、見た目にはサイトが普通に動いていても、裏側では検索エンジン向けにスパムコンテンツを返していた可能性があります。 WordPress.org側の対応 問題発覚後、WordPress.orgのプラグインチームによって、対象プラグインは閉鎖され、2026年4月8...
Read more »

デザインは売上に影響するのか？

イメージ
データから見えた「選ばれるWEBサイト」の条件 WEBサイトを作るとき、次のような発言や考え方に遭遇することがあります。 「まずは内容が大事」 「デザインは後から整えればいい」 「見た目よりSEOが優先」 当然、どれも間違いではないのですが、いざWEBサイトを作る段階では優先順位をつけておく必要があります。その時に念頭に置いておく必要があることがあります。 それは、実際のユーザー行動は、とてもシビアだということです。 多くの人は、ページを開いた瞬間に、そのWEBサイトの内容を「読むかどうか」を判断しています。 つまりデザインに求められるのは、単なる見た目ではなく、 “読もうという気にさせるかどうか” なのです。 求められるデザインの「質」 先日、以下の記事を読む機会がありました。 「デザインの質」が男性の購買判断を左右？年代別で異なる意識を調査。Ryuki Designが明らかにしたデザインの影響力とは https://newscast.jp/smart/news/1361249 この調査では、全国の20〜69歳の男性100名を対象に、 「インターネットで商品やサービスを選ぶ際、ページのデザインの質は判断材料になるか？」 というアンケートを実施しています。 結果として、 「デザインの良し悪しで判断することが多い」 「ある程度は気にするが、内容の方が重要」 と回答した人を合わせると、約4割以上が“デザインを判断材料として見ている”ことが分かりました。 さらに興味深かったのが、年代による違いです。 20代では「デザインはそこまで重視しない」という意見も一定数ある一方で、40代以降では「見やすさ」や「安心感」を重視する傾向が強く見られました。 つまり、WEBサイトの利用者はデザインを重視するが、そこで重視されているのは 「綺麗かどうか」ではなく、“信頼できるか・ストレスなく内容を読むことができるか” ということです。 そこで今回は、 なぜデザインが売上や反応率に影響するのか なぜ「内容が良いだけ」では不十分なのか 初心者でも見直せる改善ポイント を、できるだけ分かりやすく整理してみたいと思います。 デザインは「入口のフィルター」になっている ユーザーは、想像以上に早くWEBサイト...
Read more »

小規模サイトの表示速度改善メモ：第１回　WordPressを毎回動かさないためのキャッシュの考え方

イメージ
小規模WordPressサイトが重いとき、まず見直したい「ページキャッシュ」の考え方 はじめに この記事は、小規模なWordPressサイト・企業サイトの制作・保守を担当している方向けです。 特に、共用レンタルサーバを使っているサイトで、コストを大きく増やさずに表示速度を改善する場合、まず何から考えるべきかを整理します。 表示速度の改善というと、サーバのスペックアップや高機能なCDNの導入を思い浮かべるかもしれません。もちろん、それらが有効な場合もあります。 ただ、小規模な企業サイトやブログでは、予算や運用体制の都合から、すぐに大きな環境変更ができないケースも少なくありません。 そのような場合にまず考えたいのが、 アクセスのたびに毎回WordPressを動かさない という考え方です。 小規模サイトでは、サーバを強くするだけが解決策ではない 小規模な企業サイトやブログでは、WordPressを共用レンタルサーバで運用しているケースも多いと思います。 共用サーバは低コストで使いやすい一方、サーバの混雑や同居サイトの影響を受けることがあります。 たとえば、次のようなケースです。 サイトを開くときに時間がかかる ページ遷移のたびに少し待たされる 自社サイトへのアクセスは増えていないのに、特定の時間帯だけ応答が遅い 管理画面や公開ページの表示が日によって不安定に感じる こういったサーバに依存する部分は、自社サイト側だけでは完全にコントロールできません。 もちろん、サーバのスペックを上げたり、より高性能な環境へ移行したりすることも選択肢です。しかし、予算や運用体制を考えると、すぐに実施できないケースも少なくありません。 そのため、まずは現在の環境でできることとして、 WordPressやデータベースの処理を毎回発生させない工夫 を検討する価値があります。 そこで重要になるのが、ページキャッシュの考え方です。 WordPressは、ページ表示のたびに処理が走る WordPressは、あらかじめ完成したHTMLファイルをそのまま置いている静的サイトとは異なります。 多くの場合、ユーザーがページにアクセスするたびにPHPが動き、データベースから必要な情報を取り出し、テーマやプラグインの処理を通してHTMLを生成しています。 たとえ...
Read more »