W3 Total Cache 設定ガイド (Browser Cache編)

W3 Total Cache(以下 W3TC)のBrowser Cacheメニューでは、CSS、JavaScript、画像、HTMLページなどの静的なリソースをブラウザにキャッシュさせ、コンテンツの鮮度と表示パフォーマンスを調整するための各種設定をおこなう4つのセクション(ブラウザキャッシュポリシー)と、SSL化に対応したサイトが、Webサイトの訪問者に対してより安全なアクセスを提供するための設定をおこなう1つのセクション(セキュリティーヘッダー)で構成されています。

このチュートリアルでは、ブラウザキャッシュポリシーの全項目について、その仕組みと実際の挙動について解説します。

ここでの設定は、General Settingsで Browser Cache を有効化している場合のみ機能します。

ブラウザキャッシュポリシー

W3TC Browser cache General セクション

ブラウザキャッシュポリシーのための4つのセクションの構成は、ごく一部を除いて共通の項目で構成されており、General(一般・全般)セクションから他の3セクション(CSS & JS | HTML & XML | Media & Other Files)を一括設定することができます。

同じ項目を繰り返し説明するとややこしくなるので、ここでの解説はGeneralセクション固有のものと全てに共通する項目を合わせておこないます。ただし、実際に設定する際は各セクションに移動し、吟味したうえでON/OFFと値の設定をするようにしてください。

キャッシュポリシーはとりあえず何でもONにすればよいというものでもありません。適当な設定はかえってパフォーマンスを低下させるので、面倒な場合は安全な初期値のまま運用するのも手です。

Set Last-Modified header

Webページにアクセスした時に、サーバーから新たにリソース(CSS、JS、HTMLなど)を取得するか、閲覧者のブラウザ(≒端末)にキャッシュされているリソースを使用するかを判断するための情報を提供するために、そのリソースの最終更新日時をサーバーの応答内容に含めます。

ブラウザは、初回に受け取った Last-Modified の値を、次回アクセス時にサーバーから提供される Last-Modified の値と比較して、リソースの新旧を判断することができます。

初期値はONで後続の3セクション全部で有効になっています。なお、常時アクセス数が多く、かつ訪問者のリピート率や一人当たりの回遊数が高いサイトでは、こちらよりも次の Set expires header が適しているようです。

  • W3TCによってキャッシュされたページまたはMinifyされたファイルについてはそれらが生成された日時がリソースの最終更新日時ということになります。

Set expires header

リソースの有効期限の日時※1をサーバーの応答内容に含めます。

理論上は、リソースの有効期限が来るまでブラウザはサーバーに対してリソースの更新の有無を確認しないので、上のLast-Modified よりも サーバーへの負荷を軽減できるとされています。

Generalセクションでの初期値はOFFで、後続のCSS&JSおよびMedia&Other Files でのみ有効になっています。これは内容が更新される可能性が高いHTML(≒記事)と、通常短期的な更新が予定されていないCSSなどの静的なリソースとで、性質の違いが考慮されているためです。

  • リソースの有効期限は、サーバーが応答した日時(≒ブラウザがリソースをダウンロードした日時)を起点として設定されますが、W3TCによってキャッシュされたページまたはMinifyされたファイルについてはそれらが生成された日時を起点として設定されます。

  • Google PageSpeed Insights の改善項目「静的なアセットでの効率的なキャッシュ ポリシーの使用」をクリアするには、こちらのSet expires headerか、この後で解説する Cache Control policy の max-age を使用します。

Expires header lifetime(後続の3つのセクションで個別に設定)

上の expires header におけるキャッシュされたリソースの有効期限を設定するための時間的長さ 、または下のcache control header における再使用可能時間(max-age)を秒単位で設定するための入力欄です。

Set cache control header

cache control headerを使用すると、上の Set expires header よりも複雑なキャッシュ処理方法を ブラウザに対して指示することができます。初期値はOFFで、後続の3セクションでも無効になっています。

やや上級者向きの設定項目なので、初心者の方は無理に設定する必要はありません。なお、W3TCのページキャッシュやMinifyを使用している場合、Set expires header と Set cache control headerの併用において注意すべき点があります。

Cache Control policy(後続の3つのセクションで個別に設定)

W3TCでは Cache Control policy(キャッシュコントロールポリシー)を以下の6種類から選択するようになっています。

cache(“public”)

明示的にキャッシュの利用を許可します。これ自身ではキャッシュの有効期限を指定していないので、Set Last-Modified header や Set expires header、Etag など、他の有効期限を検証する項目が設定されていない場合は、キャッシュが置き換えられず、閲覧者に更新内容が反映されない可能性があります。

一般公開向けで公開後に変更する可能性が極めて低い画像などの静的リソース向きの設定です。

cache with max-age (“public, max-age=EXPIRES_SECONDS”)

リソースを読み込んだ時から Expires header lifetime で指定した期間が経過するまでキャッシュの利用を許可します。オリジンサーバーの負荷を抑えつつキャッシュの鮮度を保つことができます。
注意点1・2も参照してください。

たまに変更する可能性のある一般公開向けHTMLや、そもそも保護するような情報が含まれないCSSなどの静的リソース向きの設定です。

期限切れのキャッシュの取り扱い基準は下の2つよりも緩やかなので、キャッシュの利用効率が良く、個人向けブログなどには使い勝手が良いでしょう。初期値として選択されているのもうなづけます(おすすめ)。

cache with validation (“public, must-revalidate, proxy-revalidate”)

expires header の有効期限までキャッシュの使用を許可し、有効期限後はキャッシュの再検証に成功しない限り古いキャッシュの再使用を認めません。
注意点2・3も参照してください。

cache with max-age and validation (“max-age=EXPIRES_SECONDS, public, must-revalidate, proxy-revalidate”)

max-age(Expires header lifetime)を使って有効期限を設定すること以外は、注意点を含め、上の cache with validation と同じです。
注意点1・2も参照してください。

cache without proxy (“private, must-revalidate”)

個人的なユーザー情報を含むHTMLページで、CDNなどの中間サーバーでキャッシュを使用したくない場合向きの設定です。なお、 Set expires header と組み合わせてユーザーのブラウザでキャッシュを使用することができます。
注意点2・3も参照してください。

no-cache (“max-age=0, private, no-store, no-cache, must-revalidate”)

中間サーバーはもちろんですが、ブラウザにもキャッシュをさせません(メモリへの一時的なキャッシュは認められる)。ブラウザキャッシュによる恩恵の大半を犠牲にする代わりに、リアルタイムに近い間隔で更新されるようなページ(≒HTML)や、コンテンツや情報の保護を優先する場合の設定です。

Cache Control policy 利用時の注意点

  • WordPressにログイン中のユーザーが見るページについては、ここでの設定に関わらず Cache-Control: no-cache, must-revalidate, max-age=0 が適用されます(但しログイン中のユーザーのページキャッシュを生成するようにしている場合を除く)。

  • W3TCにおいて max-ageの値は、Expires header lifetime 欄の値で設定します。

  • リソースの有効期限は、通常、サーバーが応答した日時(≒ブラウザがリソースをダウンロードした日時)を起点として設定されますが、W3TCによってキャッシュされたページまたはMinifyされたファイルについてはそれらが生成された日時を起点として設定されます。

    このことから、HTML&XML セクション及びCSS&JSセクションで、Set expires headerをONにした状態でCache Control policyを使用する場合、有効期限が経過すると、W3TCによって該当のリソースファイルが更新されるまで、Expired または max-age=0 となり、リソースは毎回ダウンロードされます

    ページキャッシュについては Page Cache メニュー AdvancedセクションにあるGarbage collection interval の値を、CSSおよびJSについては Minifyメニュー AdvancedセクションのUpdate external files every および Garbage collection intervalの値を調整することで、Expired または max-age=0 となる期間を少なくすることができますが、Set expires headerをOFFにした方が楽です。

  • max-age の指示がないキャッシュポリシーを選択し、Set expires header をOFFにした状態では、max-age=0と同様にリソースは毎回ダウンロードされます。Set expires header をONにすると有効期限までキャッシュを利用できます。

Cache Control policy のディレクティブ(構成オプション)

public

応答する内容が複数のユーザーによって再使用される場所にキャッシュできることを示します。通常、ユーザーの端末(ブラウザ)と配信元のサーバーの間には中間サーバーがあり、publicは、中間サーバーでもキャッシュ可能であることを意味します。

private

閲覧に使用している端末(またはブラウザ)内で、1人のユーザーだけが参照できるものとしてのみ、キャッシュすることが許されます。例えば個人的なユーザー情報を含む HTML ページはそのユーザーのブラウザでのみキャッシュに格納でき、上の public のようにCDNなどの中間サーバーで格納することはできません。

max-age

キャッシュされたリソースを再使用できる時間的長さを秒単位で示します。そのリソースを読み込んだ時を起点に指定時間が経過するまでブラウザはそのリソースをサーバーから再ダウンロードせずにキャッシュを使用できます。

ちょっと紛らわしいですが、キャッシュそのものの有効期限というよりも、キャッシュの整合性を再検証するまでの猶予期間といった感じで、下の revalidate と併用しなけれは再検証に失敗した未検証のキャッシュの使用も許容されるようです。

must-revalidate

キャッシュされたリソースを使用する際、有効期限等が切れている場合は、キャッシュの整合性を必ずオリジンサーバー(オリジナルのコンテンツが存在するWeb サーバーのこと)に再確認(≒検証)するように指示します。

確認できた時は最新版の提供または有効期限を更新しますが、確認できない時はキャッシュの使用を認めず、504 Gateway Timeout(≒時間切れでサーバーから取得できない)エラーを返すなど、期限切れのキャッシュの取り扱いは厳格です。

proxy-revalidate

中間サーバーを使用する場面で、認証されたユーザーからのリクエストに対してキャッシュ利用を可能にする一方で、各ユーザーが認証されていることを確認するため、中間サーバーに対して毎回 must-revalidate と同レベルの検証を要求します。

このディレクティブは、中間サーバーでのキャッシュを認めない private との併用はできず、public と合わせて使用することが前提となっています。

no-cache

no-cache は一見すると must-revalidate と似ていますが、その最大の違いは、キャッシュの有効期限に関わらず毎回整合性を必ずオリジンサーバーに再確認した上でキャッシュを使用するように指示する点です。これは他のどの指示よりもキャッシュの鮮度を最新に維持する ことを意味しますが、確認に成功して変更がなければリソースの再ダウンロードは省略できます。
なお、Expires header lifetime の指定と矛盾する場合はこちらが優先します。

※ no-cacheと同じ目的で期限切れ時の処理が厳格な、max-age=0, must-revalidate を組み合わせる方法もあります。

no-store

リソースのディスクへのキャッシュを禁止します。メモリ上にキャッシュする場合、使用後に可能な限り速やかに削除するように要求します。

いわゆるキャッシュの無効化(≒毎回リソースをダウンロードさせる)を指示するには、上の no-cache ではなくこちらをを使用しますが、より完全なキャッシュの無効化を指示するために、private, must-revalidate, no-cache, max-age=0 を併用(明記)するようです。

Set entity tag (ETag)

ETag(イータグ=エンティティタグ)は、各リソースに固有の値(ハッシュ値、フィンガープリントなどという)を付与することによって、リソースの変更を識別するための情報です。Etagは全てのファイルで異なるのはもちろん、同じファイルでも更新することで値が変化します。

似たような識別方法に、最新更新日時を示すLast-Modified header がありますが、日付だけだとサーバーの日付のずれなどで、正しいキャッシュ処理ができない可能性があります。EtagはLast-Modified header の不足を補完するのに有効なオプションです。

初期値はONで後続の3セクション全部で有効になっていますが、サーバー側で自動的に追加される場合がほとんどなのでOFFにしてもサーバーの応答情報に違いはありません。特別な事情がない限りOFFにする必要はありません。

Set W3 Total Cache header

トラブルシューティングや微調整に使うとされるいくつかのヘッダー情報を追加します。この情報自体はパフォーマンスに全く寄与しないので、OFFのままで構いません。

Enable HTTP (gzip) compression

GZIP圧縮は、サーバーとブラウザ(ユーザー)の間で転送されるデータのサイズを大幅に圧縮します。このオプションはサーバーに若干の負荷がかかりますが圧縮によるメリットが上回るので、基本的には全セクションで有効のままにしておくことが推奨となりますが、お使いの共用レンタルサーバー側で有効になっている場合はOFFにしても構いません。

Enable HTTP (brotli) compression

Brotli(ブロトリ)は上のGZIP圧縮よりも圧縮効率の高い方式です。お使いのサーバーでBrotli圧縮を利用できる構成になっていない場合はONにすることができませんが、利用できる場合は全セクションでONにしましょう。

Prevent caching of objects after settings change

このオプションをONにすると、CSSおよびJSファイル名に ?x12345 のような文字列が追加されます。この文字列は Browser Cacheメニューで設定を変更したり、CSSなどを編集した後に変化するので、これにより訪問者のブラウザは古い文字列のついたファイルのキャッシュを破棄して最新の文字列の付いたファイルを改めてダウンロードします。

結果、CSSファイルの編集やキャッシュポリシーの変更を速やかに反映させることができます。

Google PageSpeed Insights の改善項目「静的なアセットでの効率的なキャッシュ ポリシーの使用」をクリアするには、CSS,JS,画像ファイルの有効期限を1年に設定する必要があるため、CSSの変更時に訪問者のブラウザキャッシュを強制的に更新させるのに非常に有効です。

なお、このオプションはW3TCのMinifyを使用していなくても利用することができます。

CSS変更時などのファイル名の文字列変更操作

Update media query string

CSSファイルを変更したら、W3TCのダッシュボードまたはBrowser Cacheメニュー上部の Update media query string ボタンをクリックし、その後表示される Hide this message ボタンをクリックして完了です。キャッシュをクリアする必要はありません。ただし、W3TCでCSSやJSをMinifyしている場合は、Minifyのキャッシュをクリアしてください。

Remove query strings from static resources

このオプションをONにすると、オリジナルのリソースに付加されている ?から始まる文字列(クエリ―文字列)を取り除きます。たとえば style.css?ver=1.1 などがそうです。

特にONにする必要はありませんが、セキュリティ上の観点からWordPressのバージョン表記を消したいなどの要請がある場合はONにしても良いでしょう。なお、このオプションは上の Prevent caching of objects after settings change と併用可能です。

Prevent caching exception list

この欄には、2つ上の Prevent caching of objects after settings change でキャッシュを強制的に更新させるための文字列追加をしたくないファイルの場所を指定します。例えば以下のように記述します。

wp-includes/css/admin-bar.min.css

なお、この欄では正規表現を使って記述することもできます。

Don’t set cookies for static files

このオプションをONにすると静的ファイルにCookie情報をつけないことで、再訪問時のブラウザからサーバへの通信容量を削減してパフォーマンスを向上させます。全セクションでONにしておきましょう

この項目は、GTmetrixのYSlowスコアの評価項目 Use cookie-free domains に関係しています。

Do not process 404 errors for static objects with WordPress

このオプションをONにすると、削除されるなどして実体のなくなった画像などの404 Not Foundエラーを.htaccess側で処理し、WordPressの負荷を軽減させることができます。大量の404エラーが発生するようなサイトでは大きな効果を発揮します。初期値はOFFになっています。

404 error exception list

上のオプションには副作用があり、プラグインによってオンザフライ(≒リアルタイム)で生成されるファイルまで404エラーを返す場合があるので、この欄に例外処理となるファイル(404エラーになっているプラグインが生成しているファイル)を指定します。初期値では、SEO対策系のプラグインが出力する robots.txt や サイトマップ、ページキャッシュプラグインが出力するhtmlファイルなどが記述されています。

恐らく個人のブログであれば、初期値のままでも問題ないはずですが、エラーに対処する自信がなければこのオプションを使用しない方が無難です。

とはいえ、試してみたい場合は、とりあえずこのオプションをONにしておいて、Redirection プラグインなどで404ログをしばらくの間モニターすれば、リストに追加すべきファイルがあるかどうかわかるかもしれません。

Rewrite URL structure of objects

プラグインの説明書きによれば「ブラウザによるキャッシングから保護されている各ファイルに一意のURIを生成します。」とあり、通常ブラウザキャッシュできないファイルをキャッシュできるようですが、具体的にどのようなファイルなのかは不明でした。

ただ、このオプションによって不具合が出た事例がWordPress.orgのユーザーフォーラムにあり、OFFにしておいた方が無難なようです。

セキュリティーヘッダー

HTTPセキュリティヘッダーは、Webサイトへの安全な接続とコンテンツの利用などに関して、ブラウザレベルで保護層を追加する仕組みのひとつです。Webサイトへの攻撃に対するセキュリティの脆弱性を緩和するのに役立ちます。

設定に関しては、ブラウザキャッシュポリシーよりも技術的な知識が必要で、ほとんどの項目の初期値が空欄となっていることからもわかるように、Webサイトによって設定内容が異なるため、現状ではこのチュートリアルの対象範囲外としています(いずれまとめるかもしれません)。

なお、このチュートリアルの対象となる共用レンタルサーバーを利用される一般個人の方が運営されるサイトにおいて、セキュリティーヘッダーの設定は必須ではなく、サーバーで提供されているその他のセキュリティ対策等で充分かと思います。