GoogleとYouTubeの人が話したセッションより良いユーザーエクスペリエンスの作り方の原則として、第1に速くあれ!ってことを挙げていました。Googleのデザインガイドラインでも速さってのは重要だと言ってきているので、これ自体は特に珍しいことではないのですが、そこで引用されていた言葉が興味深かったので挙げてみました。Ventures)フレッド・ウィルソンさんはTwitterにも投資している有名なベンチャー投資家ですね。この人が言った言葉に「スピードはもっとも重要な特徴だ、もしアプリケーションが遅ければ誰も使わなくなるだろう。この傾向はパワーユーザーよりもメインストリームのユーザーで顕著だ」と。パワーユーザーというのは日本で言えば、はてなを使っているような人たちでしょう。彼らはそれなりの知識があるので、ページが遅くても同情的な感情になるらしいです。負荷分散大変だろうなとか。メインストリームユーザー、つまりノンデベロッパーの人はそんなこと知りませんから、なんで遅いん?は?みたいな感じですぐ去ってしまうんですね。ここで重要なのは、スピードというのは決して一部のパフォーマンスオタクのだけのもではないということです。フレッドさん自体、投資家であり開発者ではありませんので、スピードというのは全ての人が当然のように期待するモノなのかなと考えます。これまで見てきたように言わずもがなWPOというのは私たちにとって常に最重要課題なのではないかと考えます。前述のパフォーマンス計測の標準化が進めば、皆が同じルールの環境下で比較されるので、パフォーマンスが良いということはセールスポイントになることはもちろん、今後はミリ秒単位での厳しい争いになったりするのかなと考えます。機械は進化するWebパフォーマンスというのは重要なのは理解できたかと思うので、今度はそれを対策するために機械(コンピュータ)の部分に目を向けてみましょう。機械というのは当然のことながらものすごく進化が速いです。有名なムーアの法則で半導体の集積密度は18〜24ヶ月で倍増するというのがあります。簡単に言ったら、半導体の性能はものすごいスピード向上していくことになります。2年前の自分と比べて今の自分が2倍成長してるかと言うと、そうではないですよね?人間と比べれば進化のスピードというのは比較にならないほど速いものです。Webの世界においても同じことが言えます。有効な対策であるHTTPリクエストを減らすこと。これまで2度クライアントサイドでのパフォーマンスについて話してきましたが、言っていることはただ一つです。HTTPリクエストを減らすことしか僕は言っていません。現状はリクエストを減らすには、イメージマップ、CSSスプライト、インライン画像、ファイルの結合といったことが挙げられます。いった対策がブラウザ(機械)の改善(進化)が進めばどのように変わるのか次は見ていきましょうCSS3まずはCSS3。画像はコニッターさんのiPhone4をCSS3で描いてみたです!このような込み入ったものもCSS3で描けるということは、言わずもがなグラデーションボタンや見出しの背景画像といった比較的簡単なものならCSS3で十分事足りる可能性は大きいわけです。ちなみにGoogleが42億ページ調べた結果、1ページにあるリソースの和は平均44個でそのうち画像の平均は29個と最も多く全体の60-70%に当たるらしいです。このようなデータからも画像を減らすことはHTTPリクエストを減らす有効な対策だと考えます。Cacheアプリケーションキャッシュは、HTML5のオフライン機能ですね。マニフェストファイルというテキストファイルにキャッシュさせたいファイル名(パス)を記述しHTMLのマニフェスト属性に指定するだけで、セッションを越えての、オフラインでのキャッシュが可能になります。1回リクエストしてキャッシュしてしまえば、次回以降は余計なリクエストは発生させないということです。この機能と同じことを実現しようと思うと、サーバーの方でEXPIREヘッダに遠い未来を指定しなければならないんですけど、アプリケーションキャッシュの場合クライアント側ですべてできるのは使い勝手がよいですね。Package次に、リソースパッケージなんですがこれはMozillaの中の人提案した機能で、簡潔にゆうとZIPでくれ!ってことです。何回もリクエストするから効率が悪いので全部ZIPでまとめて、そのZIPファイルだけリクエストするというやり方です。いやーこれ考えた頭いいですね。今までなかったのか分からないほどクレバーな技術なんですけど、Firefox3.7に実装されるかどうかって話しだったんですけど、全然話にきかないので、たぶんFirefox5とかになるのでしょうか。マニフェストテキストにリソースのパスを書いてlink要素でリクエストするといった感じですね。Positionをちまちま設定しなくてもいい分、リソースパッケージのほうが圧倒的に管理が楽です。SPDY最後は、Googleが提案したSPDYというプロトコルです。こちらはブラウザの機能改善というより現状のHTTP通信変えようぜってことです。なるということではありません。裏側の部分が変わるんですね。実現できるのはこの3つです。重要なのは多重化ストリームです。これは現状のHTTP通信だと、1のホスト名に同時に2つのリクエストしかできません。2コネクション貼られて2リクエストするわけですから、つまり1コネクション1リクエストの原則です。これを解消するために、最新のブラウザは6つまでコネクションを貼ることができるのですが、これが1000ユーザー、10000ユーザーが同時接続してきたらどうでしょう?6万コネクションがサーバーに貼られるわけですからあまり効率のよいことではないですよね。そこで、SPDYでは1コネクションにリクエストする制限撤廃しました。1つのコネクションを何度も再利用するんですね。これが多重化ストリームです。HTTPリクエストがコストが高いのかというと、リクエストするたびに接続・解除を繰り返すから効率が悪いので、SPDYはこの点を解決できるのではないでしょうか。これまで4つ見てきたように、現在最も注意しなければならないHTTPリクエストも、近い将来、ブラウザの機能改善やネットワークの仕組みが変われば特に意識する必要はなくなるかもしれません。いえ、実際問題、各ブラウザが一斉に改善(アップデート)されるわけではありませんので、各ブラウザの実装度を見つつ対応しなければならない状況は続きます。私たち製作者はは常に走り続けなければなりません(‘・ω・`)...人間は変わらないそこで、人間側に着目する必要があります。人間というのは昔から何も変わっていません。オギャーって生まれて恋をしてカクカクシカジカで死んでいくわけですよ。少なくとも、2年毎に2倍成長しているかといえばそうではありません。要はこれまでは機械側ばっかりに着目してきたわけですけど、ここは進化が速い、ついて行くのはしんどいってことで、もっと変化の遅い人間側に着目しましょう。Perceptionそこで、人間は知るうえで重要になってくるのが知覚の問題です。1分感で7560ビット、1時間50万ビットくらいの大量の情報を処理できるそうです。実際は毎秒10ビットくらいしか処理していません。相対的に判断したり、これまでの知識を元に判断したりして情報を簡略して処理しています。世界をありのままにインプットしているわけではありません。このことを理解するのに良い例があります。上記の図のA、Bのマスの色は違いますよね、実は2つは同じ色なんですね。2本のグレーの線を引きますと、同じ#6B6B6Bのグレーだと理解できます。1つ例がありますので紹介します。こちらは2つのオレンジ色の円の大きさは左の円の大きさの方が小さく感じます。これも周りのオブジェクトを消してみると同じ大きさというのが分かりますよね。人間というのは曖昧に世界を知覚しているのが理解できるかと思います。これは、別に視覚だけに限ったことではありません。時間感覚においても同じようなこと言えます。アメリカの神経科学学会の人が発表したレポートによると、同じ3分という時間でも、若い人とお年を召した方では体感時間が違うといったデータが報告されています。この調査によると若い人にとっては3分は自分で秒数をカウントするとで実際は平均3:03秒くらいだったそうです。対して、60歳以上の人にとって3分は3:40秒に感じられたようです。お年を召した方のほうが流れている時間は速く感じているようです。時間感覚は年齢以外にも、地理的条件で違ったり、文化気候、体温によっても影響をうけるようです。2001年に調べた調査があります。ユーザーに10個の違うサイトを使ってもらってどのサイトが一番速く感じたか?という調査です。Time調査結果を見てみると、About.comは実際の平均読み込み時間が8秒で一番速かった(※2001年調べです)にもかかわらず、ユーザーからは一番遅いと判断されました。対して、amazon.comは実際の平均読み込み時間が36秒ともっとも遅かったにもかかわらず、ユーザーからは最も速いと評価されました。この調査のまとめでは、実際のダウンロード時間と体感速度に相関性はなく、それよりもユーザーのタスク処理の成功度具合と体感速度に相関性があると締めくくっていました。詳細を見るこのことを理解するのに重要なキーワードを持つ人物がアメリカの心理学者のミハイチクセントミハイです。彼が提唱した概念にフローというのがあります。注意が自由に個人の目標達成のために投射されている状態のことを指します。完全に集中している状態のことですね。皆さんも経験ありませんか?コーディングがのりに乗って気づいたらお昼だった。定時?といったことないですかね?ああいった感じを想像してもらえれば理解が速いかと思います。フローの構成要素にはこうっいったものが挙げられます。活動に本質的な価値がある明確な目的をもって集中している状態ですよね。ここで重要なのは時間感覚のゆがみです。先程のamazon.comの結果をフローを用いて、もう1度説明すると実際速度が遅かったにも関わらず速いと評価されたのはタスクの成功率、使いやすさのおかげで集中することができ、軽いフローみたいな状態にユーザが近づいたため、時間感覚がゆがみ、実際の速度以上に速いと感じるようになったのではと考えられます。このフローをうまく利用することができれば、サイトの体感速度も向上させることができるのではないでしょうか?この人間編をまとめますと、人間を曖昧で相対的です。フローといったモデルをうまく利用することでWPOにもうまく利用できると考えます。実践編さて、ここからはWebサイトにフローを落とし込むためにはどうしたら良いのか考えてみましょう。ここまで人間側の部分を考えてきました。体感速度を向上させるために人間の頭をこねくりまわすことはできないので、知覚される前になにか対策する必要性がありますね。インターフェイスが重要になってくるわけです。Webインターフェイスをデザインするパターンはいろいろあるのですが、ここではフローの構成要素から、直接的で即座な反応と、自分で制御している感覚から考えるに、フィードバックというパターンがフローを作り出すに最適なパターンかと今回は考えます。実際にフローのためにどのようなフィードバックをしたらよいのか見ていきましょう。Previewまずはライブプレビュー。Twitterのパスワード設定とかナイスだと思うんですね。こたないんですけども、パスワードの安全度をタイプするたびに提示(プレビュー)してくれるんですね。これがライブではなくて、とりあえず入力して、設定ボタン押してページが切り替わってから「パスワードに不備があります。一度設定しなおしてください。」言われたらどうでしょう。一度入力したフォームの情報もクリアになってたらどうでしょうか?完全にフローは断ち切られますよね。ライブプレビューはそういった意味で、即座の反応と自分で操作している感からフローを作るのに最適化と考えます。Rendering次のフィードバックはもう少し短いスパンにおいてのフィードバックです。プログレッシブレンダリングとは、まぁプログレッシブエンハンスメントという言葉もあるように、漸次的、段階的レンダリングと考えればよいでしょう。真っ白なページから、いきなりページが表示されるのではなく、ヘッダー、サイドナビ、メインコンテンツといった具合に順々にレンダリングしていく具合です。プログレッシブレンダリングで有名なBingの事例のよると、Bingの検索結果画面はそれまでプログレッシブレンダリングしてませんでした。検索クエリを入力して結果が表示されるまでに真っ白な画面をユーザーに表示させていました。そこで、スライドの紫色の選より上の部分、ビジュアルヘッダーの部分是が非でもまず表示させるように対応したようです。しただけで、各種評価は軒並み上昇しました。中でも、ユーザーの満足度は0.7%上昇と、ページをリニューアルしたとき並の効果があったようです。ここで重要なのは全体のページの読み込み速度自体は変わってはいないのですが、まず何か見せておくことでユーザーに安心感を与えるいるわけですね。Indication最後はお馴染みのインジケータですね。ページの読み込み速度が速いことにこしたことはないのですが、やはり、どうしても読み込みに時間がかかる場合もあるわけですよね、FLASHサイトとか。いった場合に、ユーザーをつなぎとめとくために、フィードバックを返しつづけることで安心感を与えることは大切です。プログレスバーなどのケアを心がけたいところです。Designにフローを落としこむテクニックはフィードバック以外にも上記のようなものがありますので、みなさんも取り入れてみてはどうでしょうか?まとめこれからもブラウザは進化し続けます。結局、何のためにWebパフォーマンス最適化をするのか?といったことですよね。スコアのためでもなければ、開発者の自己満足のためにでもありまん。ユーザーのために最適化するわけです。したらやっぱりユーザー(人間)側についても考える必要性があるのではないでしょうか。知覚や認知ついて知れば、それは今後数十年といったスパンで使える知識です。可能になると考えます。Lifeにしてみてください。ありがとうございました。こうじ)1983年石川県生まれ。大学でデザインを専攻後、晴れてWebデザイナーになるが、コーディング好きが高じてWebデベロッパーに転身。