プラグイン5つの導入などでWordPressの表示が大幅に高速化しました(2015年12月追記あり)

先日、ブログデザインのリニューアルが終わったので、手付かずだったブログ表示の高速化に挑戦してみました。

これまでサーバーを移転(シックスコアへ)する位しかしていなかったのですが、ある5つのプラグインを導入するだけで大幅な高速化が実現できたので記事にしてみました。

*2014年5月30日に公開した記事ですが、2015年12月28日に再び高速化を図ったときのことを追記しています。
*同日、外部リンク先のページ名・URL変更に伴い、文章を一部リライトしています。

スポンサーリンク

このブログ、重すぎ…?

まず現状を把握するためにPageSpeed InsightsGtmetrixで表示速度を測ってみました。

計測したのはトップページと郵便物転送サービス、期間延長出来るって知ってました?
という記事のページ。後者に関しては、このブログで最も読まれている記事であること、そして最もページ容量が大きいことから採用しました。(投稿日時点)

それでは早速PageSpeed Insightsによる計測結果を見てみましょう。次の画像はトップページの結果となります。

PageSpeed Insightsトップページの結果

モバイル環境が66/100点、PC環境が78/100点でした。

続いて郵便物転送サービス、期間延長出来るって知ってました?の結果がこちら。

PageSpeed Insights郵便物転送サービス記事の結果

モバイル環境が58/100点、PC環境が68/100点とトップページよりも悪い結果に。画像をたくさん貼っているページなので重いとは思ったのですが、かなりひどいですね…。

ため息もほどほどに、とりあえずGtmetrixでの結果も見てみましょうか。

まずトップページですが、Page Speed Gradeが66/100%でDランク、Y Slow Gradeが72/100%でCランクでした。

Gtmetrixトップページの結果

続いて郵便物転送サービス、期間延長出来るって知ってました?の結果です。

gtmetrix郵便物転送サービス記事の結果

Page Speed Gradeが49/100%でFランク、Y Slow Gradeが67/100%でDランクでした。

思わず両手で顔を覆ってしまいたくなるレベル。早くなんとかせねば…というわけで次から実際に導入したプラグインについて書いていきたいと思います。

JavaScript/CSS関係

PageSpeed Insightsは、スコアの他に読み込み時間短縮のための方法を教えてくれるのですが、当ブログへの指摘事項の一部として次のようなものがありました。

  • スクロールせずに見えるコンテンツのレンダリングブロック JavaScript/CSS を排除する
  • JavaScript を縮小する
  • CSS を縮小する

2番目と3番目はまだしも、素人な僕には1番目が何を言っているのか分からなかったので調べてみました。どうやらヘッダーにあるJavaScriptがページの表示を妨げているようで、フッターに移動させるのが良いとのことでした。

1. Head Cleaner

JavaScriptをフッターに移動させるだけであれば他のプラグインを使用したり、あるいはプラグインなしでも対応出来たりするようですが、CSSやJavaScriptの縮小もやってくれるという点に惹かれ、Head Cleanerを導入することにしました。

このHead Cleanerに関しては、他のプラグインなどとの相性があるようで、導入後にページが真っ白になってしまったという報告も結構見かけたので注意です。

さて、導入後の設定ですが、今回は「バズ部」さんのHead Cleaner の最も理想的な設定方法を参考にしました。

「バズ部」さんで紹介されているのとほぼ同じ設定なのですが、当ブログでは「フッタ領域の JavaScript も対象にする」にはチェックを入れていません。ここにチェックを入れるとレイアウトがかなり崩れ、表示されない要素も出てきてしまったためです。

したがって、当ブログの設定はこんな感じになっています。

head cleanerの設定画面

これ以外にも設定画面で<有効なフィルタ>という項目があるのですが、他のプラグインとの兼ね合いで一部”対象外”にしています。

ちょっと設定に手こずりましたが、以前に比べるとヘッダーがかなり綺麗になったので、個人的には導入して正解だったと思います。

2. Async JS and CSS

Head Cleanerによる設定を終え、PageSpeed Insightsを試したところ、JavaScriptのブロッキングリソースは0になっていました。

続いてCSSのブロッキングリソースの数を減らすために導入したのがAsync JS and CSSです。

このプラグインにしたのは、上記リンク先の説明文から「PageSpeed Insightsで”レンダリングブロック JavaScript/CSS を排除する”が表示されるときに良いですよ」的なことが読みとれたためです。

インストール後の設定はほぼデフォルト状態。

Async JS and CSSの設定画面

<Load CSS asynchronously>にチェックしただけです。ここをチェックするとその下の<CSS loading method>と<Minify CSS>も自動でチェックされました。<CSS loading method>の項目に関してはそれぞれ試してみたのですが、表示が崩れたので結局デフォルトのものにしました。

この設定によって、CSSのブロッキングリソースは何もしない状態の”9″から”1″へと減少させることが出来ました。ちなみに、この”1″は先に紹介したHead CleanerのCSSです。

画像関係

PageSpeed Insightsによる指摘事項には、次のようなものもありました。

  • 画像を最適化する

これは自覚ありました。完全に目を逸らしていました。すいませんでした。戦わなきゃ現実と、というわけで次の2つのプラグインを導入することにしました。

1. EWWW Image Optimizer

EWWW Image Optimizerはサーバー上の画像を圧縮してくれるプラグインです。色々と設定出来るようですが、「バズ部」さんのEWWW Image Optimizer の設定方法と使い方という記事に詳しい解説があったので、その設定方法と全く同じようにしてみました。

デフォルトの設定から<Optimization Settings>の「Remove metadata」と<Conversion Settings>の「Hide Conversion Links」にチェックを入れただけ。とても簡単です。

さて、肝心の画像圧縮ですが、ワードプレスの左メニュー・メディア内のBulk Optimizeから行うことが出来ます。

ダッシュボード・メディア内のBulk Optimize

まず上のような画像が出てくるので、「import images」 をクリックします。その後、ページを更新すると次のような項目が出現します。

EWWW Image Optimizerの画像圧縮画面

今回はメディアライブラリ内の画像を圧縮したいと思ったので、<Optimize Media Library>の「Start Optimizing」をクリックしました。画像の圧縮が開始され、しばらく経ってから”Finished”という文字の表示がされました。

僕は実施しませんでしたが、もしテーマにデフォルトで使用されている画像など(メディアライブラリー外にある画像)を圧縮したいという時は、<Optimize Everything Else>の「Scan and optimize」をクリックすればOKとのことです。

なお、このプラグインの導入以降に画像をアップロードすると自動で圧縮されるようになります。また、今回は一括で圧縮しましたが、メディアライブラリから個別に圧縮することも可能です。

2. Unveil Lazy Load

続いて導入したのがUnveil Lazy Loadという画像遅延読み込みプラグイン。

普通はページを読み込む際に一気に画像データも読み込むのですが、これはスクロールして画像が表示される領域に入った段階で初めて画像を読み込むという仕組みになっているようです。

画像遅延読み込みプラグインで有名なものにLazy Loadといったものなどがありますが、より表示時間の短縮にこだわって作成されたのがUnveil Lazy Loadであるとのこと。

詳しいことは分からないのですが、画像遅延読み込み実現のためにlazyload.jsよりも軽いUnveil.jsを採用することなどで表示時間の短縮を図っているようです。

利用方法はとても簡単で、インストールして有効化するだけです。これで効果が得られます。

キャッシュ関係

最後にキャッシュ関係のプラグイン。これもやはりPageSpeed Insightsの以下のような指摘を受けてのことです。

  • ブラウザのキャッシュを活用する

これまでその重要性は分かっていたのですが、とてもややこしそうに感じてしまい、プラグインのインストールだけして何も設定していませんでした。だめだめでした。

W3 Total Cache

そのインストールしていたプラグインというのがW3 Total Cache。とても有名で人気なプラグインですが、設定出来る項目が多く、素人な僕にはどうすればいいのかさっぱりだったのです。

しかし、またしても「バズ部」さんがW3 Total Cache のおすすめの設定方法という記事で解説されていたので、それを参考に設定してみました。

なお、僕はページキャッシュとブラウザキャッシュだけを設定・有効化しています。当ブログは共有サーバーで運営しているのですが、オブジェクトキャッシュなどは逆に負荷が大きくなる場合があると聞いたためです。

さて、実際のページ/ブラウザキャッシュですが、変にいじって不具合が生じるのも嫌なので、バズ部さんが紹介しているのとまるっきり同じ設定にしています(当記事投稿時)。

このプラグインの効果は絶大で、PageSpeed Insightsではモバイル/パソコン共に10点近くアップしました。今のところ目立った不具合は見られないので、しばらくはこの設定でいこうかと思います。

プラグインを導入した結果

ここまで今回導入した5つのプラグインを紹介してきましたが、ここでその結果に触れたいと思います。

1. PageSpeed Insights

まず、PageSpeed Insightsによるトップページの計測結果から。

プラグイン導入後のトップページのモバイル結果

プラグイン導入後のトップページのPC結果

このようにモバイル環境が66点→85点、PC環境が78点→93点とスコアが大きく上昇しました。

次に郵便物転送サービス、期間延長出来るって知ってました?の結果です。

プラグイン導入後の郵便物転送サービス記事のモバイル結果

プラグイン導入後の郵便物転送サービス記事のPC結果

このようにモバイル環境が58点→82点、PC環境が68点→91点とスコアが大幅に改善されました。トップページも読み込み速度がアップしましたが、こちらはそれ以上です。まさか25点近く上がるとは思いもしませんでした。

“修正を考慮”という項目は何個かあるものの、外部スクリプト(ソーシャルボタン絡みが主)の指摘がほとんどです。ツイートボタンやいいね!ボタンを外せばもう少しスコアを伸ばせそうですが、外さずに置いておくメリットの方が大きいと思うので、とりあえずはこれでよしとします。

2. Gtmetrix

続いてGtmetrixの測定結果です。まずトップページの結果から。

プラグイン導入後のGtmetrixトップページの結果

プラグイン導入の結果、Page Speed Gradeが66%(D)→90%(A)、Y Slow Gradeが72%(C)→79%(C)となりました。後者はそこまでではないものの、前者はいい感じに改善しました。

また、画像右下にあるTotal page sizeは1.59MB→730KBと半分以下に縮小し、Page load timeは5.10s→3.15sと約2秒も縮まりました。

では、郵便物転送サービス、期間延長出来るって知ってました?の結果はどうでしょうか。

プラグイン導入後のGtmetrix郵便物転送サービスページの結果

こちらはPage Speed Gradeが49%(F)→91%(A)、Y Slow Gradeが67%(D)→72%(C)となり、Page Speed Gradeがかなりいい感じに改善されました(元が酷すぎるというのはありますが)。

また、Total page sizeは4.48MB→759KBと約1/6に縮小し、Page load timeは7.04s→3.38sと3秒以上縮まりました。このページは画像を多く使っていたので、画像関係のプラグインとして導入したEWWW Image Optimizerがかなり効いたのではないかと思われます。

なお、Y Slow Gradeはあまり良い成績ではありませんが、CDN(Contents Delivery Network)を利用すれば大きな改善が期待できそうです。

無料CDNとして有名なCloudFlareを使っている方々のブログを見たのですが、絶大な効果を実感している方がたくさんいました(もちろん全員ではありませんが)。正直なところ、僕が今回導入したどのプラグインよりも効果があるのではないかと思えるほど高速化に成功していました。

しかし、今回僕はCDNを利用しないことにしました。CloudFlareは不具合が多いという意見が結構あったことや、プラグインだけである程度の高速化が実現出来たためです。

また、無料CDNとして「Jetpack」というプラグインの中のPhotonを試したのですが、このブログではあまり効果を感じられなかったほか、表示が崩れることもあった(他のプラグインとの相性が悪かった?)ので利用を見送りました。

おわりに

とても長くなってしまいましたが、そろそろ終わりたいと思います。

今回は「Head Cleaner」「Async JS and CSS」「EWWW Image Optimizer」「Unveil Lazy Load」「W3 Total Cache」という5つのプラグインを利用することでブログの高速化に成功しました。

しかし、まだまだ改善の余地はあると思うので、今後も継続的に高速化を図っていきたいと思います。ただ僕は新たなプラグインを入れてみたりとブログをいじるのが好きなので、逆に遅くなってしまうこともあるかもしれません。スコアが悪くなっていたらどっかいじったんだなと思ってやってください。

これは余談ですが、W3 Total Cache、EWWW Image Optimizer、Head Cleaner、Unveil Lazy Load、Async JS and CSSの順に効果があったかなと感じました。もちろんこれは当ブログの環境における個人的な印象であり、プラグインそれ自体の優劣を表しているわけでもありません。

この記事がワードプレスの高速化を考えている方の参考になれば幸いですが、紹介したプラグインの中には環境によって不具合が生じるものもあるため、利用するかどうかは慎重にご検討下さい。また、実際に導入する際にもあらかじめバックアップを取っておいた方が安心かもしれません。

それでは、最後までお付き合いいただきありがとうございました。

2015年12月追記

状況

最近スコアを計測してみたところ、PageSpeed Insightsにおけるモバイル・PC環境のスコアが40点前後まで落ち込んでいました。およそ4-50点のダウンです。(ただしGtmetrixはあまり変わらず)

この記事を書いてから1年半以上が経過し、当ブログの環境が変わったことが一因にあるでしょう。具体的には、ワードプレステーマを変更したり、Head CleanerやAsync JS and CSSを無効化したりしました。(運用サーバーはシックスコアで変わらず)

また、PageSpeed Insightsそのものの仕様変更があった可能性も否定できません。

PageSpeed Insights は継続的に改良されているため、新しいルールの追加や分析の改良に伴ってスコアが変わることがあります。

https://developers.google.com/speed/docs/insights/about

……前置きが長くなるのもアレなので、指摘された次の項目を改善するために何をしたか紹介していきますね。その都度記録をとっていたわけではないので抜けがあるかもしれませんが、覚えているもの全て紹介します。

  • サーバーの応答時間を短縮する
  • CSSを縮小する
  • スクロールせずに見えるコンテンツのレンダリングをブロックしている JavaScript/CSS を排除する
  • 画像を最適化する

PHPのバージョンアップ

これまでPHP5.3.3を利用していたのですが、使用しているサーバーで「非推奨」となっていたため、PHP5.6へとバージョンアップしました。なんでもシックスコアでは5.6にすると「FastCGI」と「OPcache」が標準で有効化されるとのこと。

そのおかげなのか、毎回1,500ミリ秒以上かかっていたサーバーの応答時間が300-500ミリ秒程度に改善され、PageSpeed Insightsの「サーバーの応答時間を短縮する」という警告が表示されなくなりました。

CSSを縮小

約160KBあったCSSファイルの容量を約半分にしました。

まず、無駄な記述(ページの描写に使われていない箇所)を消すことで約120KBに。さらに、PageSpeed Insightsの結果画面から「このページ向けに最適化されたCSSリソース」をダウンロードして約80KBに。

このファイルをサーバーにアップして読み込むことにした結果、「CSS を縮小する」の警告が消えました。

Script要素をまとめて非同期化

こちらの記事で紹介されているコードをfunctions.phpに記述。Script要素にasync属性が付与され、非同期化が実現しました。

当ブログでは「Crayon Syntax Highliter」というプラグインのスクリプトがうまく実行されなくなりましたが、記事で言及されている通り、該当するスクリプトを除外する(async属性を付与しないようにする)ことで解決しました。

Google Fontsをサーバーにアップして利用

ブログタイトルにロゴ画像ではなくGoogleフォントを利用しているのですが、これもレンダリングブロックの要因となっていました。head内でこのように読み込んでいたためです。

<link href='http://fonts.googleapis.com/css?family=フォント名' rel='stylesheet' type='text/css'>

何か解決策はないかと調べていると、ダウンロード後サーバーにアップして使えば良いという単純なことに気付きました。

こちらの記事を参考にフォントのサブセット化(指定した文字だけを抜き出したフォントファイルの作成)を行い、サーバーにアップして利用可能な形にしました。

CSSは一応こんな感じに記述しています。

@font-face {
  font-family: 'obolog-font';
  src: url('./fonts/obolog-font.eot'); /* IE9 Compat Modes */
  src: url('./fonts/obolog-font.eot?#iefix') format('embedded-opentype'), /* IE6-IE8 */
       url('./fonts/obolog-font.woff') format('woff'), /* Modern Browsers */
       url('./fonts/obolog-font.ttf')  format('truetype'), /* Safari, Android, iOS */
       url('./fonts/obolog-font.svg#svgFontName') format('svg'); /* Legacy iOS */
}

Google Fontsのレンダリングブロックが解消し、サブセット化で読み込むサイズも小さくなり(約10分の1)、フォントライセンスの勉強にもなって良いこと尽くめでした。

アイキャッチ画像にsrcset属性を

当ブログでは、トップページ、アーカイブページ、個別記事ページ、サイドバーの新着記事・人気記事にアイキャッチ画像を表示させています。それらはRetina対応のため、2倍の大きさの画像を半分のサイズに指定していました。

しかし、そのやり方だとPageSpeed Insights的にはマズいようで、「画像を最適化する」という警告が表示されてしまいました。

この記事を書いた当時は半分の大きさに指定するやり方でも問題なかったんですけどね。仕様が変わったのかもしれません。

で、対策としてはJavaScriptやjQueryを使うやり方も考えたのですが、ちょっと僕には難しそうでした。画像名に@2xがついていることが前提だったりしたので。

そこで考えたのがsrcset属性です。対応していないブラウザでもsrcで指定した画像は読み込んでくれますし、そもそも当ブログは画像を売りにしているわけではなく、またアイキャッチ画像のみに適用するといった点から採用を決定しました。

phpファイルに記述するコードは、次の記事を参考にしました。

そして、htmlコードとしては次のように出力されています。

//サイドバーにおける新着記事一覧のアイキャッチ画像
//見やすくするため途中改行を入れています
<img src="(省略)/201512-linemalleye4-100x90.jpg"
 srcset="(省略)/201512-linemalleye4-200x180.jpg 2x"
 width="100" height="90">

<デバイスピクセル比が1より大きいディスプレイ>で<srcset対応ブラウザ>だった時には「200×180(px)」の画像が表示され、そうでない時には「100×90(px)」の画像が表示されるようになりました。

この状態でPageSpeed Insightsにて計測したところ、「画像を最適化する」における修正対象画像数が一気に減りました。2015年12月28日現在、グーグルアドセンスの広告画像のみが対象となるまでに改善しています。

なお、この対処法は「とりあえず」としてのものです。

サイドバーの新着記事や人気記事のアイキャッチ画像は、画面幅によらず常に一定のサイズで表示させています。そのため、devicepixelratioのみで画像を出し分けるのは理に適っていると言えるでしょう。

しかし、トップページ等の記事一覧や個別記事ページの本文上のアイキャッチ画像は、画面幅によって表示サイズも異なってきます。そのため、devicepixelratioではなくsizes属性で出し分けた方が良いのかもしれません。

ただ、sizes属性についてはまだ理解出来ていないので、とりあえずすべてのアイキャッチ画像をdevicepixelratioで出し分けることにしています。

スコア上昇に挑んだ結果

さて、今回は40点前後まで落ち込んだPageSpeed Insightsのスコアを改善すべく、プラグイン以外にも様々な対策をとりました。

最後にその結果を見てみましょう。
まずは、トップページの測定結果です。

モバイルが89点、パソコンが90点とスコアが大幅に改善しました。

続いて、記事内で測定対象としていた郵便物転送サービスに関する記事の結果です。

モバイルが89点、パソコンが95点とこちらもスコアが大幅に改善しました。アドセンスを3つ貼ってこの点数は良い感じではないでしょうか。

さらに高得点を目指すには、Abobe the foldのコンテンツを描写するためのCSSをインライン化したり、htmlを縮小したり、アドセンス広告を全部外したりする必要がありますが、そこまでしなくていいかなと考えています。

レスポンシブデザインにおいてクリティカルCSSをインライン化するのは単純に面倒ですし、htmlの縮小もプラグイン導入で可能なようですが、当ブログの場合は1キロバイト未満の削減にしかならないようで、「それだけのために?」と思ってしまいます。

既にグーグルのトップページに近いスコアになっていますし、現にスマホの3G回線で閲覧してもそれほどストレスは感じないので、高速化に関しては「この辺で満足かな」といったところです。

もちろん、またスコアが大幅に低下したら対策を考えますが、それまではコンテンツの充実の方に力を入れたいと思います。