「設定が難しい」と言われる「W3 Total Cache（W3 トータル・キャッシュ）」ですが、ウェブサイトの特徴や、サーバーのスペックなどに合わせて最適な設定ができれば、強力なキャッシュプラグインとしての恩恵を受けることができます。

W3 Total Cacheは、データベースキャッシュや、オブジェクトキャッシュなど、様々なキャッシュ機能をトータルで設定、管理できます。

サーバのスペックが高い場合、W3 Total Cacheの機能をフル活用できます。

W3 Total Cacheの特徴

1. 細やかな設定ができるため、キャッシュプラグイン特有のトラブルを回避する事ができます。
2. ページ数が多いウェブサイトの場合は、他のキャッシュプラグインよりサーバも安定しており、ウェブサイトの表示速度も高速です。
3. 専用サーバー、またはVPSサーバーでメモリーの割当に余裕がある場合、MemcachedやRedisなどのメモリーへのキャッシュが可能です。

Page Speed Insigntsの結果

ページ速度改善のチューニングはW3 Total Cacheだけではありませんが、W3 Total Cacheによるキャッシュで大幅に改善されています。

Page Speed Insightsで計測した結果が下記になります。

W3 Total Cacheの設定方法

W3 Total Cacheをインストールするとセットアップガイドが表示されますので「スキップ」をクリックして手動で設定していきます。

W3 Total Cacheの設定は手動で設定を進めていきます。

設定の前に気をつける点

これから設定を進めていきますが、気をつける設定が「データベスキャッシュ（Database Cache）」と「オブジェクトキャッシュ（Object Cache）」の設定です。

W3 Total Cacheで不具合が起こる原因がこの２つのキャッシュ設定です。

この2つのキャッシュ設定は、サーバのスペックに合わせて設定することが重要になりますので、設定の時には慎重に設定することになります。

そのため設定の手順としては下記になります。

1. 基本的な設定のページキャッシュ
2. 圧縮
3. ブラウザキャッシュ
4. データベースキャッシュ（無効でも良い）
5. オブジェクトキャッシュ（無効でも良い）
6. CDN（CDNを利用していない場合は無効）

データベースキャシュ、オブジェクトキャッシュを無効にしても、パフォーマンスの良い結果を得えることができます。

また、ウェブサーバーにキャッシュ機能があればOFFにしてからW3 Total Cacheの設定を進めます。

ページキャッシュ

ページやクエリ、HTTPヘッダーなどのキャッシュについての設定ができます。

一般

ページやRSSフィードなどのキャッシュ設定になります。

• 投稿ページをキャッシュはON
• フロントページはキャッシュしないはOFF
• フィードのキャッシュはON
  RSSフィードの配信をしていない場合はOFF
• XML MIME タイプを処理はON
  サイトマップのXMLを生成している場合はONにします。
• SSL (HTTPS) リクエストをキャッシュはON
• クエリ文字列変数を使ってURLでキャッシュを実行は、サイト内検索があり、よく検索されている場合はONにすると検索結果がキャッシュされます。
• 404 (not found) ページのキャッシュはON
  404Not Foundページが無い場合はOFFにします。
• ログイン済みユーザーに対してページをキャッシュしない。は、ONにします。
• 以下のユーザー権限グループに対してページをキャッシュしない。は、ユーザーレベルごとにキャッシュの表示・非表示を設定できます。運営に合わせて適宜設定してください。

Aliases

ミラーサイトなど、複数のドメインで同じコンテンツが存在する場合に設定します。
通常のウェブサイトはOFFにします。

該当するウェブサイトの場合はONにして「Additional home URLs」にドメインを記入します。

キャッシュプリロード

キャッシュはアクセスされたページがキャッシュされ、2回目の表示からキャッシュが表示されるため表示が早くなります。

ページへのアクセスが無くても、事前にページをキャッシュするのが「キャッシュプリロード」機能になります。
便利な機能ですが、ページ数が多い場合はサーバーに負荷がかかります。そのためOFFでも問題はありません。

キャッシュプリロードをONにした場合は自動的にキャッシュする間隔やプリロードするタイミングを設定できます。

• 更新期間は、15分（900秒）間隔で良いでしょう。
• キャッシュするページ数は10で良いでしょう。サーバーの負荷を抑えたい場合はページ数を減らします。
• サイトマップURLにsitemap.xmlのURLを記載すると、sitemap.xmlの情報を基にページをキャッシュしていきます。
• Preload cache upon publishing a postはONにします。
  非公開のページが公開になった時にキャッシュするようになります。
• Preload cache upon updating a postは、ON、OFFどちらでも良いです。
  ページが更新された後にキャッシュされます。

パージポリシー

記事やページの投稿・更新をした際のキャッシュのパージ（削除）を設定できます。

パージもサーバに負荷がかかるため、パージさせるコンテンツは少ない方が良いです。

• 削除するフィードの種類は、全てOFFでも良いでしょう。
• パージ上限は、アーカイブのパージ上限を設定できます。全て削除する場合は「0」を記入します。
  例えば、ページ数が1,000以上ある場合、記事を投稿しても古いアーカイブまでパージする必要はありません。
• 追加ページは、任意のページをパージする設定ができます。
  例えば、記事を固定ページで表示している場合は、固定ページのURLを記載します。

REST API

W3 Total CacheのPROではREST APIのキャッシュ機能が利用できます。

• フリーの場合は「キャッシュしない」が選択されます。
• Disable REST APIを選択すると、REST API機能を無効にすることができます。
  セキュリティは向上しますが、REST APIを利用しているプラグインを導入している場合などは不具合が発生します。通常はOFFにしておきます。

詳細

ページやディレクトリ、HTTPヘッダーなど、細かい設定ができます。

• 後期の初期化は、フラグメント（一部）キャッシュに関する設定になります。
  動的コンテンツが多い場合はONにしますが、サーバの負荷は大きくなります。
  ON / OFFを切り替えてパフォーマンスを測定した方が良いでしょう。
• Late cacingは、キャッシュのキーをコントロールする機能になります。一般的なウェブサイトではOFFにします。
• キャッシュの有効期間は、頻繁に更新される場合は「3600秒（1時間）」ほとんど更新されない場合は「86400秒（24時間）」「604800秒（7日間）」など、ウェブサイトの更新頻度に合わせて設定してください。
• ガベージコレクション間隔は、期限切れキャッシュを削除する間隔を設定できます。
  サーバーのリソースにも影響するため、パフォーマンスを測定しながら設定します。
  目安としてウェブページが1,000ページ以上ある場合は、3600秒より徐々に減らして最適値を探ります。1,000ページ以下の場合は3600秒より徐々に増やして最適値を探ります。
• コメントcookieの有効時間（TTL:Time to Live）は、コメントするユーザーが多いウェブサイトでは1800（30分）や3600秒（1時間）が良いでしょう。
  コメントが少ない、またはOFFの場合は「-1」（WordPressのデフォルト）に設定します。
• 利用可能なクエリー文字列は、クエリパラメーターを含むURLをキャッシュします。
  例えば「category=news」と記入すると「?category=news」が含まれるURLがキャッシュされます。
  動的なコンテンツでも頻繁に使用されるクエリパラメーターを記入することでキャッシュされ、パフォーマンスが向上します。
• 拒否されたユーザーエージェントは、キャッシュページを表示しないデバイスやボットを指定できます。例えば「Googlebot」と記入すると、Googleのボットにはキャッシュを表示しません。
  ※Googlebotのユーザーエージェント
• 拒否されたクッキーは、指定したCookieを使用するページをキャッシュから除外します。Cookieを利用したプラグインを利用している場合は記入することがあります。
• Never cache pages associated with these categories:は、キャッシュから除外するカテゴリーのカテゴリー名、またはIDを記入します。
• Never cache pages that use these tags:は、キャッシュから除外するタグのタグ名、またはIDを記入します。
• Never cache pages by these authors:は、キャッシュから除外するユーザーページのユーザー名を記入します。
• Never cache pages that use these custom fields:は、特定のカスタムフィールドを含むページがキャッシュから除外します。除外する場合はフィールド名を記入します。
• キャッシュ除外リスト:は、キャシュから除外するページを指定できます。
  お問い合せページを除外する場合は「/contact/」や「/^\/contact\/.*/」などと記入します。
• 非末尾のスラッシュのページ：は、URLの最後「/contact」と最後にスラッシュの無いページ（ディレクトリー）をキャッシュする場合に記載します。
  「/contact」や「/^\/contact\/[a-z0-9-]+$/」などと記入します。
• ページヘッダーを指定:は、キャッシュに含める追加のHTTPヘッダーを指定するための機能です。
  例えば、XMLRPCのPingback機能を無効にしている場合は「X-Pingback」を削除しても良いです。「X-Frame-Options」など任意のHTTPヘッダーも追加できます。

圧縮

W3 Total Cacheには、htmlやCSS、javascriptファイルのminify（最小化）機能が備わっています。この機能の設定を行うことができます。

サーバーや他のプラグインとの互換性によって、minifyや、リライト機能が正しく動作しない場合もあります。
（キャッシュをパージすることで機能することもあります）

一般

• URL 構造をリライト:は、ONにします。
  この機能は、CSS、JSファイルをユーザーフレンドリーなURLに表示します。
  例えば「/test.js?ver=4.4」を「/test.js」のような形式にします。
• ログイン中のユーザーに対する圧縮を無効化:は、OFFにします。
• 圧縮エラー時の通知:は、適宜ご設定ください。

HTML＆XML

HTML、フィードのminify機能の有効化、設定ができます。

JSをminifyすると不具合が発生しやすいので、JSファイルをminifyする場合は、検証しながら設定してください。

JS

javascriptファイルのminify機能を利用する場合は有効化します。詳細設定ではJSファイルの読み込み方法などの設定ができます。

JSのminifyはトラブルが発生しやすいので、有効化する場合は検証しながら調整を進めてください。

• Minify engine settings:は、JSファイルの読み込み方法を設定できます。
  「JSを使用した非ブロック」は、JSファイルが非同期でロードされます。
  「asyncを使用した非ブロック」は、レンダリング後にJSファイルが並行で読み込まれます。JSの実行順序は保証されませんが、ページの表示速度は向上します。
  「deferを使用した非ブロック」は、HTMLが解析後にJSが実行されますので、ページの読み込み速度は高速です。JSの実行に依存関係がある場合は有効な選択です。
  「extsrcを使用した非ブロック」は、CDNなどの外部からJSファイルをロードしている時に有効な選択です。
  「asyncsrcを使用した非ブロック」は、外部からのJSファイルを非同期でロードし、ページのレンダリングをブロックしないでスクリプトの実行順序を無視して実行します。
• JS file management:はminifyするテーマを選択します。
• HTTP/2 push:はONにします。
  サーバーとブラウザのリクエスト方式で、現在、ほとんどのサーバーが対応しています。

CSS

CSSファイルのminify機能の有効化、詳細設定ができます。

• Minify method:は、「結合と縮小」「縮小のみ」「結合のみ」を選択できます。通常は「結合と縮小」を選択します。
• Minify engine settings:は、コメントや改行の除去設定ができます。両方ともONにします。
• @importの扱い:は、パフォーマンス重視なら「Process」を選択します。CSSの読み込み順が重要な場合は「Bubble」を選択します。通常は「Process」を選択します。
• CSS file management:は、CSSをminifyするテーマを選択します。
• HTTP/2 push:は、ONにします。

詳細

minifyキャッシュのパージや、minifyしないファイルなどを設定することができます。

• 外部ファイルを以下の間隔で更新:は、外部のJS、CSSのキャッシュ期間を記入します。
• ガベージコレクション間隔:は、期限切れのキャッシュデータを削除する頻度を記入します。最大値は30日間（2592000秒）までとなります。
• 以下のページは圧縮しない:は、圧縮しないページやディレクトリを記入します。
  例えばページの場合は「pagename」。ディレクトリの場合は「blog」。サブディレクトリの場合は「blog/category」。正規表記での指定も可能です「^(category|tag)」
• Never minify the following JS files:は、minifyから除外するjavascriptを指定できます。
  例えばファイル名を指定する場合は「wp-content/themes/theme-name/js/custom.js」。
  特定のディレクトリ以下のファイルの場合は「wp-content/themes/theme-name/js/」
  特定のファイル名のJSの場合は「*jquery*.js」
• Never minify the following CSS files:は、minifyから除外するCSSを指定できます。記述方法はjavascriptの場合と同じです。
• 拒否されたユーザーエージェント:は、キャッシュしたファイルを表示しないデバイスやボットを指定できます。

ブラウザキャッシュ

データベースキャッシュ、オブジェクトキャッシュの前に「ブラウザキャッシュ」を設定します。

一般

ブラウザキャッシュの一般的な設定を行います。

• Last-Modifiedヘッダーを設定:は、ONにします。
  ファイルが最後に更新された日時を示し、ブラウザはキャッシュの更新日を判断することができます。
• Expiresヘッダーを設定:は、ONにします。
  キャッシュの有効期限をブラウザに指定します。サーバーへの無駄なリクエストがなくページの読み込み速度が向上します。
• キャッシュ制御ヘッダーを設定:は、ONにします。
  ブラウザやサーバにキャッシュ方法を指示します。
• エンティティタグ (ETag) を設定:は、ONにして、不具合がある場合はOFFにします。
  キャッシュのバージョンを認識させるために利用され、効率的にキャッシュの読み込みができます。
• W3 Total Cache ヘッダーを設定:は、OFFにします。
  デバッグやパフォーマンスを調査する時にONにします。
• Enable HTTP (gzip) compression:は、ファイルをgzipで圧縮する場合にONにします。
• Enable HTTP (brotli) compression:は、ファイルをbrotli形式で圧縮する場合にONにします。
  ※サーバーがbortliに対応しており、既にbortliに圧縮されている場合、グレーアウトして有効化できない場合があります。
  bortliに圧縮されているかをチェックすることができます。
• 設定変更後のオブジェクトのキャッシュを防止:は、変更されたCSSやJSファイル名にクエリ（?ver=1.0など）を追加します。
  必要な場合はONにします。
• Remove query strings from static resources:は、OFFにします。
  CSSやJSのファイル名のクエリを削除します。
• 静的ファイルに Cookie を設定しない:は、ONにします。
  静的ファイル（画像、CSS、JavaScriptなど）には通常Cookieは不要です。
• 静的オブジェクトに対する404エラーを WordPress で処理しない:は、通常はOFFにします。
  404エラーはサーバー側で処理した方がパフォーマンスが向上することがありますが、動的に生成されるファイルがある場合は404エラーと誤認識されないように「404エラー除外リスト」に記載します。
• Rewrite URL structure of objects:は、JSやCSSをユニークなファイル名にリライトして、更新されたJSやCSSファイルをブラウザが読み取りやすくします。
  必要な場合はONにします。

CSS＆JS

CSSとjavascriptのキャッシュポリシーの設定になります。
先程の「一般」設定と同じ項目の説明は割愛します。

• Expires ヘッダーの有効期限:は、CSS、JSファイルをブラウザがキャッシュする期間を設定します。
  デフォルトは1年（31536000秒）です。頻繁にCSS、JSが更新される場合は7日（604800秒）などの値にします。
• キャッシュコントロールポリシー
  「cache ("public")」は、殆どCSSやJSが更新されない場合に選択します。CDNを利用している場合でも有効です。
  「cache with max-age」は、キャッシュの有効期間だけキャッシュします。CSSやJSがあまり更新されない場合に選択します。
  「cache with validation」は、CSSやJSが頻繁に更新される場合に選択します。
  「cache with max-age and validation」もCSSやJSが頻繁に更新される場合に有効です。cache with validationより厳密にキャシュを検証し利用します。
  「プロキシなしでキャッシュ」は、プライベートキャッシュになるため、ECサイトや会員サイトなどに最適な選択になります。
  「don't cache」は、キャッシュさせないことになるため、通常は選択しません。
  「don't store」は、キャッシュさせないことになるため、通常は選択しません。

パブリックキャッシュとプレイベートキャッシュとは？

パブリックは、共有キャッシュと呼ばれ、どのユーザーにも適用されるキャッシュになります。そのためブラウザや、プロキシサーバー、CDNなどにもキャッシュされます。

プライベートは、個人キャッシュと呼ばれ、特定のユーザーのブラウザ内でのみキャッシュが行われます。プロキシサーバーやCDNではキャッシュされません。
ECサイトや会員サイトなどに最適なキャッシュになります。

お問い合わせフォームを利用している場合は、パブリックキャッシュを選択し、お問い合わせページのキャッシュを除外することで、高いパフォーマンスを得ることができます。

HTML＆XML

HTML（ページ）、XML（フィード）のブラウザキャッシュ設定になります。
「一般」設定と同じ項目の説明は割愛します。

• Expires ヘッダーの有効期限:は、HTMLファイル、XMLファイルをブラウザがキャッシュする期間を設定します。更新頻度に合わせて数値を設定します。
  頻繁に更新する場合は86400秒（24時間）、あまり更新しない場合は604800秒（7日間）、ほとんど更新しない場合は最大値の2592000秒（30日間）でも良いでしょう。

メディアとその他ファイル

画像やPDFなどのファイルのキャッシュ設定になります。
先程の「一般」設定と同じ項目の説明は割愛します。

静的ファイルに対する Cookie を無効化：は、ONにします。通常は静的ファイルにCookieは不要です。

Security Headers

ウェブサイトとブラウザ間でのセキュリティを強化する設定ができます。
設定を誤るとSEOやセキュティに影響するため、よく分からない場合はデフォルトの設定をお薦めします。

以下、推奨される設定を紹介します。

• Use cookies to store session IDs:は、セッションIDをcookieに保存し、URLに含めない設定になります。DefaultまたはEnableを設定します。
• Access session cookies through the HTTP only:は、セクションcookieをXSSなどの攻撃により盗まれるリスクを軽減します。DefaultまたはEnableを設定します。
• Send session cookies only to secure connections:は、セッション Cookie を HTTPS 接続でのみ送受信するように制御し、ユーザーセクションの乗っ取りを抑止します。DefaultまたはEnableを設定します。
• HTTP Strict Transport Security policy：は、HSTSヘッダーを使用し、httpからhtppsへのリダイレクトやman-in-the-middle、SSLストリッピング攻撃を防止します。
  HSTSには下記のパラメーターが存在します。
  「max-age」はhttpsへのリダイレクトを有効（1年間継続）とします。
  「includeSubDomains」はサブドメインも対象に含めます。
  「Preload」は、HSTSプリロードリストに登録します。
  HSTSはHSTS Preload List Submissionで確認できます。登録すると解除が困難なため慎重に検討した方が良いでしょう。
  サブドメインを含めない場合は「max-age=EXPIRES_SECONDS」を選択します。
• X-Frame-Options：は、ウェブページが他のサイトのフレームやiframe、またはobject要素内で表示されることを制御するための設定になります。これによりクリックジャッキング攻撃を防ぐことができます。
  「Deny」は完全に禁止。「SameOrigin」は自サイトのみ可能。「Allow-From」は特定のURLに許可しますが、サポートするブラウザが少ないため意味が無いでしょう。
  一般的には「SameOrigin」を設定します。
• X-XSS-Protection：はブラウザでのサポートが終了するため、未設定にします。
• X-Content-Type-Options：は、ラウザに対して「サーバーが宣言したContent-Typeヘッダーに厳密に従うように指示」し、MIMEタイプスニッフィングなどの不正なコンテンツの実行を防ぐことができます。
  通常はONにします。
• HTTP Public Key Pinning：は、公開鍵（Public key）を使用してセキュリティを高める設定になります。一般的なウェブサイトでは有効にする必要は無いでしょう。
• Referrer Policy：は、Referer ヘッダーの情報を制御します。プライバシーに関する事になるのですが、設定によってはGoogle Analyticsに影響がでます。
  設定をOFFにするか、ONする場合は「same-origin」を設定します。

データベースキャッシュ

WordPressはデータベースから頻繁にデータを取得するため重く遅くなります。

そこでデータベースのクエリを予めキャッシュすることで、データベースへのアクセスを減らし、表示速度を上げるのがデータベースキャッシュの機能になります。

ただし、会員機能、EC機能、予約機能などのプラグインとデータベースキャッシュの相性が悪く、トラブルも多くなります。

また、サーバーのメモリーの消費や、サーバーへの負荷が大きくなる場合もあり、最悪はWordPressが落ちます。

そのため通常はデータベースキャッシュはOFFにした方が良いです。

データベースキャッシュの有効化

データベースキャッシュを有効にする場合は、テストを行いながら進めて下さい。

データベースキャッシュは、MemcachedまたはRedisのメモリーへのキャッシュが推奨されています。

サーバーにMemcachedサーバー、Redisサーバーがインストールされている必要があります。Redisの方が永続化機能があり柔軟な設定が可能です。

データベースキャッシュのRedis設定

キャッシュ先をRedisを選択すると、Redisの設定画面が表示されます。

• Redis hostname:port：にはRedisサーバーへの接続を記入します。一般的には「127.0.0.1」で、ポートは6379が利用されます。
• Verify TLS Certificates：は、TLS接続でRedisサーバーにアクセスする際にサーバーの証明書を検証するかの設定になります。テスト中はOFFにし、本番ではONにします。
• Use persistent connectionは、Radisへの永続的な接続を有効化にするかの設定です。サーバーへの負荷が軽減され、パフォーマンスが向上するため通常はONにします。
• Connection timeout：は、Redisサーバーへの接続が確立されるまでの最大待機時間の設定になります。2～5秒が良いでしょう。
• Connection Retry Interval：は、Redisサーバーへの接続が失敗した場合の再試行までの待機時間になります。1～2秒が良いでしょう。
• Connection Read Timeout：は、Redisサーバーの読み取りタイムアウトの設定になります。2～5秒が良いでしょう。
• Redis Database ID：は、Redisは16のデータベースが使用可能で、特定のデータベースを指定することが可能です。通常は０で良いでしょう。
• Redis password：は、Redisサーバーへの接続にパスワードを設定している場合はそのパスワードを記載します。

データベースキャッシュの詳細設定

• キャッシュオブジェクトの最長有効期間：は、データベースキャッシュの有効期間を設定します。
  頻繁に更新される場合は3600秒（1時間）。更新頻度があまりない場合は86400秒（1日）を目安に設定します。
• ガベージコレクション間隔：は、期限切れのキャッシュを定期的に削除する間隔の設定になります。キャッシュオブジェクトの最長有効期限とのバランスが必要になります。
  例えば、有効期限が86400秒（24時間）の場合は、21600秒（6時間）などが考えられます。
• 以下のページはキャッシュしない：は、キャッシュから除外するページやディレクトリを記載します。
  例えば、https://itti.jp/contact/の場合は「/contact/」や「/contact/*」と記載します。
• 無視するクエリ：キャッシュを無視するデータベースに関するプレフィックスを記載します。デフォルトの「gdsr_（GD Star Rating）」「wp_rg（Gravity Form）」「_wc_session_（WooCommerce）」のプレフィックスのため、使用していない場合は削除します。
• 検索語句を拒否：は、キャッシュを除外する検索語句を設定できます。デフォルトの他に下記を追記すると良いでしょう。
  ^\s*lock\b
  ^\s*flush\b
  ^\s*drop\b
  ^\s*optimize\b
  ^\s*analyze\b
  ^\s*describe\b
• Reject constants：は、指定した定数が定義されている場合にデータベースキャッシュを無効化する設定です。
  ブロックエディタやWooCommerceを利用している場合はREST APIを利用しているため「REST_REQUEST」を追記します。

オブジェクトキャッシュ

データの処理をメモリにキャッシュして、パフォーマンスを向上させるのが「オブジェクトキャッシュ」です。

アクセスが多く、サイト内検索や動的コンテンツが多いウェブサイトほど、オブジェクトキャッシュの恩恵を受けることができます。

サーバーのスペックが低い場合、最悪のケースとしてWordPressが落ちます。通常はオブジェクトキャッシュ機能はOFFの方が安全です。

オブジェクトキャッシュの有効化

オブジェクトキャッシュを利用する場合は、テストを行いながら進めて下さい。

データベースキャッシュ同様に、キャッシュの保存先はMemcachedまたはRedisのメモリーへの保存が推奨されます。

オブジェクトキャッシュのRedis設定

データベースキャッシュのRedis設定と同様の設定になります。設定は同じで良いでしょう。

オブジェクトキャッシュの詳細設定

オブジェクトキャッシュの設定になります。
「データベースキャッシュの詳細」設定と同じ項目の説明は割愛します。キャッシュの有効期間などはデータベースキャッシュと同じにして、運営しながら数値を調整します。

• グローバルグループ：は、マルチサイト間で共有するオブジェクトキャッシュのグループを設定することができます。サイト間でキャッシュを共有できるためパフォーマンスが向上します。
• 非永続グループ：は、オブジェクトキャッシュから除外するグループを設定できます。デフォルトでは「counts（投稿数やコメント数）」「plugins（プラグインの設定）」が記述されています。
  ウェブサイトの特徴に合わせて下記を追記します。
  transient（一時的なデータの保存。ランキングや外部APIなどでデータが頻繁に変わる場合）
  comments（コメント機能がある場合）
• Enable caching for wp-admin requests：は、管理画面のキャッシュを有効にする事ができます。通常はOFFにします。
• Store transients in database：は、transientをデータベースに保存するかの設定ができます。
  アクセスが多いウェブサイトや、非永続グループでtransientを記述した場合はOFFにします。OFFにするとtransientデータはキャッシュにのみ保存されます。

 

Debug

問題が発生した場合にのみ有効にします。有効にするとページフッターにデバッグ情報が表示されます。

通常はスルーしてOKです。

Import Export

設定した内容をファイルとして保存することができます。
他のウェブサイトにも同じ設定をする時などに便利です。

全ての設定が完了したら、設定を保存しておくことをお薦めします。

以上でGeneral Settingsは完了です。続いて詳細設定を行っていきます。

 

フッターのコメントを削除する方法

W3 Total Cacheは、HTMLのフッターにパフォーマンスについてのコメントを追記します。

このコメントを削除するにはテーマの「functions.php」にフィルターフックを記述することでコメントを削除することができます。

PHP

functions.phpの更新後に、キャッシュをパージする必要があります。

キャッシュと相性の悪いプラグインの調整

キャッシュと相性の悪いプラグインでも、W3 Total Cacheは細かな設定ができるのでトラブルを回避することができます。

Contact Form 7 Multi-Step Forms

フォームのデータをCookieに保存するため、ページキャッシュの「拒否されたクッキー」に「cf7msm_posted_data」を記入することで、トラブルを回避できます。