前回同様、「そうだ、京都、いってきた」的なページを参考ページとしまして、今回は画像に関するちょっとした話なんかも入れていきたいと思います。では、Page Speed編もいってみましょう。

始める前に、Page Speedのインストールから

「Page Speed」は、Firefoxのアドオンサイトには登録されていませんので、GoogleさんのPage Speedのダウンロードページから直接インストールします。現在、正式版が「Version 1.4」、β版として「Version 1.5」が公開されていますので、どちらかお好きな方を。古いものよりは新しいものの方が良いと思いますけど。ちなみにこちらもYSlow!同様、Firebugが必要です。

Page Speedでサイトをチェックしてみよう

Page Speedのインストールが終わったら、さっそくサイトを開いてチェックしてみましょう。YSlow!と同じようにFirebugのパネルの中に隠れていますので、ブラウザウィンドウ右下の虫のボタンをクリックします。

パネルの上のメニューに「Page Speed」と「Page Speed Activity」の2つのタブが追加されていると思います。サイトをテストして最適化ポイントを表示する場合は、「Page Speed」のタブを開いて「Analyze Performance」のボタンをクリックします。

ちなみにこのタブには設定項目がいくつか隠れています。実はこのPage Speed、テストと同時に構成要素を最適化するという素敵な仕様になっています。最適化されたファイルの保存先はここで変更しましょう。

テスト結果と最適化のための指針はYSlow!とはちょっと違う

YSlow!が米Yahoo!さんの14のルールをベースにいろいろ新しい項目が追加されているのに対し、こちらのPage SpeedはGoogleさんのものです。チェック項目は基本的に同じような内容になりますが、パフォーマンス向上のための指針などはちょっと異なります。

赤いビックリマークは要改善なポイント、黄色い三角はできればやっといた方がいいんじゃない？ぐらいな感じでしょうか。「使ってないCSSは取り除こう」「冗長なCSSのセレクタはやめて、効率的なセレクタにしよう」「画像サイズは指定しようよ」「styleとscriptの順番もちゃんと最適化しよう」みたいな感じでいろいろなチェック項目が並んでます。

（追記: 2010.02.03）バージョン1.6βがリリースされたので、こちらに各項目の意味を書き出しておきました。よければご覧ください。

たとえば、上図では「Parallelize downloads accross hostnames」にビックリマークが出ています。これは「ブラウザの並行ダウンロードの機能を有効に活かすために、配信ファイルをいくつかのホストに分けた方がいいですよ」的な内容です。このサンプルページはCSSやJavaScriptに加え、写真のサムネイルが15個、その他の画像が10個ほどありますので、1つのホストから配信するのはあまり効率的でないのは事実です。もちろん改善の方法はあるんですが、その話は後半で。

Page Speedの特徴として、三角矢印をクリックして展開すると結構詳細な解説をしてくれます。たとえばこの「Use efficient CSS selectors」の項目は、もっと効率的な書き方にしといた方がいいんじゃない？って話ですね（WordPressのデフォルトテンプレートなので、いろいろ事情があってこうなってるわけですが 笑）。

とまぁ、より詳細に改善すべき点を教えてくれるってわけです。

「Resources」でステイタスコードやファイルサイズのチェック

テストが終わるとサイトの構成要素の一覧を「Resources」で確認できます。

このResourcesでは、個々のデータのHTTPステータスコード（200だったり304だったり404だったり）に加えて、実際のファイルサイズと転送データサイズなんかも表示されます。矢印をクリックして展開すれば、HTTPヘッダのリクエストとレスポンスとかも確認可能です。

「File Size」が実際のファイルサイズ、「Transfer Size」が転送サイズです。前回も書いてますが、うちはテキストデータは基本Gzip圧縮がかかるようにしてるので、HTMLやCSSなんかは転送量が少なくなっているというわけです。

ちなみに最新のβ版からは「ShowSlow.com」へテスト結果を送信することもできます。Show Slowは、YSlow!とPage Speedを使ってテストした結果を集めてるサイトです。年末にどっかのサイトで紹介されてから毎日いろんなサイトのテスト結果が載るようになりました。FirefoxのAbout ConfigでちょいちょいっといじってあげるとYSlow!でも送信可能です。

「Page Speed Activity」でデータの流れとイベントをチェック

Page Speedをインストールするともうひとつ追加されるタブ「Page Speed Activity」では、データリクエスト開始からの一連の流れを記録することができます。

データのリクエストからDNSの参照にかかってる時間や接続までの時間、データのダウンロードにかかる時間をはじめ、描画されてるタイミングとかJavaScriptが実行されてるタイミングなんかも見れるようになっています。

この機能は、SafariやChromeに搭載されているWebインスペクタにもありますね。最新版のChromeとかはより細かく見れるようになってますし、GoogleさんがChromeのエクステンションとして年末にリリースした「Speed Tracer」をインストールすればもっともっと詳細な表示が可能です（こんな感じ）。

ちなみにChromeのOS X版では最新のDev.版でエクステンションが利用可能になってますが、残念ながら起動の前にとあるおまじないを指定しないといけないので今のところ使えません（笑）。

Page Speedの最適化機能はなにげに便利

冒頭でも書いたようにPage Speedはテストする際に自動的に画像やCSS、JavaScriptなどのファイルの最適化をしてくれるという素敵な仕様になっています。これがまぁ案外役に立つこともあるわけです。

たとえば、今回のサンプルページはこんな感じで写真のサムネイルがバラバラ並んでいます。

これらのサムネイル、そもそも画像本体はFlickrにアップしてあるものなので、そこからこのスクエアなサムネイルを引っ張って貼り付けていました。要は「配信ホストを分けて、スピードの速いホストから一気に並行ダウンロードさせる」ってやり方です。

しかし、Flickrで生成されているこのサムネイルは、画像そのもの最適化がされてない状態でしてね…、実は。いくらFlickrからの転送が速いとは言っても、この15枚のサムネイル画像を合計すると500kぐらいありました。

それじゃ見てくださる皆さんにあんまり良くないよね、ってことで、このPage Speedが自動的に最適化してくれたサムネイル画像に差し替えました。そうすることで、並行ダウンロードに支障があるものの、画像データの合計を約69kまで落とすことができたというわけです。

JPGもPNG（GIFよりもPNGが軽い）もただ単にPhotoshopから書き出しただけではまだダメで、Web Designing誌やうちのエントリーにも書いたように、さらに最適化処理をすることでデータサイズを大きく削減することができます（ものによりますが）。

Page SpeedはCSSやJavaScriptのMinify化もやって保存してくれますので、「Miniify化なんてチマチマやってらんねーよ！」って方は保存されたものを使えば楽ちんです（笑）。

とまぁ、こんなとこでPage Speedの見方、使い方を終わりにしたいと思います。

Webサイトのパフォーマンスの最適化って、目に見えて効果がでることばかりではありませんが、YSlow!とPage Speedやそれ以外のツールを使って検証しながらできそうなことだけでもやっておけば、それがたとえ気付かれなかったとしても最終的には良い結果をもたらすかもしれません。

目に見えないところにも気を配ってこそのホスピタリティですから。

双方のツールを使ってトータルであれこれと解説したいところなので、このサイトで割と画像を使ってる「そうだ、京都、いってきた」的なページを参考ページとします。

では、そんな感じで始まり始まり。

まずは、YSlow!が使えるようにする

米Yahoo! Inc.さん謹製の「YSlow!」は、Firefoxのアドオンです。これ単体で動作するわけではなく、あらかじめ「Firebug」というアドオンが必要になりますので、こちらもあわせてインストールしましょう。インストールするとブラウザウィンドウの右下に「虫」のアイコンが出てきますので、それをクリックするとFirebugの画面を呼び出すことができます。

YSlow!を使ってWebサイトをチェックする

インストールが終わったら、チェックしたいWebサイトを開いてFirebugのウィンドウを表示します。ウィンドウ上部には「HTML」「CSS」「Script」…などと、Firebugの機能のタブが並んでいますが、その中に「YSlow!」ってのが表示されているはずですので、それをクリックします。

まずは、対象サイトをどのような項目（ルールセット）でチェックするかを決めましょう。初期状態では、「Small Site or Blog」「YSlow（V2）」「Classic（V1）」が登録されており、これは後からカスタマイズすることもできます。比較的小規模なWebサイトであれば、「Small Site or Blog」、より詳細にチェックしたければ「YSlow」を選択します。

ルールセットを決めたら、左下にある「Run Test」と書かれたオレンジというか黄色のボタンをクリックしてテストスタートです。

「Grade」タブで改善点を見つけ出す

テストが終わると自動的に結果表示のウィンドウに切り替わります。「Grade」タブが一番最初に出てきますので、まずはこの説明から。

左上にドーンと出るのが総合評価、で、その下にはWebサイトの表示パフォーマンスに影響を及ぼす項目がずらりと並んで、それぞれ個別にAからFまでのランクが表示されます。個別の項目をクリックすれば、改善点が表示されるようになっています。

「Small Site or Blog」の場合は、「HTTPリクエストの数を減らしましょう」「Gzip圧縮をかけましょう」「CSSは上に置きましょう」「JavaScriptは下に置きましょう」「DNSの参照を減らしましょう」みたいな極めて初歩的な内容です。

それぞれの評価は良いに超したことはありませんが、必ずしもAになれば良いというわけではないですし、そこは「できること、できないこと」がありますので、あくまでも改善した方が良い点、どうすれば改善できるのか？という指針だと受け取った方が良いでしょう。

上の図だと「HTTPリクエストを減らすためには、4つの外部のJavaScriptがあるので、できればそれらをまとめちゃいましょう」みたいな感じです。うちの場合、これ以上はまとめることができませんが。

「Components」タブで転送データ量や有効期限のチェック

「Components」タブは、ページに含まれる構成要素をすべて表示します。それぞれの項目に表示された「＋」ボタンをクリックすれば展開されます。個別のデータサイズなどは展開して確認しましょう。

ここではJavaScriptの内容を見てみましょう。
それぞれのスクリプトのデータサイズは、一番左の「SIZE」に表示されます。Gzip圧縮をかけて転送していれば、「GZIP」に圧縮後のデータサイズが表示されます。やってなければ、ここは空欄になります。

うちは、HTMLもJavaScriptもCSSもブラウザが対応していればGzipがかかるようにしてますので、転送データサイズはごらんの通り1/2〜1/3程度になっているというわけですね。クライアントさえ対応していれば、これで転送にかかる時間は大幅に削減できると。

このComponentsタブの右側には、個々のデータの有効期限や反応時間などが表示されます。有効期限を設定していなければ、ここは日付ではなく「no expires」という表示になります。GoogleさんのAnalyticsのコードは一週間先の有効期限が設定されてます。うちの場合は、WebサーバのApacheの方で「mod_expire」を使って、一部のデータを除き3ヶ月先の有効期限を設定しています。

参考程度にうちの設定でも（一部抜粋）。

<ifModule mod_expires.c>
ExpiresActive On
ExpiresDefault “access plus 1 seconds”
ExpiresByType image/jpeg “access plus 3 months”
ExpiresByType image/png “access plus 3 months”
ExpiresByType image/gif “access plus 3 months”
ExpiresByType text/css “access plus 3 months”
ExpiresByType text/javascript “access plus 3 months”
ExpiresByType application/x-javascript “access plus 3 months”
ExpiresByType text/html “access plus 600 seconds”
ExpiresByType application/xhtml+xml “access plus 600 seconds”
</ifModule>

あまり変更することのない画像やCSS、JavaScriptなどは有効期限を設定しておくことで、ブラウザのキャッシュにある間はいちいちリクエストされることもなく、基本的にはHTTPヘッダのやりとりだけで終わることになります。リロードしたときはイヤでもキャッシュに残ってますが、日を空けて再度閲覧したとしてもブラウザのキャッシュがクリアされてなければそっちが使われるって感じでしょうか。

いちいちデータをリクエストをしない分表示が速くなるということですから、数が多ければ多いほど効果的ってなわけです。

「Statistics」タブでキャッシュの有無による違いをチェック

「Statistics」タブに表示される内容は、初回閲覧時（キャッシュが空の状態）とキャッシュが有効な状態それぞれでのHTTPリクエストの数とデータサイズを確認できます。

この京都のページは画像もパラパラいれてますので、HTMLやCSS、JavaScriptなどをすべて合計すると、初回接続時には41回のHTTPリクエストと131.9Kの転送データ量になります。これがキャッシュが有効な状態で再度閲覧した場合は、先ほどの有効期限の設定の関係でCSSやJavaScript、画像はリクエストされず、HTMLと有効期限のないJavaScriptだけでよくなって、合計6回のリクエストと13.1Kの転送データで済むということがわかります。

有効期限の設定がされていない場合は、データの転送量こそ数値的には少なくなっているはずですが、HTTPリクエストの数そのものはほとんど変化がないんじゃないかと。リロードしたときはまぁすぐ表示されるけど、日を空けて表示したときはさてどうかな？ってことになるんじゃないでしょうか。

「Tools」タブには便利ツールが…

「Tools」タブには、いろいろな便利ツールが用意されています。

JavaScriptのチェックツールやMinify化のための「All JS Minified」、逆に読みやすくする「All JS Beautified」、画像を最適化するための「All Smush.it™」などがありますので、それぞれを活用したいものです（※画像の最適化はPageSpeedの方がいいかなぁ…）。

とまぁ、こんな感じでチェックをしていくと…

今回は、まずはYSlow!の使い方というか見方的なものを紹介しました。ただツールを使って眺めるだけでは何も始まりません。ホスティング環境や制作環境によって「できること、できないこと」がありますが、はじき出されたテスト結果を参考にまずは試してみるのが一番ですね。

「Gzipがかけられないのなら、せめてMinify化だけでもやってみる」「逆にGzipかけるからMinify化はしない」とか選択肢はいろいろあります。CSS Spriteでリクエスト減らすのもいいですが、そんな手間のかかることしないでも有効期限を設定してキャッシュさせれば、HTTPヘッダのやりとりだけで済んだりもするわけです。

工数の問題とかいろいろありますから、とりあえずは試してみて総合的にどうした方が良いか判断することが必要でしょうか。

さて、次回は「PageSpeed」の使い方です。実はこっちはこっちでかなり便利な機能が用意されていたりするので、その辺を中心にお届けしたいと思います。

もともとFirebugを一緒に使うものであったようですけど単体で独立したのかな？ これをインストールしておけば、HTMLの要素だったりCSSのプロパティだったりを検索窓に入れてあげると、書籍の「The Ultimate CSS Reference」とかの表記と同じ感じでブラウザ毎の対応状況が表示されます（IE 7はBuggyとかね 笑）。

インストールして下のアイコンをクリックするとこんな感じ。

「オレはもう完璧」って人はいらないと思いますけど、ボクみたいに「あれ？あのプロパティ名ってなんだっけ？」っていうような人は入れておくと便利でしょう（笑）。

ま、そんなことは人の勝手なのでどうでもよいとして（笑）。
前述のBetter Gmailは、Gmailのあの画面をカスタマイズしたスキンなんかも選べるんですけど、久しぶりに設定を見たら素敵なのが増えてました。Better GmailはStylishとかで提供されているものが時折組み込まれるんですよね。

で、最近は素のままでスキンを適用していなかったのですが、今日久しぶりにスキンの項目を見てそこにあった「Gmail Redesigned v2」なるものを適用してみたら、「あら、最初のローディング画面から素敵じゃない！」と思わずおネエ言葉になってしまうぐらいの画面が出てきました。

というわけで、飽きるまではこのスキンに決定でございます。

余談ですが、わたくし通常はThunderbirdやiPhoneでGmailを確認することが多く、仮にブラウザで見る場合はGmailにかぎったことではないですが、CustomizeGoogleのおかげで広告やら自分にとって無駄なものが表示されない仕様になっております。

こんな私も実は10何年前ぐらいはDTPの入出力の行程で長いこと印刷に関わる部分の色あわせ的なことをやっていたり、富士ゼロックスさんの業務用プリンタのカラーマネジメントあたりのアレコレ（制作側と出力側で確実に同じ色で出すためのなんだかんだ 謎）にも関わっていたりという過去があるのですが、そんなことやってても言葉に出してとなると「ごめんなさい」と言いたくなります（笑）。

そんなコンピュータ周りの色に関することについて、先日のFirefox 3のカラーマネジメントの記事にコメントをしてくださったハラショさんのブログに素敵なリンクがありました。「miyahan.com | 液晶ディスプレイとカラーマネージメント」という記事は結構長いのですが、これでもかこれでもかというぐらい親切丁寧な解説（検証結果含め）がされています。

ここまでまとめてあるのは初めてみました。
凄いとしか言いようがありませんね、これは。

なんで、私が「色が、色が」とわけわからないことにこだわってるのか、上のリンクを読んでいただくとわかってもらえるかも知れません（笑）。基準がsRGBなのは別にいいとして、「違ってて当たり前」ではなく「本来の色に近い色で見て欲しい」と思っているだけなのです。

＃ま、いかにWindowsで見てるのがアレなのか、ってことになりますが今後この辺りが改善されていくといいなぁって思います。何も考えないで勝手に設定されるぐらいね。

追記: 私が先日あれこれやっていたFirefox 3のカラーマネジメントについても別ページに記載されていました。

と、そんな話はここでお終いにして…。
バージョン3になってやっとMac版のFirefoxは、カラー調整したモニタで見てもsRGBの色空間で表示されるようになったような気がするのですが、気のせいでしょうか？

で、今回それだけではなくチロチロッとコンフィグをいじってあげると、写真の中に特殊なカラープロファイルが埋め込まれていればそれを有効にして表示してくれるようですので、仕事にもなんとなく関わることですし早速実験してみました。

まずは、カラーマネジメントが無効であるデフォルトの状態でAdobe RGBのカラープロファイルが埋め込まれた写真を表示してみます。

これはJPGファイルの中に埋め込まれたプロファイルを無視した状態ですね。WindowsのSafari以外で見ると（このページ）、なんとなくこんな色味に近い状態で出てるのではないかと思います。

で、早速カラーマネジメントの機能を有効にしてみましょう。
アドレスバーに「about:config」って入力してコンフィグの画面を呼び出し、上にある空欄に「color」とか打ってカラーマネジメントの機能を有効にするための「gfx.color_management.enabled」の項目を探します。
※後述してますが、この状態ではカラーマネジメントが有効かつモニタのプロファイルが有効な状態になります。

その項目をダブルクリックすると「false」が「true」に変わってカラーマネジメントの機能が有効になります。一度リスタートしないと反映されません。

そうすると写真の中に埋め込まれたカラープロファイルで写真が表示されます。
この画面にある写真の場合は、ダウンロードして加工する人のためにわざとAdobe RGBのプロファイルを埋め込んでいるので、色の再現領域がsRGBより広いためこんな感じで派手めな感じで表示されます。ま、なんとなくこんな感じで（Photoshopとかでファイルのカラープロファイルを有効にして開いた状態ですね）。

Safariはもともとカラープロファイルを認識するので、同じように表示されるかチェックしてみました。その結果が下の画面になります。

いかがでしょうか。ほぼ一緒というか同じですね。

といっても、単純にこれを有効にするだけではサイト全体の色味にも影響するようですのでご注意下さい、というか対処方法はこの辺りに書いてあるようです。

具体的には、同時に「gfx.color_management.display_profile」をダブルクリックして、iccカラープロファイルの場所（例えばOS XでsRGBにしておきたければ、/Library/ColorSync/Profiles/sRGB.iccとかね）を指定するようです。sRGBにしておくか、モニタのプロファイルにしておくか（何も指定しない状態）でもまたサイト全体の色味が変わってきますからね。あー、こりゃこりゃって感じです…。色の話は面倒ですね。ややこしやー、ややこしや。

A string containing the full path to an ICM profile for output. Default is an empty string in which case the systems global profile is used. If no global profile can be found a default sRGB profile is used.

ってな感じで、空にするとシステムで設定してるiccカラープロファイルが用いられるけど、それがなければsRGBのプロファイルになるよって感じでしょうか。

結局この記事を書きながらアレコレ試してみて、どうしておくのが一番かって何もしないのが一番かもね、って結論に達しつつカラープロファイルだけ有効にしてます（かつモニタのプロファイルが有効な状態）。このカラーマネジメントの機能を有効にした方が良いかどうかは判断に迷うとこですが、そんなのが隠されているよっていう話でした。

「about:config」いじるのがあれなら「Color Management」ってアドオンもあるようです。

＃余談ですが、スムーズスクロールが気持ちいいです。

＃あ、あとサイト毎に文字サイズの変更が保存されてるようです。「Content Preferences」がいらなくなりました。文字の拡大縮小はデフォルトでズームの挙動なので、画像サイズをそのままにしたければ「テキストのみ（日本語でどう書いてあるか知りませんが）」を有効にしましょう。

追記（2008.06.20）: OS XのFirefoxでここにsRGBを明示すると、AdobeRGBの含まれた写真もsRGBになってるなぁ…。とりあえず何も指定しないでおこうっと。

※ココよりもこちらに紹介しているページの方がはるかに参考になります。

インストールして表示されるボタンを押してFlickrとかYouTubeを見るとこんな感じ。

ま、動いてるとこうなるわけです。マイティマウスがあるとボールというかホイールの上へ下へでウォールの拡大縮小、右へ左へで移動といった素敵な動作が楽しめます。

で、ここからが本題。実は色味のチェックができるじゃん

Windowsの場合はIEだろうがFirefoxだろうが、何がなんでもsRGBで表示されてるかもしれませんが、実はMacのFirefox 2.xは写真のカラープロファイル（Webなんで一般的にsRGBでしょう）を認識してくれないので、モニタのキャリブレーション次第では「なんだこれ？」ってなぐらいに実際の色味と違って見えます。Safariはプロファイルを理解するので、埋め込まれたプロファイルで表示してくれるんですけどね…（Firefoxも3.xからオン・オフできるとか？）。

問題になるのは、モニタをキャリブレートしていてかつ普段使いがFirefox 2.xである場合でしょうか。実際に他で見えてる写真の色味ってのが今イチわかりづらいのです。そこで役に立つのが、このPicLensだったりします。確かに3Dウォールでグリグリするにはマシンパワーが必要かもしれませんが、これを介して見ている分には、Firefoxで素で見てるのと違ってちゃんとプロファイルを認識してるようです、どうやら。
※少なくともうちでは明らかに違うのです。明らかに彩度が落ちる

これまで念のためと思っていちいちSafariで確認してましたが、これさえあれば多くの人が見えてる画像の色味がなんとなくですがわかりますね…。よかったよかった。

*1: FlickrのVideoを貼り付ける場合は、Flickrに用意されたembedボタンで表示されるコードはHTMLになってます。つまり、WordPressとかXHTMLになってるものではそのままではバリデートに引っかかります。今回はA List Apartのこの記事を参考にしてembedタグとclassidのとこを取っ払う方法に書き換えてます。
Firefox, SafariはOSXとVista、あとIE 7で動いてるのを確認しております。