WordPressのプラグインである W3 Total Cache、そしてPHPの高速化で使える memcached を絡めた設定を行った記事です。
WordPressサイトでの描画高速化
WordPressサイトの高速化を狙う場合には様々な方法が有ります。
インタプリタ言語であるPHP、更にはバックグラウンドで稼働しているデータベースMariaDB（MySQL）を扱う上では、これらがボトルネックとなってしまうためサイト全体の処理速度に影響してくることは避けられません。
昨今、クラウドインスタンスのスペック的に費用対効果が抜群な感じになってきていることから、長らくそのような事には目を向けずに真剣に考えておりませんでした。
ネットーワーク速度の高速化、SEO対策的な観点から Google の PageSpeed Insights にて状態をチェックしてみると、意外にもパフォーマンスの悪さが明確になるものです。
PageSpeed Insights がその様に表している、というだけで基準を何処に置いたら良いかという考え方も重要ですが、PageSpeed Insights を一般的な基準とすると当WordPressサイトは相応に悪い評価のようです。
W3 Total Cache を導入してみる
WordPressのプラグインとして W3 Total Cache はかなり有名な様ですが、少し前に導入していた Hummingbird から乗り換えることにしてみました。
W3 Total Cache の方が高機能？といいますか、U/I 的に分かりやすいイメージを受けます。この辺りは使う人によって受ける印象は異なるとは思いますが。
細かな設定については他のサイトで立派に解説されているところが多いので割愛いたしますが、私は下記の点で設定に少々難航しました。
W3 Total Cache についてハマったところ
wp-config.php に下記を追加してください、とアドバイス表示されます。
/** Enable W3 Total Cache */
define('WP_CACHE', true); // Added by W3 Total Cache
これについては、上述の Hummingbird でも同様にアドバイス表示されていたために手動で wp-config.php の最下部へ追記していたのですが、これがファイルの後方に記載することが意味がなかったようで、実は高速化は行われていないようでした。
W3 Total Cache でもアドバイス表示されているものの、wp-config.php には手動記載しているままだし、大丈夫だろうなと思っていました。
しかし、高速化されている様子が見受けられないため、今回は wp-config.php のパーミッションを一時的に書き込み可能へ変更し、プラグインの振る舞いを見るためにお任せしました。
そうすると、手動記載した define(‘WP_CACHE’, true); が消されたうえで、W3 Total Cacheプラグインによりwp-config.php の一番先頭に自動追記し直されていました。
あれ？ と思ったものの、その後のキャッシュ動作が成立したようで思っていた以上に高速描画をし始めました。
そもそも、この define(‘WP_CACHE’, true); は ABSPATH の設定前に定義する必要があるようで、wp-config.php の先頭に記載されたのはそのためのようです。
したがって、Hummingbird もどうやら動作していなかった、というのがオチだということになりそうです。
memcachedを有効化
PHPの高速化をするために有名な対処方法の一つですが、memcachedの利用が出来るようです。
パフォーマンスの一般設定では、ページキャッシュ、またデータベースキャッシュ、オブジェクトキャッシュ、そのそれぞれでキャッシュ方法が設定できます。
「ディスク」また「Memcached」が有効な選択方法として表示されていました。
気分的にも、Memcachedを選択したくなるのは誰でも同じかと思います。
Memcachedを選択、設定をして保存すると、下記のエラー表示がされました。
The following memcached servers are not responding or not running:
127.0.0.1:11211 からの応答がないかmemcachedが動作していない、というエラーです。
本GCPインスタンスは、Bitnamiソリューション を用いて構築しているため、細かいことは調べる事になります。
php.ini の設定内容を見てみると、extention の記述があり使える状態になっているようでした。
extension = memcached
しかし、前回行った WordPress インスタンス移行 で用いた Bitnamiソリューション においては memcachedのパッケージがインストールされていませんでした。
ただし、ソリューションの特定バージョンですので、将来的には組み込まれたものがリリースされる可能性も有ります。
memcached をコマンドからインストールします。
apt-get install memcached
インストールするのみで、自動的に起動するようです。
# systemctl status memcached
● memcached.service - memcached daemon
Loaded: loaded (/lib/systemd/system/memcached.service; enabled; vendor preset: enabled)
Active: active (running) since Tue 2022-11-15 11:55:37 JST; 1s ago
Docs: man:memcached(1)
Main PID: 141540 (memcached)
Tasks: 10 (limit: 4697)
Memory: 3.1M
CPU: 21ms
CGroup: /system.slice/memcached.service
└─141540 /usr/bin/memcached -m 64 -p 11211 -u memcache -l 127.0.0.1 -P /var/run/memcached/memcached.pid
その昔に memcachedを扱ったときには、ソースコードからのビルド、そして設定がややこしかった記憶がありますが、本環境では素直に動作しました。
下記の動画が参考になりました。
memcachedのインストールによって、先程表示されていたエラー表示もなくなり、描画速度が「爆速」と言うに値するかはさておき、以前の状態と比べても体感的にかなりの高速化を行えている状態となりました。
W3 Total Cache の圧縮設定
使っているWordPressテーマとの相性が良くないようで、W3 Total Cache の圧縮設定を行うと、サイトが壮大に崩れる状態となってしまいます。
これを調査対応している余裕がないこともありますが、高速化に関しての影響は小さいと思われるため、とりあえずは設定を外しておくことにしました。
nginx の設定
アドバイス表示に下記の設定をnginxに設定するように出てきます。
しかし当環境では設定してみたものの、なにやらまたサイトが壮大に崩れる状態になったため、設定適用を外しました。
# BEGIN W3TC Page Cache core
set $w3tc_rewrite 1;
if ($request_method = POST) {
set $w3tc_rewrite 0;
}
if ($query_string != "") {
set $w3tc_rewrite 0;
}
set $w3tc_slash "";
if ($request_uri ~ \/$) {
set $w3tc_slash _slash;
}
if ($http_cookie ~* "(comment_author|wp\-postpass|w3tc_logged_out|wordpress_logged_in|wptouch_switch_toggle)") {
set $w3tc_rewrite 0;
}
set $w3tc_preview "";
if ($http_cookie ~* "(w3tc_preview)") {
set $w3tc_preview _preview;
}
set $w3tc_ssl "";
if ($scheme = https) {
set $w3tc_ssl _ssl;
}
if ($http_x_forwarded_proto = 'https') {
set $w3tc_ssl _ssl;
}
set $w3tc_enc "";
if ($http_accept_encoding ~ gzip) {
set $w3tc_enc _gzip;
}
set $w3tc_ext "";
if (-f "$document_root/wp-content/cache/page_enhanced/$http_host/$request_uri/_index$w3tc_slash$w3tc_ssl$w3tc_preview.html$w3tc_enc") {
set $w3tc_ext .html;
}
if (-f "$document_root/wp-content/cache/page_enhanced/$http_host/$request_uri/_index$w3tc_slash$w3tc_ssl$w3tc_preview.xml$w3tc_enc") {
set $w3tc_ext .xml;
}
if ($w3tc_ext = "") {
set $w3tc_rewrite 0;
}
if ($w3tc_rewrite = 1) {
rewrite .* "/wp-content/cache/page_enhanced/$http_host/$request_uri/_index$w3tc_slash$w3tc_ssl$w3tc_preview$w3tc_ext$w3tc_enc" last;
}
# END W3TC Page Cache core
Bitnamiソリューションのnginx設定と何かしらが干渉している可能性もありますが、こちらも設定を施さずにおくことにいたしました。
部分的な弊害
こっちを引けばあっちが持ち上がるという状態は Post Views Counter の導入の際も同様でしたが常に出てきます。
W3 Total Cache ではURLハッシュが適切に効かなくなっているいう症状が出ていました。
これはキャッシュされている内容を適切にイジれば改善しそうですが、キャッシュするということは何らかの弊害が有ることは許容した方が精神的にも良さそうです。
実際のところ、Post Views Counter の値については、ブログリストと記事単体とのカウント値に差異が出ていることも。
WordPressはサイトの構成によりますが投稿などによって内容が常に変化していくことは必須であるため、この辺りのバランスを見ての運用、キャッシュ削除などの定期対応が求められるかもしれません。
記事の新規投稿、サイトの内容を変更した場合にキャッシュ削除を行う必要があるかは、ページキャッシュのポリシーの設定、有効期間の設定などを調整して対応する必要が有りそうです。
総括
W3 Total Cache では、キャッシュ設定も色々と便利になっている印象を受けました。
設定変更や環境特有の症状への対応なども比較的スムーズに行なえ、これはWordPressサイト運営では使ったほうが良いと思えるものです。
サイト構成内容にもよりますが、WordPressを素のまま使っているような場合にはかなり有効な高速化対応手段となりそうですね。
他の運用サイトに適用すべきか、提案などを含め諸々検討していきたいと思います。
その後
W3 Total Cache の圧縮設定
見直しをかけて「圧縮モード」を「手動」に設定してみました。
設定を変えて試していると、どうも「Minify engine settings」で改行を除去してしまうことで問題が発生している様子のため、これらを無効にしました。
テーマが提供しているJSの一部がこの圧縮設定によって破損するようなのですが、使っているテーマによってはこの辺りを調整することで圧縮設定も使った方が良さそうですね。
今回はこの「改行除去」を無効にすることで回避。
nginxの設定
上記の設定（Page Cache）とは別に、/opt/bitnami/wordpress/nginx.conf として、W3 Total Cache によって自動的に書き出された設定（Browser Cache）が有りました。
これを includeさせました。ファイルの拡張子別にキャッシュコントロールをするもののようです。
# BEGIN W3TC Browser Cache
gzip on;
gzip_types text/css text/x-component application/x-javascript application/javascript text/javascript text/x-js text/richtext text/plain text/xsd text/xsl text/xml image/bmp application/java application/msword application/vnd.ms-fontobject application/x-msdownload image/x-icon application/json application/vnd.ms-access video/webm application/vnd.ms-project application/x-font-otf application/vnd.ms-opentype application/vnd.oasis.opendocument.database application/vnd.oasis.opendocument.chart application/vnd.oasis.opendocument.formula application/vnd.oasis.opendocument.graphics application/vnd.oasis.opendocument.spreadsheet application/vnd.oasis.opendocument.text audio/ogg application/pdf application/vnd.ms-powerpoint image/svg+xml application/x-shockwave-flash image/tiff application/x-font-ttf audio/wav application/vnd.ms-write application/font-woff application/font-woff2 application/vnd.ms-excel;
location ~ \.(css|htc|less|js|js2|js3|js4)$ {
expires 31536000s;
etag on;
if_modified_since exact;
add_header Pragma "public";
add_header Cache-Control "public";
add_header Referrer-Policy "no-referrer-when-downgrade";
try_files $uri $uri/ /index.php?$args;
}
location ~ \.(html|htm|rtf|rtx|txt|xsd|xsl|xml)$ {
expires 3600s;
etag on;
if_modified_since exact;
add_header Pragma "public";
add_header Cache-Control "public";
add_header Referrer-Policy "no-referrer-when-downgrade";
try_files $uri $uri/ /index.php?$args;
}
location ~ \.(asf|asx|wax|wmv|wmx|avi|avif|avifs|bmp|class|divx|doc|docx|exe|gif|gz|gzip|ico|jpg|jpeg|jpe|webp|json|mdb|mid|midi|mov|qt|mp3|m4a|mp4|m4v|mpeg|mpg|mpe|webm|mpp|_otf|odb|odc|odf|odg|odp|ods|odt|ogg|ogv|pdf|png|pot|pps|ppt|pptx|ra|ram|svg|svgz|swf|tar|tif|tiff|_ttf|wav|wma|wri|xla|xls|xlsx|xlt|xlw|zip)$ {
expires 31536000s;
etag on;
if_modified_since exact;
add_header Pragma "public";
add_header Cache-Control "public";
add_header Referrer-Policy "no-referrer-when-downgrade";
location ~* ^(?<path>.+)\.(jpe?g|png|gif)$ {
if ( $http_accept !~* "webp|\*/\*" ) {
break;
}
expires 31536000s;
etag on;
if_modified_since exact;
add_header Pragma "public";
add_header Cache-Control "public";
add_header Referrer-Policy "no-referrer-when-downgrade";
add_header Vary Accept;
try_files ${path}.webp $uri /index.php?$args;
}
try_files $uri $uri/ /index.php?$args;
}
add_header Referrer-Policy "no-referrer-when-downgrade";
# END W3TC Browser Cache
記事の内容が古くなっているものもあり、適宜アップデートされる場合がございます。