WordPressの表示が遅いとき、最初からキャッシュプラグインを追加するのはおすすめしません。レンタルサーバー側ですでにページキャッシュが動いている場合は、機能が重なって更新内容を確認しにくくなるからです。まずページ表示速度を測り、サーバーの機能を確認したうえで、改善作業を進めるのが安全です。

キャッシュは効果の大きい対策ですが、画像や外部サービスの読み込みまで一度に直せる機能ではありません。この記事では、IT担当者がいない会社でも戻し方を確保しながら、導入の要否と効果を判断できる順番で説明します。

キャッシュを入れる前に測るページを決める

設定前の状態を残さずにキャッシュを有効にすると、速くなったのか、体感だけが変わったのかを判断できません。確認する代表URLは3種類です。トップページに加え、通常の記事または固定ページと問い合わせフォームを選びます。設定前後で同じページを確認します。

測定にはPageSpeed Insightsを使います。ただし、表示される点数だけで結論を出さない方が良いです。Googleの公式説明では、PageSpeed Insightsには実際の利用データと検証用のラボデータがあり、対象期間や測定条件が異なります。ラボデータは実行時の条件でも変わるため、同じURLと端末区分で複数回測り、傾向を見ます。

この段階で画像の読み込みが大半を占めているなら、キャッシュより画像の見直しを先に行う場合があります。原因を分けて考える方法は「Webサイトの表示速度に影響するサーバー設定とスペックの関係」も参考にしてください。

キャッシュは一つの機能ではない

WordPressのキャッシュには役割の違う層があります。ここを分けておくと、プラグインを増やす前に、現在どこまで設定されているかを確認しやすくなります。

会社サイトで最初に検討するのは、完成したHTMLを再利用するページキャッシュです。通常はアクセスのたびにPHPが動き、データベースから情報を取得してページを組み立てます。ページキャッシュが使えると、この処理を省いて保存済みのHTMLを返せるため、サーバーの負荷と応答時間を抑えられます。

ブラウザキャッシュは画像やCSSなどを閲覧者の端末へ保存し、再訪時のダウンロードを減らす仕組みです。オブジェクトキャッシュはデータベースから取得した結果をRedisやMemcachedなどへ保持します。後者はサーバー側の対応が前提になるため、一般的な会社サイトで自己判断のまま追加するより、まずページキャッシュの効果を確認した方が進めやすいです。

WordPress公式のキャッシュ解説でも、役割ごとに分けて説明しています。対象はキャッシュプラグイン・ブラウザ・オブジェクト・サーバーの4種類です。名称よりも、どの層が何を保存しているかを整理することが大切です。

サーバー機能かプラグインかを選ぶ

最初にレンタルサーバーの管理画面と公式マニュアルを確認します。「高速化」「ページキャッシュ」「サーバーキャッシュ」などの機能が有効なら、いったんその機能だけで効果を測ります。管理画面に機能が見つからない場合も、契約プランによって利用条件が異なることがあるため、プラグインを追加する前にサーバー会社へ確認した方が確実です。

サーバー側にページキャッシュがなく、WordPress内で補う場合は、目的をページキャッシュに絞ってプラグインを選びます。WP Super Cacheは、WordPressが生成したページを静的なHTMLとして保存する選択肢です。知名度だけで決めず、現在の提供元と更新履歴を公式ディレクトリで確認します。利用中のWordPressへ対応しているかも確認が必要です。

LiteSpeed Cacheは、ページキャッシュを使う場合にLiteSpeed系サーバーまたは対応するCDNが必要です。画像最適化など一部の機能は別のWebサーバーでも使えますが、プラグインを入れただけでページキャッシュが動くとは限りません。利用中のサーバーが対応しているかを先に確認します。

複数のフルページキャッシュを同時に動かすと、どの層に古いページが残っているか分かりにくくなります。最初は一つに絞り、必要性を説明できない機能は追加しません。

キャッシュを安全に有効化する手順

キャッシュ設定は、速くする操作よりも、問題が出たときに元へ戻せる順番が重要です。次の手順は前後を入れ替えず、一つの変更ごとに表示を確認します。

  1. WordPressとデータベースのバックアップを取得し、現在のキャッシュ設定を画面またはメモで残す
  2. 更新作業中のページがある場合は公開を終え、代表URLの表示とフォーム送信を記録する
  3. サーバー機能またはプラグインのどちらか一方で、ページキャッシュだけを有効にする
  4. キャッシュを一度削除し、ログアウトした状態でトップページと代表ページを開く
  5. 記事の一部を安全な範囲で更新し、公開側へ反映されることを確認する
  6. 問い合わせフォームを実際に送信した後、設定前と同じ条件で速度を測る

シークレットモードは、普段のログイン情報やCookieから分けて訪問者向け表示を確認するために使えます。「キャッシュがない状態」になるわけではなく、サーバー側のページキャッシュはシークレットモードでも適用されます。表示確認では、通常のブラウザで管理者側を見ながら、別のウィンドウで訪問者側を見ると違いを追いやすくなります。

CSSやJavaScriptの圧縮・結合と読み込み順の変更は、ページキャッシュとは別の調整です。最初から同時に有効にすると、表示崩れが起きたときに原因を切り分けられません。ページキャッシュの動作を確認してから、一項目ずつ検討します。

更新ページと動的な機能を確認する

会社サイトでは、トップページが速く表示されるだけでは運用できません。更新内容が公開側へ反映され、問い合わせが届くところまで確認して、初めてキャッシュ設定が完了します。

特に確認したいのは、問い合わせフォーム・サイト内検索・ログイン後だけ表示が変わるページです。ECサイトや会員サイトでは、カートやマイページも対象になります。これらは訪問者や操作によって内容が変わるため、通常の固定ページと同じ条件でキャッシュしない設定が必要になる場合があります。

多くのキャッシュ機能には、ログイン中の利用者や特定URLを対象外にする仕組みがあります。ただし、自動的に適切な除外が行われるかは、使っているプラグインやサーバー機能で異なります。「一般的には除外される」と考えて確認を省かず、自社サイトのフォームや会員機能を実際に操作して判断します。

更新が反映されない場合は、使っているキャッシュ層を洗い出します。WordPressのプラグインから始めます。次にレンタルサーバー、CDN、ブラウザの順で確認します。闇雲にすべて削除するのではなく、どの操作で表示が変わったかを記録すると、次に同じ問題が起きたときの対応が早くなります。

キャッシュで速くならない原因を分ける

ページキャッシュを有効にしても変化が小さい場合は、設定を強くする前に別の原因を疑います。画像ファイルが大きければ、転送に時間がかかります。外部の計測タグやテーマのJavaScript処理が重い場合も、保存済みHTMLを返すだけでは解消しません。

管理画面だけが遅い場合も、公開ページのキャッシュでは改善しにくいです。ログイン後の処理はページキャッシュの対象外になることが多く、データベース・PHP・プラグインの処理を分けて調べる必要があります。画像が主な原因なら「Webサイトの画像最適化：ファイル形式・圧縮・遅延読み込みの基礎」へ進む方が効果的です。

PageSpeed Insightsの点数が上がっても、フォームが動かなくなれば会社サイトとしては改善とは言えません。速さ、更新の反映、業務機能の動作を同じ確認項目として扱います。

社内でキャッシュ削除のルールを決める

設定後は、誰がキャッシュを削除できるかを社内で決めます。制作会社が更新を担当しているなら、公開作業の完了条件に「訪問者向け画面の確認」を含め、キャッシュを削除した日時と対象ページを作業記録へ残します。

削除方法はサーバーとWordPressで異なります。管理画面の場所を文章だけで残すより、現在の画面を一枚保存し、障害時にも確認できる保管場所へ置く方が実用的です。担当者が変わったときは、操作権限と手順をまとめて引き継ぎます。

プラグインやテーマを更新した後も、代表URLとフォームを確認します。毎回すべてのページを調べるのは現実的ではありませんが、基準となるページを決めておけば、更新による変化へ早く気づくことができます。