Chromeはなぜ速いのかTweetNewsInsight[Analysis]Chromeはなぜ速いのか2008/12/22Chromeの動作が圧倒的に速いように感じている。Chromeがリリースされた当初、それがなぜなのかよく分からなかった。グーグルだけにできて、ほかのWebブラウザ開発者にできないことなどあるように思えないが、それにしてはあまりに速いように感じたからだ。その疑問のほとんどは、Chromeのオープンソースプロジェクト版「Chromium」の公式ブログの解説で氷解した。ブログを読んで分かったのはグーグルのエンジニアたちが信じられないほどのスピード狂であることと、そのスピードへのこだわりには2種類の“スピード”があることだ。1つは処理速度、もう1つは応答速度だ。後者、ユーザーをできるだけ待たせない、イラつかせないということに対する徹底したこだわりは、すさまじい。その背後には「スピードとは、つまりお金だ」という洞察があるようだ。2.0関連イベントのWebGuildで行った講演で(講演ビデオ)、“スピード”にこだわる理由を、自分たちの経験から得た知見とともに述べている。バイス・プレジデントのマリッサ・メイヤー氏1つは検索サービスに関するユーザーテストの結果だ。通常、検索結果には1ページ当たり10のリンクが含まれるが、ユーザーにどのぐらい検索結果数がほしいかと尋ねると、ほとんどの人がより多くと答えたという。ところが、実際に結果数を30に増やして実験したところ、トラフィックも収益も20%も落ちてしまったという。理由は、10の結果を返すのに0.4秒だったものが、30の結果を返すのに0.9秒と0.5秒余計にかかっているから、だったという。この話に関して元Amazon.comの開発者のグレッグ・リンデン氏は、ブログでこう述べている(リンク)。Amazon.comでもわれわれは同様の経験をしている。100ミリ秒単位でページ表示を遅らせるA/Bテスト(条件を変えて2つのサービスを同時に公開するテスト)で、非常に小さな遅延ですら、収入に大きく響いてくるということを発見した。速いというのは本当に大切なことだ。マリッサが言うように“ユーザーはスピードに敏感に反応する”のだ」(リンデン氏)メイヤー氏は、Googleマップでは、Webページを100KBから70〜80KBに減らしたことで翌週にトラフィックが10%、その後3週間で25%伸びたことがあるとも指摘する。言うまでもなく、グーグルは収益のほとんどを広告でまかなっており、それはトラフィック量に比例する。グーグルにとって、スピードを稼ぐことは価値を生む行為そのもので、それは収益最大化という企業の論理からも正当化できるリソースの投下方法なのだ。ユーザーはページが重いとか遅いなどと文句は言わない。遅くなっても気付きもしない。来なくなるだけなのだ。ユーザーの意識に上るような遅さは論外だが、無意識レベルの遅れであっても確実に数字に表れるというわけだ。起動シーケンスに見る「応答性」へのこだわり「Webブラウザが速い」といったとき、これまでは一般にHTMLのレンダリングが速いことや、JavaScriptエンジンの処理が速いことが、その基準として注目されてきた。Chromeではこれまで注力されてこなかった「応答性」について、徹底して最適化しているようだ。それがユーザーが感じる速さにつながっているのだと思う。グーグルのソフトウェアエンジニア、ブレット・ウィルソン氏が10月8日に投稿したブログエントリには、こうある。Chromeの目標は、このブラウザをできるだけ速くすることだった。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ではボタンなどのコントロールも“ウィンドウ”として扱われ、親ウィンドウに対して子ウィンドウがたくさん生成される。この階層化されたウィンドウ間をメッセージが上下するとき、もしどこかでメッセージ処理が止まれば、親ウィンドウは待ちに入ってしまう。レンダラーが何かの処理で時間がかかったり、止まってしまったら、その間は親ウィンドウのブラウザ自体がユーザーからの反応を受け付けなくなるということだ。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が高速化して、むしろその傾向が強まったようにも感じている。users)と喝破している(リンク)。今のようにJavaScriptライブラリが充実する以前、Ajaxは開発者にとっては高いスキルを要求する複雑な仕事だったが、それでもユーザーを待たせないため、イライラさせないため、あるいは他サービスとの差別化のために、気が利いた開発者はこぞってAjaxやCommetといった技術を採用し、発展させもしてきた。Ajaxが非同期の通信であるのと、Chrome中のプロセス間の処理が非同期で複雑になっているのは偶然の一致ではないと思う。それはたとえ処理モデルやコーディングが複雑になろうとも、ユーザーを待たせない(ユーザーをないがしろにしない)ために、裏でできる限りのことをやろうという技術者たちの努力の現れだ。この意味でChromeはWeb2.0的なWebブラウザだと思う。ところで「Web2.0」は、もはや物事の分かった大人が口にしてはいけない言葉のような雰囲気があるが、「ユーザーをないがしろにしないこと」という技術革新のムーブメントを含意する言葉としてであれば、今でも意味があると思う。今後はデスクトップやネットよりもずっと広い世界、一般社会で使われるコンピュータという文脈でこそ、こうした技術の価値が増してくるのではないかと思う。(2017/7/12)資料を作る際に、「グラフ」は必要不可欠な存在だ。(2017/6/26)素数判定のロジックからbreak文やcontinue文の利点と使い方を解説。マーケティング」新着記事Accenture調査から見えた2020年の5つのテクノロジートレンド「テック・クラッシュ」を乗り切るにはどうすればいいのか。AccentureのCEOおよびCTOの記...電話サポートの保留音、世界の主流はクラシック——Genesys調査13カ国で実施した電話サポートの保留音に関する調査結果です。「フードロス」「廃プラスチック」に高い関心——CCC調査エコ・環境問題への関心や関連トピックスへの認知度などを調査しています。