WP高速化：LiteSpeed Cache全設定項目を詳しく解説

けーちゃん

こんにちは。管理人のけーちゃんです。

mixhost等のLiteSpeedサーバー採用レンタルサーバーを使っているなら、WordPressのLiteSpeed Cacheは必須プラグインです。

LiteSpeed Cacheは簡単な設定でWebサイトを高速化できるのです。

そして、LiteSpeed Cacheに様々な機能が含まれており、試行錯誤しながらチューニングすることでさらなる高速化を狙えます。

そこで今回は、チューニングの一助としてLiteSpeed Cacheの設定項目について解説します。

けーちゃん

全部解説したら10万文字をこえました（汗
ブックマークして後で見てね

＼目次も見てね！／

初心者向け設定

LiteSpeed Cacheは初めて使用する方がどうしたらいいのか迷ってしまうほど、様々な設定項目があります。しかも適当に設定すると、Webページのレイアウト崩れなどの問題を引き起こします。

そこで、レイアウト崩れの問題を起こしにくい設定方法を、別のページで紹介しています。これからLiteSpeed Cacheを使い始める、という方は参考にしてください。

前提知識：LiteSpeedサーバーのキャッシュ

LiteSpeed Cacheプラグインは用途に応じて三つのキャッシュを操作します。

まずはLiteSpeed Cacheのキャッシュについて簡単に解説します。

パブリックキャッシュ

パブリックキャッシュは、WordPressにログインしていない閲覧者向けのキャッシュです。

ブラウザからWebページが呼び出されるとWordPressがページを生成しますが、ログインしていない閲覧者からの呼び出しだった場合、生成されたページがパブリックキャッシュに保存されます。

パブリックキャッシュはクエリ文字が考慮されます。例えば、次のURLは異なるページとしてキャッシュされます。

https://ドメイン/page1
https://ドメイン/page1&prm=1
https://ドメイン/page1&prm=2

異なるクエリ文字が頻繁に使用される場合、パブリックキャッシュがディスクスペースを圧迫する可能性があります。このような事態が想定されるときは、クエリ文字列を落とすを設定することで、特定のクエリ文字を無視できます。

パブリックキャッシュは、キャッシュ設定の[1] キャッシュ内のキャッシュを有効にするで有効化と無効化の切り替えを行います。

プライベートキャッシュ

プライベートキャッシュは、WordPressにログインしている閲覧者向けのキャッシュです。

これはECサイトや会員制サイトなどで、個人ごとにページをカスタマイズして情報を提供するサイトで利用されます。

個人ごとにページを生成するのは非常に時間がかかる作業です。またサーバーに大きな負担をかけます。キャッシュを利用することで、時間と負担を大幅に減らすことができます。

その反面、対象となるユーザーが増えるに従って、キャッシュデータも増大します。例えばユーザーが一万人なら、一つのページで一万のキャッシュが生成されます。そのため記録媒体の監視が必要になります。場合によっては、プライベートキャッシュを使用しない選択が必要です。

プライベートキャッシュは、キャッシュ設定の[1] キャッシュ内のログインしたユーザーをキャッシュで有効化と無効化の切り替えを行います。

ESIキャッシュ

ESIキャッシュはESIとして生成されたデータをキャッシュします。

通常はパブリックやプライベートキャッシュの内容は、後から変更できません。そのため、現在時間表示など毎回内容が変わる箇所は、キャッシュ時の内容で固定されます。

ESIは、キャッシュに動的なパーツを組みこむ仕組みです。ESIを使用することで、キャッシュ内の内容を更新できます。
参考：https://en.wikipedia.org/wiki/Edge_Side_Includes

ESIはショートコードで組み込みます。

次のコードは、1から100までのランダムな数値を返すショートコードを作成しています。

add_shortcode('random',function(){
	return rand(1,100);
});

これをESIとして呼び出します。投稿記事で、次のようにショートコード呼び出しします。

[esi random ttl="1"]

ttlはESIキャッシュの有効期限で単位は秒です。

Webページを呼び出すと、ブラウザに表示されると同時に、ページがキャッシュされます。次回表示はキャッシュがブラウザに送られますが、ESIの部分は内容が更新されます。

ただしESIの内容はキャッシュされ、ttlを経過するまで同じ内容が表示されます。

ESIを利用するときは、キャッシュ設定の[5] ESIでESIを有効にする必要があります。有効でない場合、上記のショートコードは機能しません。

前提知識：CCSSとUCSS

WebページはCSSという仕組みでページの外観を定義しています。

一般的にCSSは一つの大きなファイルです。Webサイト内のページは、このファイルを共通的に使用するため、Webページ上で使用していない定義も読み込みます。例えばtableタグを使用していないWebページでも、tableタグの定義を読み込みます。

使用しない定義の読み込みは、ページ表示を遅くする原因の一つです。そこで、CCSSとUCSSという仕組みを使って、CSSの読み込みによるページ表示速度の低下を改善します。

CCSS

CCSS（クリティカルCSS）は、ブラウザ上で最初に表示される範囲（ファーストビュー）で使用しているCSS定義を抜き出したものです。

CCSSはWebページ内に直接記述（インライン）されます。そのため読み込み遅延なく、ファーストビューが表示されます。閲覧者はこの時点でページ操作可能になるため、ページ表示が速いという印象を与えることができます。

そして残りのCSSは、ファーストビューがブラウザに表示されてから、読み込まれます。

CCSSはページの最適化設定の[1] CSS 設定タブのCSSを非同期読み込みで有効化できます。

UCSS

UCSS（ユニークCSS）は、Webページ内で使用しているCSS定義のみを抜き出したものです。不要なCSS定義を読み込まないため、Webページの表示時間を短くすることができます。

UCSSはページの最適化設定の[1] CSS 設定タブのUCSS を生成するで有効化できます。

CCSSとUCSSの併用

CCSSとUCSSの併用する場合、CCSSをWebページにインラインで埋め込み、ファーストビュー表示後にUCSSを読み込みます。

UCSSをインラインで埋め込むことも可能です（ページの最適化設定の[1] CSS 設定タブのUCSS インライン）。この場合は、CCSSは使用しません。なぜなら、UCSSにはCCCSと同じ内容が含まれているからです。

LiteSpeed Cacheの設定項目

LiteSpeed Cacheは、10種類の設定ページが用意されています。

メニュー画像	メニュー項目
	1.ダッシュボード
	2.プリセット
	3.一般
	4.キャッシュ
	5.CDN
	6.画像の最適化
	7.ページの最適化
	8.データベース
	9.クローラー
	10.ツールボックス

ダッシュボード

ダッシュボードは、LiteSpeed Cacheの稼働状況に関する様々な情報が表示されます。

項目1：QUIC.cloud サービスの使用統計

QUIC.cloud サービスの使用統計欄は、QUIC.cloudサーバーにて処理される最適化の無料枠の数と使用量が表示されます。

各項目の使用量はひと月の無料割り当てを表しています。『of』の前の数値が使用量を、後ろの数値が割り当てられている最大量です。前の数値と後ろの数値が同じ値になると、その月は使用できません。

各項目の一日の割り当て量は、『/』の前の数値が残りの使用量を、後ろの数値が割り当てられている最大量です。前の数値がゼロになると、その日は使用できません。

QUIC.cloudサーバーの四つのサービスは、次の設定項目で有効化します。

• 画像の最適化：
  画像の最適化設定のオリジナル画像の最適化
  
• ページの最適化：
  ページの最適化設定のUCSS を生成する
  ページの最適化設定のCSSを非同期読み込み
  ページの最適化設定のビューポートイメージ
  
• CDN帯域幅：
  CDN設定のQUIC.cloud CDN の自動設定
  
• 低品質の画像プレースホルダー：
  ページの最適化設定のLQIP クラウドジェネレーター

QUIC.cloudの無料枠については、次のページを参照してください。

項目2：ページの読み込み時間

ページの読み込み時間欄は、ページ読み込み時間が表示されます。

『更新前』は最適化とキャッシュ無効の状態での読み込み時間です。
『後』は最適化およびキャッシュ後の読み込み時間です。

読み込み時間測定は『同期する』を押すことで実行されます。

読み込み時間の計測は、QUIC.cloudサーバーで行われます。

項目3：PageSpeed スコア

PageSpeed スコア欄は、PageSpeed APIでの計測結果が表示されます。

『更新前』は最適化とキャッシュ無効の状態での計測結果です。
『後』は最適化およびキャッシュ後の計測結果です。

PageSpeed APIでの計測は『同期する』を押すことで実行されます。

計測は、QUIC.cloudサーバーで行われます。

項目4：画像最適化の概要

画像最適化の概要欄は、画像の最適化状況が表示されます。

画像の最適化は画像の最適化設定のオリジナル画像の最適化をオンにすることで有効になります。

画像の最適化は定期的に自動で行われますが、『最適化要求を送信』を押すことで即時に画像最適化を開始できます。

ただし画像最適化はQUIC.cloudサーバーで処理されるため、時間がかかる可能性があります。

画像最適化について詳しくは画像の最適化設定を参照してください。

項目5：キャッシュステータス

キャッシュステータス欄は、キャッシュ機能が有効化されているかどうかを確認できます。

パブリックキャッシュについては、このページのパブリックキャッシュを参照してください。

プライベートキャッシュについては、このページのプライベートキャッシュを参照してください。

オブジェクトキャッシュについては、キャッシュ設定の[6] オブジェクトを参照してください。

ブラウザキャッシュについては、キャッシュ設定の[7] ブラウザーを参照してください。

項目6：クリティカル CSS

クリティカル CSS欄は、CCSS生成待ちのキュー確認と即時実行を行います。CCSSとはページのファーストビューで使用されているスタイルで構成されたCCSSです。

CCSSは自動でQUIC.cloudサーバーに送信されて生成されます。送信待ちのデータがある場合は『強制 cron』ボタンを押すことで、即時送信できます。

CCSS生成は、ページの最適化設定のCSSを非同期読み込みで有効化します。

項目7：ユニークな CSS

ユニークな CSS欄は、UCSS生成待ちのキュー確認と即時実行を行います。UCSSとはページで使用していないスタイル定義が削除されたCSSです。

UCSSは自動でQUIC.cloudサーバーに送信されて生成されます。送信待ちのデータがある場合は『強制 cron』ボタンを押すことで、即時送信できます。

UCSS生成は、ページの最適化設定のUCSS を生成するで有効化します。

項目8：低品質の画像プレースホルダー

低品質の画像プレースホルダー欄は、LQIP生成待ちのキュー確認と即時実行を行います。LQIPとは画像 遅延読み込みで、初期表示画像として生成された画像です。具体的には、遅延後に表示される画像の低品質バージョンを生成します。

LQIPは自動でQUIC.cloudサーバーに送信されて生成されます。送信待ちのデータがある場合は『強制 cron』ボタンを押すことで、即時送信できます。

LQIP生成は、ページの最適化設定のLQIP クラウドジェネレーターで有効化します。

項目9：ビューポートイメージ (VPI)

ビューポートイメージ (VPI)欄は、VPI解析待ちのキュー確認と即時実行を行います。VPIとはファーストビューに表示される画像です。

VPIとして特定された画像は、画像 遅延読み込みの対象から除外されます。

VPIは自動でQUIC.cloudサーバーに送信されて解析されます。送信待ちのデータがある場合は『強制 cron』ボタンを押すことで、即時送信できます。

VPI解析は、ページの最適化設定のビューポートイメージで有効化します。

項目10：クローラーステータス

クローラーステータス欄は、クローラーのクローラー Cronで定義されているクローラーの稼働状況が表示されます。

項目11：QUIC.cloud

QUIC.cloud欄は、QUIC.cloudの接続に関する情報ページへのリンクが表示されます。

プリセット

プリセットは次の二つのタブで構成されます。

プリセットタブ：[1] 標準プリセット

プリセットの[1] 標準プリセットタブは、事前設定された設定を使って、LiteSpeed Cacheを一括設定します。

プリセットは初心者向けに用意されたものですが、『アグレッシブ』と『エクストリーム』はレイアウト崩れを引き起こす可能性が高く、LiteSpeed Cacheの知識と十分なテストが必要です。

おススメは『高度（推奨）』ですが、こちらもある程度の調整が必要です。詳しくは次のページを参照してください。

プリセットタブ：[2] インポート/エクスポート

プリセットの[2] インポート/エクスポートタブは、LiteSpeed Cacheプラグインの設定値データのダウンロード（エクスポート）と、ダウンロードしたデータを使ってLiteSpeed Cacheの設定値を変更（インポート）します。

この機能は次のような場面で使用します。

• 他のサイトに同じ設定を適用する
• 複数の項目の設定を変更する前にバックアップをとる

項目1：設定のエクスポート

『エクスポート』ボタンを押すと、LiteSpeed Cacheプラグインの設定値が記述されたファイルのダウンロードが始まります。その後の手順はブラウザ毎に異なります。

ダウンロードを行うと、履歴が『エクスポート』ボタンの下方に表示されます。表示されない時は、他の機能を表示後に、再度[2] インポート/エクスポートタブを表示してください。

ダウンロードした設定ファイルはテキスト形式のため、メモ帳などのテキストエディタで参照および変更が可能です。

項目2：設定のインポート

設定のエクスポートでダウンロードしたLiteSpeed Cacheプラグインの設定ファイルを使って、LiteSpeed Cacheプラグインの設定を置き換えます。

『参照』ボタンを押してコンピューター内の設定ファイルを選択した後、『インポート』を押すと確認画面等が表示されずに置き換えが行われます。

インポート後に前の状態に戻すことはできません。エクスポートするつもりでインポートしてしまった、などの失敗をしないようにしましょう。

項目3：すべての設定をリセットする

LiteSpeed Cacheプラグインの設定値を規定値にリセットします。

『設定をリセット』ボタンを押すと確認画面が表示されます。確認画面で『OK』を選択すると、設定値がリセットされます。

リセット後に元に状態に戻すことはできません。リセット前に設定のエクスポートで設定値をダウンロードすることをおススメします。

一般設定

一般設定は次の二つのタブで構成されます。

一般設定タブ：[1] 一般設定

一般設定の[1] 一般設定タブは、LiteSpeed Cacheプラグインの他の機能で分類されない設定を行います。

項目1：自動アップグレード

LiteSpeed Cacheプラグインの新しいバージョンを利用できるようになったとき、新しいバージョンを自動でダウンロードしてインストールします。

更新チェックはwp-cronの呼び出し時におこなわれます。通常はWebページや管理画面が呼び出された時に呼び出されます。そのためWebページへのアクセスが無く管理も放置しているサイトは、自動で更新されません。

またwp-cronの呼び出しが無効になっているサイトも、自動で更新されません。

wp-cronはWordPressで無効にしておいて、サーバーのcron機能で呼び出しているケースもあります。このケースでは、一定間隔で更新の確認が行われます。

wp-cronとサーバーのcron機能については、次のページを参考にしてください。

項目2：ドメインキー

ドメインキーは、LiteSpeed Cacheプラグインの次の機能を使用する際に必要になります。

• CDN設定：QUIC.cloud CDNの利用
• 画像の最適化設定：画像の最適化
• CSS 設定：クリティカルCSS(CCSS)、ユニークCSS(UCSS)の生成
• メディア設定：低品質画像プレースホルダー(LQIP)の生成
• VPI：ビューポート イメージ(VPI)の生成

『ドメインキーの要求』ボタンを押すとQUIC.cloudサーバーにドメインキーの発行を依頼します。通常は発行まで数分かかります。

QUIC.cloudサーバーはドメインキーの要求を受け付けると、次のURLでWordPressのREST APIにアクセスします。

他のプラグイン等でREST APIを無効にしている場合は、ドメインキーを取得できません。上記のAPIを有効にするか、REST API全体を有効に変更する必要があります。

画面を再表示しながら、要求に対する返信を待ちます。次の画面が表示されたらドメインキーの取得成功です。

項目3：ゲストモード

ゲストモードは、訪問者の属性で内容が決定されるWebページで、初回訪問者に高速なページ読み込みを提供するための機能です。

例えば訪問者の所在地によってページの言語を決定したり、性別や年齢で表示内容を変更するサイトは、Cookie等から訪問者の属性を読み取ってWebページを生成します。このとき、生成に時間がかかると訪問者は、長時間待たされることになります。

ゲストモードは、最初に標準的なページ（デフォルトバージョン）を送信します。これにより、閲覧者は自分用のページが生成されるまで待つことなくページ閲覧を開始できます。そして閲覧者ごとにカスタマイズされたページが生成できたら、ブラウザにページを送信します。

送信したデータは訪問者の属性と共にサーバー内にキャッシュされます。そして以降の訪問は、キャッシュからデータが送信されます。

この仕組みは、全ての閲覧者に同じ内容のページを提供するサイト向けではありません。場合によっては同じ内容を二回読み込む可能性があります。また訪問者の属性毎にキャッシュを作成するためディスク容量を圧迫します。そのためオフ推奨です。

なおゲストモードは、閲覧者視点では毎回同じページが表示される（静的ページ）必要があります。PV数表示や価格のみ改定されるときなど、ページの一部が動的に変化するときはESI機能を利用します。

• 参考ページ（外部）：LSCWP v4.0 のゲスト モード

項目4：ゲストの最適化

ゲストの最適化は、ゲストモードがオンのときに閲覧者に最初に送信するページを最大限に最適化します。

ページ最適化と画像最適化の各設定がオフでも、デフォルトバージョンは最適化されます。ゲストモードがオンのとき、該当機能でオフのものは次のようにオレンジの文字が表示されます。

翻訳が上手くいってないようで理解しにくいですが、原文を翻訳すると「ゲスト最適化により、この設定は特定の適格なリクエストに対してオンになっています。」という意味になります。ようするに、「設定はオフだけど、実際はオンですよ」という意味です。

項目5：サーバー IP

WebサイトのIPアドレスを入力します。この項目は任意のため空欄のままでも問題ありません。

この機能はクローラーがサイトのドメイン名をIPアドレスに変換（名前解決）する際に、DNSへの問い合わせを省略して、入力された内容を使用します。

ドメイン名をIPアドレスに変換するとき、通常はDNS問い合わせを行います。問い合わせは外部サーバーにおこなうため、時間がかかります。問い合わせを省くことで、時間短縮を行います。

実際には一度名前解決されるとその情報はサーバーにキャッシュされ、以降はキャッシュから情報を取得します。キャッシュからの情報取得時間は、この項目にIPアドレスが入力されている状態よりも遅いですが、処理速度に大きな差が出るようなデメリットはありません。

• 自作ツール（外部）：ドメインからIPアドレスを取得するツール

項目6：通知

LiteSpeed Cacheプラグインの更新情報やプロモーションなどの通知を、プラグインの画面上部に表示します。

通知例：

上記はLiteSpeed Cacheプラグインに脆弱性が発見されたため、バージョンアップを促しています。バージョンアップ通知はセキュリティ面で有用ですが、自動更新を有効化（管理画面のインストール済みプラグイン一覧で有効化可能）しておくことをおススメします。

一般設定タブ：[2] チューニング

一般設定の[2] チューニングタブは、ゲストモードの追加オプションを設定します。

項目1：ゲストモードのユーザーエージェント

ゲストモードがオンのとき、必ずゲストモードとして処理するユーザーエージェントを指定します。

ユーザーエージェントはWebページのアクセス元から送信されるヘッダー情報に含まれるデータの一つで、主にブラウザの種類等が記述されています。

デフォルト値は既知のボットのユーザーエージェントです。これにより例えばGoogle検索のクローラーに対して必ずデフォルトバージョンを返します。

またLighthouseとGTmetrixはWebサイトのパフォーマンス計測サイトですが、これらで良い結果を出すことを目的としてデフォルト値に含まれています。

項目2：ゲストモード IP

ゲストモードがオンのとき、必ずゲストモードとして処理するIPアドレスを指定します。

デフォルト値は検索エンジンなどの既知のボットのIPアドレスです。

この項目はゲストモードの動作をテストする目的で使用できます。この目的で使用するときは、Webページへのアクセス元となるコンピューター、つまり今使っているパソコンのIPアドレスをリストに追加します。

今使っているパソコンのIPアドレスは、次のリンク先で確認できます。

• 自作ツール（外部）：グローバルIP・ユーザーエージェント等確認ツール

キャッシュ設定

キャッシュ設定は次の九つのタブで構成されます。

キャッシュ設定タブ：[1] キャッシュ

キャッシュ設定の[1] キャッシュタブは、キャッシュについての一般的な設定を行います。

項目1：キャッシュを有効にする

LiteSpeed Cacheプラグインのキャッシュ機能の有効化または無効化を行います。

この項目をオフにすると、他のキャッシュに関する項目がオンになっていてもオフとして扱われます。また、オフにした時点で全てのキャッシュがパージされます。

項目2：ログインしたユーザーをキャッシュ

この項目がオンの場合、プライベートキャッシュが有効になります。

ユーザーごとにWebページの内容が変更されるサイト向けの機能ですが、ユーザー数の増加と共にキャッシュデータのサイズが増えるため、大規模なサイトはこの機能の使用を慎重に検討する必要があります。

項目3：コメントをキャッシュ

コメント投稿でモデレート（承認）待ちになったとき、この項目がオンなら、コメント投稿者にコメント投稿前のキャッシュを配信します。つまり、コメント投稿されていないページが表示されます。

この機能がオフの場合はWordPressの本来の処理がおこなわれ、コメント投稿者に承認待ちであることと投稿したコメントが表示されたページが配信されます。

※コメント投稿者以外は、モデレートされるまでコメントが表示されません。

項目4：REST API をキャッシュ

WordPressのREST APIは、記事内容の取得や投稿、サイトに関する情報の取得をWordPressの管理画面を使用せずにおこなえる仕組みです。カスタマイズにより、公開する情報を増やしたり、制限したりできます。

この項目をオンにすると、REST API呼び出しで生成され、呼び出し元に送り返したデータをキャッシュします。そして以降に同じREST API呼び出しされたら、キャッシュのデータを送り返します。

例えばブログカードはREST APIを利用しますが、不特定多数の閲覧者がページを閲覧する度に必要なデータを収集してデータを返します。REST APIをキャッシュすると、データ収集時間をスキップできるため、生成コストを大幅に減らすことができます。

REST APIのキャッシュ機能は、同じ内容のREST API呼び出しで毎回同じ結果を返すことが前提条件です。例えば現在のPV数を取得するREST APIを自作したときに項目をオンにすると、PV数が刻々と増えていても最初のREST API呼び出し時のPV数を返し続けます。

REST APIが異なる値を返す可能性があるときは、REST APIキャッシュを無効にするか、デフォルトの REST TTLの値を短い値に変更してください。

項目5：ログインページをキャッシュ

WordPressのログイン画面をキャッシュします。

カスタマイズを行っていないログイン画面は毎回同じ内容のため、キャッシュを利用すると効率が上がります。ただしプラグイン等で文字入力認証などの仕組みを導入している場合は、毎回内容が変化するためオフにする必要があります。

また会員サイト等でWordPressのログイン画面をカスタマイズして使用している場合は、注意が必要です。会員名等の個人情報が含まれたログイン画面がキャッシュされ、以降にアクセスした会員に表示される可能性があります。

項目6：PHP リソースをキャッシュ

この機能をオンにすると、一部のPHPリソースをキャッシュします。

PHPはプログラミング言語で、ブラウザから呼び出すとサーバー内部で実行されて結果を返します。一部のテーマやプラグインは、cssやjsなどのデータをPHP呼び出しで取得します。取得した内容は毎回同じものである可能性が高いので、キャッシュすることで効率が上がります。

ただし異なる内容を返す場合は、この機能をオフにする必要があります。

現在のテーマとプラグインは、リソースをcssファイルやjsファイルから直接呼び出すため、あまり影響がないと思われます。

この機能をオンにすると、.htaccessファイルに次の内容が書き込まれます。

### marker CACHE RESOURCE start ###
RewriteRule wp-content/.*/[^/]*(responsive|css|js|dynamic|loader|fonts)\.php - [E=cache-control:max-age=3600]
### marker CACHE RESOURCE end ###

wp-content/から.phpまでは正規表現と呼ばれるもので、URLのドメインより後ろが一致するかどうかチェックされます。

これによりwp-contentフォルダ内のいずれかの階層の、responsive.php、css.php、js.php、dynamic.php、loader.php、fonts.phpで終わるファイルが一致します。

最後の[E=cache-control:max-age=3600]は、LiteSpeedサーバーに3600秒間キャッシュするように指示しています。

項目7：モバイルをキャッシュ

モバイルからのアクセスを、他の端末からのアクセスとは別にキャッシュします。同じURLでPC向けとモバイル向けのサイトを提供しているときなどにオンにします。

またモバイル端末でWebページの表示が乱れるときはこの項目の設定を変更して、改善するか確認してください。

この機能をオンにすると、.htaccessファイルに次の内容が書き込まれます。

### marker MOBILE start ###
RewriteCond %{HTTP_USER_AGENT} Mobile|Android|Silk/|Kindle|BlackBerry|Opera\ Mini|Opera\ Mobi [NC]
RewriteRule .* - [E=Cache-Control:vary=%{ENV:LSCACHE_VARY_VALUE}+ismobile]
### marker MOBILE end ###

上記の内容の一部は、項目8：モバイルユーザエージェントのリストで入力した内容が反映されます。

項目8：モバイルユーザエージェントのリスト

項目7：モバイルをキャッシュがオンのとき、モバイルとして扱う端末のユーザーエージェントに含まれる文字を指定します。

項目9：プライベートキャッシュ URIs

通常ならパブリックキャッシュされる場合でも、プライベートキャッシュさせるURLを指定します。

通常は全ての閲覧者に同じページを提供して、特定のページのみユーザーごとに異なる内容を提供する場合などに、そのページのドメインより後のURLを入力します。

入力した値がURLに含まれているとき有効です。

例えば『/a/b/』と入力した場合、次のようなＵＲＬが対象となります。

• https://ドメイン/a/b/
• https://ドメイン/c/a/b/
• https://ドメイン/a/b/c/

また特殊な文字として『^』（先頭）と『$』（末尾）を使用できます。

例えば『^/a/b/』と入力した場合、『https://ドメイン/a/b/』『https://ドメイン/a/b/c/』に一致しますが『https://ドメイン/c/a/b/』は一致しません。

• 〇：https://ドメイン/a/b/
• ✖：https://ドメイン/c/a/b/
• 〇：https://ドメイン/a/b/c/

『/a/b/$』と入力した場合、『https://ドメイン/a/b/』『https://ドメイン/c/a/b/』に一致しますが『https://ドメイン/a/b/c/』は一致しません。

• 〇：https://ドメイン/a/b/
• 〇：https://ドメイン/c/a/b/
• ✖：https://ドメイン/a/b/c/

『^/a/b/$』と入力した場合、『https://ドメイン/a/b/』に一致しますが『https://ドメイン/a/b/c/』『https://ドメイン/c/a/b』は一致しません。

• 〇：https://ドメイン/a/b/
• ✖：https://ドメイン/c/a/b/
• ✖：https://ドメイン/a/b/c/

項目10：URIs を強制キャッシュする

ここに入力されたページは、他の設定項目によりキャッシュから除外される場合でも強制的にキャッシュします。

入力値は項目9：プライベートキャッシュ URIsと同じです。

またURLの後にスペースと数値を入力できます。

例：『/a/b/ 300』

これによりTTL（キャッシュの有効期限）を秒数で指定できます。

項目11：パブリックキャッシュ URI を強制する

ここに入力されたページは、他の設定項目によりキャッシュから除外される場合でも強制的にパブリックキャッシュします。

入力値は項目9：プライベートキャッシュ URIsと同じです。

またURLの後にスペースと数値を入力できます。

例：『/a/b/ 300』

これによりTTL（キャッシュの有効期限）を秒数で指定できます。

項目12：クエリ文字列を落とす

クエリ文字列とは、URLの『?』から最後までの文字です。

WordPressのプレビューなどで目にします。

https://kc-mixh.com/?p=7777&preview=true

上の例は『p』と『preview』というクエリ文字が使用されていて、それぞれ『7777』と『true』という値が指定されています。

サイトによっては、クエリ文字列を解析してページの内容を変更するものがあります。このようなケースならクエリ文字列毎にキャッシュを行うことは理にかなっています。

しかしGoogleアナリティクスが追加する『_ga』や『utm』など意図していないクエリが紛れ込むことがあります。このようなケースではクエリ文字列を落とす（削除する）ことで、ムダなキャッシュを防ぐことができます。

なお『utm』は『utm_source』『utm_medium』『utm_campaign』など様々な種類があります。このようなケースでは『utm*』と『*』を使うことで、頭文字が一致したものを落とすことができます。

キャッシュ設定タブ：[2] TTL

キャッシュ設定の[2] TTLタブは、キャッシュのTTLを設定します。

TTLとはTime to Liveの略称で直訳すると『生きる時間』です。TTLはIT分野の様々な場面で使用され、特定のデータの有効期限や、特定処理の繰り返し回数を表す値として使用されます。

LiteSpeed CacheプラグインでのTTLは、キャッシュの有効期間として使用されます。

具体的には、LiteSpeedサーバーはブラウザ等からWebデータ要求を受け付けると、キャッシュのTTLを確認して有効期間内ならキャッシュを返します。有効期間を過ぎていたらデータを再生成後にキャッシュして返します。このときTTLも再設定されます。

TTL期間内にキャッシュの内容を更新するときは、パージ機能を使用してキャッシュを削除する必要があります。

項目1：デフォルトのパブリックキャッシュ TTL

パブリックキャッシュされたデータのTTLを指定します。値は秒単位で、30より大きい数値を指定します。

ESI等でTTLを指定した場合、そちららの設定が優先されます。

項目2：デフォルトのプライベートキャッシュ TTL

プライベートキャッシュされたデータのTTLを指定します。値は秒単位で、30より大きい数値を指定します。

ESI等でTTLを指定した場合、そちららの設定が優先されます。

項目3：デフォルトのフロントページ TTL

WordPressのフロントページ、一般的にはトップページのキャッシュTTLを指定します。値は秒単位で、30より大きい数値を指定します。

記事ページの内容が変更されることが少ないが、トップページは頻繁に変更されるときなどに使用します。

項目4：デフォルトのフィード TTL

フィードのキャッシュTTLを指定します。値は秒単位で、30より大きい数値を指定します。

フィードとはサイトの更新情報やページ一覧などをまとめたデータです。WordPressは自動でフィードを生成します。

フィードも記事ページと同じようにアクセスされるたびに生成されるため、キャッシュを使用することで効率をアップできます。

項目5：デフォルトの REST TTL

REST APIのキャッシュTTLを指定します。値は秒単位で、30より大きい数値を指定します。

この項目はREST API をキャッシュでオンを選択したとき、使用されます。

項目6：既定の HTTP ステータスコードページ TTL

404(ページが存在しない)等のステータスコードを返したとき、そのページの内容をキャッシュするTTLを指定します。

炎上したページを削除すると404エラーを返します。その後もアクセスが集中することが予想されるときは、TTLを増やすことでサーバーの負担を減らすことができます。

403、404、500エラーのキャッシュは、個別に削除（パージ）できます。

キャッシュ設定タブ：[3] パージ

キャッシュ設定の[3] パージタブは、パージに関する設定をおこないます。

パージとは、キャッシュデータを削除して、新規でキャッシュできる状態にすることを指します。

項目1：アップグレード時にすべてをパージする

WordPress、テーマ、プラグインが更新されたとき、全てのキャッシュをパージするかどうか設定します。

テーマが変更されるとWebページの外観が全く異なものになるため、これまでのキャッシュを使用できません。WordPressまたはプラグインの更新で外観が変わることはあまりありませんが、可能性があるためオン推奨です。

項目2：公開 / 更新の自動パージルール

投稿が更新されるのと連動して、キャッシュをパージするページを選択します。

画像内のメモは、投稿を変更したことでウィジットの内容が変化し、それが全てのページに影響する場合に『すべてのページ』をチェックする、という意味です。

これ以外のケースではキパージ処理の効率が悪くなるため、『すべてのページ』は選択するべきではありません。

また年別や月別アーカイブなど、Webサイトで使用していないページも効率に影響するため、チェックから外しておくことをおススメします。

項目3：古いものを出す

閲覧者がキャッシュが削除されたページにアクセスしたとき、削除した古いキャッシュを閲覧者に送信します。

このとき新しいキャッシュが生成されますが、閲覧者は古いコンテンツのままです。次回アクセス時に、新しいコンテンツを閲覧できます。

この項目は、キャッシュ作成処理中に同じページへのアクセスが集中するケースで使用します。このケースではキャッシュ生成中に、同じページのキャッシュ生成処理が行われるため、サーバーに大きな負荷を与えるためです。

一般的なサイトでも、同時にアクセスされる可能性があります。しかし数人程度なら、それほどサーバー負荷になりません。それよりも、古いコンテンツが表示されている可能性があることが問題となります。

そのため基本的にはオフにしておいた方が良いでしょう。

項目4：スケジュールされたパージURL

パージ予定時間で指定した時間にパージを行うページのURLを指定します。

集計結果など、内容が毎日更新されるWebページはデフォルトのパブリックキャッシュ TTLとは異なるタイミングでパージする必要があります。この項目を使用することで、毎日決まった時刻にパージできるようになります。

URLは『httpから』、またはドメインより『後ろから』の二つの方法で記述できます。ただし完全に一致する必要があります。

https://ドメイン/a/b/c/のとき

〇：https://ドメイン/a/b/c/
〇：/a/b/c/
✖：https://ドメイン/a/b/
✖：/a/b/

また前後に『*』（ワイルドカード）を使用できます。

https://ドメイン/a/b/cのとき

〇：*/b/c/
〇：/a/b/*
〇：*/b/*

なおワイルドカード指定したURLと一致するWebページは、TTL経過後または手動によるパージ後に、スケジュールによるパージが可能になります。本項目指定後に、パージ対象指定によるパージ機能で対象URLをパージしてください。

項目5：パージ予定時間

スケジュールされたパージURLで指定したWebページをパージする時間（時分）を指定します。

スケジュールによるパージを行わない場合は、空欄（–:–）にします。入力されている数値BackまたはDeleteキーで削除できます。

項目6：すべてをパージするフック

指定されたWordPressアクションフックに、全てのキャッシュをパージする処理を登録します。これにより、カテゴリが作成されたなどのタイミングでキャッシュをパージできるようになります。

キャッシュ設定タブ：[4] 除外

キャッシュ設定の[4] 除外タブは、キャッシュ対象から除外するWebページを設定します。

項目1：URIs をキャッシュしない

キャッシュ対象から、指定されたURLを除外します。

入力値は[1] キャッシュの項目9：プライベートキャッシュ URIsと同じです。

項目2：クエリ文字列をキャッシュしない

URLに特定のクエリ文字列が含まれているとき、そのページをキャッシュしません。

クエリ文字列とは、URLの『?』から最後までの文字です。

例えば、次のようなURLです。

https://ドメイン/page1/?test=true

上の例は『test』というクエリ文字を使用すると、テストバージョンを表示するように作りこまれたページだと仮定します。

テストバージョンはキャッシュされると、次回以降はキャッシュから提供されてしまうため、変更内容を確認できない可能性があります。そこで、本項目に『test』と入力することで、キャッシュを防ぎます。このときクエリ値の『true』は考慮されません。『false』『123』や未指定でも、除外されます。

なお同じページでもクエリが異なれば、異なるページとしてキャッシュされます。

項目3：カテゴリをキャッシュしない

指定されたカテゴリーページをキャッシュしません。ここではカテゴリーのスラッグを入力します。

カテゴリーのスラッグはカテゴリーページのURLで確認できますが、WordPress管理画面の『投稿』メニュー内の『カテゴリー画面』でも確認できます。

入力したカテゴリーのスラッグが存在しない場合、変更保存時にリストから削除されます。

項目4：タグをキャッシュしない

指定されたタグページをキャッシュしません。ここではタグのスラッグを入力します。

タグのスラッグはタグページのURLで確認できますが、WordPress管理画面の『投稿』メニュー内の『タグ画面』でも確認できます。

入力したタグのスラッグが存在しない場合、変更保存時にリストから削除されます。

項目5：クッキー をキャッシュしない

Cookie（クッキー）に入力された文字列が含まれている場合、そのページをキャッシュしません。Cookie（クッキー）は、ブラウザから送信されてくるヘッダーデータ内に含まれる文字列で、WordPressならログイン情報などが記述されています。

項目に値を入力すると、.htaccessの内容が変更されます。例えば『test』と『color=red』の二行を入力すると、次のように記述されます。

### marker NOCACHE COOKIES start ###
RewriteCond %{HTTP_COOKIE} test|color\=red
RewriteRule .* - [E=Cache-Control:no-cache]
### marker NOCACHE COOKIES end ###

このコードにより、該当するWebページのキャッシュが除外されます。

項目6：ユーザーエージェントをキャッシュしない

ユーザーエージェントに入力された文字列が含まれている場合、そのページをキャッシュしません。ユーザーエージェントは、ブラウザから送信されてくるヘッダーデータ内に含まれる文字列で、ブラウザの種類などが記述されています。

項目に値を入力すると、.htaccessの内容が変更されます。例えば『Win64』と入力すると、次のように記述されます。

### marker NOCACHE USER AGENTS start ###
RewriteCond %{HTTP_USER_AGENT} Win64 [NC]
RewriteRule .* - [E=Cache-Control:no-cache]
### marker NOCACHE USER AGENTS end ###

このコードにより、該当するWebページのキャッシュが除外されます。

項目7：ロールをキャッシュしない

この項目はWordPressにログインしたユーザーが対象です。ログインユーザーのロール（権限）がチェックされている場合、そのユーザーが閲覧したページの内容がキャッシュされません。

ここでは英語でロールが記載されていますが、日本語版のWordPressのプロフィールでは次のように記載されています。

administrator：管理者
author：投稿者
contributor：寄稿者
editor：編集者
subscriber：購読者

キャッシュ設定タブ：[5] ESI

キャッシュ設定の[5] ESIタブは、ESIについての設定をおこないます。
※ESIキャッシュを参照してください。

項目1：ESIを有効にする

ESI機能の有効化または無効化をおこないます。

ESI機能を有効にすると、次のWordPress機能がESI化されます。

• 管理バー
• コメント
• コメントフォーム
• 最近の投稿ウィジェット
• 最近のコメントウィジェット

項目2：管理バーをキャッシュ

ESIを有効にするがオンのとき管理バーがESI化されます。この項目はESI化された管理バーをキャッシュするかどうかを指定します。

管理バーはログイン時に上部に表示される黒いバーです。管理バーの表示対象者が一人、または数人の場合はオンにする必要がありません。

項目3：コメントフォームをキャッシュ

ESIを有効にするがオンのときコメントフォームがESI化されます。この項目はESI化されたコメントフォームをキャッシュするかどうかを指定します。

項目4：ESI ノンス

この項目に入力された文字列に一致するノンス（nonce）をESI化します。

ノンスとはWordPressが生成するセキュリティートークンです。

Webページに設置された入力欄に入力されたデータをサーバーが受け取りとき、それが不正な方法で作成されたものでないことを確認する必要があります。WordPressはノンスと呼ばれるセキュリティートークンをWebページに埋め込みます。ブラウザはノンスとデータをサーバーに返すことで、正規のデータであることを確認します。

通常はノンスが含まれたページごとキャッシュされます。しかし、ノンスは有効期限があるため、キャッシュ内のノンスが無効になる可能性があります。

そこでノンスをESI化してページのキャッシュから切り離すことで、ノンスを有効にします。

この項目を使用してもノンスが上手く動作しないときや、ノンス名がわからないときは、[4] 除外タブのURIs をキャッシュしないでページをキャッシュ対象から除外することをおススメします。

項目5：グループを変更

※この機能はESIとは関係ありません。

同じページの内容をユーザー権限（ロール）毎に変更する、例えばWebページに管理者のみ管理ボタンを設置するなど、ケースがあります。さらに他のロールにも、特殊な細工を組みこむことがあります。

このようなケースではロール単位でキャッシュされますが、残りのロールが同じ内容のときにそれぞれをキャッシュするのは効率が悪いです。

そこでグループ分けを行い、同じグループは一つのキャッシュを共有します。

入力欄には数値を入力しますが、同じ数値は同じグループを表します。数値そのものに意味はないので好きな数字を入力できます。

キャッシュ設定タブ：[6] オブジェクト

キャッシュ設定の[6] オブジェクトタブは、オブジェクトキャッシュについての設定をおこないます。

永続オブジェクトキャッシュは、分単位程度の比較的短い時間にデータベース上の同じデータが頻繁に参照されるケースで、サーバーの負荷軽減とページの読み込み速度を向上させることができる仕組みです。

項目1：オブジェクトキャッシュ

オブジェクトキャッシュ機能の有効化と無効化の切り替えを行います。

この機能をオンにすることで、WordPressのサイトヘルス画面に表示される、『永続オブジェクトキャッシュを使用してください』を消すことができます。

ただし、実際にオブジェクトキャッシュを利用するには『Memcached』または『Redis』という外部ツールが必要です。

参考）オブジェクトキャッシュサポートの設定方法（英語）：https://docs.litespeedtech.com/lscache/lscwp/admin/#how-to-set-up-object-cache-support

これらの機能が適切にインストールされていない場合、サイトヘルス画面から『永続オブジェクトキャッシュを使用してください』が消えていても、オブジェクトキャッシュは無効です。適切にインストールされていない場合は、オフ/オンの下方にあるステータス欄の接続テストに『利用できません』と表示されます。

次のリンク先ページで解説していますが、オブジェクトキャッシュはWebサイトごとに適切な設定を行う必要があることと、サーバーに大きな負担を与えること、多くのサイトは他のキャッシュ機能で十分な効果が得られることから、レンタルサーバーの多くは外部ツールをインストールしていません。

項目2：方法

オブジェクトキャッシュとして使用する外部ツールを、『Memcached』または『Redis』から選択します。

項目3：ホスト

外部ツールのホスト名またはIPアドレスまたはソケット名を指定します。

項目4：ポート

外部ツールの接続ポートを指定します。Memcachedのデフォルトポートは11211、Redisのデフォルトポートは6379ですが、他のポートに変更している場合は、そのポート番号を指定します。

またソケット接続している場合は、0を指定します。

項目5：デフォルトのオブジェクトの有効期間

オブジェクトとしてキャッシュしたデータのTTL（有効期限）を秒で指定します。デフォルトとして360秒（6分）という値が入力されているように、短い時間を指定することが推奨されています。

項目6：ユーザー名

SASL（インターネットプロトコルに認証機能を追加する仕組み）がインストールされていて外部ツールの利用にユーザー名が必要な時に使用する文字列を指定します。Memcachedで有効です。

項目7：パスワード

接続時に使用するパスワードを指定します。

項目8：Redis データベース ID

外部ツールとしてRedisを使用しているとき、使用するデータベースのIDを指定します。

項目9：グローバルグループ

オブジェクトキャッシュ対象となるWordPress上のグローバルキャッシュグループを指定する。

グローバルキャッシュグループ名の明確な情報がないため、WordPressのソースコードから該当すると思われる部分を抜き出しました。

# wp-includes/ms-blogs.phpより
#
wp_cache_add_global_groups(
    array(
        'blog-details',
        'blog-id-cache',
        'blog-lookup',
        'blog_meta',
        'global-posts',
        'networks',
        'network-queries',
        'sites',
        'site-details',
        'site-options',
        'site-queries',
        'site-transient',
        'theme_files',
        'rss',
        'users',
        'user-queries',
        'user_meta',
        'useremail',
        'userlogins',
        'userslugs',
    )
);

項目10：グループをキャッシュしない

オブジェクトキャッシュ対象外とするキャッシュグループを指定する。

デフォルト値の『wc_session_id』は、WooCommerceプラグイン（ECサイト構築プラグイン）のカートに関するキャッシュグループです。これにより、WooCommerceを使用したECサイトでカート内の商品が表示されないなどの問題が解決されます。

その他のグループは資料がないため、WordPressのソースコードからキャッシュグループ名を抜き出しました。

# wp_cache_set()の第三引数および
# wp_cache_set_last_changed()の第一引数より
#
'blog-details'
'blog-id-cache'
'blog-lookup'
'bookmark'
'calendar'
'comment'
'counts'
'customize_changeset_post'
'networks'
'oembed_cache_post'
'options'
'plugins'
'post-queries'
'posts'
'term-queries'
'terms'
'theme_json'
'timeinfo'
'transient'
'translation_files'
'users'
'widget'
"{$taxonomy}_relationships"

項目11：永続的な接続

キープアライブ接続とはサーバーとクライアントで定期的に通信を行うことで、両者が動作していることを確認し、接続を維持する仕組みです。

ここではMemcachedとの接続を維持することで、パフォーマンスを向上させます。

ここでオフを選択した場合は、php.ini設定の『memcached.sess_persistent』がfalse、オンの場合は、trueである必要があります。値が異なる場合、Memcachedとの接続に失敗する可能性があります。

項目12：WP-Admin のキャッシュ

WordPressの管理画面表示で使用されるデータをオブジェクトキャッシュの対象にします。これにより管理画面の表示が高速化されます。

この機能をオンにすると、管理画面で変更しても表示が変わらない可能性があります。実際には変更されているため、内容の不整合がおこります。

一般的に管理画面はサイト運営に関わりのある人物がアクセスするため、多少遅くてもサイトの評価が悪くなることはありません。この機能をオンにして得られる利点よりも、デメリットの方が多いです。

項目13：Transients を格納

この項目は、WP-Admin のキャッシュがオフのとき『○○○が完了しました』等のサーバーステータス通知を受け取ることができない問題を解消するために追加されました。

この機能をオンにすることで通知を受け取れるようになります。

キャッシュ設定タブ：[7] ブラウザー

キャッシュ設定の[7] ブラウザータブは、ブラウザ側のキャッシュ機能をコントロールします。

項目1：ブラウザキャッシュ

※この項目をオンにした場合、ブラウザキャッシュ TTLの値を変更することをおススメします。

この項目をオンにすると、次のように、.htaccessファイルにブラウザキャッシュに関する設定が追加されます。

### marker BROWSER CACHE start ###
<IfModule mod_expires.c>
ExpiresActive on
ExpiresByType application/pdf A31557600
ExpiresByType image/x-icon A31557600
ExpiresByType image/vnd.microsoft.icon A31557600
ExpiresByType image/svg+xml A31557600

ExpiresByType image/jpg A31557600
ExpiresByType image/jpeg A31557600
ExpiresByType image/png A31557600
ExpiresByType image/gif A31557600
ExpiresByType image/webp A31557600

ExpiresByType video/ogg A31557600
ExpiresByType audio/ogg A31557600
ExpiresByType video/mp4 A31557600
ExpiresByType video/webm A31557600

ExpiresByType text/css A31557600
ExpiresByType text/javascript A31557600
ExpiresByType application/javascript A31557600
ExpiresByType application/x-javascript A31557600

ExpiresByType application/x-font-ttf A31557600
ExpiresByType application/x-font-woff A31557600
ExpiresByType application/font-woff A31557600
ExpiresByType application/font-woff2 A31557600
ExpiresByType application/vnd.ms-fontobject A31557600
ExpiresByType font/ttf A31557600
ExpiresByType font/otf A31557600
ExpiresByType font/woff A31557600
ExpiresByType font/woff2 A31557600

</IfModule>
### marker BROWSER CACHE end ###

ブラウザキャッシュとは、画像やスクリプトファイル等をブラウザ内で保管（キャッシュ）しておき、同じデータが必要となったときにキャッシュから取り出す仕組みです。これにより、サーバーから同じデータを重複して呼び出すムダが省けます。

特にスクリプト（JavaScript）やcssファイルは複数のページで使用されることが多いため、ブラウザキャッシュはWebページの高速化に欠かせません。

書き込まれる内容は、ブラウザキャッシュ TTLを除いて、固定です。

実際にはLiteSpeedサーバーの管理者が内容を変更できます。レンタルサーバーなら、サーバーを管理している事業者です。

項目2：ブラウザキャッシュ TTL

ブラウザキャッシュの有効期限を秒数で入力します。ここで入力した値は、.htaccessファイルに書き込まれます。

規定値は31557600秒です。これは約一年に相当します。

この値は少し長いかもしれません。例えば画像の内容を変更しても、それ以前にブラウザキャッシュされていたら、変更後の画像を読み込みません。読み込むのはブラウザキャッシュTTLの秒数が経過した後なので、最長で一年後です。現実的ではありませんね。

GoogleはブラウザキャッシュTTLについて、次のように推奨しています。

頻繁に画像やスクリプトを変更するサイトは一週間でも長いかもしれません。そのようなサイトは１日から3日程度で指定するとよいでしょう。

キャッシュ設定タブ：[8] 高度な設定

キャッシュ設定の[8] 高度な設定タブは、キャッシュに関する高度な設定をおこないます。

項目1：AJAXキャッシュTTL

admin-ajax.phpによるAjax呼び出しで、キャッシュを行うアクションとTTLを設定します。

一行に一つのアクションを指定します。各行はアクション名と秒数をスペースで区切って入力します。

項目2：ログインクッキー

この機能は、サブディレクトリ等を利用して、一つのドメインにLiteSpeed Cacheをインストールした複数のWordPressが稼働しているケースで使用します。

このようなケースではログイン情報が競合するため、異なるサイトのキャッシュを操作する可能性があります。そこで、WordPressログイン情報、ここではログインに関するクッキーを各サイトで被らないように変更します。

変更は、入力欄に入力するだけです。入力するクッキー名は使用されていないもの（使用されているクッキーを確認する必要あり）で、他サイトと被らない任意の文字列を使用できます。

この項目は、.htaccessファイルを変更します。例えば、_my_blog_login_vary と入力すると、次のような内容が .htaccessファイルに追加されます。

### marker LOGIN COOKIE start ###
RewriteRule .? - [E="Cache-Vary:_my_blog_login_vary"]
### marker LOGIN COOKIE end ###

項目3：クッキーを変更する

この機能は、プラグイン等でクッキーの値でページの表示内容を変更しているケースで使用します。

入力欄に入力した文字列と同じクッキーがない場合、そのページはキャッシュされます。クッキーがある場合は、クッキーの値毎にページがキャッシュされます。

この項目は、.htaccessファイルを変更します。例えば、_my_count と入力すると、次のような内容が .htaccessファイルに追加されます。

### marker LOGIN COOKIE start ###
RewriteRule .? - [E="Cache-Vary:_my_count"]
### marker LOGIN COOKIE end ###

項目4：HTTP / HTTPS の互換性を向上させる

この機能はWordPressにログインしたユーザーが、 http:// と https:// の両方を使用するケースで有効です。

https://　でログインすると、ログイン情報を含んだクッキーはHTTPSで保存されます。これはhttp:// では読み取れないため、https:// でログイン後に http:// でページを表示すると、ログインしていない状態として扱われます。

この機能をオンにすると、ログインクッキーをHTTPで保存します。その結果、https:// と http:// の両方で読み込むことが可能になります。

項目5：インスタントクリック

Webページ上のリンクにマウスを置いたとき、リンク先の内容を先読みするスクリプトをページ内に挿入します。リンククリック前にページ読み込みが始まるため、クリック後の待ち時間を短縮できます。

この機能は、閲覧者がクリックするつもりがないページも読み込みます。そのためリンクが多いサイトは、バックで複数ページを読み込む可能性があり、閲覧者に重いサイトという印象を与える可能性があります。

またPV数を集計するサイトは、この機能により閲覧者が実際に閲覧していないページがカウントアップされる可能性があります。

キャッシュ設定タブ：WooCommerce設定

キャッシュ設定のWooCommerce設定タブは、WooCommerceに関するキャッシュ設定を行います。

※このタブはWooCommerceプラグインがインストールされているときのみ表示されます。
※WooCommerce使用時は、ESI機能の有効化が推奨されています。

項目1：製品更新間隔

商品ページおよびカテゴリページのキャッシュを削除（パージ）するタイミングを選択します。

商品ページまたはカテゴリページに、在庫数や『在庫切れ』等の在庫状況を表示している場合、商品が売れたタイミングでページの表示内容を更新する必要があります。しかしページがキャッシュされていると、表示内容を更新できません。そこで、商品の在庫数または在庫状況が変動したタイミングでキャッシュを削除することで、ページの表示内容を変更できるようにします。

この項目の四つの選択肢は、商品ページとカテゴリページに数量と在庫状況をどのような組み合わせで表示しているかを考慮して選択します。

例えば、商品ページとカテゴリページの両方で数量と在庫状況を表示している場合、上から四つ目の『数量または在庫状況の変更で、製品とカテゴリの両方をパージします。』を選択します。

選択肢を表にまとめると、次のようになります。

項目2：ミニカートによって異なります

この機能はWooCommerceのミニカートの内容が更新されない時に使用します。

通常は商品ページは、ミニカートの内容も含めてキャッシュされます。そのため、再表示時はキャッシュの内容が表示されます。カートの内容に変更があっても、表示上では反映されません。ですがブラウザにキャッシュの内容を表示した後に、AJAX機能を使用してブラウザから動的にカートの内容を取得しています。つまり、古いカートの内容がキャッシュされても、後から上書きされるため問題ありません。

しかしテーマによっては、AJAX機能が上手く動作しないものがあります。そのようなケースでもミニカートの内容が更新されるように、キャッシュ設定の[8] 高度な設定タブのクッキーを変更するの仕組みを利用して、カートの内容ごとにページをキャッシュします。

この機能をオンにすると、.htaccessファイルに次の内容が追加されます。

### marker LOGIN COOKIE start ###
RewriteRule .? - [E="Cache-Vary:woocommerce_cart_hash"]
### marker LOGIN COOKIE end ###

woocommerce_cart_hashは、カートの内容を元に生成されるハッシュ値です。カートの内容が異なると、ハッシュ値も異なります。その結果カートの内容ごとにキャッシュデータが生成されることになり、ディスク容量を圧迫する可能性があります。

ミニカートの内容が更新されないときは、この機能に頼るよりも、AJAX機能が正常に動作するように原因を調査することをおススメします。

CDN設定

CDN設定は次の三つのタブで構成されます。

CDN設定タブ：[1] CDN 設定

CDN設定の[1] CDN 設定タブは、CDNに関する設定を行います。QUIC.cloud CDNを利用する場合は、先に[2] QUIC.cloud CDN の設定で自動設定を行ってください。

項目1：QUIC.cloud CDN

LiteSpeed CacheとQUIC.cloud CDNの連携機能の有効化または無効化をおこないます。これによりLiteSpeed Cacheで設定したキャッシュ設定がQUIC.cloud CDNに通知されます。またツールボックス設定からのパージや記事投稿等による自動パージについても、QUIC.cloud CDNに通知されます。

※この機能オフにしても、QUIC.cloud CDNは無効になりません。

項目2：CDN マッピングを使用

Webサイトの画像などのリソースをCDN経由で公開する場合にオンにします。

これはWebサイトのCDN化に関する設定ではなく、一部のリソースをCDNに移動したケースを想定した機能です。

実際には以降のCDN URL、置換する HTML 属性、元の URL、含まれるディレクトリ、除外パスで設定された値を元に、imgタグのsrc属性等のURLを置き換えるだけです。置き換え先のリソースが存在しているかどうかは考慮されません。またCDNである必要もありません。

置き換えは、次のように行われます。

置換前：https:[元の URL]/xxx/[含まれるディレクトリ]/xxx/xxx.[CDN URLのファイルの種類]
↓
置換後：https:[CDN URL]/xxx/[含まれるディレクトリ]/xxx/xxx.[CDN URLのファイルの種類]

項目3：CDN URL

置き換え後のドメインと、置き換え対象ファイルの拡張子を指定します。

置き換え後のドメインは『CDN URL』に httpまたは httpsから入力します。入力されていない場合、設定保存時にCDN マッピングを使用がオフに変更されます。またドメイン以降のディレクトリを指定できます。

『CDN URL』の入力例
https://cdn.kc-mixh.com/
https://cdn.kc-mixh.com/image/

拡張子指定は『画像を含める』『CSS を含める』『JS 含める』でオン/オフができますが、『ファイルの種類を含める』が優先されます。そのため、例えば『CSS を含める』をオフにしても『ファイルの種類を含める』に.cssが入力されていたらcssファイルが置き換え対象になります。

拡張子ごとに異なる設定を行うときは、『⊕ 新しい CDN URL を追加する』で入力欄を増やすことができます。

項目4：置換する HTML 属性

置換する HTML 属性は、置き換え対象となるhtmlタグと属性を入力します。

属性のみ指定するときは、属性の前に『.』（ドット）を指定します。例えば『.src』と入力すると、imgタグだけでなく、次のようなタグのsrc属性も置き前ます。

<mytag src="https://kc-mixh.xyz/wp-content/image.jpg"></mytag>

タグを限定するときは、『.』（ドット）の前にタグ名を入力します。『img.src』と入力するとimgタグのsrc属性に限定できます。

項目5：元の URL

元の URLは、置き換え対象のURLを『//』から入力します。現在使用しているURLでなくても、指定可能です。

また、深い階層までURL指定することで、特定のディレクトリ以降のディレクトリ内のファイルに限定できます。

例）元のURL：//kc-mixh.xyz/wp-content/abcdef/
https://kc-mixh.xyz/wp-content/abcdef/image.jpg
https://kc-mixh.xyz/wp-content/abcdef/js/script.js
等を置き換え

置き換え後は、先頭から元のURL部分までがCDN URLに変更されます。

項目6：含まれるディレクトリ

URLが元の URLから始まり、『含まれるディレクトリ』で指定した値がURLにディレクトリとして含まれている（『/』と『/』で囲まれている）とき、置き換え対象となります。

元のURL：//kc-mixh.xyz/
含まれるディレクトリ：abc

〇 https://kc-mixh.xyz/abc/image.jpg
〇 https://kc-mixh.xyz/xxx/abc/xxx/image.jpg
✖ https://kc-mixh.xyz/abcdef/image.jpg
✖ https://kc-mixh.xyz/image.jpg

項目7：除外パス

『除外パス』で指定した文字がURLに含まれている場合、置き換え対象から除外されます。

元のURL：//kc-mixh.xyz/
含まれるディレクトリ：abc
除外パス：script

〇 https://kc-mixh.xyz/abc/image.jpg
✖ https://kc-mixh.xyz/abc/script/my.js
✖ https://kc-mixh.xyz/abc/css_script/style.css
✖ https://kc-mixh.xyz/abc/js/script.js

ファイル名と拡張子も判定対象です。

項目8：Cloudflare API

Cloudflare API機能がオンのとき、CloudflareとLiteSpeed Cacheを関連付け、[3] 管理タブのCloudflareで、Cloudflareのキャッシュパージを可能にします。詳しくは、次のページを参照してください。

CDN設定タブ：[2] QUIC.cloud CDN の設定

CDN設定の[2] QUIC.cloud CDN の設定タブは、QUIC.cloud CDNの自動設定および設定状況の確認を行います。

QUIC.cloud CDNの詳しい設定方法は、次のページを参照してください。

項目1：QUIC.cloud CDN の自動設定

この項目は、QUIC.cloud CDNを自動設定で行われる手順が記載されています。実際に作業を行わないと、理解するのは難しいです。

項目2：QUIC.cloud のアカウント設定

QUIC.cloud CDN自動設定を開始します。QUIC.cloud のアカウント設定は最初のステップです。

手順が進むと、表示されている内容が変化します。

項目3：CDN 設定状況

QUIC.cloud CDN自動設定の進行状況表示と、次ステップへの移行ボタンが表示されます。指示に従って作業を進めてください。

項目4：ネームサーバー

QUIC.cloud CDN自動設定が進むと、QUIC.cloudが用意したネームサーバー名が表示されます。サイトのドメインのネームサーバーを、ここに表示された名前に変更してください。

この項目は、自動設定が完了すると非表示になります。

項目5：操作

この項目は、自動設定開始後に表示されます。

二つのボタンが用意されています。

• 『CDN設定をリセットする』ボタン
  
  LiteSpeed Cache上の自動設定進捗情報をリセットします。ただしドメインキーはリセットされません。
  
• 『QUIC.cloud のデータを削除する』ボタン
  
  LiteSpeed Cache上の自動設定進捗情報と、自動設定で行ったQUIC.cloud上の設定をリセットします。ただしドメインキーとQUIC.cloud のアカウントはリセットされません。

CDN設定タブ：[3] 管理

項目1：QUIC.cloud

QUIC.cloud欄は、QUIC.cloudとLiteSpped Cacheがリンク済みのとき、QUIC.cloudの管理ページへのリンクが表示されます。

項目2：Cloudflare

Cloudflare欄は、[1] CDN 設定タブのCloudflare APIが設定済みのとき、Cloudflareキャッシュの『すべてパージする』ボタンが有効になります。

開発モードはCloudflareを一時的に無効にして、Webサイトのサーバーに直接アクセスする機能です。Webページを変更したときなどにCloudflareキャッシュが参照されると、古い内容が表示されることがあります。開発モードをオンにすることで、最新の内容を確認することができます。ただし、LiteSpeed Cacheが古い内容をキャッシュしている可能性があるので、注意しましょう。

画像の最適化設定

画像の最適化設定は、主に画像ファイルの配信速度を向上させることを目的として、ファイルサイズを縮小します。

LiteSpeed Cacheの画像最適化はQUIC.cloudサーバーで行います。そのため、QUIC.cloudサーバーからドメインキーを取得する必要があります。詳しくは次のページを確認してください。

画像の最適化設定は、次の二つのタブで構成されています。

画像の最適化設定タブ：[1] 画像最適化の概要

項目1：QUIC.cloud サーバーで画像を最適化する

QUIC.cloud サーバーで画像を最適化するの『最適化要求を送信』をクリックすると、画像の最適化を行うためにQUIC.cloud サーバーに画像ファイルを送信します。また『画像を引き戻す』をクリックすると、QUIC.cloud サーバーで最適化済みの画像をWebサイト側に戻します。

この機能は[2] 画像最適化設定タブのオリジナル画像の最適化がオンのとき有効です。オフのとき『最適化要求を送信』をクリックしても最適化されません。

初回は1グループ（各サイズのサムネイルを一組とした画像グループ）のみ最適化要求できます。何度か繰り返すと、要求できる画像数が増えます。ただし一日に要求可能なグループ数に上限があります。画像数が多いときは、数日待つか、QUIC.cloudアカウントとリンクして有料枠を購入する必要があります。

この機能は[2] 画像最適化設定の自動要求 Cronと自動戻し Cronをオンにすることで、自動化できます。

項目2：最適化ステータス

最適化ステータスは、現在の画像最適化要求状況等が表示されます。

『完了していないデータのクリーンアップ』を押すと、要求中の画像がリセットされます。数日経っても完了しないときは、このボタンを押してください。

項目3：ストレージの最適化

ストレージの最適化の『バックアップのディスク容量を計算する』を押すと、バックアップファイル（最適化前の画像ファイル）の数と合計サイズが計算され、表示されます。

画像サムネイルグループサイズは、メディアライブラリに登録した画像から生成されるサムネイル画像の名称とサイズが表示されます。

項目4：元の画像のすべてのバックアップを削除します

『元の画像バックアップを削除する』をクリックすると、バックアップファイルが削除されます。

バックアップファイルを削除すると最適化前の状態に戻すことができません。ですが、バックアップファイルはディスク容量を圧迫する原因の一つです。

運営開始から数か月経過してもバックアップファイルの出番がないなら、今後もバックアップファイルが必要になる可能性が低いです。思い切って削除しましょう。また[2] 画像最適化設定タブのオリジナルバックアップを削除するをオンにして、最適化時にバックアップファイルを削除するように設定しましょう。

項目5：画像の情報

画像の情報は、最適化が終了した画像の割合がパーセントで表示されます。割合が100パーセントに達すると、チェックマークに変化します。

画像を追加していないのに100パーセントにならないときは、最適化処理が失敗している可能性があります。最適化ステータスの『完了していないデータのクリーンアップ』を押して、失敗した最適化をやりなおしてください。

項目6：最適化の概要

最適化の概要は、画像最適化によって削減できたファイルサイズ等が表示されます。

最下欄の『メディアライブラリ』リンクをクリックすると、メディアライブラリがリスト形式で表示されます。メディアライブラリの右端に最適化で削減できたファイルサイズを確認できます。

メディアライブラリはリスト表示すると、次回以降もリスト表示されます。グリッド表示する場合は、上部の切り替えボタンをクリックしてください。

項目7：最適化ツール

最適化ツールは、全ての最適化された画像とバックアップ画像を切り替えます。

切り替えはファイル名の変更で行われます。

画像を最適化すると、元のファイル（バックアップ）は拡張子の前に『.bk』が挿入されます。

最適化画像：image.jpg
バックアップ：image.bk.jpg

『元のファイルを使用』をクリックすると、最適化画像の拡張子の前に『.bk.optm』が挿入され、バックアップから『.bk』が削除されます。

最適化画像：image.jpg → image.bk.optm.jpg
バックアップ：image.bk.jpg → image.jpg

『最適化されたファイルを使用する』をクリックすると、バックアップの拡張子の前に『.bk』が挿入され、最適化画像から『.bk.optm』が削除されます。

最適化画像：image.bk.optm.jpg → image.jpg
バックアップ：image.jpg → image.bk.jpg

『すべての最適化データを破棄する』をクリックすると、最適化済みの画像がバックアップで上書きされ、バックアップは削除されます。バックアップが存在しない場合は、最適化画像が残ります。最適化の進行状況がリセットされるため最適化処理をもう一度行うことができますが、バックアップで上書きされなかった画像は、最適化が二回行われることになり、画質が大きく低下する可能性があります。

画像の最適化設定タブ：[2] 画像最適化設定

項目1：自動要求 Cron

自動要求 Cron機能をオンにすると、最適化対象の画像をQUIC.cloudサーバーに自動送信します。この機能をオフにしているときはQUIC.cloud サーバーで画像を最適化するを使用して、手動で送信する必要があります。

自動送信はWP-Cronで定期的に処理されます。WP-Cronについて次のページで解説しているので、参考にしてください。

項目2：自動戻し Cron

自動戻し Cron機能をオンにすると、QUIC.cloudサーバーで最適化された画像をWebサイト側に戻す処理を、自動で行います。この機能をオフにしているときはQUIC.cloud サーバーで画像を最適化するを使用して、手動で戻す必要があります。

この機能も自動要求 Cronと同様に、WP-Cronで定期的に処理されます。

項目3：オリジナル画像の最適化

オリジナル画像の最適化機能をオンにすると、JPGとPNG画像を最適化します。

最適化前の画像はバックアップとして別名で保存されます。別名は拡張子の前に『.bk』が挿入されます。

元の画像： image.jpg
バックアップ： image.bk.jpg

バックアップとして別名で保存させない場合は、オリジナルバックアップを削除するを有効化します。

項目4：オリジナルバックアップを削除する

オリジナルバックアップを削除する機能をオンにすると、最適化後の画像で元画像を上書きします。これにより、最適化前の画像は完全に削除されます。

オフにすると元画像を別名に変更し、最適化後の画像で元画像の名前で保存します。これにより、最適化後の画像と最適化前の画像（オリジナルバックアップ）の二つの画像がディスクスペース内に保存されます。

オリジナルバックアップが存在しない場合、[1] 画像最適化の概要タブの最適化ツール等のオリジナル画像に戻す機能が使用できません。※実際には使用できますが、効果がありません。

項目5：可逆最適化

可逆最適化機能をオンにすると、可逆（ロスレス）圧縮での画像最適化を行います。

可逆圧縮は画像表示時に、圧縮前の画像が復元されます。そのため、オリジナルと全く同じ画質をキープできます。

この機能が無効化されている場合は非可逆圧縮で最適化されます。非可逆圧縮は元の画像が復元されません。多くのケースで画質が低下します。

可逆圧縮は非可逆圧縮よりもサイズが大きくなることが多いため、画像にこだわらないWebサイトは非可逆圧縮を選択する傾向があります。

項目6：EXIF / XMPデータを保存する

EXIF / XMPデータを保存するをオンにすると、画像に含まれるEXIF / XMPデータを、最適化後も保持します。オフにすると、EXIF / XMPデータが画像から削除されます。

EXIF / XMPデータには撮影位置情報などの個人情報が含まれている可能性があります。そのため、不特定多数が閲覧するWebサイトでは、削除することが推奨されます。

項目7：WebP 画像への置換

WebP 画像への置換をオンにすると、画像の最適化時にWebP画像を生成します。

この機能の有効化前に最適化された画像は、WebP画像生成の対象外です。最適化済みの画像からWebPを作成する場合は、[1] 画像最適化の概要タブの最適化ツールで『すべての最適化データを破棄する』をクリックして最適化状況をリセットする必要があります。

また、この機能が有効化されているときは、.htaccessファイルに次のような記述を追加します。これにより、WebPをサポートしているブラウザにWebP画像を、WebPをサポートしていないブラウザにJPGまたはPNG画像を配信します。

### marker WEBP start ###
RewriteCond %{HTTP_ACCEPT} "image/webp"
RewriteRule .* - [E=Cache-Control:vary=%{ENV:LSCACHE_VARY_VALUE}+webp]
RewriteCond %{HTTP_USER_AGENT} iPhone.*Version/(\d{2}).*Safari
RewriteCond %1 >13
RewriteRule .* - [E=Cache-Control:vary=%{ENV:LSCACHE_VARY_VALUE}+webp]
### marker WEBP end ###

項目8：WebP 属性を置換する

WebP 属性を置換する機能の入力欄には、WebP画像の置き換え対象となるHTMLタグと属性を指定します。

WebPをサポートしているブラウザへのWebP画像配信は、imgタグのsrc属性に含まれる画像URLを変更することでおこないます。

この項目に他のタグや属性を追加することで、imgタグ以外もWebP配信の対象にできます。またimgタグを削除することで、imgタグのWebP配信を無効化できます。

通常は『タグ名.属性』で置き換え対象を指定しますが、『.属性』とすることで全てのタグを対象にできます。

項目9：WebP の 特別な srcset

外部プラグイン等でsrcset要素を追加している場合、そのsrcset要素をWebPに置き換えられないことがあります。

WebP の 特別な srcsetをオンにすることで、そのようなsrcset要素の置き換えを行います。

ページの最適化設定

ページの最適化設定は、Webページの最適化による転送速度の高速化やSEOに関わると言われているPageSpeed Insightsスコアの改善に関する設定を行います。

ページの最適化設定は、ブラウザ表示やスクリプトに関わるデータを自動で変更するものがいくつかあります。これらの設定をオンにすると機械的に内容が変更されますが、稀にページのレイアウトが崩れたり、今で動いていたスクリプトが動作しなくなるなどの不具合を引き起こします。

設定を変更後は全てのキャッシュをパージ後に、パソコンおよびスマホでテストしてください。ただし一部の機能は最適化タイミングが遅延したり、QUIC.cloudサーバーで処理されるなどで、パージ後すぐに反映されるとは限りません。そのため、ページの確認は時間を置いて数回行う必要があります。

なおページ表示の乱れ等がおこった場合、原因を特定して対策する時間とコストが非常に多くなる可能性があります。多くの場合、ページの最適化によるSEO効果はあまり高くありません。レイアウト崩れ等の対策をするよりも、設定をオフにすることを検討してください。

設定をオフにせずにレイアウト崩れ対策をおこなう場合は、次のLiteSpeedドキュメントを参考にしてください

CSS/JS の問題のトラブルシューティング：https://docs.litespeedtech.com/lscache/lscwp/ts-optimize/

ページの最適化設定は、次の九つのタブで構成されています。

ページの最適化設定タブ：[1] CSS 設定

ページの最適化設定の[1] CSS 設定タブは、CSSの最適化に関する設定を行ます。

項目1：CSS 圧縮化

css圧縮化機能をオンにすると、cssファイルから余分な空白文字と改行文字および行頭以外のコメントを削除します。

けーちゃん

プラグイン上の説明にはインラインCSSコードを最小化と書いてありますが、インラインCSSは対象に含まれないようです

cssファイルは圧縮後に、WordPressフォルダ内の /wp-content/litespeed/css/フォルダにランダムな文字列で構成された別名で保存され、linkタグのhref属性が置き換えられます。

項目2：CSS 結合

CSS 結合機能がオンのとき、ドメイン内のCSSファイルを結合して、新規で一つのファイルを生成します。CSSファイルを呼び出す既存のlinkタグが削除され、結合後のCSSファイルを呼び出すlinkタグが挿入されます。

これにより、サーバーからCSSファイルを呼び出す回数を減らすことができます。

ただし、CSSファイルとstyleタグによるCSSが相互に影響を及ぼしているサイトは、優先順位が変更されてレイアウトが崩れる可能性があります。

例えば、次のように二つのCSSファイルの間にstyleタグが存在するケースがあるとします。それぞれに、同じ要素についてのスタイル設定が設定されている場合、最後のCSSが有効になります。

<link rel='stylesheet'  href='https://ドメイン/style1.css' /> ← 内容：p{color:red;}
<style>
p{color:blue;}
</style>
<link rel='stylesheet'  href='https://ドメイン/style2.css' /> ← 内容：p{color:green;}

上記のように各CSSのpタグの色が設定されているとすると最後の p{color:green;} が有効になるので、Webサイト上の文字は緑色で表示されます。

CSS結合をオンにすると、CSSファイルが一つのファイルとなりますがstyleタグは残ります。その結果優先順位が変更され、p{color:blue;}が有効になるので、Webサイト上の文字は青色で表示されます。

<link rel='stylesheet'  href='https://ドメイン/結合済み.css' />← 内容：p{color:red;}p{color:green;}
<style>
p{color:blue;}
</style>

ここでは色を例として挙げましたが、Webサイトのレイアウトに関する設定が重複している場合はWebページの見た目を大きく変える可能性があります。

そのためCSS結合をオンにした場合は、PCとスマホでWebページを表示して、レイアウトが崩れていないかどうかなど、想定している結果になっているかどうかを確認する必要があります。

なお、CSS の外部とインラインを組み合わせるをオンにすることでstyleタグを結合対象に含めることができます。

項目3：UCSS を生成する

UCSS を生成する機能がオンのとき、各ページ毎にCSSの使用状況解析を行い、使用していないCSSを削除して、UCSS（ユニーク CSS）を生成します。

この作業はQUIC.cloudサーバーで行われます。ただし月ごとに回数制限があり、それを超えて使用する場合は有料となります。回数制限については、次のページを参照してください。

ブラウザ表示等でキャッシュされたタイミングでUCSS生成対象となり、QUIC.cloudサーバー送信待ちのキューに入ります。

キューは自動で処理されますが、『UCSSキューを手動で実行する』を押すことで即時に処理を開始できます。

一般的にWordPressテーマに含まれるCSSは、使用されない内容が多く含まれています。使用されない内容を削除することで大幅なサイズ縮小が期待でき、転送速度の向上が見込まれます。

しかしUCSSを用意しないで共通的なCSSを利用する方法にも利点があります。共通的なCSSは1度呼び出すだけでブラウザにキャッシュされ、以降は他のページでも使用されます。UCSSは異なるページの呼び出し毎にCSS呼び出しが発生するので、閲覧者がWebサイト内のページを巡回する可能性が高いサイトは、UCSSを使用しない方が有利な可能性があります。

また、ページ数が多いWebサイトはUCSSのデータ量が大幅に増加することで、サーバーのディスクスペースを圧迫する可能性があります。このようなケースでは、Webページ単位のUCSSから、投稿タイプ単位のUCSSに切り替えることでディスクスペースを節約できます。

次のようなコードをfunction.php等に記述することで、投稿タイプ単位でUCSSを生成できます。

// litespeed_ucss_per_pagetypeフィルターがtrueを返すと
// 投稿タイプ単位でのUCSS生成対象
add_filter( 'litespeed_ucss_per_pagetype', '__return_true' );

次のように記述すると、ページ単位でのUCSS生成対象をコントロールできます。

// 固定ページのみページ単位でUCSS生成する
add_filter( 'litespeed_ucss_per_pagetype', function(){
    return get_post_type() !== 'page'; // 固定ページ
} );

次のコードは、トップページのみをUCSS生成対象から外しています。

add_action( 'litespeed_optm', function(){
	if( is_front_page() || is_home() ){
	    do_action( 'litespeed_conf_force', 'optm-ucss', false );
	}
});

項目4：UCSS インライン

UCSS インライン機能がオンのとき、UCSS を生成するで生成されたCSSを、Webページ内にstyleタグで埋め込みます。

これによりCSSファイルの読み込み回数が削減できるのと同時に、CSSファイル読み込みの遅延によるレイアウト変更が回避できます。

この機能は、Webサイトのデータ量が増大するためページ表示が遅くなる可能性があります。

項目5：CSS の外部とインラインを組み合わせる

CSS の外部とインラインを組み合わせる機能がオンのとき、外部ドメインのCSSファイルとStyleタグのCSSを、CSS 結合の対象に含めます。これにより、CSSの優先順位を維持され、Webページのレイアウトが崩れる可能性を減らすことができます。

ただし外部ドメインのサーバー負担を自ドメインのサーバーで請け負うことになり、状況によってはページ表示が遅くなります。

項目6：CSSを非同期読み込み

CSSを非同期読み込み機能は、UCSS インラインがオンのとき無効です。

CSSを非同期読み込み機能がオンのとき、ファーストビューで使用されるCSS（クリティカル CSS）を既存のstyleタグとlinkタグ内のcssファイルから抜き出して、Webページのstyleタグ内に埋め込みます。既存のstyleタグとlinkタグがそのまま残るため、クリティカル CSSとして抜き出したスタイルは重複します。

また、linkタグ内のcssファイルがファーストビュー表示後に非同期で読み込まれるようにlinkタグの内容を書き換えます。

これによりページが素早く表示されたという印象を、閲覧者に与えることができます。

ただし、『data-no-async=”1″』が記述されたlinkタグは、クリティカル CSS（CCSS）として抜き出されますが、非同期読み込みの対象外となります。

この作業はQUIC.cloudサーバーで行われます。ただし月ごとに回数制限があり、それを超えて使用する場合は有料となります。回数制限については、次のページを参照してください。

ブラウザ表示等でキャッシュされたタイミングでCCSS生成対象となり、QUIC.cloudサーバー送信待ちのキューに入ります。

キューは自動で処理されますが、『CCSSキューを手動で実行する』を押すことで即時に処理を開始できます。

項目7：URL ごとの CCSS

URL ごとの CCSS機能がオフのとき、CSSを非同期読み込みで生成されるCCSSが、投稿タイプ単位で生成されます。オンのときは、ページ単位で生成されます。

記事ページのファーストページの見た目がほぼ同じ場合、CCSSの内容も同じ可能性があります。このようなケースでは、オフにすることでディスク容量とQUIC.cloudサーバーの使用料を削減できます。

項目8：インライン CSS 非同期ライブラリ

インライン CSS 非同期ライブラリ機能をオンにすると、クリティカルCSSから除外されたCSS（非クリティカルCSS）を読み込むスクリプトがWebページ内に埋め込めれます。

非クリティカルCSSは、ファーストビューの表示後にJavaScriptで読み込まれます。

インラインCSS非同期ライブラリがオフの時はscriptタグによってJSファイルが読み込まれます。

<script data-optimized="1" src="https://kc-mixh.xyz/wp-content/plugins/litespeed-cache/assets/js/css_async.min.js" defer>

このとき、JSファイルの読み込みが完了するまで非クリティカルCSSを適用できません。何らかの理由でJSファイルの読み込みが大幅に遅延した場合、画面を下方にスクロールするとレイアウトが乱れる可能性があります。

オンの時は、JSファイルの内容がBASE64形式にエンコードされてscriptタグ内に埋め込まれます。

<script src="data:text/javascript;base64,IWZ1bmN0aW9uKGEpeyJ1c2Ugc3RyaWN0Ijt（省略）ckludGVydmFsKGMpfSl9fX0odGhpcyk7" defer>

JSファイルの読み込み遅延が発生しないため、ファーストビューより下方のレイアウト乱れを防ぐことができます。

ただし、非クリティカルCSSは外部CSSファイルに保存されているため、このファイルの読み込みが遅延した場合は、レイアウトが乱れる可能性があります。

項目9：フォント表示の最適化

フォント表示の最適化機能で『Swap』を選択すると、CSSの@font-faceルールに『font-display: swap;』を挿入します。『デフォルト』は、既存の値またはブラウザの既定動作が適用されます。

@font-faceルールは、サイトで使用するWebフォントを指定します。font-displayはWebフォントが読み込まれるまでの動作を指定します。

『font-display: swap;』はWebフォントの読み込みが終わるまで、その他のフォントで表示して、読み込みが終わったら、Webフォントに切り替えます。

font-displayのその他の値には、読み込みが終わるまで文字を表示しないものがあります。わずか数秒間だとしても、閲覧者が何もないページと判断した結果、ページを離脱する可能性があります。このような事態を防ぐために『Swap』を選択することをおススメします。

ページの最適化設定タブ：[2] JS 設定

ページの最適化設定の[2] JS 設定タブは、JavaScriptの最適化に関する設定を行います。

項目1：JS 圧縮化

JS 圧縮化機能をオンにすると、JSファイル中の余分な空白と改行および行頭を除いたコメントが削除されます。

JSファイルは圧縮後に、WordPressフォルダ内の /wp-content/litespeed/js/フォルダにランダムな文字列で構成された別名で保存され、scriptタグのsrc属性が置き換えられます。

項目2：JS 結合

JS 結合機能をオンにすると、ドメイン内のJSファイルが結合されて一つのファイルを生成します。インラインJSは対象外です。

WordPressはJSファイルとインラインJSをセットで出力することが多いですが、JSファイルのみ結合するため、依存関係が崩れ、相対した動作を行わない可能性があります。

項目3：JS は外部とインラインを組み合わせる

JS は外部とインラインを組み合わせる機能をオンにすると、ドメイン外のJSとインラインJSをJS 結合の対象に含めます。これにより依存関係が保たれ、想定した動作を行う可能性が高くなります。

ただし外部CSSのファイルサイズが大きい場合、転送量が大幅に増える可能性があります。

項目4：JS を遅延読み込み

JS を遅延読み込み機能はJSファイルの実行タイミングを変更します。

通常はJSファイルがWebデータ内に現れる度にJSファイルを読み込んで実行します。読み込み中は他の処理が停止するため、Webサイトが表示されるまで時間がかかることがあります。

この機能の『Deferred』を選択すると、JSファイルの実行をページ読み込み終了後に送らせます。これによりページが表示されるまでの時間を短縮できます。

『遅延』はページ読み込み終了後に閲覧者がマウス操作などを行うまで待ち、操作を行った時点でJSファイルを実行します。これによりPageSpeedなどが『重いスクリプトを使用しているサイト』と判定することによるＳＥＯに関する問題を避けることができます。

ただし『遅延』はLiteSpeed Cacheが独自のスクリプトを挿入して、無理やり実現している印象が強いです。そのため想定しない不具合が発生する可能性が高いです。あまりおススメできません。

ページの最適化設定タブ：[3] HTML の設定

ページの最適化設定の[3] HTML の設定タブは、HTMLに関する最適化を行います。

項目1：HTML 圧縮化

HTML 圧縮化機能をオンにすると、HTML内の空白や改行およびコメントが削除されます。

この機能でWebページの表示が崩れる可能性は非常に低いので、オンにすることをおススメします。

項目2：DNS プリフェッチ

DNS プリフェッチ機能の入力欄に文字列を入力すると、DNSプリフェッチに必要なタグが挿入されます。入力した文字列は一行につき、次のタグが一つ生成されます。

<link rel='dns-prefetch' href='入力した文字列' />

DNSプリフェッチとは、ドメインのIPアドレス解決を自動で行う機能です。

ドメインのIPアドレス解決は、通常はリンククリックなど、そのドメインのIPアドレスが必要なったタイミングで行われます。しかし稀にですが、IPアドレス解決まで時間がかかることがあります。その結果画面遷移まで間が開いてしまい、閲覧者にクリックしても何もおこらない等の印象を与えます。そこで、DNSプリフェッチであらかじめIPアドレス解決をしておくことで、間を置くことなく画面遷移を行うことができます。

項目3：DNS プリフェッチ制御

DNS プリフェッチ制御機能をオンにすると、ブラウザへの応答ヘッダーに『X-DNS-Prefetch-Control: on』を追加します。

これにより、ブラウザが必要に応じてリンク、画像、 CSS、 JavaScript等のドメイン解決を事前に行います。

項目4：DNSプリコネクト

DNSプリコネクト機能の入力欄に文字列を入力すると、ドメイン事前接続（プリコネクト）に必要なタグが挿入されます。入力した文字列は一行につき、次のタグが一つ生成されます。

<link rel="preconnect" href="入力した文字列" />

プリコネクトはドメインのIPアドレス確認後にドメインと接続して、画像やcss等の取得や画面遷移の直前までの処理を終了させます。これによりDNSプリフェッチよりも高速に、画面遷移等ができます。

ただしプリコネクトは、使用する可能性が高いドメインにのみに使用します。使用する可能性が低いドメインへの接続はムダな処理となり、ブラウザへ負担を掛ける可能性があります。

項目5：HTML Lazy Load セレクタ

HTML Lazy Load セレクタ機能を利用すると、セレクタで指定した要素が画面上で表示されるまで描画を待ちます。これにより、最初の画面表示を高速化できます。

この機能はcssにより実装され、HTML内に次のような内容が挿入されます。

<style>
入力したCSSセレクタ{
   content-visibility:auto;
   contain-intrinsic-size:1px 1000px;
}
</style>

『content-visibility:auto;』により、要素がビューポート内のみ表示されます。

『contain-intrinsic-size:1px 1000px;』は要素のおおよそのサイズです。スクロールバー等のサイズ計算で必要となります。

項目6：HTMLComments の保持

HTMLComments の保持機能はHTML 圧縮化がオンのとき、削除対象外とするHTMLコメントを指定します。

入力した文字列を含むHTMLコメントが削除されずに残ります。

例：『これはコメント』と入力した場合

削除されない：<!– これはコメント –>
削除されない：<!– これはコメントです –>
削除される：<!– これは？コメントです –>

項目7：クエリ文字列を削除

クエリ文字列を削除機能は、HTML内の静的リソースURLから、クエリ文字列を削除します。

対象は自ドメイン内かつ『wp-content』『wp-admin』『wp-includes』ディレクトリ以下の階層で、拡張子が『.js』または『.css』のファイルです。

ただしURL内に『_litespeed_rm_qs=0』または『/recaptcha』を含むときは、クエリ文字列を削除しません。

またURLはWordPressの内部関数を使用して追加されている必要があります。linkタグ等を直接記述したものは対象外です。

なお、この機能がクエリ文字列を削除した後に、テーマやプラグインがクエリ文字列を追加する可能性があります。

けーちゃん

私が使っているWPテーマのCocoonは、fverというクエリを追加しています

項目8：Google フォントを非同期に読み込む

Google フォントを非同期に読み込む機能はGoogleフォント用のlinkタグを、非同期読み込みスクリプトで置き換えます。styleタグの@importによる読み込みは対応していません。

例えば、次のようなlinkタグがあるとします。

<link href="https://fonts.googleapis.com/css2?family=Noto+Sans+JP:wght@100..900&display=swap" rel="stylesheet">

本機能により、次のようなコードに置き換えられます。

<link rel="preconnect" href="https://fonts.gstatic.com/" crossorigin />
<script>WebFontConfig={google:{families:["Noto Sans JP:wght@100..900"]}};if ( typeof WebFont === "object" && typeof WebFont.load === "function" ) { WebFont.load( WebFontConfig ); }</script>
<script data-optimized="1" src="https://sub.affi-sapo.com/wp-content/plugins/litespeed-cache/assets/js/webfontloader.min.js"></script>

このコードはheadタグ内に次のlinkタグを非同期で挿入します。

<link rel="stylesheet" href="https://fonts.googleapis.com/css?family=Noto+Sans+JP:wght@100..900" media="all">

挿入されたlinkタグにより、Googleフォントが読み込まれます。

この機能は、プリコネクト用のタグを追加します。既存のプリコネクト用タグは削除されないため、重複する可能性があります。

項目9：Google フォントを削除

Google フォントを削除機能は、Googleフォント用のlinkタグを削除します。

Google フォントを非同期に読み込むがオンの場合、Googleフォントが非同期で読み込まれるため、Googleフォントは有効になります。

また、この機能はプリコネクト用のタグを削除しません。

項目10：WordPress 絵文字を削除

WordPress 絵文字を削除機能をオンにすると、次の絵文字に関するスクリプトとスタイルを削除します。

<script>
window._wpemojiSettings = {"baseUrl":"https:\/\/s.w.org\/images\/core\/emoji\/15.0.3\/72x72\/","ext":".png","svgUrl":"https:\/\/s.w.org\/images\/core\/emoji\/15.0.3\/svg\/","svgExt":".svg","source":{"concatemoji":"https:\/\/sub.affi-sapo.com\/wp-includes\/js\/wp-emoji-release.min.js?ver=6.7.1"}};
/*! This file is auto-generated */
!function(i,n){var o,s,e;function c(e){try{var t={supportTests:e,timestamp:(new Date).valueOf()};sessionStorage.setItem(o,JSON.stringify(t))}catch(e){}}function p(e,t,n){e.clearRect(0,0,e.canvas.width,e.canvas.height),e.fillText(t,0,0);var t=new Uint32Array(e.getImageData(0,0,e.canvas.width,e.canvas.height).data),r=(e.clearRect(0,0,e.canvas.width,e.canvas.height),e.fillText(n,0,0),new Uint32Array(e.getImageData(0,0,e.canvas.width,e.canvas.height).data));return t.every(function(e,t){return e===r[t]})}function u(e,t,n){switch(t){case"flag":return n(e,"\ud83c\udff3\ufe0f\u200d\u26a7\ufe0f","\ud83c\udff3\ufe0f\u200b\u26a7\ufe0f")?!1:!n(e,"\ud83c\uddfa\ud83c\uddf3","\ud83c\uddfa\u200b\ud83c\uddf3")&&!n(e,"\ud83c\udff4\udb40\udc67\udb40\udc62\udb40\udc65\udb40\udc6e\udb40\udc67\udb40\udc7f","\ud83c\udff4\u200b\udb40\udc67\u200b\udb40\udc62\u200b\udb40\udc65\u200b\udb40\udc6e\u200b\udb40\udc67\u200b\udb40\udc7f");case"emoji":return!n(e,"\ud83d\udc26\u200d\u2b1b","\ud83d\udc26\u200b\u2b1b")}return!1}function f(e,t,n){var r="undefined"!=typeof WorkerGlobalScope&&self instanceof WorkerGlobalScope?new OffscreenCanvas(300,150):i.createElement("canvas"),a=r.getContext("2d",{willReadFrequently:!0}),o=(a.textBaseline="top",a.font="600 32px Arial",{});return e.forEach(function(e){o[e]=t(a,e,n)}),o}function t(e){var t=i.createElement("script");t.src=e,t.defer=!0,i.head.appendChild(t)}"undefined"!=typeof Promise&&(o="wpEmojiSettingsSupports",s=["flag","emoji"],n.supports={everything:!0,everythingExceptFlag:!0},e=new Promise(function(e){i.addEventListener("DOMContentLoaded",e,{once:!0})}),new Promise(function(t){var n=function(){try{var e=JSON.parse(sessionStorage.getItem(o));if("object"==typeof e&&"number"==typeof e.timestamp&&(new Date).valueOf()<e.timestamp+604800&&"object"==typeof e.supportTests)return e.supportTests}catch(e){}return null}();if(!n){if("undefined"!=typeof Worker&&"undefined"!=typeof OffscreenCanvas&&"undefined"!=typeof URL&&URL.createObjectURL&&"undefined"!=typeof Blob)try{var e="postMessage("+f.toString()+"("+[JSON.stringify(s),u.toString(),p.toString()].join(",")+"));",r=new Blob([e],{type:"text/javascript"}),a=new Worker(URL.createObjectURL(r),{name:"wpTestEmojiSupports"});return void(a.onmessage=function(e){c(n=e.data),a.terminate(),t(n)})}catch(e){}c(n=f(s,u,p))}t(n)}).then(function(e){for(var t in e)n.supports[t]=e[t],n.supports.everything=n.supports.everything&&n.supports[t],"flag"!==t&&(n.supports.everythingExceptFlag=n.supports.everythingExceptFlag&&n.supports[t]);n.supports.everythingExceptFlag=n.supports.everythingExceptFlag&&!n.supports.flag,n.DOMReady=!1,n.readyCallback=function(){n.DOMReady=!0}}).then(function(){return e}).then(function(){var e;n.supports.everything||(n.readyCallback(),(e=n.source||{}).concatemoji?t(e.concatemoji):e.wpemoji&&e.twemoji&&(t(e.twemoji),t(e.wpemoji)))}))}((window,document),window._wpemojiSettings);
</script>
<style id='wp-emoji-styles-inline-css'>
	img.wp-smiley, img.emoji {
		display: inline !important;
		border: none !important;
		box-shadow: none !important;
		height: 1em !important;
		width: 1em !important;
		margin: 0 0.07em !important;
		vertical-align: -0.1em !important;
		background: none !important;
		padding: 0 !important;
	}
</style>

このスクリプトの主な目的は、古いブラウザで絵文字を表示することです。現在のブラウザでは不要なので、削除しても問題ありません。

項目11：Noscript タグの削除

Noscript タグの削除機能をオンにすると、HTML内のnoscriptタグを削除します。

noscriptタグはブラウザのJavaScriptを無効化しているときに使用されるタグです。現在はほとんどのWebサイトでJavaScriptが使用されているため、個人の判断でJavaScriptを無効化するケースはほとんどありません。そのため、noscriptタグを削除しても大きな問題になる可能性は低いです。

ですが、HTML内でnoscriptタグが占める割合はとても小さいため、削除することでのメリットはあまりありません。

ページの最適化設定タブ：[4] メディア設定

ページの最適化設定の[4] メディア設定タブは、主に画像の遅延読み込みに関する設定を行います。

項目1：画像 遅延読み込み

画像 遅延読み込み機能をオンにすると、画像の読み込みを、ブラウザ上で閲覧者が視認できる位置（ビューポート）で表示されるまで待ちます。

具体的にはimgタグに対して、次のような変更を行います。

• 『data-lazyloaded=”1″』を挿入
• 画像URLを値に持つdata-src属性を追加
• src属性を基本的な画像プレースホルダーの値で置き換え
• 変更前のimgタグを内部に持つnoscriptタグを追加

これにより、次のようなタグが生成されます。（imgタグ内のwidthとheight属性は、WordPressの標準機能により追加されます。）

<img data-lazyloaded="1" src="data:image/gif;base64,R0lGODdhAQABAPAAAMPDwwAAACwAAAAAAQABAAACAkQBADs=" decoding="async" width="300" height="270" data-src="https://ドメイン/wp-content/uploads/image.png" class="wp-image-105"/>
<noscript>
<img decoding="async" width="300" height="270" src="https://ドメイン/wp-content/uploads/image.png"  class="wp-image-105"/>
</noscript>

さらに、次のようなスクリプトタグを追加します。

<script data-no-optimize="1">
!function(t,e){"object"==typeof exports&&"undefined"!=typeof module?module.exports=e():"function"==typeof define&&define.amd?define(e):(t="undefined"!=typeof globalThis?globalThis:t||self).LazyLoad=e()}(this,function(){"use strict";function e(){return(e=Object.assign||function(t){for(var e=1;e<arguments.length;e++){var n,a=arguments[e];for(n in a)Object.prototype.hasOwnProperty.call(a,n)&&(t[n]=a[n])}return t}).apply(this,arguments)}function i(t){return e({},it,t)}function o(t,e){var n,a="LazyLoad::Initialized",i=new t(e);try{n=new CustomEvent(a,{detail:{instance:i}})}catch(t){(n=document.createEvent("CustomEvent")).initCustomEvent(a,!1,!1,{instance:i})}window.dispatchEvent(n)}function l(t,e){return t.getAttribute(gt+e)}function c(t){return l(t,bt)}function s(t,e){return function(t,e,n){e=gt+e;null!==n?t.setAttribute(e,n):t.removeAttribute(e)}(t,bt,e)}function r(t){return s(t,null),0}function u(t){return null===c(t)}function d(t){return c(t)===vt}function f(t,e,n,a){t&&(void 0===a?void 0===n?t(e):t(e,n):t(e,n,a))}function _(t,e){nt?t.classList.add(e):t.className+=(t.className?" ":"")+e}function v(t,e){nt?t.classList.remove(e):t.className=t.className.replace(new RegExp("(^|\\s+)"+e+"(\\s+|$)")," ").replace(/^\s+/,"").replace(/\s+$/,"")}function g(t){return t.llTempImage}function b(t,e){!e||(e=e._observer)&&e.unobserve(t)}function p(t,e){t&&(t.loadingCount+=e)}function h(t,e){t&&(t.toLoadCount=e)}function n(t){for(var e,n=[],a=0;e=t.children[a];a+=1)"SOURCE"===e.tagName&&n.push(e);return n}function m(t,e){(t=t.parentNode)&&"PICTURE"===t.tagName&&n(t).forEach(e)}function a(t,e){n(t).forEach(e)}function E(t){return!!t[st]}function I(t){return t[st]}function y(t){return delete t[st]}function A(e,t){var n;E(e)||(n={},t.forEach(function(t){n[t]=e.getAttribute(t)}),e[st]=n)}function k(a,t){var i;E(a)&&(i=I(a),t.forEach(function(t){var e,n;e=a,(t=i[n=t])?e.setAttribute(n,t):e.removeAttribute(n)}))}function L(t,e,n){_(t,e.class_loading),s(t,ut),n&&(p(n,1),f(e.callback_loading,t,n))}function w(t,e,n){n&&t.setAttribute(e,n)}function x(t,e){w(t,ct,l(t,e.data_sizes)),w(t,rt,l(t,e.data_srcset)),w(t,ot,l(t,e.data_src))}function O(t,e,n){var a=l(t,e.data_bg_multi),i=l(t,e.data_bg_multi_hidpi);(a=at&&i?i:a)&&(t.style.backgroundImage=a,n=n,_(t=t,(e=e).class_applied),s(t,ft),n&&(e.unobserve_completed&&b(t,e),f(e.callback_applied,t,n)))}function N(t,e){!e||0<e.loadingCount||0<e.toLoadCount||f(t.callback_finish,e)}function C(t,e,n){t.addEventListener(e,n),t.llEvLisnrs[e]=n}function M(t){return!!t.llEvLisnrs}function z(t){if(M(t)){var e,n,a=t.llEvLisnrs;for(e in a){var i=a[e];n=e,i=i,t.removeEventListener(n,i)}delete t.llEvLisnrs}}function R(t,e,n){var a;delete t.llTempImage,p(n,-1),(a=n)&&--a.toLoadCount,v(t,e.class_loading),e.unobserve_completed&&b(t,n)}function T(o,r,c){var l=g(o)||o;M(l)||function(t,e,n){M(t)||(t.llEvLisnrs={});var a="VIDEO"===t.tagName?"loadeddata":"load";C(t,a,e),C(t,"error",n)}(l,function(t){var e,n,a,i;n=r,a=c,i=d(e=o),R(e,n,a),_(e,n.class_loaded),s(e,dt),f(n.callback_loaded,e,a),i||N(n,a),z(l)},function(t){var e,n,a,i;n=r,a=c,i=d(e=o),R(e,n,a),_(e,n.class_error),s(e,_t),f(n.callback_error,e,a),i||N(n,a),z(l)})}function G(t,e,n){var a,i,o,r,c;t.llTempImage=document.createElement("IMG"),T(t,e,n),E(c=t)||(c[st]={backgroundImage:c.style.backgroundImage}),o=n,r=l(a=t,(i=e).data_bg),c=l(a,i.data_bg_hidpi),(r=at&&c?c:r)&&(a.style.backgroundImage='url("'.concat(r,'")'),g(a).setAttribute(ot,r),L(a,i,o)),O(t,e,n)}function D(t,e,n){var a;T(t,e,n),a=e,e=n,(t=It[(n=t).tagName])&&(t(n,a),L(n,a,e))}function V(t,e,n){var a;a=t,(-1<yt.indexOf(a.tagName)?D:G)(t,e,n)}function F(t,e,n){var a;t.setAttribute("loading","lazy"),T(t,e,n),a=e,(e=It[(n=t).tagName])&&e(n,a),s(t,vt)}function j(t){t.removeAttribute(ot),t.removeAttribute(rt),t.removeAttribute(ct)}function P(t){m(t,function(t){k(t,Et)}),k(t,Et)}function S(t){var e;(e=At[t.tagName])?e(t):E(e=t)&&(t=I(e),e.style.backgroundImage=t.backgroundImage)}function U(t,e){var n;S(t),n=e,u(e=t)||d(e)||(v(e,n.class_entered),v(e,n.class_exited),v(e,n.class_applied),v(e,n.class_loading),v(e,n.class_loaded),v(e,n.class_error)),r(t),y(t)}function $(t,e,n,a){var i;n.cancel_on_exit&&(c(t)!==ut||"IMG"===t.tagName&&(z(t),m(i=t,function(t){j(t)}),j(i),P(t),v(t,n.class_loading),p(a,-1),r(t),f(n.callback_cancel,t,e,a)))}function q(t,e,n,a){var i,o,r=(o=t,0<=pt.indexOf(c(o)));s(t,"entered"),_(t,n.class_entered),v(t,n.class_exited),i=t,o=a,n.unobserve_entered&&b(i,o),f(n.callback_enter,t,e,a),r||V(t,n,a)}function H(t){return t.use_native&&"loading"in HTMLImageElement.prototype}function B(t,i,o){t.forEach(function(t){return(a=t).isIntersecting||0<a.intersectionRatio?q(t.target,t,i,o):(e=t.target,n=t,a=i,t=o,void(u(e)||(_(e,a.class_exited),$(e,n,a,t),f(a.callback_exit,e,n,t))));var e,n,a})}function J(e,n){var t;et&&!H(e)&&(n._observer=new IntersectionObserver(function(t){B(t,e,n)},{root:(t=e).container===document?null:t.container,rootMargin:t.thresholds||t.threshold+"px"}))}function K(t){return Array.prototype.slice.call(t)}function Q(t){return t.container.querySelectorAll(t.elements_selector)}function W(t){return c(t)===_t}function X(t,e){return e=t||Q(e),K(e).filter(u)}function Y(e,t){var n;(n=Q(e),K(n).filter(W)).forEach(function(t){v(t,e.class_error),r(t)}),t.update()}function t(t,e){var n,a,t=i(t);this._settings=t,this.loadingCount=0,J(t,this),n=t,a=this,Z&&window.addEventListener("online",function(){Y(n,a)}),this.update(e)}var Z="undefined"!=typeof window,tt=Z&&!("onscroll"in window)||"undefined"!=typeof navigator&&/(gle|ing|ro)bot|crawl|spider/i.test(navigator.userAgent),et=Z&&"IntersectionObserver"in window,nt=Z&&"classList"in document.createElement("p"),at=Z&&1<window.devicePixelRatio,it={elements_selector:".lazy",container:tt||Z?document:null,threshold:300,thresholds:null,data_src:"src",data_srcset:"srcset",data_sizes:"sizes",data_bg:"bg",data_bg_hidpi:"bg-hidpi",data_bg_multi:"bg-multi",data_bg_multi_hidpi:"bg-multi-hidpi",data_poster:"poster",class_applied:"applied",class_loading:"litespeed-loading",class_loaded:"litespeed-loaded",class_error:"error",class_entered:"entered",class_exited:"exited",unobserve_completed:!0,unobserve_entered:!1,cancel_on_exit:!0,callback_enter:null,callback_exit:null,callback_applied:null,callback_loading:null,callback_loaded:null,callback_error:null,callback_finish:null,callback_cancel:null,use_native:!1},ot="src",rt="srcset",ct="sizes",lt="poster",st="llOriginalAttrs",ut="loading",dt="loaded",ft="applied",_t="error",vt="native",gt="data-",bt="ll-status",pt=[ut,dt,ft,_t],ht=[ot],mt=[ot,lt],Et=[ot,rt,ct],It={IMG:function(t,e){m(t,function(t){A(t,Et),x(t,e)}),A(t,Et),x(t,e)},IFRAME:function(t,e){A(t,ht),w(t,ot,l(t,e.data_src))},VIDEO:function(t,e){a(t,function(t){A(t,ht),w(t,ot,l(t,e.data_src))}),A(t,mt),w(t,lt,l(t,e.data_poster)),w(t,ot,l(t,e.data_src)),t.load()}},yt=["IMG","IFRAME","VIDEO"],At={IMG:P,IFRAME:function(t){k(t,ht)},VIDEO:function(t){a(t,function(t){k(t,ht)}),k(t,mt),t.load()}},kt=["IMG","IFRAME","VIDEO"];return t.prototype={update:function(t){var e,n,a,i=this._settings,o=X(t,i);{if(h(this,o.length),!tt&&et)return H(i)?(e=i,n=this,o.forEach(function(t){-1!==kt.indexOf(t.tagName)&&F(t,e,n)}),void h(n,0)):(t=this._observer,i=o,t.disconnect(),a=t,void i.forEach(function(t){a.observe(t)}));this.loadAll(o)}},destroy:function(){this._observer&&this._observer.disconnect(),Q(this._settings).forEach(function(t){y(t)}),delete this._observer,delete this._settings,delete this.loadingCount,delete this.toLoadCount},loadAll:function(t){var e=this,n=this._settings;X(t,n).forEach(function(t){b(t,e),V(t,n,e)})},restoreAll:function(){var e=this._settings;Q(e).forEach(function(t){U(t,e)})}},t.load=function(t,e){e=i(e);V(t,e)},t.resetStatus=function(t){r(t)},Z&&function(t,e){if(e)if(e.length)for(var n,a=0;n=e[a];a+=1)o(t,n);else o(t,e)}(t,window.lazyLoadOptions),t});!function(e,t){"use strict";function a(){t.body.classList.add("litespeed_lazyloaded")}function n(){console.log("[LiteSpeed] Start Lazy Load Images"),d=new LazyLoad({elements_selector:"[data-lazyloaded]",callback_finish:a}),o=function(){d.update()},e.MutationObserver&&new MutationObserver(o).observe(t.documentElement,{childList:!0,subtree:!0,attributes:!0})}var d,o;e.addEventListener?e.addEventListener("load",n,!1):e.attachEvent("onload",n)}(window,document);
</script>

このスクリプトにより、『data-lazyloaded=”1″』のimgタグが基本的な画像プレースホルダーの画像から、正規の画像に置き換えられます。

画像置き換え後は、litespeed-loadedクラスが追加されます。

現在のブラウザは『loading=”lazy”』が記述された画像を遅延読み込みする機能が組み込まれています。WordPressは標準機能で『loading=”lazy”』をメディアライブラリで設置した画像に挿入するので、何もしなくても遅延読み込み機能を利用できます。

LiteSpeed Cacheの遅延読み込み機能の利点は、メディアライブラリを使用しないで設置した画像も対象にする点です。例えば、アフィリエイトの画像タグをコピペして貼り付けた場合、WordPressは対象になりませんが、LiteSpeed Cacheは対象となります。

また、LiteSpeed Cacheの遅延読み込み機能は、任意の初期画像を表示できるなどきめ細かい設定を行うことができます。

項目2：基本的な画像プレースホルダー

基本的な画像プレースホルダー機能は、画像 遅延読み込みがオンのとき初期表示する画像をBASE64形式で指定します。

入力端が空白のときは『data:image/gif;base64,R0lGODdhAQABAPAAAMPDwwAAACwAAAAAAQABAAACAkQBADs=』が使用されます。これは、1×1の灰色画像を表しますが、これを使用して、正規の画像のサイズで塗りつぶします。

項目3：レスポンシブプレースホルダー

レスポンシブプレースホルダー機能をオンにすると、遅延読み込み前の画像として、基本的な画像プレースホルダーの代わりにレスポンシブプレースホルダー SVGを使用します。

項目4：レスポンシブプレースホルダー SVG

レスポンシブプレースホルダー SVG機能は、レスポンシブプレースホルダーがオンのときに遅延読み込み前の画像として使用するsvgタグを指定します。

ここで指定したsvgタグはBASE64形式に変換されて、imgタグのsrc属性にセットされます。

svgタグは置き換え要素として、次の文字列を使用できます。

• {width}： imgタグのwidth属性と置き換え
• {hieght}： imgタグのheight属性と置き換え
• {color}：レスポンシブプレースホルダーの色と置き換え

次のsvgタグは、中央に『只今画像読込中です…』という文字を表示しています。

<svg xmlns="http://www.w3.org/2000/svg" width="{width}" height="{height}" viewBox="0 0 {width} {height}"><rect width="100%" height="100%" style="fill:{color};fill-opacity: 0.1;"/><text x="50%" y="50%" text-anchor="middle">只今画像読込中です...</text></svg>

入力欄に貼り付けると、遅延読み込みプレースホルダーとして、次のように表示されます。

項目5：レスポンシブプレースホルダーの色

レスポンシブプレースホルダーの色機能は、レスポンシブプレースホルダー SVGで指定したsvgタグ内の文字列『{color}』と置き換える色を指定します。

項目6：LQIP クラウドジェネレーター

LQIP クラウドジェネレーター機能をオンにすると、元の画像から遅延読み込み前の画像（LQIP：低品質画像プレースホルダー）を生成します。これにより、これから表示される画像の雰囲気を閲覧者に伝えることができます。

生成されたLQIPは、imgタグのsrc属性にBASE64形式で埋め込まれます。その結果、Webページのデータ量が増えるため表示速度が遅くなります。画像数が多いWebサイトは、LQIPにより得られる視覚的効果よりも速度低下でのデメリットの方が多くなる可能性があります。

またLQIPはQUIC.cloudサーバーで生成されます。LQIP生成は有料ですが、月毎に無料枠が割り当てられます。無料枠については、次のページを参照してください。

項目7：LQIP 品質

LQIP 品質機能は、元の画像から生成された遅延読み込み前の画像の品質を1から20の整数値で指定します。

品質は数値が小さいほど荒い画像になります。また品質が高いほどデータ量が多くなります。

画像	LQIP 品質	データサイズ
	元画像	6603バイト
	品質4	1121バイト
	品質20	3096バイト

項目8：LQIP 最小寸法

LQIP 最小寸法は、LQIP画像を生成する画像の最小サイズ（縦横）を指定します。

縦横共に、指定サイズを超えた画像が生成対象となります。

項目9：バックグラウンドでの LQIP の生成

バックグラウンドでの LQIP の生成機能がオンのとき、自動（バックグラウンド）でLQIPを生成します。

この機能がオフのとき、ページが閲覧されて時点でLQIPを生成します。閲覧者への応答はLQIP生成後になるため、画像数が多いページは非常に遅いという印象を与える可能性があります。そのため、事前にページを表示してLQIPを生成しておくことをおススメします。ただし、WordPressログイン時はLQIPが生成されません。ログアウトするか他のブラウザを利用してください。

項目10：遅延読み込み iframe

遅延読み込み iframe機能をオンにすると、iframeがビューポート内に入った時点でiframe内の読み込みを開始します。

読み込み開始まではブランクページが表示されます。

項目11：不足しているサイズを追加する

不足しているサイズを追加する機能をオンにすると、画像 遅延読み込みがオンのとき、widthとheight属性が記述されていないimgタグに、widthとheight属性を追加します。

この機能は外部ドメインの画像サイズも取得します。

外部ドメインの画像サイズ取得は時間がかかるため、Webページの表示が遅くなる可能性があります。次のコードをfunction.php等に記述することで、外部ドメインからのサイズ取得を止めることができます。

add_filter( "litespeed_media_ignore_remote_missing_sizes", "__return_true" );

imgタグにwidthとheight属性が記述されていない場合、画像読み込み後に文字と文字の間に画像が割り込み、サイトのレイアウトが大きく変更される可能性があります。このような動作は、閲覧者の満足度を大きく下げる可能性があります。

そのため不足しているサイズの追加はとても有効な機能ですが、同様の機能がWordPressの標準機能でサポートされています。そのため、LiteSpeed Cacheの機能をオフにしても、imgタグにwidthとheight属性が追加追加されます。

ただしWordPressのサイズ追加機能はメディアライブラリで追加して画像が対象です。画像タグをコピペしたときや、外部ドメインの画像を貼り付けたときなどは、LiteSpeed Cacheの取得機能を使用するとよいでしょう。

項目12：WordPress 画像品質管理

WordPress 画像品質管理機能は、WordPress内での画像処理（主にJPGのサイズ変更）で適用する圧縮品質を指定します。

ページの最適化設定タブ：[5] VPI

ページの最適化設定の[5] VPIタブは、ビューポートイメージ機能の設定を行います。

項目1：ビューポートイメージ

ビューポートイメージ機能は画像 遅延読み込みがオンのとき、ブラウザのファーストビュー（ビューポート）内に表示される可能性が高い画像を遅延対象から除外する機能です。

ファーストビューで大きな画像を表示しているサイトで遅延読み込みに時間がかかると、何も表示されないという印象を与える可能性があります。ビューポート内の画像を遅延対象から除外することで、画面表示と同時に画像が表示することができます。

この機能はビューポートイメージの解析をQUIC.cloudサーバーで行います。解析は有料ですが、月ごとに無料枠が割り当てられます。無料枠については、次のページを参照してください。

なお画像 遅延読み込みがオフのとき、WordPressの画像遅延読み込み機能が有効になります。WordPressの画像遅延読み込み機能は、ファーストビューに表示される可能性がある画像を遅延対象から除外します。精度はQUIC.cloudサーバーでの解析よりも劣ると思われますが、ブラウザのネイティブ機能のみを利用するため高速に動作します。

項目2：ビューポートイメージCron

ビューポートイメージCron機能をオンにすると、自動でQUIC.cloudサーバーにビューポートイメージ生成を要求します。

ブラウザ表示等でキャッシュされたタイミングでビューポートイメージ生成対象となり、QUIC.cloudサーバー送信待ちのキューに入ります。

この機能がオンのときキューは自動で処理されますが、『VPIキューを手動で実行する』を押すことで即時に処理を開始できます。

ページの最適化設定タブ：[6] 除外するメディア

ページの最適化設定の[6] 除外するメディアタブは、[4] メディア設定で有効にした遅延画像および遅延iframe対象からの除外設定をおこないます。

項目1：遅延読み込み Imageを除外

遅延読み込み Imageを除外機能は、画像 遅延読み込みの対象がとする画像のURLを指定します。

完全なURLを入力する必要はありません。入力欄に入力された文字がURLに含まれているとき、対象から除外されます。ワイルドカード等は使用できません。

例えば『.jpg』と入力すると、JPG画像が遅延読み込み対象外となります。

ディレクトリ名を入力すると、そのディレクトリ内の画像が全て除外されます。ただし、ディレクトリと同じ名前の画像も含まれる可能性があるので注意する必要があります。

項目2：遅延読み込み Image クラス名を除外する

遅延読み込み Image クラス名を除外する機能は、入力したクラス名を持っているimgタグを画像 遅延読み込み対象から外します。

例えば、次のような『eye-catch-image』をクラスメイト持つimgタグなら、入力欄に『eye-catch-image』と入力することで、対象から除外できます。

<img class="eye-catch-image" src="https://・・・">

また、次のように部分的に一致するクラスも対象外となります。

<img class="eye-catch-image-1" src="https://・・・">
<img class="eye-catch-image-2" src="https://・・・">

項目3：遅延読み込み Image 親クラス名を除外する

遅延読み込み Image 親クラス名を除外する機能は、入力したクラス名を持っている要素の内部に含まれるimgタグを画像 遅延読み込み対象から外します。

次の例は、headerクラスを持つdiv要素内に複数のimgタグが含まれています。

<div class="header">
  <div>
      <img class="header-image" src="https://・・・">
  </div>
  <div>
      <img src="https://・・・">
      <img src="https://・・・">
  </div>
</div>

入力欄に『header』と入力すると、内部の全ての画像が対象外となります。

この機能は遅延読み込み Image クラス名を除外すると同じように、部分一致したクラスも対象外となります。

項目4：遅延読み込み iframe クラス名を除外する

遅延読み込み iframe クラス名を除外する機能は、入力したクラス名を持っているiframeタグを遅延読み込み iframeの対象から外します。

この機能は遅延読み込み Image クラス名を除外すると同じように、部分一致したクラスも対象外となります。

項目5：遅延読み込み iframe 親クラス名を除外する

遅延読み込み iframe 親クラス名を除外する機能は、入力したクラス名を持っている要素の内部に含まれるiframeタグを遅延読み込み iframeの対象から外します。

この機能は遅延読み込み Image 親クラス名を除外すると同じように、部分一致したクラスも対象外となります。

項目6：遅延読み込み URI の除外

遅延読み込み URI の除外機能は、画像 遅延読み込みと遅延読み込み iframeの対象外とするWebページのURLを指定します。

URLはドメインの後方の『/』から指定します。

指定例
ページURL：https://ドメイン/category/page1/
入力するURL：/category/page1/

また部分一致での指定も可能です。

指定例
ページURL：https://ドメイン/category/page1/
入力するURL：
/category/
/page1/
ory/pa

『^』(先頭一致)と『$』(末尾一致)を使用できます。

指定例
ページURL：https://ドメイン/category/page1/
入力するURL：
^/category/　（先頭から一致）
/page1/$　（末尾から一致）
^/category/page1/$　(完全に一致）

項目7：LQIP を除外

LQIP を除外機能は、LQIP クラウドジェネレーターの対象外とする画像URLを指定します。

指定方法は遅延読み込み Imageを除外と同じです。

ページの最適化設定タブ：[7] ローカリゼーション

ページの最適化設定の[7] ローカリゼーションタブは、外部リソースをWebサーバー内に保存して内部リソースとして配信する機能の設定を行います。

項目1：Gravator キャッシュ

Gravator キャッシュ機能をオンにすると、Gravatorを利用したプロフィールやコメントのアバター画像をWebサーバー内にキャッシュします。

GravatorはAutomattic社が運営しているオンライン上のアバターサービスです。Gravatorを使用することで、様々なプラットフォームで共通のアバターを使用できます。

通常は、WordPressはメールアドレスからGravatorのサーバー上のアバター画像URLを生成してimgタグのsrc属性にセットします。そして、ブラウザがGravatorのサーバーからアバター画像を取得します。

Gravator キャッシュ機能をオンにすると、アバター画像をキャッシュしてローカルファイルに保存します。そしてimgタグのsrc属性に保存したファイルのURLをセットします。その結果、ブラウザはアバター画像として、保存したファイルを取得します。

この機能によりWebサーバーの負担が増えますが、Gravatorサーバー側の遅延やダウン等の影響を受けることなくアバター画像を表示できます。

項目2：Gravator キャッシュ Cron

Gravator キャッシュ Cron機能をオンにすると、Gravatorのサーバー上のアバター画像を自動取得します。

項目3：Gravator キャッシュ TTL

Gravator キャッシュ TTLは、Webサーバー内にキャッシュしたGravatorアバターのTTL(有効期限)を指定します。

TTL時間が経過する前にGravatorサーバーでアバター画像を変更しても、Webページ上のアバター画像は変更されません。

項目4：リソースのローカライズ

リソースのローカライズ機能をオンにすると、ローカライズファイルで指定した外部ファイルをWebサーバー内に保存し、以降は内部ファイルとして配信します。

項目5：ローカライズファイル

ページの最適化設定タブ：[8] チューニング

ページの最適化設定の[8] チューニングタブは、[2] JS 設定タブの高度な追加設定および最適化についての追加設定を行います。

項目1：JS 遅延が含まれるもの

JS 遅延が含まれるもの機能は、JS を遅延読み込みが『Deferred』のとき『遅延』を適用するスクリプトファイルを指定します。

スクリプトファイルはscritptタグのsrc属性と一致または部分一致したものが有効です。

インラインJSコードは、コードの一部と一致したものが有効です(*1。

項目2：JS 除外

JS 除外機能は、JS 結合とJS は外部とインラインを組み合わせるがオンのとき、結合対象から除外するスクリプトファイル、またはインラインJSコードを指定します。

スクリプトファイルはscritptタグのsrc属性と一致または部分一致したものが有効です。

インラインJSコードは、コードの一部と一致したものが有効です。

項目3：JS Deferred / Delayed 除く

JS Deferred / Delayed 除く機能は、JS を遅延読み込みが『Deferred』または『遅延』のとき、『オフ』を適用するスクリプトファイル、またはインラインJSコードを指定します。

スクリプトファイルはscritptタグのsrc属性と一致または部分一致したものが有効です。

インラインJSコードは、コードの一部と一致したものが有効です。

また、scriptタグ内に『data-no-optimize=”1″』を記述すると、同様の効果を得ることができます。

項目4：ゲストモードのJSは除外

ゲストモードのJSは除外機能は、一般設定のゲストモードがオンのときに生成されるゲスト用ページ内のJSを、最適化（[2] JS 設定）対象から除外します。

スクリプトファイルはscritptタグのsrc属性と一致または部分一致したものが有効です。

インラインJSコードは、コードの一部と一致したものが有効です。

また、scriptタグ内に『data-no-optimize=”1″』を記述すると、同様の効果を得ることができます。

項目5：除外 URI

除外 URI機能は、LiteSpeed Cacheによる最適化の対象外とするページのURLを指定します。

URLはドメインの後ろの『/』からが比較対象となります。入力欄に入力した文字列がURLとすべて一致するか、部分的に一致する必要があります。

入力する文字列は『^』（先頭）と『$』（末尾）を表す文字を使用できます。

※入力文字列についてはプライベートキャッシュ URIsを参照してください。

項目6：ゲストのみに最適化

ゲストのみに最適化機能をオンにすると、WordPressにログインしているユーザーに表示されるページ内のCSSとJavaScriptを最適化しません。

この機能をオンにすると、WordPressの各ロール毎に最適化されたCSSとJavaScriptが生成されるため、ディスクスペースを圧迫する可能性があります。

項目7：ロール除外

ロール除外機能は、Webページの最適化対象から除外するWordPressのロールを指定します。

ゲストのみに最適化が対象とするのはCSSとJavaScriptですが、この機能はそれ以外の最適化にも適用されます。

ページの最適化設定タブ：[9] チューニング – CSS

ページの最適化設定の[9] チューニング – CSSタブは、[1] CSS 設定タブの高度な追加設定を行います。

項目1：CSS 除外

CSS 除外機能は、CSS 圧縮化、CSS 結合の対象から除外するcssファイルまたはstyleタグを指定します。

cssファイルはlinkタグのhref属性と一致、または部分一致したものが除外されます。

styleタグは、タグ内のスタイル定義の一部が一致したものが除外されます。

linkタグまたはstyleタグに『data-no-optimize=”1″』を記述することで、CSS 圧縮化、CSS 結合の対象から除外することができます。

項目2：UCSS ファイルの除外とインライン化

UCSS ファイルの除外とインライン化機能は、CSSファイルをUCSS を生成するの対象から除外して、Webページ内にインラインで埋め込みます。

CSSファイルはlinkタグのhref属性と一致、または部分一致したものが除外されます。

項目3：UCSS セレクターの許可リスト

UCSS セレクターの許可リスト機能は、UCSS を生成するがオン時に生成されるUCSSに必ず含めるスタイル定義を指定します。

含めるスタイル定義はセレクターで指定しますが、クラスやIDを指定すると関連するセレクタが対象となります。

例えば『.test_style_1』と入力すると、次のようなスタイルがUCSSに含められます。

/* 対象 */
.test_style_1 { color:#f12adb; }
.test_style_1 .test_style_2{ color:#c12adb; }
p .test_style_1 { color:#a12adb; }
div.test_style_1 { color:#f1eadb; }

また、『*』（ワイルドカード）を使用できます。『.t_style_*』と入力すると、次のようなスタイルがUCSSに含められます。

/* 対象外 */
.t_style_1{ color:#c12ad1; }
.t_style_2{ color:#c12ad1; }
.t_style_3{ color:#c12ad1; }

項目4：UCSS URI を除く

UCSS URI を除く機能は、UCSS を生成するがオン時に、UCSS生成から除外するWebページのURLを指定します。

URLはhttpから始まる完全なパス、または、パスの一部で指定できます。

この機能は、大多数のページが正常に表示されていて、一部のページのみレイアウトが乱れるときなどに使用します。

項目5：別々のCCSSキャッシュポストタイプ

別々のCCSSキャッシュポストタイプ機能は、CSSを非同期読み込みで生成されるCCSSを個別生成する投稿タイプを指定します。

URL ごとの CCSSがオンのとき、全てのページのCCSSが個別生成されます。これは、Webページ数が多いとディスクスペースを圧迫する可能性があります。

ファーストビューがほぼ同じ投稿タイプがある場合は、URL ごとの CCSSをオフにして、この機能の入力欄にその投稿タイプを入力することで、ディスクスペースを節約できます。

項目6：個別のCCSSキャッシュURI

個別のCCSSキャッシュURI機能は、CSSを非同期読み込みで生成されるCCSSを個別生成するWebページのURLを指定します。

URL ごとの CCSSがオンのとき、全てのページのCCSSが個別生成されます。これは、Webページ数が多いとディスクスペースを圧迫する可能性があります。

同じ投稿タイプのファーストビューがほぼ同じで一部のページのみ異なるときは、URL ごとの CCSSをオフにして、この機能の入力欄にそのWebページのURLを入力することで、ディスクスペースを節約できます。

URLはドメインの後ろの『/』から最後までの文字が対象で、入力した文字と一致、または部分一致したものが対象となります。

また入力文字は『^』（先頭）と『$』（末尾）を使用できます。

※入力文字列についてはプライベートキャッシュ URIsを参照してください。

項目7：クリティカル CSS ルール

クリティカル CSS ルール機能は、CSSを非同期読み込みで生成されるCCSSに必ず含めるスタイル定義を指定します。

UCSS セレクターの許可リストはCSSのセレクターを指定しましたが、ここではスタイル定義そのものを入力します。

データベースの最適化設定

データベースの最適化設定は次の二つのタブで構成されます。

データベースの最適化設定タブ：[1] 管理

データベースの最適化設定の[1] 管理タブは、主にデータベース内の重要でないデータを削除

項目1：データベースの最適化

データベースの最適化機能は、WordPressのデータベース内で重要ではない項目を削除します。

ボタン内の(140)等の赤い数値は削除対象のデータ数です。(0)のように緑でゼロ表示されているものは、対象のデータ数が存在しないことを表しています。

各ボタンを押すと、次のような処理を行います。

2『投稿のリビジョン』で削除される項目数は、[2] DB 最適化設定で設定可能です。

9『期限切れのTransients』と10『全てのTransients』のTransients(トランジェント)とは、WordPressのプログラムコード上で時間がかかる処理の結果を、一時的にデータベースに保存しておき、次回は保存したデータを使用することで処理時間を短縮することを目的としたデータです。

トランジェントデータには有効期限があり、トランジェントデータが必要になった時に有効期限がチェックされます。そのため、必要にならない限り、有効期限が切れてもデータベース内に残り続けます。

またトランジェントデータが存在しない場合は、新規で作成するようにコードが組まれています。そのため、有効期限内のデータを削除しても問題ありません。

11『テーブルの最適化』は、削除されたデータをファイル上から削除します。

通常は、データベースからデータを削除すると、データベース内の関連性が削除されますが、データそのものは残ります。そのためファイルサイズは削減されません。テーブルの最適化を行うことで、不必要となったデータがファイル上から削除されます。

項目2：データベーステーブルエンジンコンバーター

データベーステーブルエンジンコンバーター機能は、MyISAM形式のテーブルをInnoDB形式に変換します。

InnoDB形式はMyISAM形式よりもデータの安全性や整合性が高く、同時にたくさんの人が使う場面でも効率的です。また、データが壊れにくく、エラーが起きても復元しやすいという特徴があります。

ただし変換により何らかの不具合がでる可能性があります。修復には専門知識が必要となるため、安易な使用は避けた方がよいです。

項目3：データベースの概要

データベースの概要機能は、WordPressがWebページを生成するときに事前読み込み（オートロード）されるデータの名前とサイズが表示されます。

これはテーマまたはプラグイン開発者向け情報です。

データベースの最適化設定タブ：[2] DB 最適化設定

データベースの最適化設定の[2] DB 最適化設定タブは、データベースの最適化の条件設定を行います。

項目1：リビジョンの最大数

リビジョンの最大数は、データベースの最適化の投稿のリビジョンボタンクリック時に、削除せずに残しておく最新リビジョンデータ数を指定します。

リビジョンの最大エイジより新しいリビジョンは、カウント対象から除かれます。

項目2：リビジョンの最大エイジ

リビジョンの最大エイジは、データベースの最適化の投稿のリビジョンボタンクリック時に、削除せずに残しておくリビジョンデータの日数を指定します。

正確には日数×24時間が有効期間となります。

クローラー設定

クローラー設定は次の六つのタブで構成されます。

LiteSpeed Cacheのクローラーは、サイトマップを元にWebページを巡回して未キャッシュのページをキャッシュします。キャッシュと同時に、必要に応じて、QUIC.cloudサーバーを利用する最適化（CCSSやUCSS生成等）キューにセットされます。

通常は最初の閲覧者がWebページを閲覧したときにキャッシュが生成されます。そのため最初の閲覧者は、ページ表示が遅くなる可能性があります。あらかじめクローラーを利用してキャッシュしておくことで、最初の閲覧者にも高速なページ表示を行えます。

■サーバー管理者権限によるLiteSpeed Cacheのクローラーの無効化

クローラー機能はサーバー機器に大きな負担を与えるます。特にレンタルサーバー等の共有サーバーは無数のWebサイトが共存しているためクローラーの負担が増大し、Webページの表示速度を大きく遅延させる可能性があります。そのためサーバー管理者権限で、クローラー機能を無効化できるように設計されています。

[1] 概要タブに次のような警告が表示されている場合は、クローラー機能を利用できません。

クローラータブ：[1] 概要

クローラー設定の[1] 概要タブは、クローラーの進捗状況の確認を目的としています。

項目1：クローラー Cron

クローラー Cron機能は、各クローラー Cronの現在のステータス（進捗状況）の確認と、有効化/無効化の切り替えを行います。Cronはサーバー上で一般的に使用される名称で、決められた時間に決められた処理を行う機能です。

リスト上のゲストは未ログインでのページ閲覧を想定しています。

また、クローラーはLiteSpeed Cacheの設定により増減します。例えばWebP 画像への置換をオンにすると、WebPを想定したクローラーが追加されます。

リストの上部にある『ポジションをリセット』を押すと、クロールを最初から実行できます。

『[R] 手動で実行』を押すと、スケジュールを無視してクロールを実行できます。

リスト内のステータスの各色は、次のような意味を持っています。

各クローラーごとに、有効化と無効化の切り替えを行えます。サーバー側の設定でLiteSpeed Cacheのクローラー機能が無効化されているときは、このリスト上で有効化されていても動作しません。有効のままでもサーバーの負担が増えることはありませんが、念のため無効化しておきましょう。

項目2：クローラーステータスを見る

クローラーステータスを見る機能は、詳細な進行状況を確認できます。

『クローラーステータスを表示』を押すと、進行状況が表示されます。

クローラータブ：[2] マップ

クローラー設定の[2] マップタブは、クロール対象URLをリストアップします。

項目1：サイトマップリスト

サイトマップリスト機能は、クロール対象URLのリストアップと、クロール結果ステータスを表示します。

このリストは自動で更新されません。『クローラーマップの更新』を押すと、カスタムサイトマップで指定したサイトマップを読み込んでリストアップします。

『URL Serch』に文字列を入れてエンターを押すと、リスト内のURLと一致するものを検索してリスト内に表示します。全てのリストを表示するときは、入力欄を空欄にしてからエンターを押してください。

URLの右端の『ブロックリストに追加する』を押すと、ブロックリストにURLが追加されクローラー対象から除外されます。

クローラータブ：[3] ブロックリスト

クローラー設定の[3] ブロックリストタブは、LiteSpeed Cacheクローラーの読み取りをブロックするURLをリストアップします。

項目1：ブロックリスト

ブロックリスト機能は、クロール対象から除外するWebページのURLがリストアップされます。

このリストへの登録はサイトマップリストから行います。

URLの右端の『ブロックリストから削除する』を押すと、リストから削除できます。

リスト上部の『空のブロックリスト』を押すと、リストの内容が全て削除されます。

クローラータブ：[4] 一般設定

クローラー設定の[4] 一般設定タブは、LiteSpeed Cacheクローラーの実行タイミング等について設定します。

項目1：クローラー

クローラー機能をオンにすると、LiteSpeed CacheクローラーのCronによる実行機能が有効になります。

サーバー管理者権限によりLiteSpeed Cacheクローラーが無効化されている場合、この機能をオンにしてもクロールされません。

項目2：遅延

遅延機能は、クローラーがWebページを呼び出す間隔をマイクロ秒単位で指定します。

値が大きいほどサーバーの負担が減りますが、クロール処理が終了するまでの時間が長くなります。

値は0マイクロ秒から設定できますが、サーバー側の設定で最小値が指定されている可能性があります。

値の最大値は30000です。
※タブ上では『より小さい』と記載されていますが、その後に続く数値を受け付けるため『以下』が正しいです。

項目3：実行時間

実行時間機能は、クローラーが中断するまでの時間を秒単位で指定します。

クロールを開始して指定された秒数が経過すると、クローラーが一時停止します。そして、実行間隔で指定した秒数経過後に再開します。

項目4：実行間隔

実行間隔機能は、クローラーが中断してから再開するまでの時間を秒単位で指定します。

クロールを開始して実行時間で指定された秒数が経過すると、クローラーが一時停止します。そして、ここで指定した秒数経過後に再開します。

実行間隔は60以上の値を入力する必要があります。
※タブ上では『より大きい』と記載されていますが、その後に続く数値を受け付けるため『以上』が正しいです。

項目5：クローラー間隔

クローラー間隔機能は、クロールを開始してから、次のクロールを開始するまでの経過時間を秒で指定します。

2回目以降のクロールは、前回のクロール処理が完全に終了してから開始する必要があります。そのためクローラー間隔は、クロール処理終了までの時間よりも長い時間を指定します。

項目6：スレッド

スレッド機能は、クローラーが同時にWebページにアクセスする数を指定します。

数値が大きいほど終了までの時間が速くなりますが、サーバーの負担が増大します。

ここでは1から16までの値を指定できます。

項目7：タイムアウト

タイムアウト機能は、一つのWebページクロールに使用する最大の時間を秒で指定します。

サーバー遅延等でWebページ取得に時間がかかるとき、処理を中断して次のWebページが処理されます。

ここでは10から300までの値を指定できます。

この値はcurlのCURLOPT_TIMEOUTオプションにセットされます。

項目8：サーバー負荷制限

サーバー負荷制限機能は、サーバー負荷の許容値を指定します。

サーバ負荷が許容値を超えると、5秒間のスリープまたは稼働しているスレッド数を減らして負荷を下げます。

入力値に制限はありませんが、サーバー管理者権限で最大値が指定されている可能性があります。

クローラータブ：[5] シミュレーション設定

クローラー設定の[5] シミュレーション設定タブは、WordPressログインユーザーやクッキーを想定したクローラーをクローラー Cronに追加します。

項目1：ロールシミュレーション

ロールシミュレーション機能は、クローラー CronにWordPressにログインしたユーザーロールでのクロールを追加します。

入力欄にはユーザーID（数値）を入力します。

例えば、ユーザーIDが『1』のユーザーロールは管理者（Administrator）です。ロールシミュレーション機能の入力欄に『1』と入力すると、次の図のようにクローラー CronにAdministratorが追加されます。

項目2：Cookie シミュレーション

ロールシミュレーション機能は、クローラー Cronにクッキーを考慮したクローラーが追加されます。

入力は『Cookie 名』の下方にある入力欄にクッキーの名前を入力します。右側の入力欄にはクッキーの値を入力します。複数の値を改行で入力可能です。

例えば名前に『mycookie』を、値に『A』と『B』の二つを入力すると、次の図のように値が展開されてクローラー Cronにクローラーが追加されます。

クローラータブ：[6] サイトマップ設定

クローラー設定の[6] サイトマップ設定タブは、サイトマップリストで読み込まれるサイトマップに関する設定を行います。

項目1：カスタムサイトマップ

カスタムサイトマップ機能は、サイトマップリストで読み込まれるサイトマップの完全なURLを指定します。

サイトマップはXML形式である必要があります。

項目2：サイトマップからドメインを削除

サイトマップからドメインを削除機能をオンにすると、サイトマップから取得したページURLのドメインを削除します。これによりディスクスペースを節約できます。

ドメイン削除の結果は、サイトマップリストにも反映されます。

一般的なWebサイトはオンにすることを推奨します。ただし、サイトマップに複数のドメインが含まれているときはオフにする必要があります。

項目3：サイトマップのタイムアウト

サイトマップのタイムアウト機能は、サイトマップデータ取得のタイムアウト時間を秒で指定します。

値は15から1800の範囲で指定します。

指定された値は、wp_remote_get関数のtimeoutオプションで使用されます。

ツールボックス設定

ツールボックス設定は次の八つのタブで構成されます。

ツールボックス設定タブ：[1] パージ

ツールボックス設定の[1] パージタブは、キャッシュを手動でパージ（削除）します。

項目1：パージ

パージ機能の各ボタンを押すと、対象となるキャッシュが削除されます。

項目2：パージ対象…

パージ対象機能は、各ページのキャッシュを個別に削除します。

『パージリスト』を押すと、入力欄に入力したページのキャッシュが削除されます。

ツールボックス設定タブ：[2] インポート/エクスポート

項目1：設定のエクスポート

プリセット設定の[2] インポート/エクスポートの設定のエクスポートを参照してください。

項目2：設定のインポート

プリセット設定の[2] インポート/エクスポートの設定のインポートを参照してください。

項目3：すべての設定をリセットする

プリセット設定の[2] インポート/エクスポートのすべての設定をリセットするを参照してください。

ツールボックス設定タブ：[3] .htaccessの表示

ツールボックス設定の[3] .htaccessの表示タブは、.htaccessファイルの内容を確認できます。

項目1：.htaccess のパス

.htaccess のパス機能は、フロントエンド用およびバックエンド用の .htaccessファイルのサーバー上でのパスが表示されます。

通常はフロントエンドとバックエンド共に、同じパスが表示されます。

項目2：現在の .htaccess コンテンツ

現在の .htaccess コンテンツ機能は、.htaccessの内容が表示されます。
※編集はできません

ここで表示される内容は自動更新されません。内容を更新するときは、ページを再表示してください。

ツールボックス設定タブ：[4] ハートビート

ツールボックス設定の[4] ハートビートタブは、WordPressのハートビート機能を制御します。

ハートビート機能はブラウザからWebサーバーに定期的に通信を行う仕組みです。これによりサーバーが動作しているかどうかの確認や、サーバーからの通知受け取りなどを行います。

一方でハートビートは通信量が増える原因になるため、適切な場面で使用する必要があります。

項目1：フロントエンドハートビート制御

フロントエンドハートビート制御機能がオンのとき、フロントエンド ハートビート TTLに入力した値を使用してWebページ（フロントエンド）のハートビートを制御します。オフのときは、LiteSpeed Cache側からフロントエンドハードビートの動作に影響を与えません。
※フロントエンドハートビートの有効化/無効化を行う機能ではありません。

フロントエンドハードビートは既定で無効となっており、一部のテーマやプラグインが有効化します。例えばWooCommerceプラグインは、カートのリアルタイム更新等でハートビートを使用します。

フロントエンドのハートビートはPV数がそのまま通信量の増大につながるため、一般的なWebサイトで有効化することはほとんどありません。

項目2：フロントエンド ハートビート TTL

フロントエンド ハートビート TTL機能は、フロントエンドハートビート制御がオンのときに変更するWebページ（フロントエンド）のハートビートのTTLを指定します。ここでのTTLは、ブラウザからサーバーに通信を行う間隔です。秒で指定します。

この機能はテーマやプラグインでフロントエンドハードビートが有効になっていない場合、何の意味もありません。

入力値は0または15から120の範囲です。0はフロントエンドハードビートを無効化します。

項目3：バックエンドハートビートコントロール

バックエンドハートビートコントロール機能がオンのとき、バックエンド ハートビート TTLに入力した値を使用して管理画面（バックエンド）のハートビートを制御します。オフのときは、LiteSpeed Cache側からバックエンドハードビートの動作に影響を与えません。
※バックエンドハートビートの有効化/無効化を行う機能ではありません。

バックエンドハードビートは既定で有効になっています。

項目4：バックエンド ハートビート TTL

バックエンド ハートビート TTL機能は、バックエンドハートビートコントロールがオンのときに変更する管理画面（バックエンド）のハートビートのTTLを指定します。ここでのTTLは、ブラウザからサーバーに通信を行う間隔です。秒で指定します。

入力値は0または15から120の範囲です。0はバックエンドハードビートを無効化します。

項目5：エディターハートビート

エディターハートビート機能がオンのとき、エディターハートビート TTLに入力した値を使用して投稿画面（エディター）のハートビートを制御します。オフのときは、LiteSpeed Cache側からエディターハードビートの動作に影響を与えません。
※エディターハートビートの有効化/無効化を行う機能ではありません。

エディターハードビートは既定で有効になっています。

項目6：エディターハートビート TTL

エディター ハートビート TTL機能は、エディターハートビートがオンのときに変更する投稿画面（エディター）のハートビートのTTLを指定します。ここでのTTLは、ブラウザからサーバーに通信を行う間隔です。秒で指定します。

入力値は0または15から120の範囲です。0はエディターハードビートを無効化します。

ツールボックス設定タブ：[5] レポート

ツールボックス設定の[5] レポートタブは、LiteSpeedサポートにサーバーおよびWordPressおよびLiteSpeed Cacheの設定内容を送信します。

項目1：システム情報

システム情報は、LiteSpeedサポートに送信される情報が表示されます。

項目2：パスワードなしのリンク

パスワードなしのリンクは、LiteSpeedサポートがパスワード無しで管理画面にログインするためのリンクを生成します。

この機能は DoLogin Securityプラグインが必要です。画面上部の『DoLogin Securityをインストールする』をクリックすると、プラグインをインストールできます。

項目3：メモ

メモに入力した内容は、LiteSpeedサポートに送信されます。

項目4：LiteSpeed に送信

LiteSpeed に送信ボタンを押すと、LiteSpeedサポートにタブ内の情報が送信されます。

ツールボックス設定タブ：[6] デバッグ設定

ツールボックス設定の[6] デバッグ設定タブは、デバッグログに表示される内容をカスタマイズします。

項目1：デバッグヘルパー

デバッグヘルパー機能は、LiteSpeed CacheがWebページを最適化する前の状態のページを表示します。

ページは新しいタブ内に表示されます。

『最適化前のサイトを表示する』を押すと、最適化が実行されていないWebページが実行されます。Webページが正常に表示されないとき、最適化が原因かどうかを確認するのに役立ちます。URLの後ろに『?LSCWP_CTRL=before_optm』を追加することで同様の結果を得られます。

『キャッシュ前のサイトを表示する』を押すと、キャッシュが存在するしないに関わらず新規でページ生成を行います。Webページが正常に表示されないとき、キャッシュが原因かどうかを確認するのに役立ちます。URLの後ろに『?LSCWP_CTRL=NOCACHE』を追加することで同様の結果を得られます。WordPressにログインせずにページを表示するときは管理者 IPに、自分のIPアドレスを入力する必要があります。

『キャッシュ前のサイトを表示する』は意味的には最適化済みページを取得するように受け取れますが、未最適化のページが取得されます。これが正しい動作かどうかは情報が少ないため詳細不明です。

項目2：すべての機能を無効にする

すべての機能を無効にする機能をオンにすると、LiteSpeed Cacheの全機能が無効化されます。

LiteSpeed Cacheの全機能が無効化することで、Webページが正常に表示されないとき、LiteSpeed Cacheに問題があるのかどうかを確認することができます。

項目3：デバッグログ

デバッグログ機能の『オン』を選択すると、デバッグ情報をログファイルに出力します。

『管理 IP のみ』を選択すると、管理者 IPに登録したIPアドレスからのアクセスのみをログファイルに出力します。

『オン』のときは全てのPVが記録対象となるため、出力されるログデータのサイズが非常に大きくなります。その結果、デバッグに必要なデータを探すのが難しくなります。『管理 IP のみ』にすることで、自分のアクセスのみをデバッグログに出力できるため、デバッグが容易になります。

項目4：管理者 IP

管理者 IP機能は、デバッグログが『管理 IP のみ』のときにデバッグログファイル出力対象となるIPアドレスを指定します。

現在使用しているＰＣからのアクセスを対象とするときは、『あなたのIPアドレス:』に続く4つの数値を入力欄に入力してください。

項目5：デバッグレベル

デバッグレベル機能で『基本』を選択すると、基本的なデバッグ情報がログファイルに出力されます。

『高度な設定』を選択すると、基本的な内容に加えて、より詳細なデバッグ情報がログファイルに出力されます。

項目6：ログファイルのサイズ制限

ログファイルのサイズ制限機能は、ログファイルの最大サイズをMBで指定します。ここでのMB換算は、入力値を1000000倍して算出しています。

サイズチェックはページ生成の最初に行われ、その時点でサイズ超過している場合はファイルの内容が全てクリアされます。その後、各デバッグ情報が書き込まれます。情報書き込み時にはサイズチェックをおこなわないため、ログファイルのサイズが制限を超える可能性があります。

項目7：クエリ文字列を折畳む

クエリ文字列を折畳む機能をオンにすると、一部のURLとクエリのデバッグログファイル出力が変化します。

ログの最初に出力される『💓』が含まれる行が対象です。機能が『オフ』のとき、URLとクエリが二つの行で表示されます。

1/1/1 1:1:1.1 [1.1.1.1:1 1 lds] 💓 ------GET HTTP/1.1 (HTTPS) /wp-admin/admin.php
1/1/1 1:1:1.1 [1.1.1.1:1 1 lds] Query String: page=litespeed-toolbox

機能が『オン』のとき、URLとクエリが一行で表示されます。

1/1/1 1:1:1.1 [1.1.1.1:1 1 JIF] 💓 ------GET HTTP/1.1 (HTTPS) /wp-admin/admin.php ? page=litespeed-toolbox

項目8：包含するデバッグ URI

包含するデバッグ URI機能は、デバッグログファイル出力対象とするURLを指定します。

WebページURLのドメイン後方の『/』から最後までと、入力欄に入力した値が比較されます。完全一致または部分一致した場合、そのページはデバッグログファイル出力対象となります。

入力欄は『^』（先頭）と『$』（末尾）を表す文字を使用できます。
※入力文字列についてはプライベートキャッシュ URIsを参照してください。

除外するデバッグ URIに値が入力されている場合、まず包含するデバッグ URIでデバッグログファイル出力対象と判定されたURLが、除外するデバッグ URIでチェックされます。

項目9：除外するデバッグ URI

除外するデバッグ URI機能は、デバッグログファイル出力対象から除外とするURLを指定します。

WebページURLのドメイン後方の『/』から最後までと、入力欄に入力した値が比較されます。完全一致または部分一致した場合、そのページはデバッグログファイル出力対象から除外されます。

入力欄は『^』（先頭）と『$』（末尾）を表す文字を使用できます。
※入力文字列についてはプライベートキャッシュ URIsを参照してください。

包含するデバッグ URIに値が入力されている場合、まず包含するデバッグ URIでデバッグログファイル出力対象と判定されたURLが、除外するデバッグ URIでチェックされます。

項目10：デバッグ用文字列の除外

デバッグ用文字列の除外機能は、デバッグログファイルに出力する内容を制限します。

デバッグログで表示されるログ文字列のうち、IPアドレス後方の『]』から後ろの文字が比較対象です。比較対象と入力欄に入力した値が部分一致すると、そのデバッグメッセージはデバッグログファイルに出力されません。

ただし『💓』の行からヘッダー内容についての数行は、ここで入力した文字列と比較されません。

ツールボックス設定タブ：[7] ログ表示

ツールボックス設定の[7] ログ表示タブは、LiteSpeed Cacheのプログラムコードに埋め込めれたデバッグコードが出力した内容を表示します。

項目1：LiteSpeed ログ

LiteSpeed ログ機能は、表示するログファイルの種類を選択します。

『[D] ログを消去する』を押すと、デバッグログに表示されているログが削除されます。ただし削除についてもデバッグログが出力されます。そのため、デバッグログを完全に消去することはできません。

項目2：デバッグログ

LiteSpeed ログで選択したログファイルの内容が表示されます。

表示内容は自動更新されません。最新のログを表示するときは、ツールボックス設定画面を再読み込みしてください。

ツールボックス設定タブ：[8] ベータテスト

ツールボックス設定の[8] ベータテストタブは、過去のバージョンや開発バージョンのLiteSpeed Cacheをインストールします。

項目1：GitHubのバージョンを試す

GitHubのバージョンを試す機能は、LiteSpeed Cacheの開発バージョンや過去バージョンをインストールします。

入力欄にGitHubのコミットURLを入力するか、下方のボタンを押します。次に『アップグレード』を押すと、指定したバージョンのLiteSpeed Cacheがインストールされます。

このとき、既存のLiteSpeed Cacheに上書きされます。最新の状態に戻すときは、WordPressのプラグイン更新、またはタブ内の『最新の WordPress リリースバージョンを使用する』を選択してください。

最後に

三日ぐらいで終わると思って始めたこのページ、機能の意味を探りながらだったためか三か月かかりました。

そのおかげか、LiteSpeed Cacheの設定に詳しくなることができました。すぐに忘れそうですが…

このページのダッシュボードの解説で、次の画像を使用しています。

LiteSpeed Cacheで最大限の設定を行ったら、読み込みスピードが1.47秒から0.007秒になりました。

劇的に高速化したのです。

元々mixhostが高速なサーバーですが、さらに高速になるのはスゴイですね。

皆様も、ぜひLiteSpeed CacheでWebサイトをチューニングして、高速化を達成してください。