→ Flowdock（現在はサインアップできます）

アカウントを取得してメンバーを招待してはじめよう

アカウントの登録が終わったら自分のホーム画面に移動します。アカウント1つあれば、チームやプロジェクト毎に「Flow」と呼ばれる独立したワークスペース的なものを用意できます。使用するFlowをクリックするとそのDashboardが表示されますので、Flowに参加して欲しいメンバーをメールで招待しましょう。

既にFlowdockのメンバーであれば、招待メールのリンクから自分のアカウントでログインすることが可能です（そうでない場合はサインアップ）。

招待された人がログインすればほぼリアルタイムでDashboardにあらわれます。Flowdockの右側に見えるペインでは、チャットしたりファイルを添付したりといったやりとりが可能です。

このぐらいだったら別にFlowdockじゃなくてもいいわけですが（笑）、Flowdockはここからが違います。

「Influx」にRSSやTwitter、メールなどを読み込む

Dashboardの左に並ぶ3つのボタンの上から2番目「Influx」をクリックすると、外部のRSSや特定のTwitterのフィード、メールなどをストリームのような形で表示することが可能です。

フィードやTwitterのストリームの追加はこのダイアログから、メールはFlow毎に用意されるメールアカウントに対してメールを投稿することでここに表示されるようです。つまり、複数人が参加しているプロジェクトやグループ内での通知事項は、そのアドレスに投げておけば自動的にこの画面に現れると。

Influxに流れてくるものは、個々にコメントをつけたりすることもできるようになっていますので、メンバー同士で意見を交わすみたいなことができます。なので、別に仕事じゃなくて特定の趣味のグループを作って、そこでワイワイやるといった使い方もありでしょう。

特定の話題やファイルの検索は「Flowser」で

チーム単位での仕事になるといろいろな事柄が毎日毎日起こっていくはずです。「あの話ってどうだったんだっけ？」みたいに過去を遡るのも大変です。Influxで流れる内容にはコメントだけでなくタグを付与することもできますので、それらを見つけるにはボタンの上から3番目の「Flowser」を使います。

特定のタグを検索したり、ファイルだけを表示したりすることも可能と。

動作は軽快。仕事だけじゃなくても使えそう

こんな感じでGoogle Waveと比較されそうな感じのFlowdockですが、できることが明快な上に動作も軽快です。チーム内のコラボレーションはもちろんですが、1つのアカウントでFlow自体は複数作れるので、Twitterなどで仲良くなった人たちとお出かけするためのグループミーティングみたいな場としても活用できるかもしれません。

こんな感じで右側にある「＋」を押せば新しいFlowが作れます。

画面のインターフェイスは英語になりますが、できることが限られているので使い方に迷うようなことはないかな、と。日本語も通りますし。現在はまだパブリックβという扱いなので、今後の発展に期待したいと思います。

最近では、高機能なプロジェクトマネジメントシステムだったり、Google Waveなんかも出てきちゃったりで、複数の会社をまたいだプロジェクトのマネジメントというか、制作チーム単位での工程管理というか、複数人でコミュニケーションを取りながら仕事を進めるスタイルにも変化の兆しがありますね。

Google Waveも鳴り物いりで登場した割には、全体的に重いからなのか使い道が思いつかないからなのか、近頃はあまりその話を目にする機会も少なくなりました（使っている方も多いとは思いますが）。が、ここにきて新しい仕事のやり方ができそうなコミュニケーションツールが登場です。その名も「Flowdock」。

Flowdockは何やら良さそげですぞ

このFlowdock、日本時間の3月11日未明にベータアカウントの登録が可能になっていました。サイトにあるビデオを見る限りGoogle Waveに似た感じもありますが、Twitterなどとも連携しているようで何やら良さそうな雰囲気です。

ここで「…いました」とか「良さそうな…」と書いてるのには実は訳がありまして…（笑）。なんだかんだで一気に広まって急激な負荷がかかっているのか、今のところ正常稼働できてないようです（中の人のつぶやきによると）。で、残念ながら現在はインビテーションのリクエスト状態になっています。どうやら復活したようで、現在はサインアップできるようになっています（2010.03.11午前の段階で）。

ボクは速攻でアカウントをいくつか作ったんで「紹介でもしとこうか」とパソコンに向かったのですが、こちらも残念ながらこの画面より先に進めません（笑）。

追って使い方などを紹介できればと考えておりますが、そんなわけなので今日のところはこの辺で閉めたいと思います。興味のある方はサイトの紹介ビデオを見るなり、β版のインビテーションリクエストを送るなりしておくと良いですね。

ひょっとしたら仕事の仕方が変わるかもしれません。

（追記: 2010.03.11）
復活していたので簡単に使い方を書いてみました。

前回同様、「そうだ、京都、いってきた」的なページを参考ページとしまして、今回は画像に関するちょっとした話なんかも入れていきたいと思います。では、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」の使い方です。実はこっちはこっちでかなり便利な機能が用意されていたりするので、その辺を中心にお届けしたいと思います。

Webサイトのパフォーマンスチェックサービス

いろいろあります、実は。

WebWait – Benchmark Your Website

自身の接続環境から任意のWebサイトの表示時間を計測できる。回数指定で平均値を出すことが可能。いろんなブラウザで試すこともできるが、あくまでも自分の見てる環境からなので回線速度が速ければ、それなりに速くなるのでご注意を

Pingdom Tools

WebサイトのモニタリングサービスをされてるPingdomさんのフリーのサービス。サーバの置かれてる場所にもよるけど、レイテンシ（遅延）がかなり発生するので秒数は比較的長めになる。とはいえ、リンクヒエラルキーで並べ替えたりもでき、どのファイルが落ちてから関連するファイルが落ちてるとかもわかるのでありがたい

Pagetest – where web sites go to get FAST!

アメリカやオーストラリア、イギリスなど拠点と回線、ブラウザ種別を変えてパフォーマンスチェックができる。IE 7と8の違いなどもわかって便利。これもレイテンシがかかるので、サーバの置かれてる場所次第で秒数は変わる。San JoseのIE 8がおそらく一番速い。初回接続時とキャッシュが有効な時と二度計測可能で、それぞれのウォーターフォールチャートやHTTPリクエストの数なども表示できる

Web Page Analyzer

「Website Optimization（日本語版は、オプティマイジングWebサイト）」の著者の方のサイトにあるサービス。HTTPリクエストの総数から回線速度の違いによる表示秒数、改善すべき点などがレポートされる。「Analysis and Recommendations」の赤いとこあたりが考え直した方が良いかもな部分

Google Webmaster Tools

GoogleのウェブマスターツールズにもこないだからLabsのとこに「Site Performance」というのが追加されてます。サイト全体のコンテンツの平均値とトップページの平均値、アクセスの多いページの秒数と改善点などが表示される感じ。数ヶ月間の平均値を表示するページ上部のグラフ、緑の部分（1.4秒以下かな？）にあれば速い方で赤い部分に乗ってたら改善の余地があるってこと

海外からだと遅延も起きるけど、参考にはなるはず

とまぁ、他にも似たようなサービスを提供されているところはあるんですが、詳細にもろもろ出てくるものをピックアップしてみました。WebWait以外は設置されてる場所からのアクセスになるため、国内にあるサーバはどうしてもネットワーク間のレイテンシ（遅延）が発生します。なので、国内からだと想定すればちょっと秒数をさっぴいた方がいいかな（1秒とか）。

うちのサイトとか試しに計測してもらっても構いません。そんなリクエスト数も少ないブログだから速いだけでしょ、って思ったら大間違いですからね（笑）。こんなとこでもいらんことするとあっという間に遅くなるんですよ、マジで。今現在は、Googleさんから見てサイト全体の平均が1.6秒ぐらいのようです。

ちなみに昨日の某国会議員さんのサイトとうちのサイトの比較です（計測してる時間こそ異なりますが、一応同じDSLのIE8にしてます）。

某国会議員さんのサイト

http://www.webpagetest.org/result/091222_3SW2/

ボクんち

http://www.webpagetest.org/result/091224_3TW0/

サイトの見た目的にはさほど大きな違いはないようにみえますが、読み込んでるものの数とか構成とかでこんなにも変わってくるということですね。あちらのサイトは昨日エントリーしたような意図せぬことが起きてるせいもあると思いますが。

なんでそんなにこだわってるかってのは、例の特集の最後を…（まだ宣伝するか）。ま、警鐘をならしてるってことで。

おまけ

自分の環境からサーバまでの経路をチェックしたいなら、ターミナルエミュレータ（OS Xならターミナル、WindowsならPoderosaとかTeraTerm、PuTTYなど）を使って以下のコマンドを入力すればオッケイです。

traceroute example.com

（追記: 2010.03.10）

一個オンラインでチェックできるサービスを追加しておきます。

Load Impact – Free page analysis

Load Impactさんはサイトの負荷テストサービスを提供されている会社ですが（Free版だと同時に50クライアントまで）、その中でサイトパフォーマンス計測ツールが公開されています。ストックホルムかどこかからの計測だと思うので、国内から測るよりはレイテンシが発生しますが、シミュレーションできるUAの種類も豊富です。

PHPとMySQLが動いてれば簡単に導入できるようで、どんなもんかはデモムービーを見れば「あぁ、なるほど」な感じです。有料版のCMSになりますが、購入前に自分のサイトで動作するかどうか確認できるテストスイーツも用意されています。

なんか手軽でいいですね、これ。

今回からAmazon.comの中も検索できるので、あっちから輸入する人には便利かもしれません。いきなり検索するか、カテゴリ選んでから検索するかって使い方になります。あとは3Dウォールでグリグリです。

MightyMouse必須ですね、PicLensは。