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

W3 Total Cache(以下 W3TC)のPage Cache メニューは、ページキャッシュに関する詳細な設定をおこなうための全6セクションで構成されていて、キャッシュ対象にするページの種類や条件の設定、キャッシュの事前生成、キャッシュの削除条件などを設定します。

ページキャッシュはWebサイトのパフォーマンスを向上させる最も効果的な方法の1つです。各オプションの役割と動作の仕組みを理解し、自分のサイトにあった構成でキャッシュパフォーマンスを最大限かつ安全に引き出しましょう。

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

設定の前に知っておきたいこと

ページキャッシュは誰かがページを見た時に作られます

通常、ページキャッシュは誰かがWebページにアクセスしてきた時に生成され、次に同じページにアクセスしてきた他の誰かのために生成されたキャッシュが利用されます。つまり2回目以降の表示が高速になります。

事前にキャッシュを生成して、1回目の表示から高速化することも可能ですが、次に述べるようにサーバーへの負荷も考慮する必要があります。

ページキャッシュを作ったり消したりする時はサーバーに負荷がかかります

ページキャッシュを生成して保存したり、期限切れのキャッシュを削除したりする処理をおこなう際、サーバーには負荷がかかっています。つまり、何でもキャッシュしておけばよいというものではなく、不必要にキャッシュを作成したり削除する設定は、かえってパフォーマンスを低下させる場合があります。

キャッシュされたページかどうかを確認するには$

キャッシュされたページが表示されているかを確認するには、お使いのブラウザでページのソースコードを表示すると、最下部に挿入されたコメントで確認できます。

キャッシュされたページの場合

キャッシュされたページのコメント

キャッシュされたページの場合、ページキャッシュの方式とキャッシュの生成時間が表示されます。

キャッシュから除外したページ

キャッシュされていないページ

ページキャッシュのオプションで、キャッシュから除外したページの場合、ページキャッシュの方式の後にキャッシュされなかった理由がカッコ書きで表示され、ページを表示した時間が表示されます。

ページキャッシュを無効にしている時

ページキャッシュを無効にしている場合

Gneral Settings で、そもそもページキャッシュ自体を無効にしている場合、ページを表示した時間だけが表示されます。

General

W3TC ページキャッシュのGeneralセクション

General(一般・全般)セクションでは、ホームページや404エラーページなど通常のページとは異なる特殊なページのキャッシュや、特定条件下でのキャッシュの可否などを設定します。

Cache front page

チェクするとホームページ(サイトのトップページ)をキャッシュします。デフォルトでONになっており、ほとんどのサイトにおすすめです。

ただし、リアルタイムにデータを更新して表示内容が変化する動的なコンテンツ(例えば外部から情報を取得して表示するウィジェットなど)や、ページを表示する都度、内容が変化する要素がある場合は、チェックを外してキャッシュを無効にします。

Cache feeds: site, categories, tags, comments

チェックを入れるとフィードをキャッシュします。デフォルトではOFFですが、フィードの配信に力を入れていてフィードの購読者が多いサイトや、Google FeedBurner などのFeedプロキシサービス を利用している場合は、ONにする価値があります。

フィードって何?という方や、単純に検索エンジン対策向けにフィードを使っている程度であれば、OFFのままでも良いでしょう。

FeedBurner は、ブログが配信するフィードを収集し、読みやすく整形して代理配信(Proxy)するサービス。フィードに関する分析機能なども提供しています。ちなみにFeedBurner はWebサイトのフィードを30分おきにチェックします。

Cache SSL (HTTPS) requests

httpsから始まるアドレスのページをキャッシュします。この記事をご覧になっている方で、おそらくSSL化していないサイトはないと思います。ONにしたままにしてください。

なお、完全SSL化をしておらず、Webサイト内に https と http のページが混在している(=どちらでもアクセスできる)場合でも このオプションをONにしておきます。それぞれ固有(uniquely)のキャッシュが作成されます。

Cache URIs with query string variables

チェックを入れると パラメーター付きのURLもキャシュします。特別な理由がなければOFFのままにします。

パラメーター付きのURL(URLパラメーター)とは$

URLパラメーターの最もわかりやすい例は、Webサイトの検索ウィジェットでキーワードを入力してみると分かります。例えば、当サイトの検索ウィジェットで outlook と入力して検索すると、検索結果のURLは

https://outlook.aptrust.net/?s=outlook

になります。この場合、から始まる一連の文字列を URLパラメーター(query string)といい、簡単にいうと、これによってページに表示される内容が変化します。

このオプションを有効にすると、同じアドレスであっても、URLパラメーターによって変化した内容ごとにキャッシュを生成できるようになります。

Cache 404 (not found) pages

チェックすると、404ページ(存在せず見つからないページ)へのアクセスがあった時に表示されるページをキャッシュして、サーバーの負荷を軽減します。

大抵の場合、人の手による404ページへのアクセスはそれほど多くなく、キャッシュして高速化するメリットよりもキャッシュによるサーバーへの負荷やディスクスペースの消費というデメリットの方が大きいのでOFFにしておくことをお勧めします。

また、 ページキャッシュ方式で Disk Enhanced を選択している場合は、その性質上、キャッシュされたページが 本来返すべきレスポンスコードの404ではなく、200(存在するページ)を返してしまうので、共用レンタルサーバーを利用している場合も やはり OFFにしておくべきでしょう。

Don’t cache pages for logged in users

チェックすると、ログイン中のユーザーがページを表示した時にはキャッシュを生成しません。特別な事情がない限り必ずONにしておきます

通常、ログイン中のユーザーが見るページは、ページ上部のツールバーなどの一般公開されていない情報を含んでいます。冒頭で説明したように、キャッシュは、誰かが初めてページを見た時に作られますが、ログイン中のユーザーがページを見た時にキャッシュが作られてしまうことは、見た目はもちろんセキュリティの面からも望ましくありません。

このオプションは、そのような不適切なキャッシュの生成を防止します。

Don’t cache pages for following user roles

上記の「Don’t cache pages for logged in users」は、すべてのログイン中のユーザーが対象となりますが、こちらのオプションは、ユーザーの権限レベルを絞って キャッシュの生成を制御します。したがって「Don’t cache pages for logged in users」にチェックを入れている場合は、こちらをONにする必要はありません(ONにしても無視されます)。

このオプションをONにする場合、チェクを入れていない権限レベルのユーザーのツールバーは非表示にしておくことをお勧めします。

Don’t cache pages for following user roles が機能しない?$

このオプションをONにした後、チェックを入れた権限レベルのユーザーは、一旦ログアウトして再度ログインする必要があります。そのままページを閲覧するとキャシュが生成されるので注意してください。

これは、キャッシュを制御するためのCookieがログイン時のみ生成されるためです。

Aliases

W3TC キャッシュメニューのエイリアスドメインセクション

Aliases(エイリアス)セクションでは、W3TCをインストールしているWordPressのドメインにエイリアスドメインをマッピング(≒紐づけ)している場合に、エイリアスドメインからアクセスした時のキャッシュを制御する設定をおこないます。

この機能を個人の方が使用する必要はまずなく、無視して構わないセクションです。ここでは用語解説にとどめます。

WordPressをインストールして記事や画像などを実際に保存するのに使っている実体を伴ったドメインをプライマリドメインといい、ほとんどの場合プライマリドメインを使ってWebサイトを公開しています。

エイリアスドメインは、プライマリドメインの別名として使用する目的で、異なる文字列を使って別途取得・構成された1つまたは複数のドメインです。

  • プライマリドメイン:mydomain.com
  • エイリアスドメイン:my-site.com や mydomain.net

といった具合です。エイリアスドメインの実体はプライマリドメインなので、複数のURLを維持しながら管理するコンテンツを1セットに集約することができます。

上記の例では、my-site.comのURLにアクセスするとmydomain.comと全く同じ内容を表示させることができます。Webサイトの閲覧者から見て唯一異なるのはブラウザのアドレスバーの部分だけです。

なお、エイリアスドメインと似たような目的を達成するための手法として リダイレクト(転送)があります。こちらは my-site.com にアクセスすると ブラウザのアドレスバーの表示も mydomain.com になります。

エイリアスドメインもリダイレクトも サイトの移転や類似ドメインからの流入確保の目的で使用されることがありますが、そのような目的で使用する場合は、管理が容易でSEO的な観点でも重複コンテンツを避けられるリダイレクトを使用する方が良いでしょう。

Cache Preload

W3TC ページキャッシュのキャッシュプリロード

Cache Preload(キャッシュプリロード)セクションでは、ページキャッシュの事前生成(プリロード)に関する設定をおこないます。

  • 冒頭で説明したように、キャッシュは誰かが初めてページを見た時に作られますが、 このオプションを使うと事前にキャッシュを生成し、初めてページを見る誰かのために1回目の表示から高速化することができます。
  • キャッシュプリロードで生成されるページキャッシュはデフォルトのページキャッシュのみです。ユーザーエージェント別キャッシュなど追加のキャッシュを生成する設定をしている場合でも、追加のキャッシュ分は実際にアクセスがあった時に作られます。
Automatically prime the page cache

チェックを入れると キャッシュの事前生成が有効になり、以下のオプションが利用できます。

Update interval

W3TCは下の Pages per interval で設定したページ数を1セットとして、時間を空けながらキャッシュを生成することでサーバーへの負荷を軽減します。短くすれば、より早くキャッシュ生成処理が終わりますが、共用レンタルサーバーでは、初期値の900秒(15分)が妥当なようです。

なお、初めてプリロードを有効にした後や、全てのキャッシュを削除した後は、誰かがページにアクセスするか、ここで設定した時間経過後に、最初の1セットが生成されます。

プリローダーが一巡して最初に戻った時に、キャッシュの有効期限が切れていなければ、キャッシュを無駄に再生成せず処理がスキップされます。

Pages per interval

一度にキャッシュを生成するページ数を指定します。サーバーへの負荷を考慮して、ここも初期値のままで良いでしょう。

Sitemap URL

お使いのサイトのサイトマップがあるURLを指定します。サイトマップに記載された順序や優先度に従ってキャッシュを生成します。なお、Cache Preload を使用する場合、サイトマップの指定は必須です。

Preload the post cache upon publish events

投稿が新規公開または更新された時に、その投稿ページのキャッシュを事前作成します。Cache Preload を有効にするなら、こちらも有効にしておくと便利です。

一定数以上のアクセスを安定して確保しているWebサイトであれば、わざわざサーバーに負荷をかけて事前キャッシュを作らなくても、訪問者によってキャッシュはどんどん作られるので、ONにする必要はありません。

ただ、最近の共用レンタルサーバーは、サーバーの処理能力が高いので、お好みでONにしておいても良いでしょう。

また、立ち上げたばかりのWebサイトで、アクセスが極めて少ない場合は、事前キャッシュを作成しておけば、最初の「お客さん」を逃さないように出来るかもしれませんので、ONにしても良いでしょう。

Purge Policy:Page Cache

W3TC ページキャッシュのキャッシュ削除ポリシー

Purge Policy(パージポリシー)セクションでは、投稿の作成・編集またはコメントの投稿時に古いキャッシュをパージ(=削除)する動作を設定します。初期値のままでも問題ありません。

Specify the pages and feeds to purge…$

投稿の作成・編集時に、ここでチェックを入れた種類のページのキャッシュも同時に削除します。キャッシュの削除対象が多くなると、それだけ次に生成されるべきキャッシュの数が増えてサーバーに負荷をかけることになるので、必要以上にチェクを入れないように気をつけてください。

デフォルトでチェックの入っていない種類のページは、頻繁にアクセスされることがなければOFFのままで問題ありません。OFFのままでも設定した有効期限が過ぎれば自動でキャッシュが削除されるからです。

Front page

サイトのホームページ(トップページ)のキャッシュを削除します。一般的なブログサイトであれば、ホームページに最新の投稿が表示されるので、ONにしておくことをお勧めします。

なお、ホームページのフィードのキャッシュを削除するには 後述の Blog feed にもチェックを入れます。

Post page

投稿や固定ページを更新した時に、そのページ自身のキャッシュを削除します。チェックを入れていない場合、手動でキャッシュを削除するか有効期限が来るまで、更新後の内容が訪問者に表示されません。ONにしておくことを強くお勧めします。

投稿にコメントがついている場合に生成されるコメントフィードのキャッシュを削除するには 後述の Post comments feed にもチェックを入れます。

Blog feed

投稿や固定ページを更新した時に、ホームページのフィードキャッシュも同時に削除します。GeneralセクションでフィードのキャッシュをONにしている場合は、 こちらもONにしておきましょう。

Post comments pages

このオプションをONにすると、WordPressのディスカッション設定でコメント数が多い時にコメントページを分割するオプションを有効にしている場合、分割されたコメントページ(2ページ目以降)のキャッシュを削除します。

前述の Post page をONにしていれば、1ページ目のコメントはページキャッシュとともに削除されるので コメントを使用していない、またはコメント数が多くないWebサイトではOFFのままでOKです。

Post author pages

投稿を更新した時に、その投稿の著者アーカイブページのキャッシュを削除します。個人で運営しているWebサイトなど、著者アーカイブを無効化している場合はOFFのままにしておきます。

Post terms pages

投稿を更新した時に、その投稿に関連するタグやカテゴリー、カスタムタクソノミーのアーカイブページのキャッシュを削除します。

Post comments feed

投稿を更新またはコメントが付いた時に、その投稿のコメントフィードのキャッシュを削除します。なお、サイト全体のコメントフィードのキャシュは削除されないようです。

Post author feed

投稿を更新した時に、その投稿の著者アーカイブのフィードキャッシュを削除します。著者アーカイブを使用していない場合はもちろんOFFで。

Post terms feeds

投稿を更新した時に、その投稿に関連する カテゴリー・タグ・カスタムタクソノミーアーカイブのフィードキャッシュを削除します。

Daily/Monthly/Yearly archive pages

投稿を更新した時に、日・月・年などの日付別アーカイブページのキャッシュを削除します。日付別アーカイブへのアクセスはほとんど無く、無効化している場合も多いと思います。特別な事情がない限りONにする必要はないでしょう。

Specify the feed types to purge

投稿の更新やコメントが付いた時に削除するフィードの配信フォーマットを指定します。デフォルトでRSS2だけチェックが入っている理由は不明ですが、この状態で一般的なフィードのURL「http://example.com/feed/」にアクセスして生成されたフィードのキャッシュは削除されるようです。

なお、GeneralセクションでフィードのキャッシュをOFFにしている場合は、 RSS2 のチェックを外してしまっても構いません。

Purge limit

ホームページやアーカイブページなど、投稿がリストされる種類のページのキャッシュを削除する際に、何ページ目まで削除するかを指定します。これは、膨大な投稿数があるサイトではこのようなリストページを全て削除すると、過大な負荷がかかってしまう為です。

一般にリストページで10ページ以上も回遊されるケースは少ないので、デフォルト(10)のままで良いでしょう。なお、この値を0にすると、全ページのキャッシュを削除します。

Additional pages

投稿の作成・更新やコメントが追加されたことを契機としてキャッシュを削除するべきページが、前述の「Specify the pages and feeds to purge…」だけでは指定できない場合は、この欄に該当ページのパスを入力します。

具体的には、階層構造をもつ固定ページで、子ページを更新した時に親ページのキャッシュも合わせて削除したい時などにも使えます。

記述例$

  • URLが https://example.com/parent/ の場合
    parent
  • URLが https://example.com/parent/child/ の場合
    parent/child

※ドメイン以下の相対パスで記述します。複数ある場合は、URLごとに改行して記述します。

Purge sitemaps

投稿の作成・更新の際に、サイトマップのキャッシュを削除します。この欄は、デフォルトで sitemap~.xml の正規表現で記述されています。お使いのサイトマップのURLに、sitemap.xml が含まれている場合は、特に変更する必要はありません。

一般的なサイトマップの場合、まず変更する必要はないでしょう。

REST API

W3TC ページキャシュ REST APIセクション

REST API(レストエーピーアイ)セクションでは、WordPressが備えるREST APIのキャッシュのON/OFFを設定します。REST APIセクションの設定は W3TC Pro版の機能であり、このチュートリアルの範囲外なので解説を割愛します。

WordPressのREST APIとは$

REST API とは Representational State Transfer Application Programming Interface の頭文字を組み合わせたもので、分散処理のために、WordPressを異なるアプリケーションやプログラムと接続して活用するための仕組みです。

WordPerss内部でのデータのやり取りに使われており、WordPress5.0以降のGutenbergブロックエディターを動作させる際に必要です。

REST APIを使って、WordPressをWebサイトとしてではなく、アプリケーションや他のWebサイトのバックエンドとして活用することもできます。

Advanced

W3TC ページキャッシュのAdvancedセクション

Advanced(アドバンスド)セクションでは、ページキャッシュ生成動作の高度な設定や詳細なキャッシュの例外処理などを設定します。個人のWebサイトなど一般的な利用においては、デフォルトのままでも問題ありませんが、生成されたキャッシュの有効期限などは、運営しているサイトの状況に応じて変更するのも良いでしょう。

Gneral Settings で選択した ページキャッシュ方式 によって、利用できるオプションが一部異なります。

Late initialization

動的要素が多くフルページキャッシュに適さないサイトを高速化するための部分キャッシュを実現するフラグメントキャッシュを利用する場合にONにします。なお性質上、Gneral Settingsの ページキャッシュ方式で 静的なHTMLを使用する Disk:Enhanced にしている場合は利用できません。

Late caching

例えば、同じURLで訪問者の国別に異なる内容のキャッシュを提供する場合に、キャッシュの処理を遅延させて、キャッシュの参照先を示す値(キー)を書き換える際に使用するオプションです。 こちらも、Gneral Settings で ページキャッシュ方式を Disk:Enhanced にしている場合は利用できません。

Maximum lifetime of cache objects$

キャッシュアイテムの有効期限を指定します。このオプションは、Gneral Settings で ページキャッシュ方式を Disk:Enhanced にしている場合は利用できません

Disk:Enhanced のページキャッシュの有効期限の設定$

Disk:Enhanced を選択している場合のページキャッシュの有効期限は、Browser Cache メニューの HTML&XML セクションに移動し、 Expires header lifetime の値で設定します。

W3TC ページキャッシュの有効期限設定

なお、この設定は Gneral Settings でブラウザキャッシュをONにしていなくても動作します。また、ページキャッシュの有効期限の管理だけが目的なら、すぐ上の Set expires header にチェックを入れる必要もありません。

ページキャッシュの有効期限の初期値3600秒(1時間)より大幅に長く設定する方もいますが、個人的にはあまりメリットがないと思います。

ほとんどのWebサイトでは、毎日すべてのページに大量のアクセスがあるわけではありません。たまにしかアクセスがないページのためにサーバーのディスクスペースを占有させ続けるのは効率的とは言えないでしょう。

また、人気があるページであれば、初期値のままでも訪問者によってキャッシュは直ぐに再生成され、キャッシュの恩恵を受ける訪問者の数に影響はほとんどないからです。

デフォルトよりも長く設定するなら、多くても86400秒(1日)ぐらいにとどめて様子を見ながら調節してみてください。

Compatibility mode

このオプションを有効にすると、WordPressをインストールしている環境との互換性が向上しますが、引き換えにパフォーマンスが最大20%減少するとされています。W3TCの動作で特に問題がなければOFFにしておきます。

Charset

キャッシュされたページに文字化けがある場合に、このオプションを有効にすると改善する場合があります。

Reject HEAD requests

このオプションをONにすると、HEADリクエストのキャッシュが無効になり 、権限のないユーザーがキャッシュされたHEADリクエストを使ってページをリロードできなくなるため セキュリティが向上する反面、「空のページ」が返される可能性があります。そのため、よくわからない場合はONにすべきではありません。

Garbage collection interval

ディスク(またはメモリ)内に残っている期限切れのキャッシュを削除する間隔を指定します。デフォルトで問題ありませんが、次々にキャッシュが作成されるような非常に混雑したサイトでは、より小さい値を指定してディスクスペースを確保できます。ただし、頻繁に削除するする場合はサーバーへの負荷が高くなるので注意してください。

  • 基本的にはキャッシュの有効期限と同じ時間を設定します。
  • ここで指定する値はキャッシュの有効期限を指すものではありません。キャッシュの有効期限の設定方法はこちら

有効期限切れのキャッシュは WordPressのCron(クーロン)という仕組みによって定期的に処理されています。削除間隔を変更した場合は、変更前に指定した処理が実行された時に初めて変更後の値が次回実行日時としてセットされます。

したがって、変更前の値によっては意図した削除間隔で処理されるようになるまでにタイムラグが生じることがあります。

Comment cookie lifetime

Webサイトにコメントを残す訪問者の利便性を向上するためのCookie情報の保持時間を設定します。きわめて多くの訪問者が同時にコメントをするようなサイトでは、デフォルト値よりも少ない値を指定することで、コメント入力に関する利便性と引き換えにサイトのパフォーマンスを向上できます。

Accepted query strings

Generalセクションで「Cache URIs with query string variables」のオプションを有効にしていない場合、この欄で指定したパラメーターを持つURLを個別にキャッシュすることができます。

パラメーターは、名前と値をセットにして記述するか、名前のみで指定することもできます。例えばURLが
https://mydomain.com/shoes/?brand=nike
の場合、
brand=nike
のように、名前と値をセットにすると、ブランドをNikeで絞り込んだ結果だけをキャッシュします。
brand
とだけ記述すると、他のブランドで絞り込んだ結果もキャッシュします。

※ 複数の条件を指定する場合は改行して1行ずつ記述します。なお、投稿日現在このオプションを指定しても正しくキャッシュできないバグがあるようです

Rejected user agents

指定したユーザーエージェントを持つブラウザでWebサイトにアクセスがあった場合、キャッシュの生成および配信をしないようにできます。複数のユーザーエージェントを指定する場合は1行ずつ記述します。

Rejected cookies

特定のCookieを使用するページでキャッシュの生成と配信を無効にします。上級者向けのオプションなので初期値のままにしておきましょう。

Never cache the following pages$

この欄で指定したURLでキャッシュの生成と配信を無効にします。初期値ではWordPressの管理画面など、通常の利用でキャッシュすべきでないURLを正規表現で一括指定しています。この欄を編集する際は初期値を消さずに追記するようにしてください。

正規表現を使った指定方法の例

特定の親ページとその子ページのキャッシュを無効化

例:親ページがparent という名前の場合
/parent*
この場合、parent も parent/child のいずれもキャッシュされません。

特定の親ページ配下にある子ページだけキャッシュを無効化

例:親ページがparent という名前の場合
/parent/.+
この場合、parent はキャッシュされ、/parent/child はキャッシュされません。

特定の文字列を含むURLのキャッシュを無効化

例:text という文字列を含む場合
/.*text.*

特定のディレクトリ名を含むURLのキャッシュを無効化

例:child という名前のディレクトリの場合
.+/child

特定の投稿名のキャッシュを無効化

例:投稿名(スラッグ)が child の場合
*/child

Never cache pages associated with these categories

特定のカテゴリーに属するページでキャッシュの生成と配信を無効にできます。指定するカテゴリー名(=タームスラッグ)を1行ずつ記述します。

なお、カテゴリーアーカイブページのキャッシュも無効にする場合は、前述の「Never cache the following pages」の欄で指定します。

Never cache pages that use these tags

特定のタグが付けられたページでキャッシュの生成と配信を無効にできます。指定するタグ名(=タームスラッグ)を1行ずつ記述します。

なお、タグアーカイブページのキャッシュも無効にする場合は、前述の「Never cache the following pages」の欄で指定します。

Never cache pages by these authors

特定の著者の投稿でキャッシュの生成と配信を無効にできます。指定する著者のユーザー名(半角英数のほう)を1行ずつ記述します。ここで指定したユーザーは著者アーカイブページもキャッシュされません。

Never cache pages that use these custom fields

指定したカスタムフィールドの値を有している投稿でキャッシュの生成と配信を無効にできます。前述のように一定の法則に基づいた方法でキャッシュを無効化するのが難しい場合に便利です。

記述例

例えば、nocache という名前のカスタムフィールドを作成し、フィールドの値を 1 に設定した投稿のキャッシュを無効にする場合は、
nocache=1
といったように、フィールド名(スラッグ)と値を 記号でペアにしたものを記述します。

複数の条件を設定する場合は、改行して1行ずつ記述します。

Cache exception list

前述の「Never cache the following pages」の欄で 指定した内容の例外を指定できます。つまり例外の例外設定です。

例えば「Never cache the following pages」の欄にある「wp-.*.php」は、管理画面全体に及びますが、こちらの欄に記述されている「wp-comments-popup.php」などの3つは例外としてキャッシュの対象になります。

例外の例外としたいURLやファイル名を1行ずつ記述します。正規表現も利用できるようです。

Non-trailing slash pages

末尾のスラッシュがない場合でも指定されたページ(ファイル)をキャッシュします。特別な事情がない限り、初期設定のままで良いでしょう。

URL末尾のスラッシュを trailing slash(トレイリングスラッシュ)といいます。

  • WordPressのパーマリンク設定でカスタム構造を選択し、末尾にスラッシュ付けないように設定している場合、このオプションは表示されませんが、ページは問題なくキャッシュされます。
  • パラメーター付きURLのキャッシュは、このオプションの設定と関係ありません。

Specify page headers

この欄では、キャッシュしたいページヘッダーの種類を指定できます。Gneral Settings で ページキャッシュ方式を Disk:Enhanced にしている場合は利用できません。

デフォルトでは、http2 server Push を利用するために必要な Link ヘッダーなどが入力済みです。特に変更する必要はありません。

Handle XML mime type

チェックを入れると、フィードやサイトマップのキャッシュを生成する際に、ブラウザがファイルの種類(MIMEタイプ)を正しく認識・処理できるようにするための処理を追加します。このオプションは Gneral Settings で ページキャッシュ方式を Disk:Enhanced にしている場合固有の設定です。

ブラウザーは URL を処理する方法を決定するために、ファイル拡張子ではなく MIME タイプを使用しますので、ウェブサーバーは正しい MIME タイプをレスポンスの Content-Type ヘッダーで送信することが重要です。これが正しく構成されていないと、ブラウザーはファイルの中身を誤って解釈し、サイトが正しく動作しなかったり、ダウンロードファイルが誤って扱われたりすることがあります。

developer.mozilla.org