mod_pagespeedのTips
Firefox
テクノロジー
mod_pagespeedのTips
いつもご覧頂き、ありがとうございます。アイフラッグ基盤担当のTTです。一ヶ月近くも更新が止まっていましたが、あまり気にしないでmod_pagespeedの不定期連載の第八回を開始します。
本日も弊社のホームページサービスへの導入事例を基に、役に立つかもしれないちょっとしたことを綴って参ります。
今回は、弊社が運営しておりますアイフラッグデンキのショッピングカート画面を例に説明いたします。
弊社のカート画面ではHTTPS通信が必須で、HTTPで通信しようとするとHTTPSにリダイレクトされます。
次のURLにアクセスして、httpsにリダイレクトされることを確認してください（別画面で開きます）。
http://cart.xaas3.jp/m8811894/cart/shoppingCartList/add/domain/iflagdenki.jp
このリダイレクトの実装は、例えばmod_sslを利用している場合にはサーバー変数HTTPSで判定すると思います。次の例のようにサーバー変数HTTPSが存在していなければ、HTTPSにリダイレクトします。
例：
RewriteCond %{HTTPS} ^$
RewriteRule /(.*)$ https://%{HTTP_HOST}/$1 [L]
mod_pagespeedが画像ファイルなどを要求するときにはHTTPで要求しますが、この判定でHTTPSにリダイレクトしてしまいます。
ブラウザの処理
http://example.com/index.html ⇒ リダイレクト ⇒ https://example.com/index.html
mod_pagespeedの処理（リダイレクトを抑止したい！）
http://expample.com/sample.css ⇒ リダイレクト ⇒ https://example.com/sample.css
このようなケースで使用するのがパラメータModPagespeedCustomFetchHeaderで、以下のように利用します。
ModPagespeedCustomFetchHeaderの利用例：
ModPagespeedCustomFetchHeader HTTPS on
この設定により、mod_pagespeedのリクエストのヘッダに「HTTPS: on」が付与されるためリダイレクトを回避することができます。
この他にも、「mod_pagespeedからのリクエストに専用のヘッダを追加してアクセスログを分ける。」といった用途にも利用可能です。全てのmod_pagespeedからの要求にはこのヘッダが付与されるので、その点だけ注意してください。
最後に本家URLを載せておきます。
http://developers.google.com/speed/docs/mod_pagespeed/config_filters#custom-fetch-headers
2013-04-19 14:47:42
コメント(0)
｜
トラックバック (0)
一週間のご無沙汰でした。アイフラッグ基盤担当のTTです。
今回のmod_pagespeedの不定期連載は、携帯電話への対応についてです。
携帯ページでは、XHTMLを利用している場合があります。XHTMLとして定義しているのに、HTMLの文法で記述しているというミスをした経験があるかもしれません。
通常、このような場合はXHMLの文法エラーとしてブラウザで表示できずに気がつきますが、HTTPのレスポンスで「Contet-type: text/html」と返すとブラウザではHTMLとして扱い表示できます。
ただし、このようなケースでmod_pagespeedを有効にすると、XHTMLのパースエラーが発生します。
こちらの間違ったXHTMLを見てください。
ソース表示
<br>タグが閉じられていません。HTMLでは正しいのですが、XHTMLとして記述するなら<br/>ですね。
パースエラーにならないのは、拡張子がhtmlになっているために、「Content-Type: text/html」で返ってきているためです。
ここで、フィルタ「convert_meta_tags」を有効にするとHTTPのレスポンスが「Content-Type: application/xhtml+xml」に変わります。こちらのエラー画面を開くと次のようなエラーが発生するはずです。開発者ツールなどを利用して、HTTPのレスポンスヘッダがXHTMLになっていることも確認してください。
このフィルタ「convert_meta_tags」はCoreFiltersで有効となるフィルタなので、ユーザコンテンツが存在して互換性を重視する場合には無効にすることをお勧めします。この件は本家のFAQにも記載されていますので、ぜひご一読ください。
http://developers.google.com/speed/docs/mod_pagespeed/faq#meta_tags_and_xhtml
2013-03-25 17:53:43
コメント(0)
｜
トラックバック (0)
アイフラッグ基盤担当のTTです。
今回からは他の執筆者との差別化と使い勝手の検証を兼ねて、ブログページに移って不定期に記事を投稿していきます。
これからも、よろしくお願いいたします。
なんとか今回は、時間を空けずに更新することができました。
前々回に予告したCSSスプライト機能（sprite_imagesフィルタ）についての説明です。
デモを見たのですが、「すごい！よくこんなの考え付くなぁ」と感心しました。
まずは本家のデモをご覧ください。最初は最適化されていないかもしれませんが、その場合はリロードしてください。
http://www.modpagespeed.com/sprite_images.html?ModPagespeed=on&ModPagespeedFilters=rewrite_css,sprite_images
元は3つの画像ファイルをmod_pagespeedが1ファイルに纏めています。
しかしデフォルトでは無効になっているオプションです。
何でデフォルトでは無効なのだろう？と思い、検証したところ私も以下の理由で利用をあきらめました。
- CSSスプライトにするための条件が厳しい
- 弊社の環境ではインライン化の制限内で収まるケースが多く、有効な場面が少ない
- TRIM_URLSが効かない
このフィルタの効果としては、CSSで使われる複数の画像を一度のリクエストで取得してサーバへの要求回数を減らすことです。
この利点は理由1.と2.でほぼなくなり、理由3.によりたとえ効果があっても弊社環境への適用ができなくなりました。
以下に非常に簡単ではありますが、個別の理由について説明します。
CSSスプライトにするための条件
- CSSに画像サイズ（heightとwidth）が記述されていること
- PNGとGIFのみ対応（JPEGは後日対応予定）
画像サイズはほぼ指定しておらず、CSSの修正が大量になるためにこの時点であきらめました。参考：ソースの表示
インライン化で収まることが多い
この例では、CSSスプライトを有効にしてもインライン展開で完了しています。
インライン化を無効にするとCSSスプライトを利用します。
TRIM_URLSが効かない
TRIM_URLSを有効にしてもソースを見るとドメインまで指定されています。
現在のバージョンを利用される際は、TRIM_URLSが効かないことを覚えておいてください。
前回の記事でも述べましたが、弊社のホスティング環境ではTRIM_URLSが有効でないと正常に表示できなくなります。
このために、たとえ効果があっても適用はできなくなりました。
最後に、本家の解説は以下になります。本番システムでの利用を考えている方は、制限事項やリスクを熟読されることをお勧めいたします。
https://developers.google.com/speed/docs/mod_pagespeed/filter-image-sprite
2013-03-12 20:48:53
コメント(0)
｜
トラックバック (0)
