WordPressサイトのW3トータルキャッシュ設定を構成する方法

公開: 2020-08-24

100万を超えるアクティブなインストールがあるW3TotalCacheは、WordPressリポジトリで最も人気のあるキャッシュおよび最適化プラグインの1つです。 比較的シンプルで合理化されたインターフェースを提供する他のWordPress最適化プラグインとは異なり、W3TotalCacheはWordPressサイトのキャッシュ構成を完全に制御します。

W3TCの設定の粒度は、WordPressサイトを究極的に制御したい上級ユーザーや開発者にとって理想的なプラグインです。 この記事では、W3 Total Cacheの設定について詳しく見ていき、WordPressサイトのパフォーマンスを向上させるための推奨構成を示します。

Kinstaユーザーの場合、ホスティングスタックにはすでに多くの最適化が組み込まれているため、W3 Total Cacheで特定の設定を構成する必要はありません。たとえば、NGINXを介したサーバーレベルのページキャッシュは、すべてのKinstaサイトでデフォルトで有効になっています。 、したがって、W3TotalCacheで有効にする必要はありません。 KinstaがホストするサイトでW3TCをセットアップする場合は、以下のセットアップ手順に特に注意してください。 特定の設定が不要な場合、またはKinstaと互換性がない場合は、必ずお知らせします。

W3トータルキャッシュをインストールする方法

サイトにW3TotalCacheがインストールされていない場合は、WordPressダッシュボードに直接インストールできます。 「プラグインの追加」ページで「W3TotalCache」を検索してインストールするだけです。

W3TotalCacheをインストールします。
W3TotalCacheをインストールします。

BoldGridのWebサイトで購入できるW3TotalCacheのProバージョンもあります。 Proバージョンには、REST APIキャッシング、Googleマップキャッシング、追加の拡張機能など、いくつかの追加機能が付属しています。 この記事では、WordPressプラグインリポジトリの無料バージョンを使用します。

W3トータルキャッシュ設定のこのガイドで、＃WordPressサイトのパフォーマンスを向上させ、高度な機能を制御してください️ クリックしてツイート

W3トータルキャッシュ設定はどこに保存されますか？

W3 Total Cacheをインストールすると、WordPress管理ダッシュボードのサイドバーに[パフォーマンス]タブが表示されます。 [パフォーマンス]タブをクリックすると、[一般設定]、[ページキャッシュ]、[縮小]などのさまざまなサブメニューが表示されます。

W3トータルキャッシュサイドバー設定。
W3トータルキャッシュサイドバー設定。

WordPress管理ツールバーの[パフォーマンス]タブを使用して、W3トータルキャッシュ設定にアクセスすることもできます。

W3TotalCache管理ツールバーの設定。
W3TotalCache管理ツールバーの設定。

W3トータルキャッシュをパージする方法

W3 Total Cacheを構成する方法に入る前に、キャッシュをパージまたはクリアする方法を簡単に見ていきましょう。 管理ツールバーの[パフォーマンス]タブにカーソルを合わせると、2つのパージオプションが表示されます。

  1. すべてのキャッシュを削除–すべてのキャッシュを一度に削除します。
  2. モジュールのパージ–個々のキャッシュ（縮小されたアセット、ページキャッシュ、オブジェクトキャッシュなど）をパージします。
W3トータルキャッシュをパージします。
W3トータルキャッシュをパージします。

W3トータルキャッシュの一般設定

W3 Total Cacheの「一般設定」メニューに飛び込んで、いくつかの基本設定を構成しましょう。

ページキャッシュ

デフォルトでは、WordPressサイトへのすべてのリクエストはリアルタイムでレンダリングされます。 eコマースストアやディスカッションフォーラムなどの特定の種類のサイトでは、動的レンダリングが理想的です。 ただし、動的コンテンツを必要としないブログ、ニュースサイト、およびその他のサイトの場合、ページキャッシュレイヤーを追加すると、パフォーマンスが向上し、サーバーの負荷が軽減されます。

W3TCでページキャッシュを有効にします。
W3TCでページキャッシュを有効にします。

サイトがKinstaでホストされている場合は、ページのキャッシュについて心配する必要はありません。 サイトのページを静的HTMLファイルに自動的にキャッシュする高性能のサーバーレベルの構成があります。 ホストがページキャッシュを提供していない場合は、W3TotalCacheプラグインでページキャッシュを有効にできます。

縮小する

HTML、CSS、およびJavaScriptアセットを縮小すると、不要な空白を削除して、サイトのページ全体のサイズを縮小できます。 ほとんどのWordPressサイトでは、W3 Total Cacheの「ミニファイ」機能を有効にし、「ミニファイモード」の「自動」オプションを選択するだけで問題ありません。

W3TCでHTML、CSS、およびJavaScriptアセットを縮小します。
W3TCでHTML、CSS、およびJavaScriptアセットを縮小します。

場合によっては、アセットを縮小すると、CSSまたはJavaScriptコードが破損し、フロントエンドで目に見えるエラーが発生することがよくあります。 アセットを縮小した後にサイトで異常な問題に気付いた場合は、開発者と協力して問題の原因となっているアセットを特定することをお勧めします。 その後、手動モードで「縮小」機能を使用できます。これにより、特定のCSSおよびJavaScriptファイルの縮小をバイパスできます。

オペコードキャッシュ

WordPressは動的CMSです。つまり、PHPワーカーは常にバックグラウンドでコードを実行しています。 オペコードキャッシュは、コンパイルされたPHPコードを保存することでサイトを高速化し、同じコードを必要とする後続のリクエストを高速化します。

W3TCでオペコードキャッシュを有効にします。
W3TCでオペコードキャッシュを有効にします。

サイトがKinstaでホストされている場合は、W3TotalCacheでオペコードキャッシングレイヤーを有効にすることを心配する必要はありません。 すべてのライブ環境で、オペコードキャッシュであるOPcacheを有効にします。 コンパイルされたPHPコードがキャッシュされないように、またサイトの開発とデバッグに干渉しないように、ステージング環境ではOPcacheが無効になっています。

ホストがオペコードキャッシュを提供していない場合は、W3TotalCacheで有効にすることをお勧めします。 オペコードキャッシュ機能は、ProバージョンのW3TCでのみ使用できることに注意してください。

データベースキャッシュ

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

W3TotalCacheでのデータベースキャッシング。
W3TotalCacheでのデータベースキャッシング。

場合によっては、データベースキャッシュ機能によってCPU使用率が高くなる可能性があることがわかりました。 つまり、データベースクエリの結果を保存することで節約できるCPUの量は、この機能に必要なCPUの増加によって相殺される可能性があります。

オブジェクトキャッシュ

WordPressのコンテキストでは、オブジェクトキャッシュは、完了したデータベースクエリの結果を保存します。 WordPressには実際には組み込みのオブジェクトキャッシュがありますが、1ページの読み込みでのみデータを保持します。 これにより、ページの読み込みで同一のデータベースクエリを実行するCPUリソースを浪費する必要がなくなるため、より効率的なページレンダリングが可能になります。

WordPressのデフォルトのオブジェクトキャッシュは間違いなくパフォーマンスに有益ですが、ページの読み込み全体でデータを保持するオブジェクトキャッシュはさらに優れています！ W3TCの「オブジェクトキャッシュ」機能は、 /wp-contentディレクトリにカスタムキャッシュスクリプトを追加し、WordPressのオブジェクトキャッシュの動作を変更して、データを永続的に（複数のページの読み込みにわたって）保持します。

サイトがKinstaでホストされていない場合は、WordPressサイトでW3TCのオブジェクトキャッシュ機能を有効にして、データベースクエリを利用するリクエストを高速化することをお勧めします。

W3トータルキャッシュオブジェクトキャッシュ。
W3トータルキャッシュオブジェクトキャッシュ。

サイトがKinstaでホストされている場合は、Redisアドオンを利用した高性能のオブジェクトキャッシングレイヤーを提供します。 Redisは、データベースやメッセージブローカーアプリケーションでよく使用されるオープンソースのインメモリデータ構造ストアです。

RedisはデータをRAMにキャッシュするため、WordPressは、従来のオブジェクトキャッシュ構成よりもはるかに高速な永続オブジェクトキャッシュからキャッシュされたデータにアクセスできます。

ブラウザキャッシュ

ブラウザのキャッシュは、CSS、JavaScript、画像、フォントなどの静的アセットをローカルに保存することで、WordPressサイトを大幅に高速化できます。 ブラウザのキャッシュでは、有効期限を使用してアセットをキャッシュする期間を決定します。 最新のWebでは、ほとんどの開発者が静的アセットの有効期限を1年と指定しています。

W3TotalCacheでブラウザのキャッシュを有効にします。
W3TotalCacheでブラウザのキャッシュを有効にします。

Kinstaでホストされているサイトの場合、静的ファイルに対して1年間のキャッシュ期間を適用します。 これは、Kinstaでホストされている静的ファイルのcache-controlヘッダーを確認することで確認できます。 ウェブホストがブラウザキャッシュに「遠い将来の有効期限」を適用しない場合は、W3トータルキャッシュの「ブラウザキャッシュ」機能を有効にして、有効期限を設定できます。

CDN（コンテンツ配信ネットワーク）

CDNまたはコンテンツ配信ネットワークを使用して静的ファイルを世界中のデータセンターにオフロードする場合は、W3 Total Cacheを構成して、「テーマファイル、メディアライブラリの添付ファイル、CSS、JS」などのURLを書き換えることができます。 CDNホスト名。

W3トータルキャッシュのCDN設定。
W3トータルキャッシュのCDN設定。

サイトがKinstaでホストされている場合は、KeyCDNを利用した高性能コンテンツ配信ネットワークであるKinstaCDNを使用することをお勧めします。 Kinsta CDNを有効にすると、静的ファイルのURLが自動的に書き換えられ、KinstaCDNから提供されます。

別のCDNプロバイダーを使用する場合、またはサイトがKinstaでホストされていない場合は、W3 Total Cacheで「CDN」機能を有効にして、CDNURLを追加できます。

リバースプロキシ

リバースプロキシは、WebサーバーとWordPressの間に配置され、着信要求に対してさまざまなロジックベースの操作を実行するために使用できます。 W3TCは、バックエンドの負荷を軽減することを目的として、データをキャッシュおよび提供するための一般的な「HTTPアクセラレータ」であるVarnishをサポートしています。

Varnishを使用するには、最初にホストがVarnishパッケージをインストールする必要があります。 Kinstaをご利用の場合は、リバースプロキシオプションを有効にしないでください。インフラストラクチャはVarnishで動作するように設計されていません。

ユーザー体験

W3TCの「ユーザーエクスペリエンス」の最適化により、遅延読み込みを有効にし、絵文字を無効にし、 wp-embed.jsスクリプトを無効にすることができます。 ページの読み込みを高速化するために、WordPressサイトで遅延読み込みを有効にすることをお勧めします。 ブラウザネイティブまたはプラグインベースの遅延読み込みをまだ使用していない場合は、遅延読み込みにW3TotalCacheを使用することをお勧めします。

W3TCのユーザーエクスペリエンス設定。
W3TCのユーザーエクスペリエンス設定。

今日の世界では、ほとんどのオペレーティングシステムに絵文字のサポートが組み込まれています。 したがって、絵文字のヘビーユーザーでない場合は、WordPressに含まれている絵文字スクリプトを無効にすることをお勧めします。 W3TCを使用してwp-emoji-release.min.js release.min.jsを削除すると、HTTPリクエストを削減し、ページの読み込みから最大10KBを削除するのに役立ちます。

同様に、WordPressの投稿を埋め込まない場合は、W3TotalCacheを使用してwp-embed.jsを無効にすることができます。 このスクリプトを無効にしても、YouTubeビデオやSoundCloudストリームなどを埋め込むためのoEmbed機能には影響しません。

その他

W3 Total Cacheには、構成可能なその他の設定がいくつかあります。 WordPressでGooglePageSpeedダッシュボードウィジェットを表示する場合は、PageSpeedAPIキーを入力できます。 WordPressサイトの各ページのメニューバーにページ速度の評価を表示するオプションもあります。

W3TotalCacheのその他の設定。
W3TotalCacheのその他の設定。

「NGINXサーバー構成ファイルパス」、「ファイルロックを有効にする」、「ディスク拡張ページを最適化し、NFSのディスクキャッシュを最小化する」などの他の設定については、特に変更する理由がない限り、デフォルト設定のままにしておくことをお勧めします。

デバッグ

サイトの問題のトラブルシューティングを行っている場合、W3 Total Cacheには、特定のキャッシュレイヤーと最適化設定を無効にできる便利な「デバッグ」メニューがあります。 たとえば、サイトの視覚的な不具合に気付いた場合は、「縮小」オプションのデバッグモードを有効にできます。これにより、トラブルシューティングに役立つHTMLコメントがページのソースコードに挿入されます。

W3TotalCacheのデバッグモード。
W3TotalCacheのデバッグモード。

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

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

設定の構成が完了したら、W3TCの「インポート/エクスポート」機能を使用して構成のバックアップを作成できます。 W3 Total Cacheには多くの設定があるため、完全バックアップをエクスポートできることは安心のために素晴らしいことです。 さらに、手動で何も構成しなくても、カスタムW3TC構成を複数のサイトに簡単に複製できます。

W3TC設定をインポートおよびエクスポートします。
W3TC設定をインポートおよびエクスポートします。

W3トータルキャッシュ設定—ページキャッシュ

W3TotalCacheの「ページキャッシュ」設定について詳しく見ていきましょう。 サイトがKinstaでホストされている場合は、ページのキャッシュについて心配する必要はありません。このセクションはスキップしてください。

  • キャッシュフロントページ–ほとんどのサイトでは、フロントページは通常、最も多くのトラフィックを受信するページです。 したがって、この設定を有効にすることをお勧めします。
  • キャッシュフィード– WordPressはさまざまなRSSフィードを生成します。これにより、Feedburnerなどの外部アプリやサービスがサイトのコンテンツを表示できるようになります。 RSSは以前ほど人気が​​ありませんが、この設定を有効にすることをお勧めします。
  • キャッシュSSL（HTTPS要求） – Webサーバーがすべての着信要求に対してHTTPSを強制しない場合、この設定を有効にするとパフォーマンスにプラスの影響を与える可能性があります。 すでにWebサーバーレベルでHTTPSを強制している場合は、これを有効にする必要はありません。
  • クエリ文字列変数を使用してURIをキャッシュする–クエリ文字列は、URLの最後に追加されるパラメータです（例：/？version = 123）。 クエリ文字列は、WordPressデータベースから特定のデータを要求して表示するためによく使用されます。 一般に、クエリ文字列の目的はページの一意のバージョンを要求することであるため、キャッシュする特定のクエリ文字列がない限り、これを無効にしておくことをお勧めします。
  • キャッシュ404（見つかりません）ページ–デフォルトでは、W3TCはこのオプションを無効のままにします。 この理由は、「ディスク拡張」ページキャッシュ方式を使用している場合のキャッシュ動作が原因である可能性があります。 このオプションを選択すると、404ページで200の応答コードが返されます。 理想的には、404ページは404応答コードを返す必要があるため、この設定をキャッシュ構成でテストして、互換性があるかどうかを確認することをお勧めします。
  • ログインしたユーザーのページをキャッシュしない–このオプションを有効にすることをお勧めします。 ログインしたユーザーは通常、ページの更新に取り組んでいます。 キャッシュを有効にすると、ユーザーはページの更新を確認するために常にキャッシュをクリアする必要があります。
  • 特定のユーザーロールのページをキャッシュしない–このオプションを使用すると、特定のWordPressユーザーロールのキャッシュをバイパスできます。 「ログインしているユーザーのページをキャッシュしない」オプションがすでに有効になっている場合、このオプションはキャッシュの動作に影響を与えません。

エイリアス

W3 Total Cacheの「エイリアス」機能を使用すると、異なるドメインで利用可能な同一のWordPresコンテンツをキャッシュできます。 この機能を有効にすることはお勧めしません。 WordPressサイトが異なるドメイン（たとえば、domain.comとwww.domain.com）からアクセスできる場合は、Googleや他の検索エンジンからの重複コンテンツペナルティを回避するために、リクエストをプライマリドメインに転送する301リダイレクトルールを設定することをお勧めします。

キャッシュプリロード

「キャッシュプリロード」機能は、サイトマップをクロールし、サイトのページにページキャッシュをプリロードするように要求します。 ほとんどのサイトでは、キャッシュのプリロードを無効にすることをお勧めします。これは、潜在的なパフォーマンス上の利点を相殺するサーバーリソースの急増を引き起こす可能性があるためです。

キャッシュのプリロードを有効にする場合、W3TCでは、サイトマップURL、更新間隔、および間隔ごとのページを指定できます。 CPUスパイクの可能性を減らすために、「更新間隔」と「内部ページ数」を高く設定しすぎないように注意してください。

パージポリシー

W3TCの「パージポリシー」では、投稿が公開または編集された後に自動的にパージするページとフィードを指定できます。 ほとんどのサイトでは、デフォルト設定（フロントページ、投稿ページ、ブログフィード）で十分です。 パージポリシーにページを追加する場合は、さまざまなオプションを構成できます。

REST API

WordPressに含まれているRESTAPIを使用すると、JSON形式のデータをクエリできます。 REST APIはさまざまなプラグインで使用され、ヘッドレスのWordPressセットアップに不可欠です。 REST APIの正確なユースケースによっては、クエリ結果をキャッシュすることをお勧めします。 REST APIキャッシングは「必要な場合はわかる」カテゴリに分類されるため、REST APIキャッシングを有効にするかどうかわからない場合は、「キャッシュしない」のままにしておくことをお勧めします。

高度

W3TCの「詳細」ページキャッシュオプションでは、「受け入れられたクエリ文字列」、「拒否されたユーザーエージェント」、詳細なキャッシュバイパス設定などのさまざまな設定をカスタマイズできます。 たとえば、特定のカテゴリまたはタグの下に投稿をキャッシュしないようにW3 Total Cacheを構成する必要がある場合は、「詳細」オプションでそれを行うことができます。

これらの設定はサイト固有である可能性があるため、提供できる「推奨設定」はありません。 そうは言っても、サイトのページキャッシュ動作の非常に特定の側面をカスタマイズしたい場合は、高度なオプションを確認してください。

W3トータルキャッシュ設定—縮小

次に、W3TotalCacheの「縮小」設定について見ていきましょう。

  • URL構造の書き換え–この設定は、縮小されたアセットのURL構造に影響します。 URLが「きれい」に見えるように、有効にしておくことをお勧めします。
  • ログインしたユーザーのミニファイを無効にする–トラブルシューティングまたはデバッグを行っている場合は、ログインしたユーザーのミニファイを無効にすると役立つ場合があります。 それ以外の場合は、このオプションを無効にしておくことをお勧めします。

HTMLとXML

「HTMLとXML」セクションでは、HTMLの縮小設定を構成できます。

  • インラインCSSの縮小–このオプションを有効にして、インラインCSSの空白を削除することをお勧めします。
  • インラインJSミニファイ–このオプションを有効にして、インラインJavaScriptの空白を削除することをお勧めします。 場合によっては、JSの縮小によりコードエラーが発生することがあります。 このオプションを有効にするとサイトの機能が損なわれる場合は、無効にしてください。
  • フィードを縮小しない–このオプションを無効にしておくことをお勧めします。 フィードはRSSリーダーや他の同様のサービスでのみ使用されるため、フィードを縮小する必要はありません。
  • 改行の削除–このオプションはデフォルトで無効になっているため、サイトが正しくレンダリングされるようにするために有効にすることはお勧めしません。

JS

「JS」セクションでは、JavaScriptの縮小設定を構成できます。

  • エリアでの操作–このオプションを使用すると、縮小されたJavaScriptの「埋め込みタイプ」を選択できます。 以前のJSファイルの場合以降、「ブロッキング」、「ノンブロッキング」、「非同期を使用したノンブロッキング」、「遅延を使用したノンブロッキング」から選択できます。 通常、非ブロッキングの読み込み方法を使用するとパフォーマンスが向上しますが、すべてのJavaScriptコードと常に100％互換性があるとは限りません。 さらに、「非同期」と「延期」のユースケースは大きく異なります。 したがって、非ブロッキングJavaScriptの癖に気付いていない限り、デフォルトの「ブロッキング」メソッドを使用することをお勧めします。
  • 縮小または結合のみ–JavaScriptの2つの最適化モードから選択できます。 「縮小」を選択すると、JSファイルが結合されて縮小されます。 「結合のみ」を選択した場合、結果の結合されたJSファイルは縮小されません。 ミニファイ関連の問題が発生していて、問題の原因となっているスクリプトをデバッグしたくない場合は、[結合のみ]オプションを選択するとエラーが修正される場合があります。
  • HTTP / 2プッシュ–サーバーがHTTP / 2サーバープッシュをサポートしている場合、このオプションを有効にすると、ページの読み込み時間を短縮できる場合があります。 HTTP / 2サーバープッシュは、要求される前に訪問者にファイルをプッシュします。 サーバープッシュは誤用されることが多いため、実稼働環境でこのオプションを有効にする前に、適切なテストを行うことをお勧めします。 サーバープッシュは、より大きなJavaScriptファイルには理想的ではありません。訪問者のブラウザーのキャッシュから直接、JSファイルをロードするよりもメリットが大きいことを確認する必要があります。

CSS

「CSS」セクションでは、CSS縮小設定を構成できます。

  • 結合のみ– JavaScriptファイルとは異なり、CSSは通常、縮小関連の問題に悩まされることはありません。 したがって、「結合のみ」を有効にすることはお勧めしません。
  • 保存されたコメントの削除–この設定は、CSSファイルからコメントを削除します。 このオプションを有効にして、ファイルサイズを可能な限り小さくすることをお勧めします。
  • 改行の削除–この設定は、CSSファイルから改行を削除します。 このオプションも有効にすることをお勧めします。 「改行の削除」を有効にした後で表示の問題に気付いた場合は、無効にします。

高度

「詳細」セクションには、縮小動作をカスタマイズするためのいくつかの追加設定が含まれています。

  • 外部ファイルを毎回更新– W3TCでは、CSSとJSファイルの更新間の時間を指定できます。 デフォルト設定の86400秒では、アセットは24時間ごとにダウンロードおよび縮小されます。 サイトが頻繁に変更されない場合は、より長い期間を自由に設定してください。
  • ガベージコレクション間隔–この期間設定は、期限切れのキャッシュデータが削除される頻度を指定します。 デフォルト設定は24時間です。 サイトのストレージ容量が少ない場合は、「ガベージコレクションの間隔」を短くすることをお勧めします。

「詳細」セクションの残りの部分には、縮小してはならないアセットファイルを指定できる入力フィールドが含まれています。 縮小されていないファイルを特定のユーザーエージェントに提供できる「拒否されたユーザーエージェント」フィールドもあります。 最後に、W3TotalCacheの縮小プロセスに含める外部アセットファイルを追加できます。

W3トータルキャッシュ設定—オブジェクトキャッシュ

リストの次は、W3TCの「オブジェクトキャッシュ」設定です。 ほとんどのサイトでは、デフォルト設定で問題なく機能しますが、それでも問題はありません。

  • キャッシュオブジェクトのデフォルトの有効期間–変更されていないキャッシュアイテムの有効期限。 期間が長くなると、オブジェクトキャッシュが大きくなります。 サーバーのストレージ容量が心配な場合は、デフォルト値を維持するか、デフォルト値を下げることをお勧めします。
  • ガベージコレクションの間隔–この設定は、期限切れのキャッシュデータが破棄される頻度を指定します。 ほとんどのサイトでは、デフォルト値の3,600秒（1時間）で十分です。
  • グローバルグループ–この設定により、単一のマルチサイトネットワーク内のサイト間で共有キャッシュグループを構成できます。 特別な理由がない限り、この設定をデフォルトの状態のままにしておくことをお勧めします。
  • 非永続グループ–この設定では、キャッシュしないオブジェクトグループを選択できます。 繰り返しになりますが、デフォルト構成を使用することをお勧めします。
  • wp-adminリクエストのキャッシュを有効にする–このオプションはデフォルトで無効になっていますが、副作用が発生する可能性があるため、有効にすることはお勧めしません。 さらに、ほとんどのWordPressサイトへの訪問者は、wp-adminダッシュボードを操作しません。

W3トータルキャッシュ設定—ブラウザキャッシュ

Kinstaを含むほとんどのWordPressホストは、すでにWebサーバーレベルで適切なブラウザーキャッシュヘッダーを実装しています。 ホストがそうでない場合、またはブラウザーのキャッシュ動作をさらにカスタマイズしたい場合は、W3TotalCacheを使用して行うことができます。

「ブラウザキャッシュ」設定では、「一般」、「CSS＆JS」、「HTML＆XML」および「メディア＆その他のファイル」セクションのデフォルト設定がほとんどのWordPressサイトに適しています。 このページには非常に多くの設定があるため、ブラウザのキャッシュ動作を変更する前に、開発者に相談することをお勧めします。 そうは言っても、ブラウザのキャッシュに関して注意すべきいくつかの重要な設定を以下に示します。

  • Expires Headers Lifetime –長い「expiresheaderslifetime」を設定することは、効率的なブラウザキャッシングにとって重要です。 Kinstaでは、CSS、JS、画像、フォントなどの静的アセットに1年間の有効期間を適用しています。 W3TCを使用してブラウザーのキャッシュを構成している場合は、この値を31536000 （1年）に設定してください。
  • キャッシュ制御ポリシー–静的アセットがブラウザでキャッシュ可能であることを確認するには、「キャッシュ制御ポリシー」が「public、max_age=EXPIRESSECONDS」に設定されていることを確認してください。
  • HTTP（gzip）圧縮を有効にする– GZIP圧縮は、訪問者に送信される前にHTMLページとアセットのファイルサイズを大幅に削減します。したがって、ホストのサーバー構成がGZIPをサポートしている場合は、必ずこのオプションを有効にしてください。 サイトがKinstaでホストされている場合、W3TCでGZIP圧縮を有効にする必要はありません。これは、デフォルト構成の一部としてすでに有効になっているためです。
  • 静的リソースからクエリ文字列を削除する–クエリ文字列は、URLパスの最後に追加される追加の文字列であり、リクエストパラメータを指定したり、Webサーバーに新しいアセットを配信させたりします。 クエリ文字列は?で始まります、およびほとんどのWebサーバーは、クエリ文字列を含む要求のキャッシュをバイパスするように構成されています。 ページリクエストからクエリ文字列を削除すると、サーバーの負荷を軽減するのに役立ちます。これらのリクエストはPHPを使用してページをレンダリングするためです。 W3 Total Cacheの静的リソースからクエリ文字列を削除することはお勧めしません。クエリ文字列は、CSSおよびJSファイルの最新バージョンが訪問者に確実に配信されるようにするためです。

「ブラウザキャッシュ」設定ページには、コンテンツセキュリティポリシー（CSP）やX-XSS保護などのセキュリティヘッダーに関連するさまざまな設定も含まれています。 誤った構成はサイトのユーザーエクスペリエンスに直接影響を与える可能性があるため、資格のある開発者と協力してこれらの設定を行うことを常にお勧めします。 たとえば、適切なSSL証明書とHTTPS構成なしでHSTSヘッダーを有効にすると、サイトにアクセスできなくなる可能性があります。

W3トータルキャッシュ設定—ユーザーエージェントグループ

W3 Total Cacheの「ユーザーエージェントグループ」機能は、ユーザーのデバイスタイプに基づいてトラフィックをリダイレクトする必要がある場合に非常に強力です。 たとえば、ユーザーが携帯電話からサイトにアクセスした場合に、異なるテーマでレンダリングするようにサイトを構成できます。 同様に、モバイルサイトが一意のサブドメインにある場合は、ユーザーを完全に異なるサイトにリダイレクトできます。

レスポンシブウェブデザインの時代では、この特定の機能のユースケースはそれほど多くありません。 現在のベストプラクティスは、複数のテーマやモバイル専用のサブドメインに依存するのではなく、サイトを最初からレスポンシブにすることです。

W3トータルキャッシュ設定—リファラーグループ

HTTPリファラーは、リクエストの発信元に関する情報を提供するオプションのHTTPヘッダーです。 たとえば、訪問者がGoogle検索リストからサイトをクリックした場合、HTTPリファラーはgoogle.comになります。

ダウンタイムとWordPressの問題に苦しんでいますか？ Kinstaは、パフォーマンスとセキュリティを念頭に置いて設計されたホスティングソリューションです。 私たちの計画をチェックしてください

W3 Total Cacheでは、「リファラーグループ」を使用してリクエストのHTTPリファラーに基づいてカスタムキャッシュ動作を定義できます。 たとえば、検索エンジンで構成されるリファラーグループを作成し、それらのドメインからのリクエストのみのキャッシュ動作をカスタマイズできます。

上記の「ユーザーエージェントグループ」と同様に、「リファラーグループ」機能を使用してリクエストを別のドメインにリダイレクトすることもできます。 ほとんどのWordPressサイトではリファラーグループを設定する必要がないため、設定することはお勧めしません。

W3トータルキャッシュ設定—Cookieグループ

W3TotalCacheがサポートする最新のキャッシュグループは「Cookieグループ」です。 この機能を使用すると、リクエストのCookieに基づいて独自のキャッシュバケットと動作を作成できます。 「ユーザーエージェントグループ」や「リファラーグループ」と同様に、ほとんどのサイトでは、カスタムのCookieベースのキャッシュ構成を設定する必要はありません。 サイトでCookieベースのキャッシュが必要な場合は、開発者と協力して正しく構成することをお勧めします。

W3トータルキャッシュ設定— CDN

それでは、W3TotalCacheのCDN設定に移りましょう。

  • ホスト添付ファイル–これを有効にして、CDNからWordPressメディアライブラリのアセットを提供します。
  • ホストwp-includes/ファイル–これを有効にして、CDNからwp-includesフォルダー内のファイルを提供します。
  • ホストテーマファイル–これを有効にして、CDNからテーマファイルを提供します。
  • ミニファイされたCSSおよびJSファイルをホストする–これを有効にして、CDNからW3TCのミニファイされたCSSおよびJSファイルを提供します。
  • カスタムファイルのホスト–メディアライブラリまたはテーマフォルダーにないファイルがある場合は、W3TCにファイルパスを追加して、CDNからそれらを提供できます。
  • 正規ヘッダーの追加– rel=”canonical”タグは、検索エンジンが元のソースまたはURLを識別するのに役立ちます。 CDNは通常、異なるドメインを使用するため、正規タグを追加すると、検索エンジンに元のアセットの場所が通知されます。 そうは言っても、最新の検索エンジンはサイトのSEOランキングに影響を与えることなく、CDNを識別するのに十分賢いので、この設定を無効のままにしておくのは問題ありません。

高度

  • CDNを手動でパージする場合のみ– W3TCがキャッシュのパージを自動的に処理できるようにするには、このオプションを無効にしておくことをお勧めします。
  • SSLページでCDNを無効にする–この設定を無効のままにします。 CDNを使用している場合は、HTTPページとHTTPSページの両方でアクティブにするのが最適です。
  • 管理ページでメディアライブラリにCDNリンクを使用する–メディアライブラリのURLが書き換えられるため、このオプションを有効にすることはお勧めしません。
  • CORSヘッダーの追加–この設定を有効のままにして、CDNアセットを他のドメインに表示できるようにします。
  • 次のロールのCDNを無効にする–このオプションを使用すると、特定のWordPressユーザーロールのCDNを無効にできます。 ほとんどの場合、このオプションを無効にしておくのが最善です。
  • wp-includesアップロードするファイルタイプ–このフィールドは、CDNから提供されるwp-includesのファイル形式を指定します。 ほとんどのサイトでは、デフォルトのファイル形式のリストで問題ありません。 wp-includesフォルダーにカスタムファイルがある場合は、必要に応じてフォーマットを追加してください。
  • アップロードするテーマファイルタイプ–このフィールドは、CDNから提供されるWordPressテーマフォルダー内のファイル形式を指定します。 デフォルトのリストには、一般的なアセット、画像、フォントの形式がすべて含まれています。 必要に応じて、フォーマットを追加してください。
  • カスタムファイルリスト– 「ホストカスタムファイル」を有効にした場合、このフィールドにファイルのリストを追加して、CDNから提供できます。
  • 拒否されたユーザーエージェント–このフィールドでは、CDNからアセットが提供されないユーザーエージェントを指定できます。 CDNが適切に使用されていることを確認するために、このフィールドを空のままにしておくことをお勧めします。
  • 拒否されたファイル–このフィールドでは、CDNから提供されるべきではないファイルを指定できます。 使用しているサービスでルートドメインからアセットを提供する必要がある場合は、[拒否されたファイル]フィールドにファイルパスを追加できます。

W3トータルキャッシュ設定—ユーザーエクスペリエンス

次に、W3TotalCacheの「ユーザーエクスペリエンス」または遅延読み込みの設定をカスタマイズしましょう。

  • HTML画像タグの処理–これを有効にして、画像が遅延ロードされるようにします。
  • 背景画像の処理– `background`を使用してCSSで画像を表示している場合、このオプションを有効にすると、それらの画像を遅延読み込みできます。
  • 単語を除外–このフィールドでは、遅延読み込みをバイパスするテキストを指定できます。 たとえば、このフィールドにno-lazy-loadを追加すると、 <img src="image.jpg">で表示される画像は遅延読み込みされません。
  • スクリプト埋め込み方法–この設定により、遅延読み込みスクリプトの読み込み方法をカスタマイズできます。 ほとんどのサイトでは、デフォルトのasync方式が最適なオプションです。 サイトが単一のランディングページのみで構成されている場合は、 inline方式を使用して、ページをロードするHTTPリクエストの数を減らすことができます。

W3トータルキャッシュで利用可能な拡張機能

W3 Total Cacheは、サードパーティのサービスと統合するためのさまざまな拡張機能を提供します。 W3TCには現在、次のサービスの拡張機能があります。

  • AMP
  • Cloudflare
  • Google Feedburner
  • フラグメントキャッシュ
  • ジェネシスフレームワーク
  • New Relic
  • 群がる
  • ヨーストSEO
  • WPML

サイトでこれらのサービスのいずれかを使用している場合は、W3 Total Cacheとの適切な互換性を確保するために、関連する拡張機能を設定することをお勧めします。 このセクションでは、W3TotalCacheのCloudflare拡張機能について説明します。

Cloudflare拡張機能を使用してW3トータルキャッシュを設定する方法

CloudflareをW3TotalCacheと統合するには、CloudflareダッシュボードからアカウントのメールアドレスとAPIキーの2つの情報が必要です。 アカウントのメールアドレスは、Cloudflareへのログインに使用するメールアドレスです。 CloudflareAPIキーを設定する方法を見てみましょう。

Cloudflareダッシュボードで、「概要」タブをクリックします。 次に、下にスクロールして、右側のサイドバーにある[ APIトークンを取得]をクリックします。

CloudflareグローバルAPIキーを表示します。
CloudflareグローバルAPIキーを表示します。

下にスクロールし、「グローバルAPIキー」の横にある「表示」をクリックして、CloudflareAPIキーを取得します。 Be careful not to share this API key anywhere outside W3 Total Cache because it can be used to control your Cloudflare account.

View your Cloudflare Global API Key.
View your Cloudflare Global API Key.

Next, activate the Cloudflare extension in W3 Total Cache's “Extensions” page and click “Settings”. In the “Credentials” section, click on the Authorize button.

Authorize Cloudflare in W3 Total Cache.
Authorize Cloudflare in W3 Total Cache.

In the subsequent popup, input your Cloudflare account email and API key. If you receive an error message, double-check to make sure your email address and API key are correct. After the credentials are authorized, you should see additional Cloudflare settings on the page.

Cloudflare settings in W3 Total Cache.
Cloudflare settings in W3 Total Cache.

Let's go over the Cloudflare settings in W3 Total Cache.

  • Widget Statistics Interval – This specifies the time period covered for W3TC's Cloudflare widget. The default setting is 30 minutes. If you'd like to see a longer time period, feel free to increase it.
  • Cache Time – This specifies the amount of time that widget data from Cloudflare is cached. If you don't plan on using the widget much, we recommend increasing this number to reduce the number of requests to Cloudflare from your site.
  • Page Caching – If you've configured Cloudflare to cache HTML pages for your WordPress site, enable this option to automatically clear the Cloudflare cache after post modifications and updates.

Cloudflare Caching

This section lets you customize Cloudflare's caching settings.

  • Development Mode – Keep this option disabled unless you need to put Cloudflare in Development Mode. When Cloudflare is in Development Mode, edge caching, minification, and image optimization is disabled for three hours. This allows you to see updates to CSS and JS files immediately and is useful for troubleshooting.
  • Cache Level – For most sites, we recommend using the “Standard” cache level, which serves a different resource each time the query string changes. If you're 100% sure that your WordPress site does not make use of query strings to serve dynamic content, you can also use the “Ignore Query String” setting as well.
  • Browser Cache TTL – We recommend setting Cloudflare's browser cache TTL to 31536000 seconds, which is equal to 1 year.
  • Challenge TTL – Cloudflare offers a variety of security-related services, and visitor challenges is one of them. If Cloudflare detects a malicious user or strange behavior, it will serve a challenge message in the form of a Captcha. The “Challenge TTL” setting specifies how long a user will have access to your site after completing a challenge. With the default setting of 3600 seconds, a visitor who was subject to a challenge will be able to use your site for 1 hour before another challenge.
  • Edge Cache TTL – This setting controls how long assets will be cached at Cloudflare's edge servers. We recommend setting this to the maximum value of 31536000 seconds, or 1 year.

Cloudflare Content Processing

Let's dive into the Cloudflare content processing settings in W3 Total Cache.

  • Rocket Loader – Cloudflare's Rocket Loader speeds up JavaScript loading for your WordPress site. We recommend enabling Rocket Loader if your site has a lot of JS.
  • Minify JS/CSS/HTML – If you've already enabled minification for HTML, CSS, and JavaScript in W3 Total Cache, feel free to keep these options in the Cloudflare extension settings disabled, as there is no need to minify assets that have already been minified.
  • Server Side Exclude (SSE) – This option allows you to hide sensitive information from suspicious visitors (deemed by Cloudflare). Server-side excludes are useful for hiding information like email address, phone numbers, and other personal information on your site. To use SSE, enable it and wrap sensitive information in <!--sse--><!--/sse--> tags in your HTML code or PHP theme template.
  • Email Obfuscation – When this option is enabled, Cloudflare will automatically obfuscate email addresses on your WordPress site with JavaScript. While obfuscation is not going to get rid of email spam completely, we recommend enabling this option because it does deter basic bots from scraping email addresses from your site.

Cloudflare Image Processing

Let's go over Cloudflare's image processing settings.

  • Hotlink Protection – Enabling hotlink protection will prevent other sites from embedding your images. If you're running into bandwidth limits due to unauthorized external embeds, enabling “Hotlink Protection” can help you reduce bandwidth usage.
  • Mirage (Pro Only) – Mirage optimizes image delivery to low-bandwidth devices and networks. This feature is only available on Cloudflare Pro plan and above.
  • Polish (Pro Only) – Polish optimizes your site's images, and can be configured to serve WEBP images to supported browsers. This feature is only available on Cloudflare Pro plan and above.

Cloudflare Protection

Cloudflare's primary feature is a sophisticated firewall that can help protect you against DDoS attacks and malicious actors. Let's go over Cloudflare's security settings.

  • Security Level – This setting controls the sensitivity of Cloudflare's firewall and security rules. We recommend setting the “Security Level” to “Medium” for most sites.
  • Browser Integrity Check – This feature looks out for bad behavior and suspicious user agents. If it detects a potentially malicious user or spammer, Cloudflare will automatically serve a challenge. We recommend enabling this feature.
  • Always Online – This option will serve static HTML pages of your site if your origin goes down. We recommend enabling it if you've configured Cloudflare to cache HTML.
  • Web Application Firewall – Cloudflare's WAF, or web application firewall, will scan incoming traffic and filter out “illegitimate traffic” from reaching your site. We recommend enabling this feature.
  • Advanced DDoS Protection – This feature is enabled by default, and cannot be disabled as long as Cloudflare's proxy is active. DDoS protection helps shield your site from “distributed denial of service” attacks.
  • Max Upload – This sets the maximum allowed file size for uploads to your site. You'll want to make sure that this setting is either equal to or greater than your upload file size setting in WordPress.

Cloudflare SSL

Lastly, you'll want to make sure your Cloudflare SSL settings are configured correctly. Let's go over the right configuration in this section.

  • SSL – If your site is hosted on Kinsta, we recommend using either the “Full” or “Full (Strict)” SSL option. The “Flexible” option is not compatible with our infrastructure. “Full Strict” requires an SSL from a valid certificate authority, while the “Full” option also supports self-signed SSLs. The “Flexible” option does not require an SSL certificate on the origin server – we don't recommend this option because it is the most insecure.
  • TLS 1.2 Only – TLS, or Transport Layer Security, is a secure protocol for transferring data over a network. Some PCI compliance standards require dropping support for TLS 1.1 and below. If that is a requirement for your site, you can enable the “TLS 1.2 Only” setting in Cloudflare to set the minimum TLS version to 1.2.

推奨読書：WordPress用にCloudflareAPOを設定する方法。

W3トータルキャッシュWooCommerce設定

WooCommerceは、WordPressサイトで最も人気のあるeコマースプラットフォームです。 WooCommerceを利用したスト​​アでW3TotalCacheを使用している場合は、顧客の詳細がキャッシュされないように、構成が正しいことを確認する必要があります。

WooCommerceCookieをバイパスする

WooCommerce固有のCookieを持つページのページキャッシュをバイパスするには、W3TCの[ページキャッシュ]設定に移動し、[拒否されたCookie]まで下にスクロールして、以下の4つの項目を追加します。

  • woocommerce_items_in_cart
  • woocommerce_cart_hash
  • wp_woocommerce_session_
  • wordpress_logged_in
W3TotalCacheでWooCommerceCookieをバイパスします。
W3TotalCacheでWooCommerceCookieをバイパスします。

安全のため、カートページ、チェックアウトページ、アカウントページなどのWooCommerce固有のURLをバイパスすることもお勧めします。 これらのページをキャッシュからバイパスするには、W3TCの「ページキャッシュ」設定に移動し、「次のページをキャッシュしない」セクションにURLを追加します。

W3TotalCacheからWooCommerceページをバイパスします。
W3TotalCacheからWooCommerceページをバイパスします。

W3トータルキャッシュのすべての設定をリセットする方法

場合によっては、W3TC構成を最初からやり直す必要があります。 W3TotalCacheをデフォルト設定に戻す方法は次のとおりです。 W3TCの[一般設定]メニューに移動し、[設定のインポート/エクスポート]セクションまで下にスクロールして、[デフォルト設定に戻す]をクリックします。

W3トータルキャッシュをデフォルト設定にリセット
W3TotalCacheをデフォルト設定にリセットします。
100万以上のアクティブなインストールがあるため、W3TotalCacheが人気があります。 設定方法と設定の最適化方法については、こちらをクリックしてください。

概要

ご覧のとおり、W3TotalCacheプラグインには機能と設定が満載です。 ページのキャッシュからアセットの縮小、Cloudflareの統合まで、W3TCにはWordPressサイトのパフォーマンスを向上させるために必要なすべてが揃っています。

この記事では、W3TCに推奨される構成プラグインについて説明しました。 お気に入りのWordPress最適化プラグインはありますか？ 以下のコメントでお知らせください！