WordPress Celtis-one テーマのパフォーマンスを測定してみる

サイトの表示スピードってやっぱり気になりますよね

WordPress を高速化するにはどうしたら良いのか検索してみると、キャッシュ系のプラグインとCDN(CloudFlare)をお勧めしている記事がけっこうありました

でもキャッシュ系のプラグインってトラブルも多いようですし、無料のCDNっていうのもどうなんでしょうか、なんとなく気が進みません (^_^;)

高速化のポイントは4点

  1. サーバー (Apache)の設定
  2. 画像の最適化
  3. 画像の遅延ロード
  4. HTTPリクエストの削減

1は、以前紹介した  mod_deflate, mod_expires を使用してHTTP通信データ量を削減 を参考にしていただければと思います

画像の最適化は、PNG画像最適化の段階別ツール紹介 を参考にして頂ければと思います

ここでは、3以降に関してテスト用のサイトを用いて効果を検証していきたいと思います

サイトのパフォーマンス診断測定

GTmetrix のサイトで Celtis-one テーマを使用して現状を測定してみます

表示ページは下記ページと同じ内容をテストサイトに投稿して行いました

MySQL Workbench でデータベースに接続してみる

登録しているプラグインは10個程度で、JetPack プラグインの機能も10個ほど有効にしてあります

また、Google アドセンス, カスタム検索も設置した状態です

1と2を実施済みの状態で celtis-one テーマで測定すると

GTmetrix-1

PageSpeed 92, YSlow 73 と悪くない値です

サーバーの設定とある程度画像を最適化してあるのでスコアを上げてくれているようですが、ロード時間が6秒以上でリクエスト数が 140 もあります

 HTTPリクエスト削減

ここから HTTPリクエストを減らすにはどうしたらいいかを中心に見ていきます

遅延ロード

画像の遅延ロードを使用してみます

他にも、作成したJSファイルがいくつかにわかれていたので1ファイルに統合しています
また、jQuery の読み込みを CDN サイトにする等の対策も行っています

GTmetrix-2

PageSpeed 93, YSlow 73 とほとんど代わりませんが、時間が5秒台になり、リクエスト数が 100 になり体感的にも少し早くなりました

結構効果が大きいですが、まだまだリクエストがそもそも多すぎです (^^)

CSS, JS ファイルの統合と縮小化

プラグインを十数個使っている状態だと、プラグイン毎にJSやCSSを別途読み込んでいるとそれだけでHTTPリクエストが20~30個程度増えている可能性があります。

また、スタイルシート(CSS)を </head> の前に配置、スクリプト(js) は </body>の前あたりに配置するのがページを高速に表示するのに良いと言われていますが、沢山のプラグイン等を読み込んでいると必ずしも理想の配置とはなりません

その辺りの対策を行う有名なプラグインとして head cleaner というのが有りますが、もっとシンプルな機能でもそれなりの効果が見込めそうだったので簡易版的な機能を celtispack プラグインというテーマ用のプラグインパックに実装してみました

機能は、head, footer 毎の CSS, JS の統合と縮小化です
統合したファイルは、キャッシュファイルにして transient api を用いて扱います

  • 読み込み順を CSS, JS の順に並べ替えます
  • theme, plugin の CSS の統合
  • theme, plugin の jS の統合
  • theme, plugin の CSS内の画像URL base64 変換

また、下記機能には対応していません 低リスクの安全指向です (^^)

  • 外部サイトの CSS, JS は統合、縮小化しません
  • WordPressコアの CSS, JS は統合、縮小化しません
  • インラインの CSS, JS に対しては縮小化しません
  • HTML部は縮小化しません
  • js を head部からfooter部へ移動する機能はありません
  • zip圧縮機能はありません
CSS, JS の順に並べ替え

それでは、初めに並べ替えの効果を見てみます

GTmetrix-3

PageSpeed 92, YSlow 72 とほとんど代わりませんが、ロード時間が4秒台になり、リクエスト数が 104

誤差の範囲かも知れませんが若干速くなりました

CSS統合、JS統合

次に、 テーマとプラグインのCSS統合、JS統合を行ってみます

1回目はキャッシュデータを生成して書き込む処理があるので2回目以降の測定データです
キャッシュ効果でもう少し速くなるのを期待したのですが、ちょっと残念な結果です

GTmetrix-4-2

PageSpeed 92, YSlow 72 と代わらず、ロード時間も代わりませんが、リクエスト数が 94 で少し改善

Data uri

次にCSS内の画像URLをbase64変換して Data uri に置き換えてみます

GTmetrix-5-2

それほどの効果はないようですが、リクエスト数が 90となりました

CSS縮小、JS縮小

次にファイルを縮小化してみます

本来は、ファイル縮小化を動的に実行するのはリスクがあるのでやめたほうがいいです
事前に縮小化したファイルをアップロードして使用するのが望ましいのですが、一応機能としては盛り込んでみたのでその効果を見てみます

GTmetrix-6-2

縮小しない場合とほとんど代わりません

ここまでの結果を考えると、base64 の変換まではやっておいたほうが良さげですが、リスクを賭けてまで動的に縮小化を行うメリットはないような感じです (^^)

それにしても、リクエスト数が多いです

 原因は外部サービス

薄々気づいていたのですが、Google アドセンス, カスタムサーチ, チャート表示、SNS 等の外部サイトのサービスがHTTPリクエストの多さと遅さの原因です

これらのサービスを利用しない場合を測定してみます

カスタム検索

まずはカスタム検索をやめてみます

GTmetrix-7-1

PageSpeed 93, YSlow 74 、ロード時間はあまり代わりませんが、リクエスト数が 72 と少なくなりました

SNS(JetPack)

次は SNS です。JetPack の共有を止めてみます

ほとんど変わらないので変だなと思って調べるときちんと機能が止まっていないようです
JetPack プラグインを停止してみます。

GTmetrix-7-2

他にも有効にしている機能があったのでリクエストがかなり減りました

PageSpeed 94, YSlow 79 ロード時間も少し速くなり、リクエスト数が 49 です

チャート表示

次はチャート表示を使用している人気記事ウィジェットを止めてみます

GTmetrix-7-3

PageSpeed 92, YSlow 80 とYSlow がBランクになり、ロード時間は3秒台に、リクエストは 43 とだいぶ減ってきました

アドセンス

いよいよアドセンスを止めてみます

GTmetrix-7-4

PageSpeed 86, YSlow 92 と何故か PageSpeed が悪くなりましたが YSlow はAランクです
ロード時間も2秒台前半、リクエスト数は 15 と好成績です (^^)

高速化したいならSNS関連と広告を外せば良いという結果です (^_^;)

作成したテーマ自体が遅さの原因でないことがわかってホッとしましたが、アドセンスの使用と最低限必要な機能を入れて4秒以内というあたりを目標にするのが現実的な感じです (^^)

2014/11/14 追記

celtispack という自作プラグインで行えるその他の高速化手法について少し紹介します

表示ページによりプラグインロードの最適化する方法

参照 WordPress プラグインロードに条件分岐を使い高速化する方法

ページキャッシュ

参照 ページキャッシュの仕組みと効果ーアクセス集中時用のプラグインも作ってみました

高速化は、小さなことの積み重ねが大切です (^^)

 


まとめ記事紹介

search star user home refresh tag chevron-left chevron-right exclamation-triangle calendar comment folder thumb-tack navicon angle-double-up angle-double-down angle-up angle-down quote-left googleplus facebook instagram twitter rss