[Analysis]

Chromeはなぜ速いのか

2008/12/22

speed.gif

 Chromeの動作が圧倒的に速いように感じている。Chromeがリリースされた当初、それがなぜなのかよく分からなかった。グーグルだけにできて、ほかのWebブラウザ開発者にできないことなどあるように思えないが、それにしてはあまりに速いように感じたからだ。

 その疑問のほとんどは、Chromeのオープンソースプロジェクト版「Chromium」の公式ブログの解説で氷解した。ブログを読んで分かったのはグーグルのエンジニアたちが信じられないほどのスピード狂であることと、そのスピードへのこだわりには2種類の“スピード”があることだ。

 1つは処理速度、もう1つは応答速度だ。特に後者、ユーザーをできるだけ待たせない、イラつかせないということに対する徹底したこだわりは、すさまじい。その背後には「スピードとは、つまりお金だ」という洞察があるようだ。

0.5秒の遅延でユーザー離れ

 グーグル創業約1年後の1999年に、最初の女性社員として同社に加わった現バイス・プレジデントのマリッサ・メイヤー氏が、2006年にWeb 2.0関連イベントのWebGuildで行った講演で(講演ビデオ)、“スピード”にこだわる理由を、自分たちの経験から得た知見とともに述べている。

marissa.jpg 米グーグル バイス・プレジデントのマリッサ・メイヤー氏

 1つは検索サービスに関するユーザーテストの結果だ。通常、検索結果には1ページ当たり10のリンクが含まれるが、ユーザーにどのぐらい検索結果数がほしいかと尋ねると、ほとんどの人がより多くと答えたという。ところが、実際に結果数を30に増やして実験したところ、トラフィックも収益も20%も落ちてしまったという。理由は、10の結果を返すのに0.4秒だったものが、30の結果を返すのに0.9秒と0.5秒余計にかかっているから、だったという。

 この話に関して元Amazon.comの開発者のグレッグ・リンデン氏は、ブログでこう述べている(リンク)。「この結論に驚くかもしれない――、ユーザーが0.5秒の遅れに気付くかって? しかし、Amazon.comでもわれわれは同様の経験をしている。100ミリ秒単位でページ表示を遅らせるA/Bテスト(条件を変えて2つのサービスを同時に公開するテスト)で、非常に小さな遅延ですら、収入に大きく響いてくるということを発見した。速いというのは本当に大切なことだ。マリッサが言うように“ユーザーはスピードに敏感に反応する”のだ」(リンデン氏)

 メイヤー氏は、Googleマップでは、Webページを100KBから70〜80KBに減らしたことで翌週にトラフィックが10%、その後3週間で25%伸びたことがあるとも指摘する。

 言うまでもなく、グーグルは収益のほとんどを広告でまかなっており、それはトラフィック量に比例する。だからグーグルにとって、スピードを稼ぐことは価値を生む行為そのもので、それは収益最大化という企業の論理からも正当化できるリソースの投下方法なのだ。ユーザーはページが重いとか遅いなどと文句は言わない。たぶん少しぐらい遅くなっても気付きもしない。単に来なくなるだけなのだ。ユーザーの意識に上るような遅さは論外だが、無意識レベルの遅れであっても確実に数字に表れるというわけだ。

起動シーケンスに見る「応答性」へのこだわり

 「Webブラウザが速い」といったとき、これまでは一般にHTMLのレンダリングが速いことや、JavaScriptエンジンの処理が速いことが、その基準として注目されてきた。しかし、Chromeではこれまで注力されてこなかった「応答性」について、徹底して最適化しているようだ。それがユーザーが感じる速さにつながっているのだと思う。

 グーグルのソフトウェアエンジニア、ブレット・ウィルソン氏が10月8日に投稿したブログエントリには、こうある。

「当初のわれわれのGoogle Chromeの目標は、このブラウザをできるだけ速くすることだった。しかし、生の速度(raw speed)に加えて高い応答性を持つようにしたかった。結局のところ、ページがいくら速くロードできたって、ユーザーインターフェイスが固まったら意味がないんだから!」(ウィルソン氏)

 応答性を良くするための工夫は数多いが、典型的なのは起動シーケンスの工夫だという。Chromeは起動時にchrome.exe、chrome.dllのほか、設定ファイルを読むだけで、ひとまずウィンドウを描いてしまう。実際にWebページを開くのに必要なサブモジュールは数多いが、きわめて少ない処理で、ユーザーには起動したように見せる。これにより、ユーザーはすぐに操作を始めることができる。Chromeユーザーなら、空白のタブに頻繁に訪れるWebページのサムネイルが表示されるまでにワンテンポ間があるのに気付いているだろう。ネットワーク関連のライブラリやブックマーク、キャッシュ、クッキーなどは、最初にWebアクセスの要求があってから初めてディスクからメモリ上にロードされるという。

 すべての処理が終了するまでの時間だけが重要なのではない。処理の流れや順序の工夫、あるいは見せ方でユーザーの体感速度は大きく変わる。ともかく最初の画面はできるだけ速く表示する、というアプローチは、ヤフーのWebマスターチームが「Webサイト高速化の34の秘訣」の1つとして公開したテクニックにも似ている。スタイルシートをHTMLの先頭(HEAD)に書くことで、Webブラウザが表示をスタートするタイミングがぐっと早くなる。全体を表示し終わる時間が同じでも、読み込んだものから順に表示するのと、すべてを読み込んでから表示するのとでは大違いだ。こうしたWebサービスの常識を、Chromeはデスクトップ上に持ち込んでいるとも言えるだろう。

ロックやディスクI/Oを減らす

 Chromeを貫く設計方針として、応答性を上げるためにI/Oアクセスをできる限り減らすというものがあるという。当初からグーグル自身が宣伝していたように、Chromeはマルチプロセスモデルを使っているが、ブラウザ本体、レンダラーと呼ばれる描画プロセス、プラグインは、それぞれ別プロセスとして稼働する。ブラウザ本体は、ユーザーとのやり取りを行うキモであるため、このプロセスからのディスクI/Oは一切禁止しているという。「ファイル名を付けて保存する」で表示されるダイアログですら別プロセスだ。CPUの高速化がめざましい一方、ディスクの読み書きは相変わらず非常に遅いため、1にも2にもディスクI/Oを減らすのだという。

 Chromeではブラウザ本体(のプロセス)の応答性を悪くする要素を注意深く取り除いているという。各タブのプロセスはブラウザ本体とデータやメッセージをやり取りするが、ここでタブがロックしたりフリーズしたときにブラウザが“待ち”にならないよう、レンダラーに子ウィンドウを生成させないようにしているという。Windowsではボタンなどのコントロールも“ウィンドウ”として扱われ、親ウィンドウに対して子ウィンドウがたくさん生成される。この階層化されたウィンドウ間をメッセージが上下するとき、もしどこかでメッセージ処理が止まれば、親ウィンドウは待ちに入ってしまう。レンダラーが何かの処理で時間がかかったり、止まってしまったら、その間は親ウィンドウのブラウザ自体がユーザーからの反応を受け付けなくなるということだ。一瞬固まるという感覚は、Internet Explorerではよく経験するところだ。

 このためChromeではレンダラーには子ウィンドウを生成させず、またレンダリング結果を直接タブのウィンドウに描画するのではなく、いったん画面表示されない領域にビットマップとして描画し、それをタブのウィンドウに転送するようにしているという。

 このルールでうまくいかなかったのはプラグインの実装で、プラグインが子ウィンドウを生成するのは仕様上禁じることができなかったという。プラグインが不調だと、そのWebページを閉じるという操作もままならなくなる。そこでChromeでは一定間隔でプラグインの反応を調べ、反応が悪くなっているプラグインがあれば、ユーザーに対してプラグインを停止するかどうかを聞くダイアログを表示するようにしている。

 複数プロセスが非同期で処理や通信を行うというアーキテクチャを採用した結果、Chromeでは処理やコードが複雑になった面はあるという。それでもウィルソン氏は、最速というだけではなく、最高に応答性が良いブラウザにするという当初の目標を達成するのにこのアプローチが役立っていて、それは十分に価値があることだったとしている。

アンチフィッシングでも工夫

 Chromeにはフィッシング詐欺や、不正なコードが仕込まれたWebサイトからユーザーを守るための仕組みがある。これはグーグルがネット全体をクロールする最中に発見した怪しいWebサイトのURLに対してユーザーがアクセスしようとしたら警告を出す仕組みだ。この機能を実現するために、数十万にもなるという膨大なURLリストをChromeクライアントは、グーグルのサーバからダウンロードしている。最初は起動後5分以内に、その後は約30分おきに最新のURLリストを逐次ダウンロードしている。このリストはURLを素直に書き連ねたテキストファイルではなく、SHA-256に基づくハッシュ値となっている。さらにおもしろいのは、256ビットすべてではなく先頭32ビットの値だけが送られてきているということだ。

 このURLリストのバイナリデータはディスク上で55MBほどある。もしこれがSHA-256の256ビットすべてだったら、この8倍の440MBのディスクが消費されていただろう。256ビットのうち先頭32ビットとすることによるディスクI/Oやネットワーク帯域、メモリ消費などパフォーマンス上のメリットは大きい。危険のないURLのハッシュの先頭32ビットが、危険なURLのリストにあるいずれかのハッシュの先頭32ビットと偶然ぶつかってしまう“擬陽性”は起こり得るが、その確率はきわめて低い。また、たとえ擬陽性と判定されても、再度256ビットをグーグルのサーバに送って検査することで確実に判定が可能だ。このフィッシング・マルウェア対策の仕組みも、I/Oアクセスを減らすChromeの工夫だという。

体感速度を左右する250ミリ秒の違い

 Chromeを使ってWebを見て回るとき、ほかのWebブラウザに比べてChromeが劇的に速く感じられるのは、ページ表示が開始されるまでの時間だ。初めてChromeを使ったとき、これはいったいどういうマジックなのだろうかと思ったが、やはりChromiumのブログに解説がある。9月18日のブログエントリにある「DNSプリフェッチ」というコロンブスの卵のようなテクニックの紹介がそれだ。

 これは読んで字のごとく、DNSによる名前解決を事前に行うという機能だ。Webページが表示されたら、そのHTMLに含まれる各URLのドメイン名について、先にDNSサーバにクエリを投げて名前解決をし、IPアドレスを取得しておく。こうすることで、処理自体は軽いのに時間がかかりがちなDNSクエリの往復時間を節約できる。通常、ユーザーが実際にクリックしてからDNSサーバにURLを投げて問い合わせ、その返事をもらうまでの往復時間は100〜250ミリ秒で、これがゼロになる。DNSの名前解決はWebサイトによっては1秒や2秒以上かかることもあるが、そうしたものがゼロになると劇的な効果がある(グーグルが計測したDNSクエリの600万サンプルのグラフ)。数字上でも大きな速度アップだが、たまにある「なかなか開かない」ということがなくなるのは、心理的にはかなり効果があるように感じている。

 DNSプリフェッチは、表示されているページ中のリンクだけでなく、起動時のスタートページに関しても行うほか、ユーザーがURLや検索文字列をタイプしている最中でも行っているという。サジェスト機能でどこかのWebページを提示した場合にもプリフェッチをしているという。ユーザーがリターンキーを押すよりも先に、すでにWebブラウザはユーザーが次に訪れそうなドメインのIPアドレスを取得済みというわけだ。

ChromeはWeb2.0的なWebブラウザだ

 グーグルはスピードに取りつかれている。Chromeは、何かコードに変更を加えるたびに、自動的にビルドされ、テストされ、各種パフォーマンスが計測されるという。パフォーマンスが悪くなるような変更は一切加えない、というのが開発に当たって常に従ってきたルールだという。Chrome開発チームは、この自動テストと計測のサイクルをChromeのコードがまだほとんど何も存在していなかった最初期から開始している。パフォーマンスの問題は、開発中の段階で解決するほうが後になってから修正するより簡単だからという。

 数百万人、数千万人、あるいは億単位の人が使うソフトウェアやサービスであれば、ミリ秒単位の高速化のために開発リソースをつぎ込むことには経済的合理性があるだろう。だから、彼らが速い製品を作るのは当たり前だ。逆に数十人とか数百人しか使わない業務アプリケーションは、どうだろうか。3秒かかる処理を1秒にするのに1人月すら投下できないだろう。

 一方、IEやFirefoxでは、どうして今までDNSプリフェッチのような仕組みを考えつかなかったのだろうかと問うことには意味があるように思う。IEの寡占が長く続き、WebやWebブラウザの進化が止まっていたのだ、というのが1つの答えだろう。私は別の答えとして、これまでソフトウェア開発者には応答性を重視したスピードへのこだわりがあまりなかったから、というのがあるように思う(例外がたくさんあるのはもちろん分かっている)。CPUが高速化して、むしろその傾向が強まったようにも感じている。

 Lispハッカーとして知られるポール・グレアム氏は2005年にWeb2.0の本質の1つを「ユーザーをないがしろにしないこと」(not to maltreat users)と喝破している(リンク)。今のようにJavaScriptライブラリが充実する以前、Ajaxは開発者にとっては高いスキルを要求する複雑な仕事だったが、それでもユーザーを待たせないため、イライラさせないため、あるいは他サービスとの差別化のために、気が利いた開発者はこぞってAjaxやCommetといった技術を採用し、発展させもしてきた。

 Ajaxが非同期の通信であるのと、Chrome中のプロセス間の処理が非同期で複雑になっているのは偶然の一致ではないと思う。それはたとえ処理モデルやコーディングが複雑になろうとも、ユーザーを待たせない(ユーザーをないがしろにしない)ために、裏でできる限りのことをやろうという技術者たちの努力の現れだ。この意味でChromeはWeb2.0的なWebブラウザだと思う。

 ところで「Web2.0」は、もはや物事の分かった大人が口にしてはいけない言葉のような雰囲気があるが、「ユーザーをないがしろにしないこと」という技術革新のムーブメントを含意する言葉としてであれば、今でも意味があると思う。今後はデスクトップやネットよりもずっと広い世界、一般社会で使われるコンピュータという文脈でこそ、こうした技術の価値が増してくるのではないかと思う。

(@IT 西村賢)

情報をお寄せください:

TechTargetジャパン

HTML5 + UX フォーラム 新着記事
@ITメールマガジン 新着情報やスタッフのコラムがメールで届きます(無料)

キャリアアップ

- PR -

イベントカレンダー

PickUpイベント

- PR -

アクセスランキング

もっと見る

ホワイトペーパーTechTargetジャパン

注目のテーマ

ソリューションFLASH

「ITmedia マーケティング」新着記事

インターネットは信用できるのだろうか?
パーソナルデータのマーケティングへの利用を消費者はどう感じているか、ソーシャルログ...

フィードフォース、セルフサービスでデータフィードの作成・管理が可能なプラットフォームを提供
フィードフォースは、データフィードの作成・管理・最適化を広告担当者自身で行うことの...

Facebook広告にオフラインでの行動データを活用、アクシオムがデータ提供
フェイスブックジャパンとアクシオムジャパンは、アクシオムが提供するオフラインでの消...