CSS Nite in ISHIKAWAで話をしてから1ヶ月経ったので、薄れゆく記憶の復習も兼ねて思いの丈を綴ってみたｗ
1. What's High Performance?
ここでいうパフォーマンスというのはWebサイトの表示高速化についてです。つまり、ページをいかに早く表示させるかという課題です。でも、そうゆうのってサーバー側の問題でしょ？システムエンジニアの管轄じゃないの？と思われがちですが「ハイパフォーマンスWebサイト」の著者であるSteve Soudersの調査によると、80:20。一般的にユーザーの待ち時間の実に80%がブラウザ側、フロントエンドで費やされていて、サーバー側、バックエンドでの時間は全体の20%でしかないという結果が出ています。つまり、サーバー側でデータベースのチューニングやメモリ管理、アルゴリズムの見直しなどして処理時間を半分にできたとしても全体として見れば10%でしかないということです。要するにフロントエンドを預かるWebデザイナーの責任が重大と言うことです。2. Why High Performance?
では、なぜパフォーマンスが重要なのでしょうか？パフォーマンスが悪いと何か都合が悪いのでしょうか？パフォーマンスをないがしろにしていると怖いよっていうデータを見せたいと思います。Google：0.5秒遅くなると、検索数が20%減少する
うん、怖いですね、メインの事業ですからね。
Amazon：0.1秒遅くなると、売り上げが1%減少する
怖いですね、たった0.1秒遅くなることで数十億、数百億ぐらいの影響になってくるということです。このようにパフォーマンスが低下すれば収益に直に影響してくるといったケースが考えられます。だけども、うちはAmazonみたいに大きくないから考えすぎだよとおっしゃりたいかもしれません。
Aberdeen Groupというリサーチ会社が出したレポートによると、一般的に表示スピードが1秒遅くなると、PVは11%、CVは7%、顧客満足度は16%ダウンするといったことが報告されています。こういった数値を知っていればパフォーマンス対策をするための目標を決めやすいのではないでしょうか。
またユーザービリティ的に見てもパフォーマンス低下は避けた方良いということが分かります。
反応時間の3つの重要限界
- 心理的・感情的な違和感を感じないのは0.1秒まで
- 思考の流れが妨げられないのは1秒まで
- 注意力を維持できる限界の時間は10秒まで
結局のところ、Time is Money！と言えるのではないでしょうか。つまり、ページをハイパフォーマンス化することでユーザーのストレスをなくし、ユーザーエクスペリエンス（体験）の質を向上させることで、結果収益にもつながってくるこということです。
3. How do you measure it?
次はどうやってページを計測・評価するのかといった面を考えてみましょう。計測するためにはパフォーマンスツールが必要です。いろいろあるのですが、大きくは2つに分けられると思います。Packet SniffersはWebページのコンポーネントつまり画像などの部品がどのようにダウンロードされているのか教えてくれます。Performance Analyzersはあらかじめ決められた項目を評価してくれるツールです。まぁ、見てみましょう。
Packet Sniffers
Fiddler, Firebug Net Panel, Web Inspector Resources Panelひとつひとつがバーチャートがコンポーネントを表しています。チャートの長さがダウンロードにかかった時間ですね。このようにグラフィカルに表示してくれるので、どのバーチャートが一番長いのか着目すれば、ボトルネックがすぐ見つかります。これを取り去るか縮小させれば表示速度改善につながりますね。とはいっても、このように差がはっきりしていないときもありますので、パフォーマンス初心者にとってはちょっと敷居高いかもしれません。
Performance Analyzers
GoogleつくったPage Speedというのものありますが、これ見た感じ文字ばっかて嫌になっちゃいますよね評価項目も細かいことばかりです。これはGoogleだからやっていることなので普通のサイトに当てはめるのはちょっと酷です。ということで、僕はこちらをお薦めします。YahooがつくったYSlowです。13項目の視点からWebページをABCDEFの6段階でランク付けてくれます。これは良いですね。先程のPacket Sniffersは見たいに読み取る必要がないためです。総合評価がDと言われば次はCを目指そうと思うじゃないですか。各項目毎に評価してくれるのでちょっと見てみるとHTTPリクエストを減らしなさいよなどと注意されています。Componentsはページの部品・パーツがどのくらいの数ダウンロードされているのか教えてくれます。Statisticsはコンポーネントの種類毎の容量が全体でのどのくらいの割合を占めているのか円グラフで表示してくれます。どうでしょうか、分かりやすい機能でやる気になってきませんか？僕は勝手にやる気になってきたので日本の主要なサイトをYSlowで評価してみました。
2009/10/14 YSlow Ruleset applied: Classic(V1)での評価
D, E, Cとか低い評価が目立ちますよね、これは仕方ないのかもしれません。というのも大抵のパフォーマンスを意識していないサイトはDかEといった評価になります（Ruleset:Classic(V1)で）。Cぐらいになって初めてここはちょっとパフォーマンスを意識しているなと感じるくらいです。Aにいたっては僕は2サイトしか知らないですね。GoogleとYSlowを作った米Yahoo!です。
そのGoogleなんですが、シンプルなページだからA評価当たり前だよねと思っちゃいそうですが、実は裏側を見てみますと。10個以上あったアイコンはCSSスプライトで1つの画像にまとまっていたり、シンプルなページであるのにも関わらず、さらに改行など取り除いてHTMLを圧縮しているなどの努力が見られます。こういった面もYSlowなら見逃さず評価してくれます。
YSlowの使い方ですが、最初のインストールをしてしまえば、ほんの2,3ステップでチェックできるので、是非皆さんも、自分のサイト、競合他社、大手のサイトなどチェックしてみて自分がどういう位置にいるのか確認してみてください。
というわけで、計測できないものは改善のしようがないということです。つまり、何か対策を行って評価しなければ次につながりません。対策→評価→対策→評価、このサイクルを回していくことで自ずとパフォーマンスは向上していくでしょう。
4. What should I do to improve?
では、パフォーマンスを改善するために私たちは何をすべきなんでしょうか？Yahoo!が出している高速サイトを実現するための14のルールは先程紹介したYSlowの評価項目に対応しているので、ハイパフォーマンスWebサイトの本と共に対策していけば良いでしょう。
- HTTPリクエストを減らす
- CDNを使う
- Expiresヘッダを設定する
- コンポーネントをgzipする
- スタイルシートは先頭に置く
- スクリプトは最後に置く
- CSS expressionの使用を控える
- JavaScriptとCSSは外部ファイル化する
- DNSルックアップを減らす
- JavaScriptを縮小化する
- リダイレクトを避ける
- スクリプトを重複させない
- ETagの設定を変更する
- AJAXをキャッシュ可能にする
さらにYSlowでA評価とった人のためにもっと細かい20のルールとしてこんなことも提示されています。
はたまた、Yahoo!に重複するところもありますが、GoogleのPerformance Best Practicesというのもあります。
てか、多いですよねｗ Too Many!
これら全て対策しようと思ったらWebページのパフォーマンスがあがる前に、制作者のパフォーマンスがダウンしてしまいます。しかも、ほとんどの会社にはWebパフォーマンスを専門で担当する人なんていないと思います。僕もパフォーマンスばかりやってるわけではないですから。ここで重要なのは対策を闇雲にこなすのではなく、効果的なものから優先度をつけて順にやれるところから行っていくことです。つまり、使えるリソースは有限だということです。
Make Fewer HTTP Requests
HTTPリクエストを減らす
HTTPリクエストを減らす
ということで、今回最も有効な対策、一番始めに考えるべき対策としてこれを挙げます。今日はこれだけです。本当にこれだけです。先程の14の対策を紹介したのですが、14全てやれば100%パフォーマンスが改善されるのかというと、そうでもありません。先のルールは有効的な対策として考えられるものから列挙してあるので、一番最初に紹介されているHTTPリクエストを減らすに対応するだけサイトが50%も速く表示されるようになったと言うケースも報告されています。
What’s HTTP Requests?
HTTPリクエストとはなんぞ？ってことですが、画像、スクリプト、スタイルシート、FlashなどのサーバーにHTTPプロトコルでサーバーにリクエストしているものですね。Make Fewer HTTP Requests
HTTPリクエストを減らす方法としてハイパフォーマンスWebサイトの本では以下のようなことを挙げています。Image Maps
うん、Webをまったく知らなかった大学生の頃に多用した。ボタンなどの画像を1個1個切り出すよりもまとめて1枚画像としたほうがリクエスト減らせますよと言うことです。
CSS Sprites
先程のGoogleのように、CSSを用いて一枚の画像を複数の画像のように見せることでリクエスト数を減らしています。
Inline Images
URLに画像データを長っい文字列として表現してそこから画像を生成するのでリクエストをしない。が多用するとコード量が増えるのが難点。
Combined Scripts and Stylesheets
JSとかCSSファイルをモジュール毎に管理するのは良いのだけれど、パフォーマンス的にはそれら１個にまとめた方が良いよとのこと。（開発時はモジュールで管理してページ生成時に動的にファイルを結合するやり方もあるのでシステムさんに相談してみよう。modconcatとか）
というか、めんどくさいっすよねｗｗ
なんでこんなめんどくさいことをやらなければいけないのか。
そうは思いませんか。僕は思います。
似たような話でSpace Penという話がありますのでちょっと紹介。
ここで重要なのはボールペンという枠組みに固執することなく鉛筆という解を導き出したということです。今回のケースにおいてこの鉛筆にあたるのは何でしょうか？僕はデザインだと考えます。
つまり、デザイン・設計の段階からパフォーマンス意識すれば難しいことはしなくてもいいんです。最初からHTTPリクエストを増やすようなデザインにしなければいいんです。
じゃなぜ、HTTPリクエスト一杯のデザインになってしまうのでしょうか？そう考えたときに、僕の短いWebデザイナー人生とネットサーフィンをしてて思うサイト制作者が陥りやすい3つの欲求としてこんなことが挙げられるんではないかと思います。自分も含めて。
目立たせたい！
あれやこれやと目立たせることで画像だらけになってリクエストが増えてしまう。
多機能にしたい！
あれやこれやと機能を付加することでJSファイルの読み込みすぎといったことが考えられます。
とりあえず、全部載せたい
あれやこれやと自サイトのセールスポイントを挙げてしまい長大なページになってリクエストも増える。
これらを考える上で、Jesse James Garrettの5 Planes Modelをフレームワークとして使うと、第1の目立たせたい！は表層、骨格に当たる問題だと考えます。
1. 目立たせたい！
そもそも目立つとは何なのでしょうか。目立つ目立たないは周りとのオブジェクトの対比であって、必ずしも画像にすれば良いというわけでありません。
このCaseのようにさまざまなステークホルダーが主張を通した結果、1ページに沢山の画像が溢れています。このようなページが本当に制作側の思い通り、見られるのか検証してみる必要あります。Feng-GUIという人間の視覚の動きをシミュレートしてくれるサービスがあるので、先程のページデザインをシミュレートしてみると、全ての画像が目立っていないことが分かります。
また、本当に画像にすれば目立つのかという疑問が僕の中で大きかったので実験してみました。自分のブログにて、右上部に「CSS Nite 石川に出ることになりました」というバナーを置いて、テキストリンク・画像ボタンで「詳細はこちら」表現したものを比較してみました。結果、テキストリンクで表示したほうが画像ボタンに比べて、90%以上多くクリックされました。（参考：CSS Nite in Ginza, Vol.37：フォローアップ）
また、クックパッドのプレミアム会員への入会導線比較においても、バナー画像よりも、テキストリンクの方が3倍の効果を挙げたというデータが出ています。文脈（このケースの場合、プレミアムサービスに検索結果の並べ替えが含まれていたので、検索結果ページでの誘導が効果を発揮したということが分かる）を理解すれば必ずしも画像にする必要はないということが分かります。（出典：CSS Nite in Ginza, Vol.32：フォローアップ）
つまり、デザインというのはデコレーションではありません。大事なのはコンテンツです。厚化粧することコンテンツを見えにくくしてはいけません。デザインというのはコンテンツをうまく伝えるための最適な手段を考えることです。
2. 多機能にしたい！
骨格、構造、要件、多岐にわたる要素を含んでいます。この背景にはjQueryやPrototypeなどのAJAXライブラリが普及してきたことによって、Webデザイナーでも比較的簡単にインタラクティブなサイトを制作できるようになってきたことが考えられます。また、個人レベルにおいてもブログパーツの浸透などで、安易にブログパーツは貼り付けていけば、それに伴いJSファイルなどの増加の危険性が考えられます。自分のブログが何位だとかそういった自己顕示欲を主張するパーツなどはどんどん取り去っていけば良いのですが、リッチインタラクションと呼ばれる部分は難しいものがあります。
カルーセル、アコーディオン、ドラッグ&ドロップなどのリッチインタラクションはある人にとっては便利と感じるかもしれません、しかしある人にとってはよく分からないと映るかもしれません。何を採用して何を採用しないか判断するためにはウェブ解析をする必要あります。
Google Analyticsであなたのサイトのユーザーが使っているブラウザが何なのか分かります。もし、IE6などの古いブラウザのユーザーが大半ならば、リッチインタラクションを実現するためのJSファイルでブラウザがもたつくかもしれません。そうゆう場合はやめておいたほうが無難でしょう。
Google Website Optimizerでは先程のバナーテストのように多変量テスト、A/Bテストが可能です。テストした結果、リッチインタラクションがあったほうが、コンバージョン率がいいというのなら採用しても良いかもしれません。
User HeatはFeng-GUIのように大まかなヒートマップを作成してくれます。もし、該当の機能部分がまったく見向きもされていなければ、素直に外しておきましょう。
何かを追加すれば、誰からしらの役に立つから良いのではないかと考えがちですが、37Signalsも自問していることに、”価値とは加えることと取り去ることのバランスなのです”とあるように、時としては引き算をすることで価値を増やせることも可能なのです。
結局はユーザーが何を欲しているのか、聞かなければなりません。Webデザイナーであろうとも、ウェブ解析ツールなど使うことで（今回紹介したツールはすべて無料）ユーザーのフィードバックを得ることできます。そして、無用な機能を実現するためのリクエストを削減することができます。
3. とりあえず、全部載せたい！
これは要件、戦略にあたる内容でしょうか。長すぎるページというのが存在します。果たして、このようなページは本当に読まれているのでしょうか？Click Tale社の調査によると、ページの露出は上部から540pxを境に急激に下降しており、ユーザーが流し読みしていることが考えられます。なぜユーザーは流し読みするのでしょうか。Jakob Nielsenは以下のことを挙げています。- コンピュータ画面で読むのは目が疲れる。
- ウェブはユーザ主導型のメディアである。
- 他の何億ものページと競争しなくてはならない。
- 現代生活はあわただしい。
読まれないのなら読まれないで結構なのですが、Webサイトが存在する以上、なんらかのビジネスゴール：サイトの目的、ページレベルで言えば、してほしいアクションがあると思います。企業サイトであれば、資料請求のボタンを押すとかEコマースサイトならば商品をカートに入れるなどのアクションが考えられます。そういったアクションが長大なページの中に存在すれば、コンバージョンを下げる可能性も出てきます。
決断に要する時間は、選択肢が増えるほど長くなる。
ヒック・ハイマンの法則
ヒック・ハイマンの法則
つまり、目的を分割する必要があります。この辺はiPodの戦略がうまいかと思います。iPod, iTunes, iTunes Storeで目的を分けることで最適なエクスペリエンスを提供しています。考えてもみれば、iPodの小さな画面で曲名なんて編集したくないですよね。
Webサイトも同じで1ページ 1テーマ 1スクリーンを心がけることで、サイト制作者はユーザーに伝えたいことをより正確に伝えられるわけで、ユーザーもより理解が早くなる。そしてHTTPリクエストが必要以上に増えることもない。そのためには自分がサイトで何を伝えたいのか、ユーザーにどうしてほしいのか考えることで無駄をそぎ落とすことが可能です。
結局は人は求める結果が利益となると思うのなら待つのです。おいしいと評判のお店があると聞いたら並んで待つでしょ？僕もFlashの神様と言われる中村勇吾さんが制作したFlashサイトなら3分でも待ちますよ。
しかし、一般的に、ユーザーが検索でたまたま見つけたサイトでは、あなたのサイトが本当は素晴らしいモノを提供していてもユーザーはその時点では知らないのです。ですので、そこで機会損失してしまうよりかはパフォーマンスをできる限り向上させておくのが吉となるのではないでしょうか。
5. Conclusion
パフォーマンスは収益やUXに大きく影響します。YSlowという計測ツールを手に入れました。パフォーマンスを上げるためにHTTPリクエストを減らすことが最優先事項です。そのためにはサイトで何をしたいのか、明確な目標を定めることが必要です。そうすれば、一貫性のあるデザインをすることができ、簡潔なコードにつながり、ハイパフォーマンスWebサイト！みんなHAPPY！
ありがとうございました。
Thank you!
