WordPressサイトでW3 Total Cacheプラグインを設定する方法

有効インストール数100万件を超えるW3 Total CacheはWordPressで最も人気なキャッシュ／速度最適化プラグインの一つです。シンプルで簡易的なインターフェースを持つ他の最適化プラグインとは異なり、W3 Total CacheではWordPressサイトのキャッシュの設定を細かく調整することができます。

W3TCは高い自由度での設定ができるため、WordPressサイト全体をつぶさに管理したい上級者や開発者に最適なプラグインです。今回はW3 Total Cacheの設定について深掘りし、WordPressサイトのパフォーマンスを大幅に改善するためのおすすめの設定をご紹介します。

Kinstaユーザーの方はホスティングプランの中で既に多くの最適化の工夫がされているため、W3 Total Cacheで改めて変更する必要がない設定もあります。例えば、Kinstaをお使いのサイトではNGINXによるサーバーレベルのページキャッシュがデフォルトで有効になっているため、W3 Total Cacheで別途設定する必要はありません。Kinstaのレンタルサーバーをお使いのサイトでW3TCを設定する場合についても、この記事の中で設定手順を扱っています。必要のない、もしくはKinstaでは互換性のない設定についてもご紹介します。

W3 Total Cacheのインストール方法

W3 Total Cacheのインストールがまだであれば、WordPressの管理画面からインストールすることができます。「プラグインを追加」のページから、「W3 Total Cache」を検索し、「今すぐインストール」をクリックしインストールします。

W3 Total Cacheにはプロ版も存在し、BoldGridのサイトから購入できます。プロ版では、REST APIキャッシュ、Googleマップキャッシュ、拡張機能などいくつかの機能が追加で利用できるようになります。今回はWordPressプラグインページからインストールできる無料版についてご紹介します。

W3 Total Cache設定画面の開き方

W3 Total Cacheをインストールすると、WordPress管理画面のサイドバーに「パフォーマンス」というタブが表示されます。「パフォーマンス」タブをクリックすると、「一般設定」、「ページキャッシュ」、「圧縮」などの複数のサブメニューが表示されます。

WordPress管理ツールバーの「パフォーマンス」タブからもW3 Total Cacheの設定画面を開けます。

W3 Total Cacheでキャッシュを削除する方法

W3 Total Cacheの設定方法をご紹介する前に、キャッシュを削除する方法を簡単に見ていきましょう。管理ツールバーの「パフォーマンス」タブにマウスを当てるとキャッシュ削除の2つの選択肢が表示されます。

1. Purge All Caches – 全てのキャッシュを一括で削除
2. Purge Modules – 個別のキャッシュを削除（縮小したアセット、ページキャッシュ、オブジェクトキャッシュなど）

W3 Total Cacheの「一般設定」

W3 Total Cacheの「一般設定」画面から基本的な設定を変更しましょう。

ページキャッシュ

デフォルトでは、WordPressサイトへの全てのリクエストがリアルタイムでレンダリングされます。eコマースストアやディスカッションフォーラムなど一部のサイトにとって動的なレンダリングは欠かせませんが、ブログやニュースサイトなど、動的なコンテンツのないサイトではページキャッシュを行うことによりパフォーマンスが向上し、サーバーの負荷が下がることが期待できます。

Kinstaのレンタルサーバーをお使いの方はページキャッシュの設定を行う必要はありません。当社ではサイトのページを自動で静的なHTMLファイルとしてキャッシュする高性能なサーバーレベルの設定を適用しています。お使いのレンタルサーバー側でページキャッシュの設定をしていない場合には、W3 Total Cacheプラグインで有効化することができます。

圧縮

HTML、 CSS、JavaScriptのアセットを縮小し、不必要な余白を取り除き、サイト全体のサイズを小さくすることができます。多くのWordPressサイトの場合、W3 Total Cacheの「圧縮」機能を有効化し、「圧縮モード」で「自動」を選択すれば十分です。

時にアセットの圧縮によりCSSやJavaScriptのコードが破損してしまい、フロントエンドでエラーが発生してしまうことがあります。アセットを圧縮した後にサイトで見慣れない問題が発生した場合、開発者に依頼して問題の原因となっているアセットを特定することをお勧めします。その後、「圧縮」機能を手動で設定し、特定のCSS、JavaScriptファイルを除外することができます。

OPcache

WordPressは動的CMSなので、PHPが常に背後で処理されています。OPcacheはPHPをコンパイルし保存することで、後続の同じコードが必要とされるリクエストの処理を高速化し、サイトをスピードアップしてくれます。

Kinstaのレンタルサーバーをお使いであれば、W3 Total CacheでOPcacheを有効化する必要はありません。当社では全ての本番環境でOPcacheを有効化しています。コンパイルされたPHPコードがキャッシュされサイト開発やデバッグを妨げることがないように、ステージング環境ではOPcacheは無効になっています。

お使いのレンタルサーバーでOPcacheが設定されていない場合はW3 Total Cacheで有効化することをおすすめします。なお、OPcacheを有効化する機能はW3TCのプロ版でしか使用できませんのでご注意ください。

データベースキャッシュ

W3TCのデータベースにはMySQLデータベースクエリの結果が保存されます。この機能は一見便利なようですが、こちらは無効化して、代わりにオブジェクトキャッシュを利用することをおすすめします。

データベースキャッシュ機能は、時にCPUに高い負荷をかけることがあります。というのも、データベースクエリの結果を保存することによって削減できたCPUが、この機能の利用によるCPU増加で相殺されてしまう可能性があります。

オブジェクトキャッシュ

WordPressにおいて、オブジェクトキャッシュとは、データベースクエリの結果を保存することを意味します。WordPressには実は元からオブジェクトキャッシュ機能が備わっていますが、1ページ読み込み分のデータしか保持できません。この機能により、ページを読み込む際に同じデータベースクエリを何度も実行してCPUを無駄使いすることが避けられるため、より効率的にページを処理できるようになります。

WordPressに標準搭載のオブジェクトキャッシュでも間違いなくパフォーマンスに好ましい効果がありますが、複数のページの読み込みにわたってデータを保持できる方が理想的です。W3TCの「オブジェクトキャッシュ」機能は /wp-content ディレクトリに独自のキャッシュスクリプトを付け加えることで、WordPressのオブジェクトキャッシュがデータを永続的に（複数のページ読み込みにわたって）保持できるように動作を変更します。

Kinstaのレンタルサーバーをお使いでない場合、WordPressサイトでW3TCのオブジェクトキャッシュ機能を有効化し、データベースクエリを利用したリクエスト処理を高速化することをおすすめします。

Kinstaのレンタルサーバーをお使いであれば、Redisアドオンを用いた高性能オブジェクトキャッシュをご利用下さい。Redisはよくデータベースやメッセージブローカーアプリケーションに利用されるオープンソースのインメモリデータベースです。

RedisはRAMを用いてデータをキャッシュし、従来のキャッシュよりもはるかに高速な永続的オブジェクトキャッシュデータへのアクセスが実現します。

ブラウザーキャッシュ

ブラウザーキャッシュはCSS、JavaScript、画像、フォントなどの静的なアセットをブラウザに保存するもので、これによりWordPressサイトの読み込みを大幅に高速化できます。ブラウザーキャッシュには、アセットをどれだけの間キャッシュするかを指定するための有効期間があります。現在では、多くの開発者は静的アセットのキャッシュ有効期限を1年に設定しています。

Kinstaのレンタルサーバーをお使いの場合、静的ファイルのキャッシュ有効期限は1年に設定されています。これはKinstaのレンタルサーバー上で使用している静的ファイルの cache-control ヘッダーを見ることで確認できます。お使いのレンタルサーバーのキャッシュの有効期限が1年未満に設定されている場合、W3 Total Cacheの「ブラウザーキャッシュ」機能を有効化し、有効期限を設定することができます。

CDN（コンテンツデリバリネットワーク）

世界各国のデータセンターを利用して静的ファイルの負荷を軽減できるCDN（コンテンツデリバリネットワーク）をお使いの方は、W3 Total Cacheからテーマファイル、メディアライブラリのファイル、CSS、JSなどのURLをCDNホスト名で修正できます。

Kinstaのレンタルサーバーをお使いの場合、KeyCDNを利用した当社の高性能なコンテンツデリバリネットワーク、Kinsta CDNのご利用をおすすめします。Kinsta CDNを有効化すると、静的ファイルのURLは自動でKinsta CDNから配信されるよう上書きされます。

別のCDNプロバイダーを利用したい場合やKinsta以外のレンタルサーバーをご利用の場合、W3 Total Cacheで「CDN」機能を有効化し、お使いのCDNに応じたURLを追加することができます。

リバースプロキシ

リバースプロキシはウェブサーバーとWordPressの間で、受信するリクエストに対してロジックに基づいた様々な操作を行います。W3TCは人気のミドルウェアであるVarnishに対応しており、これを使って、データのキャッシュと配信を行うことで、バックエンドにおける負荷を軽減できます。

Varnishを利用するには、予めVarnishのパッケージがレンタルサーバー側でインストールされている必要があります。KinstaのレンタルサーバーのインフラストラクチャはVarnishに対応していないため、Kinstaのお客様は、このプラグインのリバースプロキシの項目は有効にしないようご注意ください。

ユーザーエクスペリエンス

W3TCの「User Experience」の項目では、遅延読み込みの有効化、絵文字とwp-embed.jsスクリプトの無効化ができます。ページの読み込み速度改善のためには遅延読み込みを有効化することをおすすめします。ブラウザ専用もしくはプラグインによる遅延読み込み機能をまだご利用でない場合には、W3 Total Cacheで遅延読み込みの設定をしておくことをおすすめします。

近年、多くのオペレーティングシステムはデフォルトで絵文字に対応しています。そのため、絵文字をあまり使わない場合には、WordPressに含まれる絵文字のスクリプトを無効化したいという方もいるかもしれません。W3TCを利用してwp-emoji-release.min.jsを削除することで、HTTPリクエストを削減し、ページから10KB程度の負荷を軽減することができます。

同様に、WordPressに他サイトからの投稿を埋め込まない方は、W3 Total Cacheでwp-embed.jsを無効化できます。このスクリプトを無効化してもSoundCloudのオーディオやYouTube動画の埋め込みに必要なoEmbed機能には影響はありません。

その他

W3 Total Cacheには他にもいくつかの設定があります。WordPressにGoogle Page Speed管理画面のウィジェットを表示したい場合、Page Speed APIキーを入力します。また、WordPressサイトの全てのページのメニューバーにPage Speedの評価を表示することもできます。

「Nginx サーバー構成ファイルのパス」、「ファイルロックを有効化、「NFS 向けにディスクの拡張ページを最適化する」など、その他の設定に関しては、特別な理由がない限りデフォルトの設定のままにしておくことをおすすめします。

デバッグ

サイトのトラブルシューティングをする時に便利なのが、特定のキャッシュや最適化の設定を無効化できるW3 Total Cacheの「Debug」機能です。例えば、サイト上に見た目の異常を見つけた場合、「圧縮」のデバッグモードを有効にします。すると、ページのソースコードにトラブルシューティングに使えるHTMLコメントが挿入されます。

デバッグモードはサーバーのリソースに負荷をかけるため、ステージング環境もしくはトラフィックの少ない時間帯のみに使用することをおすすめします。また、トラブルシューティングが完了したら必ずデバッグモードを無効にしましょう。

インポート／エクスポートの設定

設定の変更が完了したら、W3TCの「Import/Export」機能を利用して設定のバックアップをとりましょう。W3 Total Cacheにはたくさんの設定が存在するため、全てのバックアップデータをエクスポートしておくと安心です。また、独自のW3TCの設定を毎回手動で変更することなく、複数のサイトに簡単に適用することができます。

W3 Total Cacheの「ページキャッシュ」

ここからはW3 Total Cacheの「ページキャッシュ」の中身をさらに詳しく見ていきましょう。繰り返しになりますが、Kinstaのレンタルサーバーをお使いの場合、ページキャッシュを設定する必要がないため、この項目は飛ばしていただいて構いません。

• フロントページをキャッシュ – 多くのサイトでは、フロントページが最も訪問者の多いページです。そのため、この設定をオンにすることをおすすめします。
• フィードのキャッシュ – WordPressではFeedburnerなどの外部アプリやサービスでサイトのコンテンツを表示するための様々なRSSフィードが生成されます。現在では、RSSは以前ほどの人気はありませんが、この設定を有効にしておくことをおすすめします。
• Cache SSL (HTTPS) Requests – お使いのウェブサーバーで全てのリクエストを強制的にHTTPSへリダイレクトしていない場合、これ有効にすることでパフォーマンスが改善する可能性があります。既にサーバーレベルでHTTPSリダイレクトが実装されていれば、この機能を有効にする必要はありません。
• クエリ文字列変数を使ってURIでキャッシュを実行 – クエリ文字列とはURLの最後につくパラメーターです（/?version=123など）。クエリ文字列は通常WordPressデータベースの特定のデータをリクエストし、表示するのに利用されます。一般的にクエリ文字列の目的は特定の状態のページをリクエストすることなので、キャッシュしたい特定のクエリ文字列がない限りは、こちらの設定は無効にしておくことをおすすめします。
• 404 (Not Found)のページをキャッシュ – デフォルトではこちらのオプションは無効になっています。これはおそらく、ページキャッシュの方法に「Disk Enhanced」を選択している場合のキャッシュの動作に関連しているためです。この方法を選択した場合、404画面が200番台のレスポンスコードを返すようになります。本来404画面では、レスポンスコード404が返されるべきなので、選択しているキャッシュの設定でこの機能の互換性があるかどうかを確認することをおすすめします。
• ログイン済みユーザーに対してページをキャッシュしない – このオプションにはチェックを入れておくことをおすすめします。一般的に、ログイン中のユーザーはページの更新作業をしている可能性が高いと言えるでしょう。キャッシュを有効にしてしまうと、ユーザーは更新後の画面を閲覧するために、継続的にキャッシュをクリアしなければならなくなります。
• 以下のユーザー権限グループに対してページをキャッシュしない – こちらのオプションでは、特定のWordPressのユーザーグループにキャッシュが適用されないように設定ができます。既に「ログイン済みユーザーに対してページをキャッシュしない」にチェックが入っている場合、このオプションはキャッシュの動作に影響を与えません。

エイリアス

W3 Total Cacheのエイリアス機能は複数のドメインで表示される、同一のWordPressコンテンツをキャッシュすることができる機能です。この機能を有効化することはおすすめしません。あなたのWordPressサイトが複数のドメインからアクセスできる場合（domain.comとwww.domain.comなど）、Googleなどの検索エンジンによる重複コンテンツのペナルティを回避するために、301リダイレクトルールを設定し、リクエストをプライマリドメインにリダイレクトすることが推奨されます。

キャッシュプリロード

キャッシュプリロード機能は、サイトマップをクロールし、サイトの各ページにリクエストを送信し、ページキャッシュをプリロードします。サーバーのリソース使用量が一気に増加し、本来のパフォーマンス面でのメリットを打ち消してしまう可能性があるため、多くの場合、この機能は無効のままにしておいた方がいいでしょう。

キャッシュプリロードの機能を有効にする場合、サイトマップのURL、実行する間隔、1回毎に実行するページ数を指定できます。CPUの負荷を軽減するために、更新の間隔と実行するページ数はあまり高く設定しすぎないようにしましょう。

パージポリシー

W3TCのパージポリシー（実際の表記は「ポリシーをパージ:」）では、投稿が公開もしくは編集された後に自動でキャッシュを削除したいページやフィードを指定できます。大概は、デフォルトの設定（フロントページ、投稿ページ、ブログフィード）で十分です。新たにページを追加したい場合は、様々な設定から選ぶことができます。

REST API

WordPressに含まれるREST APIではJSON形式データのクエリが可能です。REST APIは様々なプラグインで使用されており、ヘッドレスWordPressでは必要不可欠です。REST APIの活用方法によっては、クエリの結果をキャシュした方がよい場合もあります。REST APIのキャッシュは、状況によっては調整すべき項目です。こちらを有効化すべきか分からない場合は、キャッシュしない方を選択しておきましょう。

詳細

W3TCの「ページキャッシュ」ページにある「詳細」では、「利用可能なクエリー文字列」、「拒否されたユーザーエージェント」、「以下のページはキャッシュしない」など様々な設定ができます。例えば、特定のカテゴリーやタグの投稿をキャッシュしないようにしたい場合、このオプションで設定が可能です。

こちらは個別のサイトによって大きく異なるため、おすすめの設定というものが存在しません。非常に具体的なサイトのページキャッシュの動作を調整したい場合は、この「詳細」の項目に一度目を通してみてください。

W3 Total Cacheの「圧縮」

次は、W3 Total Cacheの「圧縮」の設定を見ていきましょう。

• URL 構造をリライト – この設定は、圧縮したアセットのURL構造に影響を与えます。URLを「美しく」保ちたいのであれば有効にしておきましょう。
• ログイン中のユーザーに対する圧縮を無効化 – トラブルシューティングやデバッグを行う際は、ログイン済みのユーザーに対して圧縮を無効にしましょう。それ以外はこの項目はチェックなしのままで大丈夫です。

HTMLとXML

「HTMLとXML」の項目では、HTMLの圧縮に関する設定ができます。

• インライン CSS 圧縮 – インラインCSSの余白を削除するためにこちらは有効にすることをおすすめします。
• インライン JS 圧縮 – インラインJavaScriptの余白を削除するためにこちらも有効にすることをおすすめします。時に、JS圧縮によりコードエラーが発生することがあります。こちらを有効化したことでサイトの機能が損なわれるようであれば、チェックを外して無効にしましょう。
• フィードを圧縮しない – この機能にはチェックを入れても問題ありません。フィードはRSSリーダーやそれに類するサービスでしか使用されないので、フィードの圧縮は必須とは言えないでしょう。
• 改行削除 – こちらはデフォルトで未選択になっています。サイトが正しく表示されるよう、そのままにしておくことをおすすめします。

JS

「JS」の項目では、JavaScriptの圧縮に関する設定ができます。

• エリアの操作 – ここでは、圧縮したJavaScriptの「埋め込み形式」を選択できます。 の前と の後について、「デフォルト（ブロック）」、「JSを使用した非ブロック」、「“async”を使用した非ブロック」、「“defer”を使用した非ブロック」のいずれかを選択できます。非ブロックの読み込みではより大幅なパフォーマンスの改善が見られますが、全てのJavaScriptコードと完全に互換性があるわけではありません。さらに、「async」と「defer」は全く異なるケースで使用されます。そのため、JavaScriptの非ブロックにおける特殊な動作を理解している方以外はデフォルトの「ブロック」のままにしておきましょう。
• Minify engine settings – JavaScriptに関する3つの最適化モードから選択できます。「Combine & Minify」を選択した場合、JSファイルは結合・圧縮されます。「Minify only」では圧縮のみが実行されます。「結合のみ」を選択すると、結合後のJSファイルは圧縮されません。圧縮に関連した問題が発生して、問題を引き起こしているスクリプトを特定するのが面倒だという場合は、「結合のみ」を選択することで問題が解決できる場合があります。
• HTTP/2 Push – お使いのレンタルサーバーがHTTP/2サーバープッシュに対応している場合、こちらを有効化することでページの読み込み時間が短くなる場合があります。HTTP/2サーバープッシュはリクエストされる前にコンテンツをクライアントに送るというものです。サーバープッシュは実際には誤用されることが多いので、本番環境に反映する前に十分テストを行いましょう。サーバープッシュはサイズの大きなJavaScriptファイルには適していません。利用する前に、クライアントのブラウザキャッシュから直接JSファイルを読み込むことよりもこの機能によりメリットが上回るかどうかを十分確認しましょう。

CSS

「CSS」のセクションでは、CSSの圧縮に関する設定ができます。

 

• 結合のみ – JavaScriptファイルとは異なり、CSSは通常圧縮により問題を引き起こすことはありません。そのため、「結合のみ」を選択することはおすすめしません。
• 保護されたコメントを除去 – この設定はCSSファイルからコメントを取り除きます。できる限りファイルサイズを縮小するためにこちらのオプションにチェックを入れることをおすすめします。
• 改行を除去 – こちらはCSSファイルの改行を削除する機能です。これにもチェックを入れることをおすすめします。有効化した後に表示に何らかの問題が発生した場合には、チェックを外しましょう。

詳細

「詳細」の項目には圧縮の挙動を変更するための追加の設定がいくつかあります。

• 外部ファイルを以下の間隔で更新 – CSSとJSファイルの更新の間隔を指定できます。デフォルト設定である86400秒では、24時間毎にアセットがダウンロード、圧縮されます。サイトを頻繁に変更しないのであれば、より長い間隔を設定しても大丈夫です。
• ガベージコレクション間隔 – 有効期限切れのキャッシュデータを削除する頻度を設定できます。デフォルトでは24時間に設定されています。サイトのストレージが残り少ない場合、数値を低く設定することをおすすめします。

「詳細」には他にも、圧縮しないアセットファイルを指定する機能や、「拒否されたユーザーエージェント」（圧縮されていないファイルを特定のユーザーエージェントに配信する）などの機能があります。また、外部のアセットファイルをW3 Total Cacheの圧縮プロセスに含めることもできます。

W3 Total Cacheの「オブジェクトキャッシュ」

次はW3TCのオブジェクトキャッシュの設定をご紹介します。多くの場合、デフォルトの設定で十分ですが、念のため一通りご説明します。

 

• キャッシュオブジェクトのデフォルトの有効期間 – 変更の加えられていないキャッシュ済みアイテムの有効期限が設定できます。有効期限が長いほどオブジェクトキャッシュは肥大化します。サーバーのストレージ容量が心配な場合は、デフォルトの値にしておくか、それよりも低い値に変更しましょう。
• ガベージコレクション間隔 – 有効期限切れのキャッシュデータを削除するまでの間隔を設定できます。大抵の場合、デフォルトの値である3,600秒（1時間）のままで問題ありません。
• グローバルグループ – 同一のマルチサイトネットワーク内のサイト間で共有するキャッシュグループの設定ができます。こちらは特別な理由がない限りデフォルトの値のままにしておくことをおすすめします。
• 非永続グループ – キャッシュしないオブジェクトグループを指定できます。こちらもデフォルトの設定のままにしておくことをおすすめします。
• Enable Caching for wp-admin Requests – こちらのオプションはデフォルトでは無効になっており、チェックを入れると問題が発生することがありますので、そのままにしておくことをおすすめします。どちらにせよ、大半のサイト訪問者はwp-admin管理画面へ何らかのリクエストをすることはないでしょう。

W3 Total Cacheの「ブラウザーキャッシュ」

Kinstaを含め、多くのWordPressに特化したレンタルサーバーはサーバーレベルで既に適切なブラウザキャッシュヘッダーを採用しているはずです。お使いのレンタルサーバーで対策がされていない場合、もしくはブラウザにおけるキャッシュの挙動を変更したい場合は、W3 Total Cacheを利用することができます。

大半のサイトの場合、「ブラウザーキャッシュ」の設定の中の「一般」、「CSS & JS」、「HTML & XML」、「メディアとその他のファイル」にあるデフォルトの設定で十分です。これらの項目にはたくさんの設定があるので、ブラウザにおけるキャッシュの扱い方に何らかの変更を加える際は、事前に開発者に相談することをおすすめします。念のために、「ブラウザーキャッシュ」の主な設定をいくつかご紹介します。

• Expiresヘッダーを設定 – 長めの「Expiresヘッダーの有効期限」を設定することは効率的なブラウザキャッシュの第一歩です。KinstaではCSS、JS、画像、フォントなど、静的なアセットに関しては1年間の有効期限を設定しています。W3TCで「ブラウザーキャッシュ」を設定する場合には、こちらの値を 31536000（1年）に設定しましょう。
• キャッシュコントロールポリシー – 静的アセットをブラウザでキャッシュできるよう、「キャッシュコントロールポリシー」を「Cache with max-age (“public, max_age=EXPIRES SECONDS”」に設定しましょう。
• HTTP (gzip)圧縮を有効化 – GZIP圧縮はHTMLページとアセットがサイト訪問者に配信される前にファイルサイズを大幅に削減できます。レンタルサーバーがGZIPに対応しているのであれば、こちらのオプションを必ず利用しましょう。Kinstaのレンタルサーバーをお使いの方はデフォルトで既に有効化されているので、W3TCで別途設定する必要はありません。
• Remove query strings from static resources – クエリ文字列はリクエストのパラメーターを指定したり、ウェブサーバーに強制的に最新のアセットを配信させたりするためにURLパスの最後に付け加えられる文字列です。クエリ文字列は?で始まり、大半のウェブサーバーではクエリ文字列を含むリクエストはキャッシュしないように設定されています。クエリ文字列は、ページの表示にPHPを使用するため、これをページのリクエストから削除することで、サーバーにおける負荷を軽減することが可能です。しかし、静的リソースのクエリ文字列は訪問者に最新の状態のCSS／JSファイルを配信するのに必要になるので、W3 Total Cacheでこれを削除してしまうことはおすすめしません。

「ブラウザーキャッシュ」の設定画面にはコンテンツセキュリティポリシー（CSP）、X-XSS Protectionなど、セキュリティヘッダー関連の様々な設定も含まれています。これらの設定はサイトのユーザーエクスペリエンスに直接影響を与える可能性があるので、変更を加える際は必ず熟練の開発者の助言を求めることをおすすめします。例えば、適切なSSLサーバー証明書とHTTPSの設定なしにHSTSヘッダーを有効にすると、サイトにアクセスできなくなることがあります。

W3 Total Cacheの「ユーザエージェントグループ」

W3 Total Cacheの「ユーザエージェントグループ」ではユーザーの端末の種類によってリダイレクトを実行したい場合に非常に便利です。例えば、スマホでサイトを訪問したユーザーには別のテーマを表示するよう設定することができます。同様に、例えば、モバイル版のサイトがサブドメインに位置している場合には、該当する訪問者をそのサイトにリダイレクトすることも可能です。

レスポンシブデザインが普及した今、この機能を使う機会は減っているはずです。現在では、複数のテーマやモバイル専用のサブドメインを利用するのではなく、最初からサイトをレスポンシブにするのが理想的です。

W3 Total Cacheの「リファラーグループ」

HTTPリファラーはリクエストがどこからきたかを把握するための情報を提供してくれるHTTPヘッダーです。例えば、訪問者がGoogleの検索結果にあるリンクをクリックしてきた場合、HTTPリファラーはgoogle.comとなります。

W3 Total Cacheでは、「リファラーグループ」を用いて、リクエストのHTTPリファラーに応じて別々のキャッシュの挙動を指定することができます。例えば、各種検索エンジンで構成されるリファラーグループを作成し、それらのドメイン専用のキャッシュの挙動を設定することができます。

「ユーザエージェントグループ」と同様に、「リファラーグループ」機能でもリクエストを別のドメインにリダイレクトすることができます。多くのWordPressサイトでリファラーグループの設定は必要ないはずですので、こちらは何も設定しなくて大丈夫です。

W3 Total Cacheの「Cookie Groups」

W3 Total Cacheの最新のキャッシュ機能が「Cookie Groups」です。こちらの機能では、リクエストのクッキーに応じて、別々のキャッシュの挙動を指定することができます。「ユーザエージェントグループ」、「リファラーグループ」と同様に、多くのサイトではクッキーに応じたキャッシュの設定は必要ありません。こちらの設定が必要な場合は、開発者と相談し正しく調整することをお勧めします。

W3 Total Cacheの「CDN」

次はW3 Total Cacheの「CDN」の設定です。

• ホスト添付ファイル – WordPressのメディアライブラリ内のアセットをCDN経由で配信するには、こちらにチェックを入れましょう。
• wp-includes/ files のホスト – wp-includes フォルダ内のファイルをCDN経由で配信する場合にこちらを有効化します。
• テーマファイルのホスト – テーマファイルをCDN経由で配信する場合にこちらを有効化します。
• ホストが CSS と JS ファイルを圧縮しました（注釈：「CSS、JSファイルを圧縮しホストする」の意味） – W3TCで圧縮したCSSおよびJSファイルをCDN経由で配信する場合にこちらにチェックを入れてください。
• カスタムファイルのホスト – メディアライブラリ、もしくはテーマフォルダ内にないファイルについては、W3TCにファイルパスを追加しCDN経由で配信することができます。
• カノニカルヘッダーを追加 – rel=”canonical” タグは検索エンジンがオリジナルソース、もしくはURLを特定するのに使われます。CDNには通常異なるドメインが使われるため、canonicalタグを追加することで検索エンジンに対し元のアセットの位置を知らせることができます。とは言え、現在では、検索エンジンは自力でCDNを特定でき、検索結果のランキングに悪影響は出ないので、この機能は使わないで大丈夫です。

詳細

• Only Purge CDN Manually – W3TCが自動でキャッシュを削除するよう、この設定にはチェックを入れないままにしておきましょう。
• SSLのページでCDN を無効化 – こちらもチェックなしにしておきましょう。CDNを利用する場合、HTTPとHTTPSの両方で有効にするのが一番です。
• Use CDN Links for Media Library on Admin Pages – この設定を有効化するとメディアライブラリのURLが書き換えられてしまうため、チェックなしのままにしておくことをおすすめします。
• Add CORS Header – CDNのアセットが他のドメインでも表示されるよう、この設定にはチェックを入れましょう。
• 以下の権限グループに対してCDNを無効にする – この設定は特定のWordPressユーザー権限グループに対してCDNを無効にすることができます。このオプションは通常、チェックなしで大丈夫です。
• アップロードするwp-includesファイルタイプ – ここではCDNから配信されるwp-includes内のファイル形式を指定できます。多くの場合、デフォルトのファイル形式の一覧のままで問題ありません。wp-includesフォルダに独自のファイルがある場合、必要に応じて新たな形式を追加してください。
• アップロードするテーマファイルの種類 – ここではCDNから配信されるWordPressテーマフォルダ内のファイル形式を指定できます。デフォルトの一覧ですでに、一般的なアセット、画像、フォントの形式が網羅されています。必要があれば、新たな形式を追加しましょう。
• カスタムファイル一覧 – 「カスタムファイルのホスト」を有効にすると、CDNから配信するファイルの一覧を追加できるようになります。
• 拒否されたユーザーエージェント – ここではCDN経由でアセットを受け取らないユーザーエージェントを指定できます。CDNが適切に活用できるよう、ここは空欄にしておきましょう。
• リジェクトされたファイル – ここではCDN経由で配信しないファイルを指定できます。ご利用のサービスの中に、ルートドメインから配信されたアセットしか使用できないものがある場合、「リジェクトされたファイル」の欄にファイルパスを追加することができます。

W3 Total Cacheの「User Experience」

次はW3 Total Cacheの「User Experience」、遅延読み込みの設定を見ていきましょう。

• Process HTML Image Tags – 画像に遅延読み込みが適用されるよう、こちらにチェックを入れましょう。
• Process Background Images – 画像をCSSで表示するのに「background」を使用している場合、こちらを有効化すると遅延読み込みが適用されます。
• Exclude Words – ここでは、遅延読み込みを適用しないテキストを指定できます。例えば、この欄に no-lazy-load と入力すると、<img src="image.jpg">で表示される画像は遅延読み込みが適用されません。
• Script Embed Method – ここでは、遅延読み込みの方法を変更できます。デフォルトのasyncが多くの場合最適です。あなたのサイトが一つのランディングページのみで構成されている場合、ページの読み込みのHTTPリクエストの数を低減するのにinlineメソッドを利用することもできます。

W3 Total Cacheで利用できる拡張機能

W3 Total Cacheには外部サービスと連携するための様々な拡張機能が存在します。現在W3TCで利用できる拡張機能は次の通りです。

• AMP
• Cloudflare
• Google Feedburner
• Fragment Cache
• Genesis Framework
• New Relic
• Swarmify
• Yoast SEO
• WPML

サイトで上記のうちいずれかのサービスを利用している場合、W3 Total Cacheとの互換性を維持するために該当の拡張機能をセットアップしましょう。ここでは、W3 Total CacheのCloudflare拡張機能をご紹介します。

Cloudflare拡張機能でW3 Total Cacheを設定する方法

CloudflareとW3 Total Cacheの連携のためには、Cloudflare管理画面から二つの情報を確認する必要があります。アカウントメールアドレスとAPIキーです。アカウントメールアドレスとはCloudflareにログインする際に使用するメールアドレスです。CloudflareのAPIキーを設定する方法をご紹介します。

Cloudflareの管理画面から「Overview」のタブをクリックします。次に、右側のサイドバーをスクロールし、「Get Your API Token 」をクリックします。

スクロールし、「Global API Key」のとなりの「View」をクリックしCloudflareのAPIキーを取得します。APIキーがあればCloudflareアカウントをコントロールできてしまうので、W3 Total Cache以外の場所では決して共有しないようにしましょう。

次に、W3 Total Cacheの「拡張機能」画面からCloudflare拡張機能を有効化し、「Settings」をクリックします。「Credentials」のセクションから「Authorize」ボタンをクリックします。

次のポップアップ画面で、CloudflareのアカウントメールアドレスとAPIキーを入力します。エラーメッセージが表示される場合、メールアドレスとAPIキーが正しいかどうか再度確認しましょう。認証情報が認証されると、画面上に新たにCloudflare設定のメニューが追加されるはずです。

W3 Total CacheのCloudflareについての設定を見ていきましょう。

• Widget Statistics Interval – W3TCのCloudflareウィジェットでカバーされる時間を指定できます。デフォルトの設定は30分です。より長い時間を設定したければ変更しましょう。
• Cache Time – Cloudflareのウィジェットデータがキャッシュされる時間を設定できます。ウィジェットをあまり使わない場合は、サイトからCloudflareからのリクエストの数を減らすためにこの数字を大きくすることをおすすめします。
• Page Caching – CloudflareでWordPressサイトのHTMLページをキャッシュする設定をしている場合、投稿を修正、更新した後にCloudflareのキャッシュを自動で削除するためにこの設定にチェックを入れておきましょう。

Cloudflareのキャッシュ

ここではCloudflareのキャッシュの設定を調整できます。

• Development Mode – Cloudflareを開発モードにする時以外はこのオプションは無効にしておきましょう。Cloudflareが開発モードの時、エッジキャッシュ、圧縮、画像最適化は3時間無効化されます。これにより、CSSおよびJSファイルの更新を瞬時に確認することができ、トラブルシューティングに便利です。
• Cache Level – 多くのサイトで、クエリ文字列が変わる度に異なるリソースを配信する「Standard」キャッシュレベルを選択するのが最適です。あなたのサイトがクエリ文字列を利用した動的コンテンツの生成を行っていないと確実に言える場合は、「Ignore Query String」を選ぶこともできます。
• Browser Cache TTL – CloudflareのブラウザーキャッシュTTLは31536000、つまり1年間に設定することをおすすめします。
• Challenge TTL – Cloudflareでは様々なセキュリティ関連のサービスを提供しており、「ビジターチャレンジ」はそのうちの一つです。不正な、または不審な動作を検知すると、Captcha のかたちで確認用のメッセージが表示されます。「Challenge TTL」の設定では、チャレンジに成功した後、ユーザーがどれだけの時間サイトにアクセスできるかを設定できます。デフォルトの3600秒では、チャレンジの対象となったユーザーは再度チャレンジが表示されるまで1時間サイトに滞在できることになります。
• Edge Cache TTL – ここでは、Cloudflareのエッジサーバーでどれだけの時間アセットがキャッシュされるかを設定できます。こちらは最大値である31536000秒（1年）に設定することをおすすめします。

Cloudflareのコンテンツ処理

次はW3 Total CacheでのCloudflareのコンテンツ処理の設定を詳しく見ていきましょう。

• Rocket Loader – CloudflareのRocket LoaderはWordPressサイトでのJavaScriptの読み込みを高速化します。サイトでJavaScriptをたくさん使用している場合、Rocket Loaderを有効にすることをおすすめします。
• Minify JS/CSS/HTML – W3 Total Cacheで既にHTML、CSS、JavaScriptの圧縮を有効化している場合、Cloudflare拡張機能のこちらの設定は無効にしておきましょう。既に圧縮されたアセットをさらに圧縮する必要はありません。
• Server Side Exclude (SSE) – こちらは（Cloudflareの判断する）不審な訪問者に対して機密情報を隠すことができる設定です。メールアドレス、電話番号などサイト上の個人情報を隠すのに便利です。SSEを利用するには、こちらの設定を有効化し、HTMLコードやPHPテーマテンプレート内の機密情報を<!--sse--><!--/sse-->タグで囲います。
• Email Obfuscation – この設定が有効化されると、JavaScriptによってWordPress上のメールアドレスが自動で難読化されます。難読化によってスパムを完全に防ぐことができるわけではありませんが、基本的なボットがサイト上でメールアドレスをスクレイピングするのを防ぐのには役立ちますので、有効化しておくことをおすすめします。

Cloudflareの画像処理

次はCloudflareの画像処理の設定です。

• Hotlink Protection – 直リンク防止を有効化しておくと、他のサイトにあなたの画像を埋め込まれるのを防ぐことができます。許可なく外部に画像が埋め込まれたことによって帯域幅が逼迫している場合、「Hotlink Protection」を有効化することで抑えることができるかもしれません。
• Mirage（Pro版のみ） – Mirageは低帯域幅の端末やネットワークでの画像の表示を最適化します。この機能はCloudflare Proかそれ以上のプランでしか利用できません。
• Polish（Pro版のみ） – Polishはサイトの画像を最適化する機能で、対応したブラウザではWEBP画像を表示する設定もできます。こちらの機能もCloudflare Proかそれ以上のプランでしか利用できません。

Cloudflareのセキュリティ

Cloudflareのメインの機能はDDoS攻撃や悪意のあるユーザーからサイトを保護する洗練されたファイアウォールとしてのものです。Cloudflareのセキュリティの設定について見ていきましょう。

• Security Level – こちらの設定ではCloudflareのファイアウォールとセキュリティルールの感度を調整できます。多くの場合、「Security Level」は「Medium」に設定するのがおすすめです。
• Browser Integrity Check – こちらは悪意のある行動や不審なユーザーエージェントを警戒する機能です。不審な、またはスパム送信者の疑いのあるユーザーを検知すると、自動でチャレンジが表示されます。この設定は有効化しておくことをおすすめします。
• Always Online – こちらの設定を有効にしておくと、オリジンサーバーがダウンした際に静的HTMLページを表示してくれます。CloudflareでHTMLをキャッシュする設定をしている場合、こちらを有効化することをおすすめします。
• Web Application Firewall – CloudflareのWAF（ウェブアプリケーションファイアウォール）は流入するトラフィックをスキャンし、違法なトラフィックがサイトに入り込むのを防ぎます。こちらの機能も有効化することをおすすめします。
• Advanced DDoS Protection – こちらはデフォルトで有効になっています。Cloudflareのプロキシが有効である限り無効にすることはできません。DDoSに警戒することで「分散型サービス妨害」攻撃からサイトを守ります。
• Max Upload – こちらはサイトにアップロードできる最大ファイルサイズを設定できます。この値がWordPressのアップロードファイルサイズの設定と同じまたはそれよりも大きくなるようにしましょう。

CloudflareのSSL

最後に、CloudflareのSSLの設定についてです。その適切な設定についてご紹介します。

• SSL –Kinstaのレンタルサーバーをお使いの方は「Ful」または「Full (Strict)」を選択することをおすすめします。「Flexible」は当社のインフラストラクチャとの互換性がありません。「Full Strict」は有効な認証局の発行するSSLが必要ですが、「Full」は自己署名証明書にも対応しています。「Flexible」ではオリジンサーバーにSSL証明書は必要ありません。こちらのオプションは最も安全性が低いためおすすめしません。
• TLS 1.2 Only – TLS（トランスポート・レイヤー・セキュリティ）はネットワークでデータを通信するための保護プロトコルです。PCIコンプライアンス基準の中にはTLS 1.1以下への非対応を要求している場合があります。あなたのサイトにそのような要件がある場合、「TLS 1.2 Only」を有効にすることで、TLS 1.2を最低要件とすることができます。

WordPressでCloudflareのAPOを設定する方法もあわせてご覧下さい。

W3 Total CacheのWooCommerceの設定

WooCommerceはWordPressサイトで使える人気のECプラットフォームです。WooCommerceを利用したストアでW3 Total Cacheを使用する場合、顧客の情報をキャッシュしてしまわないように、設定には気をつけましょう。

WooCommerceのクッキーのキャッシュを除外する

WooCommerce専用のクッキーを使用したページのキャッシュを除外するには、W3TCの「ページキャッシュ」を開き、「拒否されたクッキー」へスクロールし、次の4つを追加します。

• woocommerce_items_in_cart
• woocommerce_cart_hash
• wp_woocommerce_session_
• wordpress_logged_in

念のため、カート（買い物かご）の画面、チェックアウト（決済）画面、アカウント画面などWooCommerce専用のURLも除外することをおすすめします。これらの画面を除外するには、W3TCの「ページキャッシュ」設定を開き、「以下のページはキャッシュしない」にURLを入力します。

W3 Total Cacheの全ての設定をリセットする方法

W3TCの設定を全てやり直さなければならない…なんてこともあるかもしれません。W3 Total Cacheをデフォルトの設定に戻す方法は次の通りです。W3TCの「一般設定」メニューを開き、「インポート / エクスポートの設定」までスクロールし、「デフォルトの設定を復元」をクリックします。

まとめ

これまで見てきたとおり、W3 Total Cacheにはたくさんの機能や設定があります。ページキャッシュ、アセットの圧縮、Cloudflareとの連携など、W3TCにはWordPressサイトのパフォーマンスを改善するのに必要なものが全て揃っています。

今回はW3TCプラグインのおすすめの設定を一通りご紹介しました。あなたのおすすめのWordPress最適化プラグインはありますか？コメント欄で是非お聞かせください！