WordPress Plugin : YASAKANI Cache – セルティスラボ

WordPress は、動作が重いのでキャッシュプラグインを使って高速化されている方も多いと思います。

定番のキャッシュプラグインとして WP Super Cache や WP Fastest Cache 等が人気ですが、これらのキャッシュプラグインよりも「シンプル、簡単、超高速なのに多機能」なページキャッシュプラグインを作成したので是非一度使ってみてください　(^^)

YASAKANI Cache
1. 特徴
2. 効果
インストール
キャッシュの基本設定
CSS縮小化とJS非同期ロード
1. CSS Minify (Tree Shaking)
2. JavaScript (defer)
メンテナンス機能
ログ機能
統計情報
セキュリティ機能
ファイル変更の検出と復元
さらに高速化するには
免責事項
履歴

YASAKANI Cache
1. 特徴
2. 効果
インストール
キャッシュの基本設定
CSS縮小化とJS非同期ロード
1. CSS Minify (Tree Shaking)
2. JavaScript (defer)
メンテナンス機能
ログ機能
統計情報
セキュリティ機能
ファイル変更の検出と復元
さらに高速化するには
免責事項
履歴

YASAKANI Cache

特徴

WordPress の遅い原因というか、ボトルネックは WordPress 自体だったりします。矛盾するようですが、WordPress を起動させないことが一番のボトルネック解消となりますので、キャッシュプラグインでは通常 WordPress のコア機能より前に処理することで 1ms でも速くなるようにしのぎを削り合っています

一方で、定番のキャッシュプラグイン（WP Super Cache, W3 Total Cache, WP Fastest Cache 等）は、多機能ですが設定が複雑でわかりにくかったりということもあるので、もっとシンプルで使いやすいものが求められています

YASAKANI Cacheは、SQLiteを利用することで、シンプルで使いやすく超高速なキャッシュプラグインとなっています

SQLite

SQLiteは、パブリックドメインで提供されてる SQL92準拠の豊富な機能を持ったファイルベースのデータベースで、多くのWebサーバーのPHPから標準で利用できるようになっています

SQLite を使い WordPress のコア機能をロードする前、キャッシュプラグインで使われる drop in プラグイン advanced cache で処理をすることで高速に応答できます

最小限の PHP処理と SQLite の高速性によって、Webサーバーによるプロキシーキャッシュに近い速さが期待できます

また、SQLite を使った副産物として、簡易アクセスログ機能やボットブロック機能、統計情報機能を実装することも出来ました。ちょっと負荷が増えるぶん遅くなりますが、不正なボットアクセスを制限すればサーバーにかかる負荷も低減できるのでトータルで考えればとってもお得な機能です

SQLite は、今回のような用途であれば単純なテーブル構成で済み、数千件程度のデータをインデックスを活用して処理するだけなので遅くなる要素は見当たりません。
また、最近のサーバーでは SSD を記憶装置に使っていることも多いので、SQLite のデータベースファイルに対するデータI/O速度がボトルネックになることも少なく、メモリキャッシュ等と同等の高速な処理が期待できます

効果

それでは実際に YASAKANI Cache の効果を紹介します

テスト環境は、エックスサーバーを使った場合です

ちなみにこのサイトへの Ping を実行してみると 15ms 程度かかっていたので、サーバー設置場所による通信時間やもろもろのオーバーヘッドが 15ms 程度と見込まれます

このテストでは Waiting時間 19ms なので実質のページキャッシュ処理時間は４ms 程度と思われます

上記表示では同じブラウザから複数回アクセスしているので、しっかり Last Modefied の処理も効いて 304 が表示されています

このプラグインだけではブラウザでアクセスしたときに高速化したという実感は少ないかもしれません。さらに高速化して、PageSpeed 等のスコアをアップするには、後述するさらに高速化するにはで紹介している方法を併せて試してみてください。特に .htaccess でブラウザーキャッシュを設定すると PageSpeed のスコアが向上すると思います

インストール

WordPress のキャッシュプラグインの多くは、ドロップインプラグインという特定のファイル名の advanced-cache.php というファイルを使って機能しています。この advanced-cache.php を wordpress のコア機能をロードするより前にロードしてキャッシュデータを出力しています。

advanced-cache.php ファイルを用いているプラグインは１つだけしか使えません。 WP Super Cache 等の他のキャッシュプラグインが有効化されている場合は、それを無効化してからインストールして下さい

動作環境

WordPress 5.5 以上
PHPバージョン 7.4 以上
PHP の sqlite3 モジュールが有効化されている必要があります

このプラグインは、自動的に　wp-config.php ファイルにキャッシュ処理用のコードを挿入します。また、wp-content フォルダーに advanced-cache.php というファイルを設置してドロップインプラグインとして動作させています。wp-config.php ファイルや wp-content フォルダへ書き込み権限がある必要があります

YASAKANI Cache は、キャッシュデータを SQLite に gzip 圧縮して保存しています
php.ini　で zlib.output_compression を使って出力を gzip 圧縮している場合で不具合が報告されているので、zlib.output_compression を指定しないよう注意してください
※mod_deflate の使用は問題ありません

ダウンロード

公式サイトからダウンロード出来ます

YASAKANI Cache

Simple ! Easy !! Ultra-high-speed !!!. Definitive edition of the page cache. And Bot and Security Utility.

WordPress.org

ダウンロードした zipファイルを プラグインの新規追加画面 の プラグインのアップロード からインストールすることが出来ます

または、プラグインの新規追加画面から YASAKANI Cache を検索してインストールすることも出来ます

更新時の注意

WPのプラグイン管理ページから更新する場合は、一旦、プラグインを無効化して、更新後に再度有効化に戻してください

※プラグインが有効化されたまま更新すると、更新内容によっては advanced-cache.php との不整合が発生してエラーとなる場合があります。そんな場合は wp-config.php の define (‘WP_CACHE’, true) 定義を消し、FTPツール等で /wp-content 下の advanced-cache.php ファイルを削除すれば解消します

キャッシュの基本設定

YASAKANI Cache は、使用開始や、使用停止が簡単で手軽に行うことができるシンプルな操作を特徴としています

キャッシュ有効化

使い始めるのはとても簡単で、キャッシュの有効期間を選択してページキャッシュを有効化するだけです

キャッシュモードは、シンプルモードとエキスパートモードがあり、エキスパートモードを使えば、さらなる高速化とゼロデイ攻撃の防御が出来るようになります

エキスパートモードについて

エキスパートモードを有効にするには、php.ini や .user.ini ファイルが編集可能である必要があります。手動で auto_prepend_file を記述することで自動的にシンプルモードからエキスパートモードに切り替わります

auto_prepend_file の設定

設定にはひと手間かかるし、サーバー環境によっては使用できない場合もあるのですが php.ini の編集が可能なら指定された auto_prepend_file の設定を追加すると、さらなる高速化とゼロデイ攻撃の防御が出来るようになります

PHP: Description of core php.ini directives – Manual

www.php.net

php.ini の編集ができない場合でも、環境によっては .user.ini や .htaccess ファイルを使って設定できる場合があります

注意： php.ini が編集できる場合でも、複数の WordPress を運用した場合に共通の php.ini が使用されるサーバーでは auto_prepend_file を記述すると不具合が発生しますので、そのような場合には php.ini の代わりに .user.ini を試してみて下さい

CGI/FastCGI SAPI の場合で .user.ini が使える場合

.user.ini ファイルに auto_prepend_file = "設定画面に指定されている yasakani-cache-exload.php" を記述してみて下さい

PHP: .user.ini files – Manual

www.php.net

Apache Module の場合で .htaccess が使える場合

ドキュメントルート下の .htaccess への auto_prepend_file の設定を行える場合があります。

環境によっては許可されていない場合もあるのですが、可能なら編集して試してみてください（許可されていない場合は 500 Internal Server Error 等のエラー）

また、.htaccess への記述は php.ini とちょっと変わり下記のようになります

php_value "auto_prepend_file" "設定画面に指定されている yasakani-cache-exload.php"

Gravatar画像キャッシュ

Gravatar 画像のキャシュファイルを生成して高速化します

投稿や固定ページのコメント等で沢山の Gravatar 画像を使っている場合の高速化が期待できます

キャッシュ有効期間

有効期間は 10分 /１時間 / 4時間 / ８時間 / １日 / ７日　から選択します

ログ機能を使い、実際にどの程度キャッシュにヒットするか確認しながら調節して下さい

Ajax 機能を使用しているプラグイン等をご利用の場合、１日以上のキャッシュ時間を設定するとセキュリティ対策の nonce コードの有効期限切れが起きる可能性がありますので、８時間以下のキャッシュ時間を推奨します。１日以上のキャッシュ時間を設定する場合は問題が起きないか十分に確認してください

キャッシュ対象ページ

ページキャッシュの対象は、ホーム/フロントページ、固定ページ、投稿ページ、カスタム投稿ページとWPの埋め込みブログカードのみです

また、キャッシュ対象のページでも下記条件の場合は除外されます

ログインユーザーに対してキャッシュは表示しません
パスワードで保護されたページはキャッシュしません
PHPエラー（ワーニング以下は除外）が発生した場合はキャッシュしません

除外ページの設定

除外URLフィルター

URLの部分文字列を登録することにより一括してページキャッシュから除外できます。

リクエストURLに登録されている部分文字列、例えば、/forums/、/product/, /cart/, 等含まれるリクエストページをキャッシュ対象から除外します

また、キャッシュ対象外にしたい個別ページがある場合は、その投稿の編集画面に表示されるメタボックスから設定することが出来ます

個別の投稿/ページでキャッシュ除外設定すると一般設定画面側にもリストアップされます

除外ページからキャッシュ対象ページに戻すには、設定画面の除外ページのタイトルリストの 削除リンクをクリックするか、個別の編集画面のメタボックスから解除することが出来ます

モバイル対応について

ページキャッシュは、WordPress コア機能関数の wp_is_mobile を用いてモバイルとPCデバイスを分けて管理しています

キャッシュの停止

停止するのも簡単で、ページキャッシュを無効にするだけです

CSS縮小化とJS非同期ロード

CSS縮小化と JS を非同期ロードすることで高速化します

CSS Minify (Tree Shaking)

登録されたCSSファイル（自サイトの wp-content, wp-includes ディレクトリ下のファイル）を CSS Tree Shaking で縮小して head にインライン埋め込みします
~~WPコアブロックCSS分割ロード機能の停止オプション追加~~ ※Ver3.8.2 で廃止
~~AMPページの場合には amp-custom style を CSS Tree Shaking で縮小化します~~ ※Ver3.7.1 で廃止

CSS Tree Shaking は、CSSデータから使用されていない id、class のスタイル定義を取り除きます

※JavaScript 等でDOMロード後に追加される id や class 用に定義されているCSSまで削除されることがあるので、動作確認を忘れずに行ってください。不具合が出た場合には CSS Tree Shaking の対象から除外するための id や class の名称を登録しておけばその定義は削除されなくなります

JavaScript (defer)

JavaScript ファイルに defer を追加して非同期ロード

CSS縮小化と JS 非同期ロード機能は、お使いのテーマやプラグインによってはエラーとなる場合がありますので、十分確認のうえでご利用下さい

メンテナンス機能

設定データのエクスポート/インポートやキャッシュデータベースのクリア、ハードリセットを行います

エクスポート/インポート

設定データ（一部の設定は除く）を JSON ファイルとしてエクスポート/インポートすることができます

キャッシュクリア

記事の編集や削除に対しては自動的に該当する記事のキャッシュをクリアしますが、プラグインやテーマ、ウィジェット等の設定を変更した時は、メンテナンスモードにあるキャッシュクリアボタンをクリックして下さい

※個別ページのキャッシュクリアは編集画面に表示されるメタボックスからクリアできます

ハードリセット

キャッシュのデータベースに問題が発生する場合があります

データベースのテーブルの一部が壊れた可能性が高く、ほとんどの場合は、データベースの読み出しだけ出来て、書き込みが出来なくなり、キャッシュのクリアボタンも機能しなくなります

データベース動作が異常と思われた場合は、ハードリセット（データベース再生成）を行い回復することができます

※ハードリセットを行うとログや統計情報も初期化されます

ログ機能

YASAKANI Cache の特徴としてアクセスログを生成することが出来ます。ログはアクセス状態の確認やセキュリティ対策等で活用しています。

キャッシュプラグインを有効化したのに何か遅いし効いているかどうかわからないという場合には、ログを使ってアクセス状況やキャッシュの使用有無や実行時間を確認してみてください

ログを無効にしたほうがキャッシュのパフォーマンスはよくなりますが、アクセス毎の数ms より、ログ+統計情報モードを使用して、セキュリティやボットアクセス対策などを行ったほうが、トータルで考えれば不正アクセス対策も出来るのでおススメです

キャッシュ処理が行われた場合は Hit や not_modified が表示されその実行時間が表示されます

キャッシュされない場合は、ログインユーザーのブラウザクッキー（COOKIE)が影響している場合があります。wordpress_logged_in_xxxxxxxxx のようなクッキーが残っているとキャッシュ表示しません

PHPエラー（ワーニング以下は除く）が発生した場合もキャッシュしないようにしています。従って特定のプラグインやテーマでPHPエラーが出るものを使っているとキャッシュされないページが多くなると思われます

エラーが起きたアクセスは Type が php_error と表示されたり、Store (E) のように (E) がついて表示されるので、マウスオーバーするとエラー内容がポップアップ表示されます

また、IPアドレス部をボット（橙色）/通常アクセス（黒）/ログインユーザー（緑）/サーバー（空色）により色分け表示してボットのアクセスなのか判別しやすくしています

※ボット判定はユーザーエージェント内に指定したキーワードがあるか、ブラックリストに登録されているかで判定していますので誤判定する場合もあります

ログフィルター機能

ログは、日時やタイプを指定して簡単に参照することが可能です

７日間＆時間指定　：　調べたい日時を指定してログを参照
タイプ指定　：　ログインや不正アクセス等リクエストの種別を絞り込んで参照
Post ID 　：　投稿や固定ページのポストIDでアクセスを絞り込んで参照
IP指定　：　特定のIPのアクセスを絞り込んで参照
ページング　：　指定条件のログを100件ごとにページ分けして参照

※実行時間は SQLiteデータベースに接続からデータを出力するまでの時間を内部的に測定した時間なので通信時間は含まれていない値です

※ログに記録されるのは、WordPress に渡されてきたリクエストのみです。Webサーバーで処理される画像ファイル等のリクエストに関してはログに保存されません

※データベースには、1日単位に最大7日分のログが保存されています。FTP ツール等を使い yasakani_cache.db をダウンロードして、ローカル環境で SQLite データベースを扱えるツール等を用いて解析することが可能です

ログデータを含むデータベースファイルは、直接アクセス出来ないように Apache サーバー用に .htaccess ファイルで制限しています。但し、Apache 以外のサーバーをお使いの場合は、管理者が wp-content/yasakani-cache/yasakani_cache.db ファイルに直接アクセス出来ないよう対策を行うようお願いいたします

統計情報

ログが有効なら、今日と昨日の統計情報（PV / Bot / 人気記事 / リファラー）を簡単に確認することが出来ます

この統計情報は、サーバーのWordPress サイトへのアクセスを解析している方式で、Google Anaritics のようなトラッキングコードを使ったWebビーコン方式のアクセス解析とはPV数等は一致しません

通常トラッキングコードを使っている場合には、ユーザーがブラウザでアクセスして JavaScript が実行されて特定のサーバーにアクセス情報を収集して解析されるので、ボット等のアクセスでは JavaScript が実行されない為にアクセス情報が収集されずに除外されます

一方、サーバーへのアクセス時点で解析を行おうとすると、正確にボットかユーザーによるブラウザからのアクセスかをその時点で判別する必要があり（ボットによっては通常のブラウザからのアクセスのようにユーザーエージェントを偽装していたりする）、Webビーコン方式よりもPV数が大きめになります

ただし、この方式の良いところは、ボットアクセスに対する制限等をかけられることです

サイトには、びっくりするぐらいのボットが多数アクセスに来ています。このプラグインを使ってご自身のサイトでどの程度ボットアクセスがあるか確認してみて下さい。

統計情報を使うと、簡単に同一IPから多数のリクエストを発行してくるあやしいIPを特定することが出来ます

google や yahoo, bing 等のボットなら問題ありませんが、中には悪質なボットもありますので、このIPからのアクセスを禁止したい場合には、この後で紹介するセキュリティ機能のボットブラックリストに登録することでアクセスを禁止することが出来ます

セキュリティ機能

直接キャッシュ処理とは関係ないですが、セキュリティやボット対策機能等を活用出来ます

ボットキーワード

アクセスログでボットかどうかをユーザーエージェントから判定する為のキーワードを登録します

ユーザーエージェント内にここで登録されている文字（大文字小文字は区別しない）が含まれている場合にボットからのアクセスと判断されます

ボットブラックリスト

WordPress では、robots.txt が設置されていない場合は、自動的に仮想 robots.txt が設置されてボットに admin 領域をアクセスしないように設定されます

但し、悪質なボットは robots.txt では制限できないので、 .htaccess ファイル等で制限されたりしていますが、もっと手軽に制限する為の機能を実装しました

ブロックしたいボットのIPまたはユーザーエージェントに含まれているボットを識別する為の文字列を設定してください（設定文字列や IP は改行で区切ってください）。ここに登録されている条件にマッチするアクセスはブロックされます

ログが有効なら、同一IPアドレスから多くのアクセスがあった IP の一覧リストを表示するので、そのユーザーエージェント等を参考にブロックすべきボットであるか判断してください

一覧リストからはサーバーIP、ログインユーザーIPは除外していますが、念のため 自分のIPアドレスを登録されないようご注意ください

シンプルセキュリティ

不正アクセス対策に簡易セキュリティ機能を使用することが出来ます

ブルートフォース
不正アクセス対策 [ヌルバイト/ディレクトリトラサーバル/コマンドインジェクション等 ]
ゼロデイ攻撃対策（エキスパートモード有効時のみ）
WordPressオプションデータの書き込み保護機能

セキュリティ機能が有効化されていれば、不正アクセスと判定されたIPからのアクセスは自動ブロックします

ブロックされる期間は、日付変わりまでで翌日にはブロックを解除しますので、常時ブロックしたい場合は、対象となるIPをボットブラックリストへ登録してください

不正なアクセスを行うIPをログフィルターに指定すれば、そのIPからどのようなアクセスがあったのか追跡できます

詳細は下記記事を参照してください

YASAKANI Cache に HTTP header キャッシュ機能と簡易セキュリティを追加

ブルートフォース

キャッシュプラグインの機能の一つとしてブルートフォース攻撃によるサイトレスポンスへの影響が最小限になるように実装しています

5回ログインに失敗すると、そのIPからのアクセスは自動的に30分程度ブロックします

また、ブルートフォース攻撃と見なすログインユーザー入力名を登録出来ます。たとえば、ログインを試みるユーザーとして「admin」または「サイト名」がよく使用されるので、それらをコンマで区切って登録するとそのユーザー名によるログインは即座に不正アクセスとみなしブロックされます

※ログインへの制限だけでなくサイトへのアクセスもブロックされます
※ログモードが有効になっている場合のみ機能します

不正アクセス対策

以下のような簡易判定を行っています

クロスサイトスクリプティング

REQUEST_URI データに何らかのタグ <> が含まれている場合は不正アクセスと見なします

スーパーグローバル汚染

_GET, _POST, _COOKIE にスーパーグローバル変数が含まれているものを不正アクセスと見なします

ヌルバイト攻撃

REQUEST_URI データや _POST データに NULL (ゼロ)が含まれているものを不正アクセスと見なします

ディレクトリトラサーバル

REQUEST_URI データや _POST データに ../ 相対アドレスが含まれているものを不正アクセスと見なします

コマンドインジェクション

REQUEST_URI データや _POST データにシェル操作等が可能なPHPのコードが含まれていると疑われる場合に不正アクセスと見なします

コメントや bbPress フォーラムの投稿（＿POSTデータ）に対しては、単純に不正文字が含まれているかどうかだけでは判断できないので、 Akismet プラグイン等によるスパム対策等も併用することを推奨します

ゼロデイ攻撃対策（エキスパートモード有効時のみ）

auto_prepend_file を使って指定されている以外の PHPファイルへのダイレクトアクセスをブロックします

WordPress では、プラグインやテーマの脆弱性のあるPHPへのダイレクトアクセスを通常はブロックすることは出来きません。セキュリティの脆弱なプラグインのPHPファイルをダイレクトアクセスするようなサイト攻撃が日々繰り返されているのが現実です

auto_prepend_file を使うとPHPへのダイレクトアクセスが行われた時にどのPHPがアクセスされたかを調べることが可能になるので、プラグインやテーマ内のPHPファイルをダイレクトにアクセスされた場合に不正なアクセスとしてブロックすることが出来るようになります

但し、wordpress は、通常の運用において wp-login.php や他にもいくつかのダイレクトアクセスが行われるPHPファイルがありますので、それらへのアクセスはブロックしないようにする必要があります

また、ログインユーザーがダッシュボードを表示して管理操作等を行うときには wp-admin 領域にある様々な PHPへもダイレクトアドレスが行われますので、ログインユーザの wp-admin 領域へのダイレクトアクセスは全て許可しています（セキュリティ的には甘くなりますが使い勝手優先）

デフォルトで以下のPHPファイルへのダイレクトアクセスは許可してあります

/index.php
/wp-login.php
/wp-signup.php
/wp-activate.php
/wp-mail.php
/wp-comments-post.php
/wp-trackback.php
/wp-cron.php
/xmlrpc.php
/wp-admin/admin-ajax.php
/wp-admin/load-scripts.php
/wp-admin/load-styles.php

これ以外に、ダイレクトアクセスを許可する PHP ファイルがある場合には、設定画面からホワイトリストへ登録することでアクセスできるようになります

※許可されているPHPファイル以外のダイレクトアクセスはブロックされるようになるので、 WordPress 環境においてはPHPへのゼロデイ攻撃に対しかなり強固になります。

WordPressオプションデータの書き込み保護機能

WordPressアドレス(siteurl) / サイトアドレス(home) / その他オプションの書き込み保護機能です

チェックすると siteurl と home の書き換え（update_option）から保護します
また、他にも保護したいオプションデータがある場合は update_option が実行される時のオプションの名称を登録すればそのオプションも書き換えから保護します

オプション名は実際にそのオプションを更新させたときのYASAKANIのアクセスログから調べるか、WordPressプログラムのソースコードを調べる必要があるので、簡単ではありませんが頑張って調べて下さい m(__)m

また、siteurl や home の書き換えを行う場合は、一時的にこの保護機能を解除してから行う必要があります

オプションデータの siteurl と home データを狙って書き換え他のサイトへ誘導するようなサイト攻撃があります。どのような攻撃で改変されたかは不明な場合も多いのですが、ユーザーの権限で意図しない操作を行うCSRF等が使われている可能性が高いです。
siteurl や home 等の重要なオプションデータはたとえ権限があっても簡単に書き換えられないようにしておくことで（書き換えに２段階の手順が必要にする）セキュリティが強固になります

URLアドレス置き換え機能(ユーティリティ)

サイトアドレスの変更（SSL化を含む）時に、データベース内のサイトURLアドレスの置き換えをせずに手軽に出力するページデータ内のURL置き換えを行う機能です

サイトを SSL 対応すると、過去の投稿記事内で内部リンクや画像に http から始まるURLアドレスが含まれているとミックスドコンテンツエラーが多発します

そこで、SSL化対応の手順として Serch Regex というプラグインを使いデータベース内にある URLアドレスを書き換える方法がよく紹介されているのですが、もっとお手軽な方法として、データベース内のデータを書き換えずにコンテンツを出力するタイミングで内部リンク等のURL置換をする機能です

例えば http://xxxx.com というサイトを https://xxxx.com へ変更する場合は、検索するURLアドレスに http://xxxx.com を設定して、置き換えURLアドレスに https://xxxx.com と設定すれば OK です

コンテンツ出力ごとにURL置換をするのは無駄なのではという疑問もあると思いますが、キャッシュプラグインでは、URL置換したページデータがキャッシュされます。従って、一度URL置換を行ったデータはキャッシュされ、キャッシュの有効期限内は置換済みのキャッシュデータが使われるので、URL置換にかかる負荷は無視できるレベルとなります

ファイル変更の検出と復元

セキュリティ機能ですべての不正アクセスをブロック出来れば問題ないのですが、セキュリティに１００％はありませんので、万一突破されてしまった場合に被害を最小限に抑えて回復させるのに役に立つファイルの変更監視と復元アドオンがご利用できます

ファイル変更検出と復元 File Diff Detect and Restore アドオン。詳細は下記記事を参照して下さい

WordPress Plugin : YASAKANI File Diff Detect and Restore

さらに高速化するには

このプラグインのページキャッシュ処理は、PHPとSQLiteを使って処理しています。効果としては waiting(TTFB)時間の短縮とCSS縮小化、JSファイルの非同期読み込みを指定出来ます

さらに高速化するためのいくつかの方法を紹介します

高速なサーバー環境
ブラウザキャッシュの使用
必要なプラグインのみの使用
画像データの最適化

サーバー環境

基本的なサーバー環境が遅いと高速化は望めません

ポイントとしては、回線容量やCPUコア数、メモリ容量、SSD使用、最新版のPHP使用等を基準に選択すればよろしいと思います

また、共有サーバーのほとんどは Apache サーバーだと思われますが、Nginxサーバーが使えるならさらに高速化できるかもしれません

ブラウザキャッシュ

YASAKANIキャッシュでは、Apache サーバーの .htaccess ファイルに変更は加えていませんので、.htaccess ファイルを編集して mod_deflate、mod_expires 等を活用してブラウザキャッシュやGzip圧縮を使い高速化できます

mod_deflate	HTML, CSS, JS のHTTP通信をGZIP圧縮して転送クライアントは、HTTPリクエストのAccept-Encodingヘッダーでサポートしている圧縮方法を示します Webサーバは、HTTPレスポンスを返す際に、Content-Encodingヘッダーで圧縮した方法を知らせます
mod_expires	ブラウザで取得したコンテンツ（HTML, CSS, JS, 画像データ等）をキャッシュさせ、有効期間を設定するキャッシュさせることで、httpリクエスト数もサイズも減らせることが出来ます

.htaccessの編集を行う場合は十分に調べてから行ってください。また、元の .htaccessファイルをバックアップすることを忘れないでください

プラグイン

WordPressは、プラグインをたくさん使用していると遅くなります

特定のページのみで必要なプラグインを常に有効化しておく必要はありません
Plugin load filter を使うとそのページで必要なプラグインだけを有効にすることが可能です。不必要なプラグインを無効化すれば関連するCSSやJSファイルも読み込まずに済む場合があります

これを活用すると、キャッシュ対象外のページで若干高速化することが出来ます。また、キャッシュするページに対しても無駄なCSSやJSを取り除ける効果があります（不要なJS,CSSを取り除いたHTMLページがキャッシュされる）

画像の最適化

画像データは通信量が大きく増加するので、ページ内で使用している枚数、画像サイズ、圧縮率等の削減を行い遅延ロードを使うことで通信データの削減と通信時間の短縮を行うことが大切です

画像最適化プラグインを使うことで、jpeg/png 画像を簡単に WebPフォーマットに変換して出力して画像データ転送量の削減を行うことができます

詳しくは下記ページを御覧ください

WordPress Plugin : Realtime Image Optimizer

免責事項

本ソフトウェアを使用した事による、いかなる損害も作者は一切の責任を負いませんので、自己責任の上でご使用下さい

コメント機能は停止しました

セルティスラボ製のテーマやプラグインのサポートを行うフォーラムを作成しましたので、質問やコメント等はフォーラムへお願い致します

※フォーラムへ参加するには、無料のメンバー登録　が必要です

※参加する場合は運用ルールと使い方をお読みください

履歴

2024-5-15 Ver3.8.2

WordPress 6.5 確認
PHP8.3 確認
sqlite の操作を pdo_sqlite から sqlite3 モジュールに変更
sqliteのトランザクション処理をWALモードに変更
sqliteデータベースのintegrity_check処理を追加
Ajax(jquery)をfetch(js)に変更
1週間分のログと統計データを閲覧できるように変更
アクセスログ表示の添付データ最大表示サイズ変更
CSS tree shaking アップデート
WPコアブロック用の一括CSS縮小オプションを追加
disable_block_ Separate_css オプション削除
セキュリティ対策及びリファクタリング

2023-8-17 Ver3.7.1

WordPress 6.3 対応
CSS tree shaking アップデート（amp-custom style 対応停止）

2023-3-31 Ver3.7.0

WordPress 6.2 対応
PHP8.2 対応
CSS tree shaking を css nesting 対応にアップデート

2022-7-20 Ver3.6.2

すべてのWPコアブロック（id = wp-block-xxxx）のCSSを縮小し、インライン埋め込みする機能追加（FSEテーマ用）
設定ページのCSSが他の管理ページにも読み込まれていた不具合を修正

2022-6-21 Ver3.6.1

ブロックユーザー登録を追加してブルートフォースに対するセキュリティ強化
CSS/JS 最適化をカスタマイザー等の iframe 内では行わないように変更
その他、軽微な不具合の修正

2022-4-27 Ver3.5.0

File Diff Detect and Restore アドオンサポート機能追加
その他、軽微な不具合の修正

2022-2-10 Ver3.4.0

WordPress3.9, PHP8.1 対応
CSS Tree Shaking セレクタ内の疑似クラス :not :whrer :is :has 内にカンマがあると不具合が起きる場合があったので修正

2021-11-25 Ver3.3.0

画像最適化用アドオンを通常のプラグイン形式に変更したので不要になったコードを整理

2021-9-24 Ver3.2.0

ファイル監視機能をファイル変更監視と差分表示 File Diff Detect アドオンとして分ける

2021-7-26 Ver3.1.0

WordPress5.8 対応
CSS tree shaking – CSS縮小とパフォーマンス機能の向上
アクセスログ機能で詳細ダイアログが表示されない不具合を修正
HTML縮小機能の廃止

2021-2-5 Ver3.0.1

イメージオプティマイザーアドオンのサポート機能追加
大規模なリファクタリング
file_get_contents が使用できないサイト対策として SplFileObject 系の処理へ置き換え
アクセスログのタイプ指定にメール送信（phpmailer）を追加
ハードリセットで使用していた rename 処理は、動作環境によっては失敗する可能性があるため、copy 処理をフォールバックとして使用するよう修正
その他、軽微な不具合の修正

2020-5-20 Ver2.6.1
ハードリセットが機能していなかったバグを修正
ページ単位のキャッシュクリアメタボックスでのSQLエラーを修正

2020-4-8 Ver2.6.0
AMP plugin と併用できないという報告をうけキャッシュ処理のタイミングを変更
CSS最適化を CSS Tree Shaking のみに変更（v2.5.3 の変更もキャンセル）
AMPカスタムスタイルのAMPページを縮小するオプション追加
WordPress Ver5.1 以上へ変更

2020-4-3 Ver2.5.3
WP5.4でfirefox使用時に preload による方法だとチラツキが見られる場合があったので、CSS非同期ロード方法をmediaアトリビュートの書き換え方式へ変更

2020-3-6 Ver2.5.2
CSS Tree Shaking の不具合報告を修正

2020-2-21 Ver2.5.1
キャッシュ除外URLフィルター機能追加
ファイルの変更監視機能の追加
キャッシュの有効期限判定に不具合があり、古いキャッシュが更新されず残ってしまう場合があったので修正

2019-11-29 Ver2.4.1
CSS Tree Shakingで cssセレクターで ‘not’ を使用している定義が削除されてしまうバグを修正

2019-10-9 Ver2.4.0
WordPressアドレス(siteurl) / サイトアドレス(home) / その他オプションの書き込み保護機能追加

2019-7-26 Ver2.3.1
wp-cron 及び REST API リクエストのアクセスログに詳細なデータを追加

2019-7-11 Ver2.3.0
CSS Tree Shaking 機能の追加

2019-5-8 Ver2.2.5
CSS pleload の不具合報告を修正
アクセスログで REST API を識別するのに wp-json だけだったので rest_route も含めるように修正

2019-3-29 Ver2.2.2
Garvatar画像のキャッシュ機能追加、ログへのPost ID 表示追加、コード整理とブラッシュアップ

2018-10-11 Ver2.0.4
JavaScript ファイルの非同期ロード defer から除外するオプション設定追加

2018-8-14 Ver2.0.2
Gutenberg エディタが wp-includes/js/tinymce/wp-tinymce.php にアクセスしてくるので、これをゼロデイ攻撃として扱われないように除外

2018-8-1 Ver2.0.1

キャッシュの保存データを gzip 圧縮してデータサイズの縮小と高速化
CSS,JSファイルの非同期ローディングによる高速化
設定ページのユーザーインターフェースを変更
メインテナンス用機能追加（DB修復ハードリセット、設定値のエクスポート、インポート）
APCu モードの廃止
キャッシュ処理の ob_start の使い方が悪くてテンプレートファイルの global 変数に正しくアクセス出来なかった不具合を修正

2018-5-7 Ver1.4.5
HTML縮小化、小さな CSS, JS ファイルのインライン埋め込み機能追加
キャッシュクリア処理修正、不正なURLリクエストの対策強化

2018-４-11 Ver1.3.2
フォーラムに管理画面の投稿ページが重いという報告への対応

2018-3-30 Ver1.3.1

投稿毎のキャッシュクリアボタン追加
一部プラグインのショートコードが実行されない場合があったのでキャッシュ生成時のフィルターフックの優先度を 99999 へ変更

2018-2-16 Ver1.2.1
ログモードでまれにPHPエラーが発生していたので修正しました

2017-12-28 Ver1.2.0

ログイベントの追加 (サーバー側 HTTPリクエスト、wp-redirect、_FILES等）
ログフィルター機能
- 今日/昨日＆時間指定　：　調べたい時間帯のログを参照
- タイプ指定　：　ログインや不正アクセス等リクエストの種別を絞り込んで参照
- IP指定　：　特定のIPのアクセスを絞り込んで参照
- ページング　：　指定条件のログを100件ごとにページ分けして参照

2017-11-30 Ver1.1.2

エキスパートモード（さらなる高速化とゼロデイ攻撃対策機能）追加
bbPress 使用時のフォーラム、トピック、返信の関連キャッシュ自動クリア処理機能追加

2017-08-02 Ver1.0.0

HTTP header キャッシュ機能追加
不正アクセスに対する簡易セキュリティと自動IPブロック機能追加
ログに _POST データも保存するよう修正

2017-06-20 Ver0.9.8

統計情報モード追加
ログデータ表示をメインサイト限定にして、表示内容も見やすくなるよう修正.

2017-03-28 Ver0.9.6

ボットブロック機能の追加
サイトアドレス変更（SSL化を含む）時用のURLアドレス置換機能の追加
setting テーブルの構成を変更
log テーブルの構成を変更（ログデータを最大１０万件から日単位の過去7日分へ変更）
log テーブルのインデックスが壊れる場合があったので SQlite のジャーナルモードを Memory から PERSIST へ変更

2016-09-12 Ver0.9.1
PHPエラーが発生していたので修正しました

2016-09-09 Ver0.9.0

APC/APCu をSQLiteのクエリーキャッシュに使用するモードを追加（ベータテスト版）

2016-09-02 Ver0.8.3

アクセスログ表示の REQUEST_URI, HTTP_REFERER を urldecode 表示に変更
画像等の添付ファイルステータスの継承（’inherit’）をキャッシュ対象外と判断していたので親の投稿記事のステータスが公開（’publish’）ならキャッシュするように修正
マルチサイト時のサブサイトでキャッシュ無効時の処理が不完全だったので修正

2016-08-23 Ver0.8.2