tkimura.info

はじめに

WordPressは特に対策をしなければ表示がとても遅いです。そのために、このブログでも何となくキャッシュ系のプラグインを入れたりしていたのですが、せっかくなのでCloudFlareの導入を中心にWordPress高速化に取り組んでみました。

CloudFlareの効果が一番高かったのですが、それ以外にもいくつか対策していることがありますのでご紹介します。

ひと手間加えることで真価を発揮するCloudFlare

導入の前にひと手間加える

「早速、CloudFlareを入れましょう！」と行きたいところですが、事前にひと手間を加えました。

CloudFlareはcss,js,jpgといったファイルをキャッシュしてくれます。そして、CloudFlareがキャッシュするかどうかは、「URLの末尾が拡張子に見えること」が重要なようです。つまり、CSS,JSファイルの後ろに「?ver=」などのようなバージョン番号が付与されているとキャッシュの対象にならないということになってしまいます。

そのために、事前に「?ver=」を非表示にするというひと手間を加えました。

CloudFlareを導入

導入に際しては、こちらの記事を参考にしました。

CloudFlareで爆速的な話は調べてみるとたくさん出てきますが、その中でもあまり語られない、僕のようにサーバーうんぬんに詳しくない人が心に留めておいた方がいいことがあります。

それは、「DNS設定を変更すると反映するまで時間がかかる」ということ。

もう、CloudFlareを導入しようとしている時点で「速く、速く！、速く！！」っていう気持ちになってますからね。基本的なことを忘れたりします。
このブログ場合は、DNS設定後3～4時間後に問題なく表示されるようになりました。（最初はこのことを忘れていて、「あれ、なんかやっちゃったかな！？」と焦りました）

基本のキャッシュ系プラグインも忘れずに

CloudFlareと共にキャッシュ系プラグインも導入しています。キャッシュ系プラグインは最適なプラグインの組み合わせとその設定を探るのに時間がかかりますが、以下のプラグインに落ち着きました。

• Quick Cache＋WP File Cache＋MO Cache＋DB Cache Reloaded Fix＋WP Widget Cache

Quick Cache＋WP File Cache＋MO Cache＋DB Cache Reloaded Fixは、W3 Total Cache＋MO Cacheと同等かと思いますが、W3 Total Cacheは何だか評判が微妙なところもあったので不採用です。今回、実際にインストールしてみたんですが、馴染めなかったというのもありました。また、WP Widget Cacheはウィジェットをキャッシュするプラグインです。

PCとスマホで表示方法を分けている場合はひと手間加える

PCとスマホで表示方法を分けている場合は、何も手を加えないとPC表示でキャッシュされたページがそのままスマホに表示されるという状況が起こります。こちらの記事を参考にQuick Cacheの設定を1ヶ所変えて解決しました。

JavaScriptはHTMLの最後に記述する

基本的な対応ですが、JavaScriptは可能な限りbodyの閉じタグの直前に記述することでページの読み込みを早くしています。ただし、動作に影響がある場合はhead内に記述しておきます。

CSSやJavaScriptを最適化させるHead Cleaner

Head Cleanerは、CSS,JavaScriptの最適化と結合、headタグやフッターの記述を整形してくれるプラグインです。CSS,JavaScriptを最適化、結合させておいてからCloudFlareにキャッシュしてもらっています。

プラグインやスクリプトの動作への影響に注意

CSS,JavaScriptの最適化や結合、JavaScriptのheadからフッターへの移動を行った時には、これまで動作していたプラグインやスクリプトがうまく動作しなくなる場合があります。

この場合、影響を受けているプラグインやスクリプトを特定した後で必要に応じて影響を受けているプラグインを削除したり、CSSやJavaScriptを読み込む位置を変えたり、Head Cleanerの設定のうち一部のチェックを外すといったことが必要になります。

プラグインやスクリプトの動作への影響に注意しながら、CSS,JavaScriptの記述とHead Cleanerの設定とのバランスを探るのがいいでしょう。

キャッシュするファイルの増殖に注意

Head Cleanerが自分のサーバー上にキャッシュする最適化や結合したCSS,JSファイルは自動的に削除されることはありません。作成されたら自分で削除しない限りはそのままです。

ここでの問題は、HTMLの中でCSSやJavaScriptを動的に出力する場合です。
このような場合、Head CleanerがCSSあるいはJSファイルを自分のサーバー上にどんどん生成していきます。これではサーバーを圧迫してしまいますし、その都度キャッシュファイルを生成するのはかえって非効率です。

例えば、アクセス解析プラグインを導入していると、アクセスされたページは何なのかを把握するために、表示されたページごとにそれぞれ異なるJavaScriptをHTMLの中に出力する場合があります。このブログはJetpackのWordPress統計情報を使っており、WordPress統計情報の収集に関するJavaScriptがフッターに出力されます。すると、固定ページ数と投稿記事の数の分だけJSファイルがどんどん蓄積されていきます。

対策としては、「フッタ領域の JavaScript も対象にする」のチェックは外しました。（本当はフッターのJavaScriptも整形したかったのですが、そこまでの解決策は見つかりませんでした）

Head Cleanerを使う場合は、無駄なファイルが増殖していないかどうかを注意した方がいいでしょう。

参考までに

参考までにこのブログのHead Cleanerの設定は次の通りです。

画像の圧縮

このブログではアイキャッチ画像を中心に画像を使っており、画像の圧縮のためにEWWW Image Optimizerというプラグインを導入しました。以前WP Smush.itを使っていましたが、こちらの記事を見てからEWWW Image Optimizerの方に変更しました。

Google AdSenseの非同期化

面倒だったのでコードを変えていなかっただけなのですが、今回の高速化を機に非同期コードに書き換えました。ただし、CloudFlareのロケットローダーは、自動的に非同期的にJavaScriptを読み込みますので、非同期＋非同期でどうなんだろうという疑問は残ります。

ソーシャルボタンは必要最小限に

ソーシャルボタンはとにかく読み込みに時間がかかります。ブログ投稿記事でタイトル下と記事下にそれぞれソーシャルボタンを設置していたのですが、タイトル下のソーシャルボタンは外しました。また、非同期＋非同期でどうなんだろうという疑問が残りますが、一応ソーシャルボタンで読み込むJavaScriptのコードに少し手を加えて非同期で読み込むようにしています。

画像の遅延読み込み

これはどのプラグインを採用しようか迷いました。なぜなら、CloudFlareのロケットローダーがJavaScriptを非同期に読み込んでいることが影響して、アイキャッチ画像がスムーズに表示される場合とそうでない場合とバラツキがあるからです。最終的には遅延読み込みを一部除外する設定ができるBJ Lazy Loadに落ち着きました。

.htaccessの修正

細かいところになりますが、.htaccessを修正しました。参考にした記事はこちら。

この記事で紹介されているコードのうち、コンテンツの圧縮転送と静的ファイルのキャッシュはCloudFlareがやってくれますので、それ以外のコードを頂きました。

以上がWordPress高速化のためにやったことです。

効果はどうなんだ？

ここまでの間でWordPress高速化のために対策を施してきました。次に効果を見ていきます。

サイトスピードはこちらで計測しました。

何回か計測してみて分かったですが、秒数にはブレがありました。そのために、おおよその数値ということになります。

テストしたページ

計測結果

• 改善前：8秒台後半～12秒台前半
• 改善後：1秒台後半～4秒台後半

数値にブレがあるとはいえ、だいぶ改善されました。改善後、一番良かった結果が1秒台後半です。

おわりに

このブログはXREAの無料サーバー（s601サーバー）で運用していますので、決して力のあるサーバーとは言えません。それでも、これだけの数値が出ましたので満足しています。今回WordPress高速化に取り組んでみて、ひとつひとつの積み重ねによって効果が表に出てくるものだということがよくわかりました。

細かいところを見ていくと、「非同期＋非同期はどうなんだ」とか「キャッシュ系プラグインの設定はどうなんだ」とか、それぞれ今後検討していく必要があるかもしれません。当面はこれで様子を見たいと思います。