Google Analytics の「コンテンツ」→「サイトの速度」→「速度の提案」にしたがってサイトの高速化を図ってみました。忘備録です。
目次
画像を最適化する
一番簡単にできるものから取り組みました。テーマ画像である背景画像とアイコンを表示してる CSS Sprites の画像が圧縮できるみたいです。その他の画像はプラグインから自動生成されたり、外部サイトからの読み込みなので対策しようがありません。
Mac で簡単にできる画像圧縮の方法は Mac なら ImageOptim にドラッグ・アンド・ドロップすることです。背景画像の top.png が 140,042 B から 109,198 B へ、 CSS Sprites 画像の icon.png が 9,841 B から 1,456 B へ圧縮できました。
CSS と JavaScript を縮小する
圧縮の前にそもそも使用していない CSS や JavaScript の外部読み込みが発生しないようにしてみました。 WordPress にインストールしているプラグインから CSS や JavaScript の外部ファイルの読み込みタグが発生していました。その度サーバーにリクエストを送っているのかと思うとうんざりしますね。ということでプラグインの機能を使っていないページのヘッダに挿入される JavaScript を表示させないようにしました。
プラグインから挿入される JavaScript はプラグインを編集すれば、表示されなくなるのですが、それではプラグインのアップデートに対応できないので、 function.php にコードを書いて対応しました。
wp_print_scripts をいうアクションフックでヘッダに挿入される JavaScript を制御できるようです。 wp_deregister_script( $handle ); で出力登録されているのを削除できます。 $handle の JavaScript の登録名はプラグインの中身を見るか、出力されたヘッダを見ればわかります。
Easy FancyBox というプラグインの外部ファイル読み込みが多くてびっくりです。これを画像が無いページではヘッダに挿入しないようにします。このサイトの場合は画像がある場合、カスタムフィールドにてアイキャッチ画像を指定しているので、そのカスタムフィールドが空だった場合、 JavaScript を表示しないというようにしました。記事に挿入した画像があるかの条件は他にもいろいろ考えられると思うので適当に変更してください。
→ WordPress で外部サーバーの画像をアイキャッチ画像として表示する
add_action( 'wp_print_scripts', 'my_deregister_script', 999 );
function my_deregister_script() {
$post_id = get_the_ID();
//Easy FancyBox
$first_img = get_post_meta($post_id, 'thumbnail_url', true);
if(empty($first_img)){
wp_deregister_script('jquery-fancybox');
wp_deregister_script('jquery-easing');
wp_deregister_script('jquery-mousewheel');
wp_deregister_script('jquery-metadata');
}
}CSS ファイルに関してはその都度読み込みしたほうがいいのか、それとも 1 つのファイルにしてキャッシュを効かせたほうがいいのか悩むところです。 1 つのファイルにまとめるのには Head Cleaner を使うと便利です。
スクロールせずに見えるコンテンツのレンダリングブロック JavaScript/CSS を排除する
これは Head Cleaner というプラグインで解決しました。スクロールして見えない部分で使われている JavaScript をフッターに持っていくことでページの読み込みとレンダリングを速くするプラグインです。その他、細かい JavaScript/CSS を 1 つのファイルにまとめて改行などを削除してくれたり、キャッシュしたりする機能があります。設定によってはページが表示されなくなるので注意が必要。
圧縮を有効にする
データを gzip で配信すると速くなるよ、ってことです。 gzip で配信するには .htaccess の設定が必要です。
#gzip圧縮有効
<IfModule mod_deflate.c>
SetOutputFilter DEFLATE
BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4\.0[678] no-gzip
BrowserMatch \bMSI[E] !no-gzip !gzip-only-text/html
SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png|ico)$ no-gzip dont-vary
SetEnvIfNoCase Request_URI _\.utxt$ no-gzip
#DeflateCompressionLevel 4
AddOutputFilterByType DEFLATE text/plain
AddOutputFilterByType DEFLATE text/html
AddOutputFilterByType DEFLATE text/xml
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE application/xhtml+xml
AddOutputFilterByType DEFLATE application/xml
AddOutputFilterByType DEFLATE application/rss+xml
AddOutputFilterByType DEFLATE application/atom_xml
AddOutputFilterByType DEFLATE application/x-javascript
AddOutputFilterByType DEFLATE application/x-httpd-php
</IfModule>これだといちいちサーバーで gzip ファイルを作成するので、使っているキャッシュ系のプラグイン WP Super Cache の設定で「ページを圧縮し、訪問者により速くページを供給する。 ( 推奨 ) 」にチェックを入れます。すると、 gzip ファイルもキャッシュしてくれます。
ブラウザのキャッシュを活用する
これはまだ未対策。 .htaccess にキャッシュする期限を設定します。 CSS とかテーマ画像とか変更する可能性の少ないものを長い期間キャッシュするように設定することで、リクエストの回数を減らことが目的です。
.mo ファイルのキャッシュ
これは以前設定したのですが、どこにも書いてなかったので忘れないようにメモ。 WordPress で重いのは .mo ファイルと呼ばれる翻訳ファイルだそうです。英語版をインストールして動かしてみるとびっくりするくらい速いらしいです。なので翻訳ファイルをキャッシュすることでかなり軽くなるとか。
MO Cache と 001 Prime Strategy Translate Accelerator が .mo ファイルをキャッシュしてくれる代表的なプラグインです。 001 Prime Strategy Translate Accelerator は翻訳ファイルを停止するか、キャッシュするのか、キャッシュを使わず通常に翻訳するのかをサイト画面、ログイン画面、管理画面の 3 つで細かく指定できます。コメントなどを受けつないサイトならば、翻訳ファイルを使用しないでテーマを作り、翻訳を停止を設定すればかなり軽くなると思います。（下の画像は設定項目をわかりやすく表示しただけで、実際の設定とは異なります。）
WP Super Cache 設定の見直し
あとこれも忘備録になるのだけれど、 WP Super Cache を使っていたら、先週あたりしばらくトップページが携帯用がキャッシュされてそれが表示されていた模様。ご迷惑をおかけしました。これは携帯用表示プラグインの Ktai Style と WP Super Cache の相性っぽいです。 WP Super Cache では通称サイトと認証されキャッシュするのだけれど、 Ktai Style は携帯でアクセスしてきたと思い、携帯サイトを表示する。なので携帯サイトがキャッシュされてしまい、パソコンからの訪問者にもそれが表示されてしまうのです。
で、サーバーのログを調べた結果、 Ping を一括送信するために利用している PINGOO! というサイトからアクセスが原因であることが判明。記事を更新後キャッシュが生成されていない状態で、最初にアクセスしてきたのが PINGOO! のクローラーだと携帯サイトをキャッシュし、以後それを表示してしまうみたいです。 PINGOO! のクローラー訪問以後、どの端末からトップページにアクセスしても、転送容量が非常に小さく携帯用サイトになっていることがわかりました。ということで WP Super Cache の設定の「除外するユーザーエージェント」に下記を追加しました。
pingoo
PEAR HTTP_RequestPINGOO! のクローラーは上記の 2 つセットでやってくる模様。
以前も同じような状態になったことがあり、その時ちょうど WordPress プラグインのオプションの設定がセキュリティ・ホールになっているというニュースがあり、 WP Super Cache も危ないということだったので、一時期キャッシュを停止していた時期がありました。しかしキャッシュを停止したためページの読み込み速度が遅くなり、それに比例して訪問者も減少していくし、検索順位も下がるしといいことは全然ありませんでした。ページが速く表示されるというのが何よりの SEO 対策なのだと実感した次第です。
それからアクセスがあったときにキャッシュを生成するから、先のような問題が起きてしまうのではないかと思い、先にキャッシュを生成しておくことにしました。 WP Super Cache の「プリロード」という機能でポストやページをキャッシュしておきました。記事の量もそれほど多くないし、更新頻度も少ないので 10080 分（ 1 週間）毎にリフレッシュするようにしてみました。プリロードを行うのは訪問者が少ない夜中から明け方にかけてがよいかと思います。これでキャッシュがない状態でアクセスすることがなくなるので、たぶん表示が早くなっているはずです。
それでどれだけ高速化したか
4 日、 5 日に試行錯誤して設定して、 Google Analytics のページスピードでもここ 2 日は 0.00 秒と記録されています。共用サーバーなので時々負荷がかかることがあってページの表示速度が遅くなってしまうようです。
