続・mod_pagespeedの各Filterと設定について
Posted: Updated:
mod_pagespeedがサーバーから出力されるファイルを最適化する
apacheモジュールのmod_pagespeedは、Page Speedアドオンで、検査しているような項目について、HTML・CSS・JSなどを最適化してくれます。例えば、冗長なインラインのCSSを外部ファイルにしたり、逆に短く小さいサイズの外部CSSをインラインにしてリクエストを節約したり、JavaScriptのminify処理をしたりします。
基本的には、クライアントサイドの体感速度と、転送量の抑制につながる、フロントエンドに関連する最適化です。フロントの実装コストを、ある程度サーバーが吸収してくれます。
CentOSへのインストールについては、関連記事の「さくらのVPSにGoogleのmod_pagespeed入れてみた」も併せてご覧ください。
実際に、どんな感じになるのかをソースコードで見るなら、「mod_pagespeed をちょっとだけ試してみた - 酒日記 はてな支店」が分かりやすいと思います。
デフォルトのCoreFilters
mod_pagespeedでは、Filterを設定してサーバーのアウトプットに、どのような処理を加えるか設定します。
デフォルトで動作しているFilterは以下のとおりで、これらは ModPagespeedReqriteLebel に示される CoreFilters に含まれています。
- add_head
- combine_css
- rewrite_css
- rewrite_javascript
- inline_css
- inline_javascript
- rewrite_images
- insert_img_dimensions
- extend_cache
ModPagespeedRewriteLevel CoreFilters
実験中の話ですが、CoreFiltersの中の、rewrite_javascriptが有効だと、XHRとかして余所のスクリプトを読み込んでいる部分が動かなくなったりで、不具合が出たのでDisableFiltersに指定しました。
ModPagespeedDisableFilters rewrite_javascript
ModPagespeedRewriteLevel でざっくりと有効にした上で、ModPagespeedDisableFilters を指定すれば、個別のフィルターを無効にできます。
ModPagespeedEnableFilters elide_atttributes
反対に、ModPagespeedEnableFilters を指定することで、個別に有効にもできます。
その他の設定
その他にも細かいチューニング用の設定項目がありますが、詳しくは元のドキュメントを確認してください。
Using mod_pagespeed - http://code.google.com/intl/ja/speed/page-speed/docs/using_mod.html
以下で、各フィルターの効能についてをつらつらと。
各フィルターが個別に動作して、アウトプットを最適化
各フィルターの説明は、下記のURLで個別に説明されています。このエントリーでは、自分の勉強がてらに、ざっくりとアウトラインとして紹介します。これらのフィルターでいじくられたファイル群は、pagespeed.conf内で定義された場所にキャッシュされます。
mod_pagepeed Filters - http://code.google.com/intl/ja/speed/page-speed/docs/filters.html
各フィルターのアウトライン
Add Head : HTMLファイル内にhead要素がない場合に、head要素を加えるフィルター。これは、他のフィルターが動作する際に、head要素内に、新規script要素などを追加しようとするため。
Add Instrumentation : head要素とbody要素の中に、小さいスクリプトを埋め込みます。このスクリプトは、クライアントのページローディングとレンダリングについてのレポートを、サーバーに返します。
Collapse Whitespace : HTMLから不必要なホワイトスペースを除去します。pre, textarea, script, style要素の中はちゃんと考慮してくれます。
Combine CSS : 外部から読み込まれている複数のCSSファイルを、1つのCSSファイルに結合します。
Combine Heads : HTML内に含まれる複数のhead要素を、1つのhead要素に結合します。（複数存在するとかのパターンがあるのか...）
Elide Attributes : 不要、または省略可能なHTMLの属性を、除去または編集します。XHTMLの文書に基づく処理です。（HTML5とかに適用すると、ちょっとズレたりしそう？）
Extend Cache : Webページ内のリソースに対して、キャッシュ制御のヘッダーを最適化して付与します。
Inline CSS : 容量の少ない外部CSSファイルの中身を、HTMLドキュメント内に移し、外部ファイルへのリクエストを抑止します。
Inline JavaScript : 容量の少ない外部JavaScriptファイルの中身を、HTMLドキュメント内に移し、外部ファイルへのリクエストを抑止します。
Minify JavaScript : 外部・ドキュメント内問わず、JavaScriptを圧縮して最適化(minify)します。
Move CSS to HEAD : ドキュメント内に分散したCSSの読み込みを、head要素内に移動させます。
Optimize Images : 画像ファイルを、img要素のwidthとheight属性に合わせた必要最小限のサイズに調整したり、dataURIスキームに変換したりします。
Outline CSS : ドキュメント内のCSSを、外部CSSファイルに分離させます。
Outline JavaScript : ドキュメント内のJavaScriptを、外部JavaScriptファイルに分離させます。
Remove Comments : HTMLドキュメント内から、コメントを除去します。
Remove Quotes : HTMLの属性における、余分なクオーテーション( " または ' )を除去します。
Rewrite CSS : 外部・ドキュメント内問わず、CSSを圧縮して最適化(minify)します。
便利なような気はします
まじめに作っていれば、あまり気にしなくても良さそうな項目も混じっていますが、なかなか便利そうな項目もあります。
Rewrite CSS ( = rewrite_css ) や、Minify JavaScript ( = rewrite_javascript ) なんかだと、制作する側は圧縮(minify)済みのCSSとプレーンなCSSを分けて保存する必要がなくなり、メンテナンスが楽になって良い感じです。
このモジュールを導入することで、手元のメンテナンス性を維持しながらWebサイトを最適化してくれるようになるなら、メンテナンス性とパフォーマンス性におけるペイオフの関係が、少しは楽になるのかもしれません。
すでに稼働中のサイトの負荷を下げる施策として試すのはもちろん、このモジュールの導入を前提に入れて新規にWebサイトを構築する分にも効果的に使えそうです。面倒なところは、モジュールに押しつけてしまえ的な発想で構築できれば、大分気がラクになりますよね。
どれくらい本当に賢いのかな？
実用レベルかどうかという点については、ガチで最適化が必要な大規模サイトの運用に組み込んだ際、どれぐらいページごとに賢く最適化してくれるかが一番のキモですかね。クライアント側での計測データを収集するオプションもあるぐらいなので、期待はできると思うのですが。
そのあたりは、誰かがポツポツと情報をあげていってくれると思うので期待。
