INDEX目次を開く +閉じる −
サーバーの高速化設定をONにしたのに、表示速度が変わらない。
このとき、設定画面は「ON」と表示されたままなのに、実際にはキャッシュが使われていないことがあります。設定を見ているだけでは気づけません。
この記事では、キャッシュが効いているかを自分のサイトで確かめる方法を解説します。実際に計測した数値も載せます。
キャッシュが外れていた原因は、フォームプラグインが出していたCookieでした。
この記事で検証した環境
実測に使ったのは、次の2つのサーバーです。どちらも高速化機能をONにした状態で、同じWordPressを設置しています。
| サーバー | ONにしていた設定 |
|---|---|
| エックスサーバー | Xアクセラレータ Ver.2 |
| wpX Speed | サーバーキャッシュ設定、ブラウザキャッシュ設定 |
両方とも管理画面では「ON」と表示されていました。
それでも記事ページのキャッシュは働いていませんでした。
確認の手順自体は、他社のレンタルサーバーやキャッシュプラグインを使っている場合でも同じように使えます。
先に結論
確認の手順は3つです。
- 同じURLを連続で取得し、2回目以降が速くなるかを見る
- レスポンスヘッダーに
Set-Cookieが付いていないかを見る - 付いていたら、どのプラグインが出しているかを特定する
キャッシュが効いていれば、2回目以降は明確に速くなります。速くならない場合、Set-Cookie が原因の可能性があります。
なぜ「ON」なのに効かないのか
サーバーのページキャッシュは、一度生成したHTMLを保存して、次のアクセスにそのまま返す仕組みです。PHPとデータベースを動かさずに済むため、応答が大きく速くなります。
ただし、すべてのページがキャッシュされるわけではありません。
閲覧者ごとに内容が変わるページをキャッシュすると、他人の情報が表示されてしまいます。そのためサーバーは、閲覧者ごとに異なる可能性がある応答をキャッシュの対象から外します。
その判断材料のひとつが Set-Cookie ヘッダーです。
ログイン中の管理画面や、カートの中身が入ったページでCookieが発行されるのは正常な動作です。問題は、すべての記事ページで毎回Cookieが発行されている場合です。この状態だと、サイト全体でキャッシュが使われません。
確認方法1:同じURLを連続で取得する
いちばん分かりやすい確認です。
ブラウザの再読み込みではキャッシュの判断が混ざるため、コマンドで確認します。macOSやLinuxのターミナルで実行できます。
for i in 1 2 3 4 5; do curl -s -o /dev/null -w "#$i ttfb=%{time_starttransfer}s\n" https://example.com/kiji/; donettfb は、リクエストを送ってから最初のデータが返るまでの時間です。サーバーが処理にかけた時間が、ここに表れます。
キャッシュが効いている場合、1回目は遅く、2回目以降は明確に速くなります。
キャッシュが効いていない場合、何回取得しても同じくらいの時間がかかります。
実際に計測した値です。エックスサーバー(Xアクセラレータ Ver.2 有効)に設置したWordPressで、フォームプラグインを停止する前と後に、同じ記事ページを取得しました。
| 回数 | 停止前 | 停止後 |
|---|---|---|
| 1回目 | 0.258秒 | 0.150秒 |
| 2回目 | 0.499秒 | 0.221秒 |
| 3回目 | 0.298秒 | 0.273秒 |
| 4回目 | 0.341秒 | 0.136秒 |
| 5回目 | 0.499秒 | 0.121秒 |
停止前は、何回取得しても0.25〜0.50秒の範囲で上下しています。
繰り返しても速くなりません。
キャッシュが使われていない状態です。
URLを変えて比べるとさらに確実
キャッシュが効いているなら、初めてアクセスするURLは遅く、2回目以降は速いはずです。クエリ文字列を付けて、毎回別のURLとして取得してみます。
for i in 1 2 3; do curl -s -o /dev/null -w "#$i ttfb=%{time_starttransfer}s\n" "https://example.com/kiji/?cb=$RANDOM$i"; doneこの結果が、同じURLを連続取得したときとほとんど変わらなければ、キャッシュは最初から使われていません。
確認方法2:レスポンスヘッダーを見る
次に、サーバーが返しているヘッダーを確認します。
curl -sI https://example.com/kiji/-I を付けると、本文ではなくヘッダーだけが返ります。
キャッシュが効いていなかったサイトでは、次の行が出ていました。
HTTP/2 200
server: nginx
vary: Accept-Encoding
x-pingback: https://example.com/xmlrpc.php
set-cookie: mw-wp-form-token=26b154fdd4d5a7a4e65484d880f14289; path=/; secure; HttpOnly; SameSite=Lax
set-cookie が付いています。
しかもこれは、ログインしていない状態で、通常の記事ページを取得した結果です。
path=/ と指定されているため、サイト全体が対象になります。記事ページも、カテゴリ一覧も、トップページも、すべてキャッシュの対象から外れます。
見るべきポイント
set-cookieがあるか — ログインしていない状態の記事ページに出ていたら要注意- Cookieの名前 — プラグイン名が含まれていることが多く、原因の特定に使えます
path—/ならサイト全体が影響を受けます
確認方法3:原因のプラグインを特定する
Cookieの名前から見当をつけます。先ほどの例では mw-wp-form-token だったので、MW WP Formというフォームプラグインが出しているものでした。
名前だけで分からない場合は、プラグインを1つずつ停止して、set-cookie が消えるかを確認します。
curl -sI https://example.com/kiji/ | grep -i set-cookieこの出力が空になったとき、直前に停止したプラグインが原因です。
本番サイトで試す場合は、アクセスの少ない時間帯に、1つずつ戻しながら行ってください。
ステージング環境があれば、そちらで確認する方が安全です。
実際にどれだけ変わったか
原因のプラグインを停止して、同じ条件で計測し直しました。
5ページを対象に、それぞれ24回ずつ取得し、サーバー処理時間の中央値を比較しています。
| サーバー | キャッシュ無効 | キャッシュ有効 | 短縮した時間 |
|---|---|---|---|
| エックスサーバー | 411.8ms | 105.0ms | 306.8ms(約75%) |
| wpX Speed | 402.6ms | 93.8ms | 308.8ms(約77%) |
両方のサーバーで、ほぼ同じだけ速くなりました。
そして同じ計測で、キャッシュが効いている状態のエックスサーバーとwpX Speedの差は、約11msでした。
サーバーを乗り換えて得られる差より、キャッシュを効かせる方が28倍大きく効いたという結果です。
計測の詳細は、エックスサーバーとwpX Speedの比較にまとめています。
原因が分かったあとの対処
Cookieを出しているプラグインが見つかっても、停止すれば解決とは限りません。
フォームが必要だからそのプラグインを入れているはずです。現実的な選択肢は次のとおりです。
1. フォームのあるページだけキャッシュから除外する
多くのサーバーやキャッシュプラグインには、特定のURLだけキャッシュ対象から外す設定があります。問い合わせページだけを除外し、記事ページはキャッシュを効かせる形にできます。
ただし、Set-Cookie が全ページで出ている場合、この設定だけでは解決しません。Cookieの発行自体を、必要なページに限定する必要があります。
2. Cookieを出さないフォームに替える
フォームプラグインによっては、全ページでCookieを発行しない設計のものがあります。乗り換えを検討する価値があります。
替える場合は、既存のフォームの送信先やスパム対策の設定を引き継げるかを先に確認してください。
3. 外部のフォームサービスを使う
フォーム部分を外部サービスに任せ、WordPress側ではCookieを発行しない構成にする方法もあります。サイト側が軽くなり、送信データの管理もサービス側に寄せられます。
問い合わせの受け方そのものを検討する場合は、AIで作ったホームページの問い合わせはどう受ける?も参考にしてください。
Set-Cookie以外でキャッシュが効かない場合
set-cookie が出ていないのに速くならない場合、次の点も確認してください。
- ログイン状態で確認していないか — 管理画面にログインしていると、キャッシュが使われない設定になっていることがあります。プライベートウィンドウか、コマンドで確認してください
- キャッシュの反映待ちではないか — 設定を変えた直後は、キャッシュが空の状態です。数回アクセスしてから計測してください
- 測定側の回線が遅くないか — TTFBには回線の遅延も含まれます。別の回線でも同じ傾向が出るか確認すると確実です
- そもそも表示が遅い原因が別にある — 画像サイズ、外部スクリプト、広告タグなどは、サーバーのキャッシュでは解決しません
よくある質問
キャッシュが効いているかは、ブラウザの開発者ツールでも分かりますか?
分かります。ネットワークタブでページのレスポンスヘッダーを開き、set-cookie があるかを確認してください。ただしログイン状態だと結果が変わるため、プライベートウィンドウで確認してください。
Set-Cookieは消した方がいいのですか?
一律に消すべきものではありません。ログイン機能やカート機能には必要です。問題になるのは、必要のないページでも毎回発行されている場合です。
高速化設定をOFFにしても変わりませんでした
Set-Cookie が出ている状態では、そもそもキャッシュが使われていません。ONにしてもOFFにしても結果が変わらないのは、その状況と一致します。
まずCookieの有無を確認してください。
サーバーを変えれば速くなりますか?
キャッシュが効いていない状態では、サーバーを変えても同じ問題が残ります。実測では、サーバー間の差は約11ms、キャッシュの有無による差は約307msでした。先にキャッシュを確認する方が効果的です。
まとめ
高速化設定をONにしても速くならないとき、設定画面を見るだけでは原因が分かりません。
確認すべきは3点です。
- 同じURLを連続で取得して、2回目以降が速くなるか
- レスポンスヘッダーに
Set-Cookieが付いていないか - 付いていたら、どのプラグインが出しているか
Set-Cookie が全ページで発行されていると、サーバーのページキャッシュは働きません。実測では、これを解消するだけでサーバー処理時間が75%短縮しました。
サーバーの乗り換えを検討する前に、まず今の環境でキャッシュが実際に効いているかを確認してみてください。エックスサーバーでの高速化設定は、Xアクセラレータの設定方法で解説しています。