この部活について

何故、Webサイトはパフォーマンスが求められるのか?

どれだけ素晴らしいデザインであっても、どれだけ便利なサービスを提供していても、そのWebサイト自体がキビキビと高速に動作しないのであれば、ユーザはストレスを感じて、アクセスしなくなるでしょう。

Webサイトとは、鑑賞するためのものではなく、何かしらの「体験」を提供する工業品としてのソフトウェアであり、Webデザインは美術的な美ではなく、機能的な美が求められます。その意味において、Webデザインとは、工業デザインであり、その中でも「速度」という要素は重要な設計要素の一つです。

人の脳の本質として、常に処理すべき刺激を求めるが故に、思考を停止させることは苦痛であり、人は「待たされること」を嫌います。ですから、Webサイトに限らず、人は遅いものが嫌いです。

待つことが苦痛であるが故に、待つことで価値が上がっていくものもあります。例えば、ワインです。
しかし、Webサイトに、そのような価値を求める人は、殆ど居ないでしょう。

コンピュータ・システムのパフォーマンスの重要性については、今を遡ること40年以上も前の、1968年の時点で、ロバート・B・ミラー氏が秋季ジョイント・コンピュータ会議で発表しています。

  • システムが即座に反応していると感じるのは、0.1秒。
  • ユーザの思考の流れが途切れないと感じるのは、1秒。
  • 何のフィードバックもなしにユーザが待てる限界は、10秒。

昨今は、Webサイトの設計において、UX(User Experience)を重視するようになってきています。
ここで、アメリカのカール・W・ビューナーの箴言をご紹介しましょう。

They may forget what you said — but they will never forget how you made them feel.
(人はあなたの言ったことは忘れる、しかしどんな気持ちにさせたのかは決して忘れない。)

UXの観点からも、パフォーマンスは重要であり、ユーザは遅いサイトにはそれほど我慢強くなく、遅いという体験を忘れない事を留意することが、ビジネス上重要です。

「改善手法ありき」ではなく、定常計測データの分析に基づく改善の重要性

日本においては、Webパフォーマンスの定常計測が根付いていません。

多くのWeb技術者は、日本のインターネット環境やモバイル環境が世界でも随一であることから、速度について気に留めることがありませんでした。

しかし、欧米では、日本のような高速なインターネット環境はあまり浸透しておらず、そのために、Web技術者はパフォーマンスに留意する必要があり、計測が必須となりました。

その結果、欧米のWebサイトは、日本のWebサイトより高速で表示されるものばかりです。欧米の著名なWebサイトのトップページのダウンロード時間が平均して1秒を切るのに対して、日本のそれは平均で3~6秒もかかっているのです。

また、その一方で、Webサイトのパフォーマンスや可用性(繋がりやすさ)は、Webサイトの配信の品質管理の側面も持ちます。

日本の製造業においては、品質管理が広く普及・発展し、世界に名立たる品質の高さを保持しています。
しかし、同じ日本でも業界が違うソフトウェア開発、特にWeb制作については品質管理の概念が欠けています。
従来の「設計」に対する品質管理はソフトウェア業界にもありましたが、「配信」という、インターネット経由でWebページの「部品」を送り込んでユーザのブラウザ上で「製造」するという事は、1998年からADSLによって始まったブロードバンドの普及以前にはなかった仕組みです。

諸外国に比べて、統計学の教育が普及していない事も、Web技術者の間に、正しい品質管理の概念が普及しない要因でした。

そのような状況の中、スティーブ・サウダーズ氏の「ハイパフォーマンスWebサイト」「続・ハイパフォーマンスWebサイト」(オライリー・ジャパン刊)が日本のWeb技術者の間で読まれるようになり、いつしか、計測データを分析してボトルネックを判別して改善するのではなく、改善手法のベストプラクティスありきの改善が主流となってしまいました。

しかし、品質管理とは、実際の「完成品」を定常的にチェックすることで、「規格に満たさない」製品を世の中に出さないことです。定常的な計測を行わず、またそのデータを持たずに、サイトのパフォーマンスや可用性(繋がりやすさ)の改善を行うことは、品質管理ではありません。

今こそ、日本のIT業界、Web業界も、世界のIT企業やWebサイトと競争していく上で、製造業に学び、品質管理を導入すべき刻を迎えていると考えます。

この部活が果たすべき役割

上記のような日本の事情を鑑み、このコミュニティでは、以下の役割を果たすべく、創設されました。

  • パフォーマンス計測の重要性をWeb技術者の間で広く認知してもらう。
  • 統計学や品質管理で基本となっているR・A・フィッシャーの「実験計画法」に基づく、パフォーマンス計測手法を普及させる。
  • パフォーマンス管理・改善は、部分最適化ではなく、システムの全体最適化である。パフォーマンス管理・改善が行える、ネットワークレイヤーからアプリケーションレイヤーまで技術的に包括的理解し、且つ、UXを考慮した取捨選択ができる、ビジネスドメインにも詳しい技術者を目指す人達の情報交換の場を担う。
  • 統計分析手法を使って、データに基づくパフォーマンス改善ができるWeb技術者を目指す人達の交流の場を提供する。

日本では、今、どの企業も当たり前に行っているWebのアクセスログ解析ですが、それが普及するまでには、Google Analyticsの元となったUrchinが日本に上陸してから10年かかったと言われています。

インターネット、ソフトウェア、ライフサイエンスの3つの業種が主体となって世界経済を牽引しているイノベーション産業が、データドリブンで発展していく中で、10年も後塵を拝していては、日本の国際競争力は回復しないでしょう。今こそ、世界の統計教育重視の流れと共に、データ主導のシステム開発・改善の流れを日本のインターネット、ソフトウェアにも、一緒に定着させて行きましょう!

html5j パフォーマンス部 部長 竹洞 陽一郎

World Wait Web is here !?

あなたはこのWebページを完全な形で閲覧するために
なんと???ミリ秒も待たされてしまいました!
何が問題だと思いますか?

Webページ読み込み方法(Navigation Timing)T/F
ナビゲーションハイパーリンク/ブックマーク等からの読み込みブラウザ
非対応
履歴チェーン参照「戻る/進む」ボタン押下、かつキャッシュ不在時の読み込みブラウザ
非対応
リロード「更新」ボタン押下、スーパーリロードによる読み込みブラウザ
非対応
全体のタイムライン(Navigation Timing)経過時間
ナビゲーション開始ハイパーリンクや更新ボタンがクリックされた瞬間の状態ブラウザ
非対応
Webページ読込開始リダイレクトが完了し実サーバを発見、キャッシュ確認の開始ブラウザ
非対応
ドメイン名解決開始DNS/NetBISO名の名前解決を開始ブラウザ
非対応
Webサーバ接続開始TCP 3ウェイハンドシェーク、SSL確立の開始ブラウザ
非対応
HTTP Request開始HTMLファイルが置かれているサーバへHTTP Requestを発行ブラウザ
非対応
HTTP Response開始HTMLダウンロードが開始ブラウザ
非対応
HTML+ブロック型リソースパース開始HTML解釈の開始、IE/Firefox/Safariの描画開始ポイントブラウザ
非対応
HTML Response完了HTMLダウンロード完了の状態、Chromeの描画開始ポイントブラウザ
非対応
HTML+ブロック型リソースパース完了HTML/CSS/JSのパースとDOM生成が完了した状態ブラウザ
非対応
非ブロック型リソース読込完了画像/音声/動画等のファイル読み込みが完了した状態ブラウザ
非対応
ナビゲーション完了loadイベントの実行処理が終わった状態ブラウザ
非対応
HTML処理内訳(Navigation Timing)処理時間
unloadイベント実行時間前Webページの情報を破棄する直前のイベントの処理時間ブラウザ
非対応
domContentLoadedイベント実行時間DOM生成完了直後に実行されるイベントの処理時間ブラウザ
非対応
loadイベント実行時間リソース読込完了後に実行されるイベントの実行時間ブラウザ
非対応
リダイレクト実行時間短縮URLや検索エンジンから到達した際のリダイレクト時間ブラウザ
非対応
キャッシュ確認実行時間HTML5 AppCache/RFC2616 Expires参照に要した時間ブラウザ
非対応
ドメイン名解決実行時間DNS名/NetBIOS名の名前解決に要した時間ブラウザ
非対応
TCP接続処理時間TCPの3ウェイハンドシェーク/SSL確立に要した時間ブラウザ
非対応
HTTP Request事前処理HTTP Requestを行う直前の前処理に要した時間ブラウザ
非対応
HTML Response待ち時間HTTP Requestを送信後HTTP Responseが応答する時間ブラウザ
非対応
HTML Response読込時間HTTP Responseが応答してから読み込み完了までの時間ブラウザ
非対応
HTML+ブロック型リソース読込時間HTML/JS/CSSのパースに要した時間ブラウザ
非対応
非ブロック型リソース読込時間HTML/JS/CSSパース後、残りの画像等のリソース読込の時間ブラウザ
非対応
「ユーザ制作リソース」内訳(Resource Timing)取得時間
「いいねボタン」内訳(Resource Timing)取得時間
「ツイートボタン」内訳(Resource Timing)取得時間
「+1ボタン」内訳(Resource Timing)取得時間
「はてなブックマーク」内訳(Resource Timing)取得時間