WordPressの高速化

この記事は約6分で読めます。

実験的サイトなので、高速化のためキャッシュプラグインを当初より導入している。
SQLiteでWordPressを動かしているが、導入によって通常のMySQLを使用したサイトとレスポンスは変わらないか、むしろかなり良いはずだ。

導入による問題はSQLiteはサポート外のため、データーベースの最適化など余計な機能があるとデーターベースを破壊してしまう可能性があることだ。
いくつかのキャッシュプラグインを確認してみたが「WP Super Cache」が一番よさそうだった。メジャーなプラグインで機能がキャッシュに限定されており、ソースを見た限りデータの読み込みだけで書き込みなどは行っていないようで安心だ。

「WP Super Cache」導入に関しては一切トラブルはなかった。何も考えずにプラグインを導入しただけである。導入設定が難しいとのことだったが、わざわざSQLiteで動作させている様な方には特に問題ないレベルだろう。
.htaccessを編集するため、エキスパートモードは初心者は控えた方がよいという事だったが、すでにゴリゴリ編集していたため最初からエキスパートモードで動作させている。
今のところ、トラブルは一切発生していない。エラーログを見てもこのプラグインに関するトラブルはなかったので、SQLiteで動作させているサイトに関しては「WP Super Cache」の導入はお勧めできる。
実際にキャッシュの有り無しで応答速度は半分以下になり、キビキビとしたレスポンスで気持ちがいい。

設定で「ページを圧縮し、訪問者により速くページを供給する」だけは意図的にOFFにしている。相性の問題では無くて、さくらインターネットのWAFを利用するとgzipでの圧縮転送が行えないのだ。WAFをOFFにすればさらに高速表示できるのだが、自分の能力を考えるとONにしておいた方が良いので、セキュリティーを優先することにした。ちなみにONにしても設定が無視されるだけでトラブルにはならない。

新しく記事を投稿した場合はすべてのキャッシュをクリアするようにしているので、キャッシュの再構築が必要だ。キャッシュクリアしないと正しく表示されないページが出てきてしまう。誰かが閲覧すると再度キャッシュが構築される感じだ。
ここで役に立つのは迷惑でしかないクローラー達だ。20～30分に一回は何らかのクローラーがやってくる。比較的新しいページからクロールしてくるので、自動的にキャッシュが再構築されるのだ。分散して再構築されるためサーバーにも優しい。迷惑なクローラーも使い方次第である。
そのためこのサイトを訪れた方は、かなりの確率でキャッシュされたページを見ているはずだ。

そしてCDNの設定だ。さくらインターネットにはコンテンツブーストという手軽にCDN機能が使えるサービスがある。ライトプランでも1か月100GBまでは無料だ。
はっきり言って、このサイトにCDNを使うメリットは全く無い。むしろデメリットの方が大きいと思う。
このサイトは平均して1ページ1.4MBくらいを目安に作成している。100GB転送するとして、ざっくりと1か月70,000ページビューで、1日あたり2,400ページビュー位まで対応可能である。この程度なら何もしなくてもビクともしないはずだ。仮に攻撃対策でCDN導入をした場合、現実的には毎日テラバイト単位の転送量となるため、お小遣いの方が持たない。素直にあきらめるレベルである。
さくらインターネット側もお試しで用意してあるだけだろうし、自分としても全くの個人的興味で設定してあるだけだ。

さくらインターネットによると、「コンテンツブースト」と「WP Super Cache」は大変相性が悪いらしい。マニュアルにもそのような記述がある。しかしながらこのサイトは共存している。
正確には確かに導入当初はコンテンツブーストが効かなかった。原因を調べるために興味本位で色々と設定を変更していたら、いつのまにやらコンテンツブーストの機能が効くようになってしまった。。。
「WP Super Cache」のキャッシュモードの違いかと思って通常モードにもしてみたが、普通にキャッシュできており原因が全く分からない。とりあえず効く分には全くが問題ないし、その方がいいので、そのままにしてある状況だ。
設定によっては使えるという、何とも役に立たない情報で申し訳ない。引き続き調査中だ。

<IfModule mod_headers.c>
    #ブラウザキャッシュ30分とCDNキャッシュ2分
    Header set Cache-Control "max-age=1800,s-maxage=120"

    #1年キャッシュとCDN7日キャッシュ
    <FilesMatch "\.(ico|jpe?g|mp4|mpe?g|png|gif|svg|ttf|webm|webp|avif|pdf|woff|woff2|otf|eot)$">
        Header set Cache-Control "max-age=31536000,s-maxage=604800"
    </FilesMatch>

    #1ヶ月キャッシュとCDN7日キャッシュ
    <FilesMatch "\.(css|js)$">
        Header set Cache-Control "max-age=2592000,s-maxage=604800"
    </FilesMatch>    

    #SiteGuard用 10分のみクライアントだけキャッシュ
    <FilesMatch "\d+\.png">
        Header set Cache-Control "private,max-age=600"
    </FilesMatch>
    
    #CDNに対する圧縮コンテンツの制御
    Header append Vary Accept-Encoding env=!dont-vary
</IfModule>

実際に設定している、「.htaccess」の抜粋。
基本的に動的ページは2分、静的オブジェクトは7日のキャッシュにしてある。実際にCDNを導入してキャッシュのに入ると30%位高速に表示される。

動的ページの2分にあまり根拠はないが、アホみたいに何度もトップページを読み込むクローラーやPC版とスマホ版を同時アクセスしてくるクローラがいるので、その対策である。オリジンサーバには何度アクセスがあっても1回しかアクセスさせていない。
あまりにキャッシュ時間を増やすと色々と問題がありそうな気がしたので、とりえあえずこの時間にしてみた感じだ。例えば長めに1時間とかに設定してもいいが、記事を更新した場合にキャッシュされた旧コンテンツが表示されてしまう。1時間は更新した本人でも確認ができず問題があるため短めにする必要がある。
画像等の静的オブジェクトに関しては一度アップロードしたらほぼ更新が無いため、最大時間の7日にしてある。
CDNの利用によってベンチマーク的には速くなっているが、体感的にはあまり変わらない。
一応、往年の技術である端末側キャッシュ設定も加えているので、そちらの方が効果が高いと思われる。

さくらインターネットのマニュアルで見当たらなかった情報を一つ。
あまりデメリットではないが、IPv6設定をしてもCDNの設定をするとIPv4だけのアクセスに限定されるようだ。IPv6だけのアクセスに限定したい酔狂な方がいれば、注意が必要だ。

ちなみにCDNだが95%以上のキャッシュヒットが目標と言われている。それ以下だと効果が薄い。
先月のキャッシュヒット率は27%だった。やっぱり全く何も役に立っていない。。。
自己満足なだけである。

コメント