mod_pagespeedってどんなサイトに向いてるんだろう？

みなさんこんちわ。
事務所の引っ越しから1ヶ月ちょっと。ようやく新しい環境にも慣れてきました。といっても以前の場所から500mくらい渋谷よりになっただけなので、周辺まで変わったわけじゃないんですけどね。

mod_pagespeedとは

昨年末くらいからぼちぼち話題に出ていたmod_pagespeed。Google先生謹製の、入れるだけでWebの表示速度が速くなるという奴です。
方々で言われていますが、画像の再圧縮、js/cssなど各種アセットの統合など、サーバサイドの仕事が増えるので単純に速くなるわけではなさそうです。ちょうど手元というかamazonに貧弱な( m1.small )サーバがあるので、Wordpressを入れたapache環境で試してみました。

インストール

ここ↓にあるパッケージを入れるだけ。
https://developers.google.com/speed/docs/mod_pagespeed/download

設定

{ServerRoot}/conf.d/pagespeed.conf を編集します。
以下のようにModPagespeedをonにすれば有効になります。
[cc lang="text"]
ModPagespeed on
[/cc]
VirtualHostごとに設定を分けておきたければ、上記ファイルはoffにしておいて、各VirtualHostディレクティブの中に以下のような記述を追加するのでもOKです。
[cc lang="text"]

ModPagespeed on
ModPagespeedFileCachePath "/var/mod_pagespeed/cache/"

[/cc]
設定が済んだらapacheを再起動しましょう。
ディレクトリ毎に制御したい場合など、.htaccessに書くこともできるようです。
私は試していないので、詳しくは以下の公式ドキュメントをご参照ください。
https://developers.google.com/speed/docs/mod_pagespeed/configuration#htaccess

結果

計測

実際のところどうなのか、使用前・使用後の速度を比較します。

CPUパワーが貧弱なサーバで試す ( m1.small )

まずは前述の m1.small の環境で試してみました。
計測には Web担当者Forum版 ページ速度分析ツール を使います。
※各数字の単位はms、小数点以下四捨五入

はい、トータルでは見事に遅くなりました。やっぱりリクエストを送ってからサーバが返事を返すまでが長くなっています。元々長かったレスポンスまでの応答時間が、mod_pagespeedが入ったことで引き延ばされてしまい、メリットを相殺して余りある遅延を引き起こしたと考えられます。
一方で、転送速度やブラウザ側のレンダリング速度は向上しました。特に転送時間が半分以下になったのは特筆に値するのではないでしょうか。CPUパワーに余裕があり前述のデメリットが発生しなければ、大きな恩恵を享受できるかもしれません。

CPUパワーに余裕があるサーバで試す ( c1.medium )

ということで、今度はゆとりのあるHigh-CPUなサーバ c1.medium で同じWordpressを移設して試してみます。

さすがhigh cpuインスタンス、重たいWordpressを動かしながらも2割の速度向上が得られました。特に転送速度が9倍と大きく改善する一方、サーバサイドの処理時間は1割増で済んでいます。
インストールして有効にしただけでこの結果ですから、文句はありません。

CPUパワーに余裕があるサーバ( c1.medium )で静的コンテンツで試す

ついでに、Wordpressで動的に出力するのではなく静的コンテンツだとどうなるか試してみます。MovableTypeでサイトを構築した場合なんかもこれに該当すると思います。
同じ c1.medium に静的コンテンツを設置してみます。

http://tripclip.jp の内容を静的コンテンツとして保存して使用しました。結果、Wordpressのケースと同様に全体で2割ほど速くなったことが見て取れます。
中を見ると、やはり転送速度が大幅に向上しました。元々大きな時間ではなかったものの、14ms程度だったものが1msまで縮まったというのは素晴らしい結果ではないでしょうか。携帯電話回線のように、データ転送がボトルネックになる環境ではレスポンスの改善が期待できます。
なお、各項目の合計と全体の数字が若干ずれてるのですが、これはDNSの応答や接続の待ち時間など、出たり出なかったりする項目がいくつかあるためです。小さいのと、計測不能なことも多いので省いています。

画像のリサイズについて

mod_pagespeedはimgタグの属性値を見てリサイズしたファイルを生成し、キャッシュディレクトリにリサイズ結果を保存します。実ピクセル数と属性値がずれてようがずれてまいが関係ないようです。そしてimgタグのsrc要素を自動的に書き替えます。
では、そのリサイズした結果を見てみます。

pngの場合

元画像: 241.15 KB

mod_pagespeedが生成した画像: 127.35 KB (元画像の約53%)

どういう奸計か、pngが小さくなりました。減色でもしてるんでしょうか。

JPEGの場合

デカい画像を上げたらWordpressがリサイズしてくれます。でかくなくてもしてくれますね。
Wordpressとmod_pagespeedで同じサイズを吐くようにして結果を比較すると、mod_pagespeedの結果はWordpressのものほどは小さくならないようです。でもオリジナルからしたら小さくなることに違いはありません。
普通画像って表示とピッタリサイズにすると思うんですけど、諸事情でできないこともあると思うので、これはこれで有効だと思います。ただ、片っ端からリサイズされたら相当にCPUとI/Oのリソースを食うであろうことは想像に難くありません。一回きりの処理とはいえ。

元画像: 901.17 KB

WordPressが生成した画像: 206.97 KB (元画像の約23%)

mod_pagespeedが生成した画像: 275.49 KB (元画像の約31%)

リサイズ結果について、非可逆な再圧縮では避けられない画質の劣化も特に感じませんでした。ちなみに、ぼくの視力はあんまりよくないです。

画像のインライン化

小さな画像を自動でbase64エンコードして、直接htmlに埋め込んでくれます。
通常、base64するとデータサイズは膨らむんですけど、別ファイルに対してGETリクエストするよりはいいという判断だと思われます。

元のhtml

[cc lang="text"]

[/cc]

mod_pagespeedによるインライン化

[cc lang="text"]

[/cc]

表示結果

その他

JSやCSSの最適化など、詳細は https://developers.google.com/speed/docs/mod_pagespeed/filters?hl=ja をご覧ください。

問題

ChromeでWordpressの画像アップロード画面が呼べなくなりました。（Firefoxだと大丈夫）
開発者ツールで見るとJavaScriptのエラーが出ています。それ以外は問題ないようですが、問題が出るディレクトリ以下をOFFにするとか、問題となるフィルタをOFFにするとか、個別に対応しなければならなさそうです。

感想

Railsを使っていればAsset Piplineが良きに計らってくれるような最適化を、mod_pagespeedは自動でどんなサイトにも適用してくれます。画像の最適化なんかはよりアグレッシブです。
もちろん、最初っから速度を重視して最適化したサイト構成にできればいいんですけど、必ずしもそうできないこともあるでしょう。そういった場合でも、コンピューティングリソースと引き替えに、手をかけずに体感速度向上が提供できるというのはなかなかすごいことではないでしょうか。なお、nginxを使っている場合も ngx_pagespeed が用意されています。
一方で、遅くなった例の通りパワー不足のサーバでは足枷となってしまうケースや、サイトの動作に影響を与えてしまうリスクも存在します。そういった向き不向きがあることを念頭に置きつつ、手間をかけずに快適なアクセス環境を手に入れられるか試してみる価値がありそうです。

参考URL

• mod_pagespeed - Make the Web Faster — Google Developers
  https://developers.google.com/speed/pagespeed/mod?hl=ja
• インストールするだけ! お手軽サイト高速化ツールGoogle mod_pagespeedはスゴかった
  http://web-tan.forum.impressrd.jp/e/2012/11/27/14218