W3 Total Cache 設定ガイド

Browser Cache|ブラウザキャッシュ

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

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

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

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

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

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

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

Set Last-Modified header

CSS、JS、HTMLなどのリソースの最終更新日時をサーバーの応答内容に含めます。

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

ブラウザは、初回に受け取った Last-Modified の値を、次回アクセス時にサーバーから提供される Last-Modified の値と比較して、リソースの新旧を判断し、最終更新日時に変化がなければブラウザ内のキャッシュを使用するためパフォーマンスが向上します。

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

Set expires header

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

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

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

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

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種類から選択するようになっています。通常は初期設定(下記2番目)のままで問題ありません。

  1. cache(“public”)
  2. cache with max-age (“public, max-age=EXPIRES_SECONDS”)
  3. cache with validation (“public, must-revalidate, proxy-revalidate”)
  4. cache with max-age and validation (“max-age=EXPIRES_SECONDS, public, must-revalidate, proxy-revalidate”)
  5. cache without proxy (“private, must-revalidate”)
  6. no-cache (“max-age=0, private, no-store, no-cache, must-revalidate”)

W3TCのCache Control policyの詳細はこちらを参照してください。

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にしましょう。

(参考)Brotli not enabled even though server supports it

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変更時などのファイル名の文字列変更操作

CSSファイルを変更したら、W3TCのダッシュボードまたはBrowser Cacheメニュー上部の Update media query string ボタンをクリックし、その後表示される Hide this message ボタンをクリックして完了です。ただし、ページキャッシュや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にしておいた方が無難なようです。

(参考)gallery images don’t show – WP Snapcam

セキュリティーヘッダー

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

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

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