9月15日に米サンフランシスコで行なわれたInternet Explorer 9βの披露イベントに続き、Microsftは報道陣向けのReviewer's Workshop(レビュワー向け勉強会)を行なった。Workshopには実際に開発に携わった人間たちがスピーカーとして登場し、IE9がβ版で達成した性能をどのように引き出したのか、またユーザーインターフェイスの改良をどのように施したのか。開発側の視点からのプレゼンテーションが行なわれた。

　なお、元の記事はすでに修正済みだが、IE9βの削除はプログラムのインストールと削除ではなく、Windowsアップデートの履歴から削除可能だった。アップデートの履歴からIE9インストールの履歴を選んでアンインストールすれば元の状態に戻る。筆者の環境も英語から日本語へと無事遷移させることができた。

　Workshopではさまざまな説明が行なわれたが、それらを集約してIE9を筆者の言葉で表すならば、“Webアプリケーションの時代に即したブラウザ”だ。

　IEはこれまで、インターネット上の情報を閲覧する道具として開発された時代、Webが動的なコンテンツとなりインタラクティブ性を持つようになった時代、そしてWeb 2.0以降のアプリケーションプラットフォームとなったWebの時代を経てきた。その時々にMicrosoftはIEの開発方針をリセットしてきたが、今回は従来よりもアプリケーションプラットフォームとしてのWebブラウザとなることをより強く心に持って開発したようだ。

　このためHTML5への対応を進め、他プラットフォームと同じマークアップで動作するように設計し、PCの持つリッチなハードウェアをWebアプリケーションが利用できるようにし、Windows上で動作するアプリケーションと同等の使い勝手を実現し、セキュリティ面でもより安全性を高めたものにすることを目標に再設計が行なわれたという。

　Workshop直前に行なわれたコンテンツパートナーの展示会で、さまざまな開発者に話を尋ねてみたが、HTML5の実装状況、相互運用性に関して、ネガティブな意見は出てこなかった。まだ開発途上のβ版ということもあるが、パフォーマンスの高さから来る開発しやすさなどもあって不満は聞かれない(もちろんMicrosoftのイベントであることは割り引かなければならないが)。

　なお、今回のイベントの中では一切、「Silverlight」の単語は出てこなかった。SilverlightはIEの部隊にとって1つのプラグインにしか過ぎないため、Silverlightに言及する必要はないが、HTML5との位置付けの違いについてのコメントもなく、“より良いHTML5対応ブラウザ”に終始したプレゼンテーションは、開発チームのWeb標準対応に対する強い意志表示と言えるかもしれない。

　別途、Microsoft関係者に聞いたところでは、今回のβ版は開発者向けプレビューという位置付けを大きく超えて、自分の手元にあるPCで使いながら、その良さを体感してもらえるだけの高い品質を備えていると、大きな自信をもってリリースした製品だという。完成品に近いものだ、という意図なのだろう。

　ただし、あくまで開発途上のバージョンであることは言うまでもない。筆者が試した範囲では、Gmailでメールの送信がうまくできない(サーバとの通信エラーとなる)、SNSフロントエンドツールのHootSuiteでログインが行なえないといった問題があった。インストールしても致命的な影響がWindowsシステムの中心に出るということはないが、動作しないアプリケーションはあると考えておいた方がいい。

●Web情報サイト、Webアプリケーションの動作を詳細に分析

　昨年末にIE9の開発者にインタビューした際にも伺っていたが、非常に論理的なアプローチによって、IE9はパフォーマンスの向上を図っている。

　まず、MicrosoftはAPI呼び出しの多いサイトをニュース系サイト、AJAXを用いたWebアプリケーションサイトの両カテゴリに分け、それぞれについて処理時間の内訳を分析した。Microsoftの示したグラフ(IE8において、各サイトのレンダリング時にどのような処理にどのぐらいの時間を使ったのか)を見ると、意外にJavaScriptの処理にかかっている時間が短いことがわかるだろう。

　これはMicrosoftが昨今、強調している点で、JavaScriptエンジンの高速化が必要であるとしながらも、そこを高速化しただけでは、快適なAJAXアプリケーションの動作とはならない。

　例えば、あるニュースサイトはマーシャリングと呼ばれる、JavaScriptエンジンとレンダリングエンジンを仲介する処理に、かなり多くの時間を要するという。そこでIE9では、JavaScriptエンジンやレンダリングエンジンなど、特定の処理を行なうソフトウェアモジュールを強化するだけでなく、それらの連携する部分を含め、どのように処理を高速化すべきか検討を重ねた。

　性能改善の目的は特定処理モジュールのベンチマークを高速にすることではなく、コンテンツの表示レスポンスを高め、アプリケーションの利用を快適にすることだ。故に特定の処理エンジンばかりを訴求したくない、というのがIE開発陣のメッセージと言えるだろう。

米国における人気の高い5つのニュースサイトを分析した結果	各人気ニュースサイトを表示させる際に、各サブシステムにかかった負荷をグラフ化	ニュースサイトをレンダリングする際にかかるサブシステムへの負荷を平均化したもの
こちらはAJAXアプリケーションの処理負荷の内訳。意外にJavaScriptの処理時間は短い	あるサイトにおけるの処理負荷のかかり方を示したグラフ。片方のコアがバックグラウンドでコンパイル処理に専念する	WebKitのSunSpiderを処理した結果。トップクラスのパフォーマンスを得るようになった

　とはいえ、JavaScriptエンジンのパフォーマンスを軽視しているというわけではない。今回はJavaScriptエンジンをJIT(Just-in-time)コンパイラで処理することにより、速度を向上させ、CPUへの負荷を下げている。その結果、Chrome 6.0やOpera 10.5といったJavaScriptエンジンの高速性を売りにするブラウザには及ばないものの、同等の処理性能を実現するに至った。

　もっとも、ベンチマークが速ければなんでも良いというわけではない。JITの導入ではコンパイラの負荷が動作のレスポンスを下げ、部分的には快適性を下げる可能性もある。そこでマルチコアによる処理を前提に、1つの処理コアにJITの処理を集中させ、バックグラウンドでコンパイル。レンダリングエンジンの動作が、よどみなくコンスタントになるよう工夫してあるそうだ。

　9月15日のIE9β版出荷は、事前にMicrosoftがアナウンスをしていたため、その直前にはライバルのChrome 7やFirefox 4などの最新βがそれぞれリリースされている。これは、GPUで高速化したHTML5レンダラーがIE9だけのものではない事を、きちんと訴求しておきたいという意図があるのかもしれない。

　しかし、どうやら現時点において、IE9と他のGPU対応ブラウザの開発版の間には、桁違いの差があるようだ。それはIE9対応コンテンツの紹介サイトでも確認できるが、もっとシンプルにGPUの加速機能を確認できるIE9のテスト用ページで、より詳細な検証が可能だ。

　IE9はWindows Vistaと7のユーザーが対象だが、これら2つのOSを使うユーザーのグラフィックスパフォーマンススコアは4～5が中心で、最低でも2以上を記録しているという。またVista以降にAeroへと対応するためにGPUが普及したこともあり、IE9が動作する環境ではDirectX 10が利用できる。このため、IE9ではDirectX 10のファンクションを用いてHTML5の高速化を行なう。

　速報でもお伝えしたように、筆者が現地に持って行っているSantaRosaベースのdynabook SS RX1(しかもこのモデルは省電力化のため、内蔵GPUやCPUのパフォーマンスが抑えられており、すこぶるグラフィックス性能が悪い)でも、明らかにブラウジングは快適になっている。

開発者向けの情報サイトをオープン。ベンチマーク用のサンプルや解説なども	Windows Vistaおよび7ユーザーのGPUパフォーマンススコア分布	IE8とIE9で、それぞれFlying Imagesを実行した時のCPU負荷

　HTML5のアクセラレーションと書いているが、実際にはWebページのレンダリングには全面的にGPUが使われており、普通のWebページであってもDirect 2D経由での描画が行なわれる。またアニメーションGIFなどは、独立したテクスチャを貼り付けているようで、スクロールさせると、わずかな時間差を伴いながらスクロールするのが見える。ともかく、HTML5でなくともGPUの恩恵は受けられるということだ。

　例えばアイコンが3D空間で飛び回るデモを実行した際のIE8とIE9のCPU負荷を比べると、GPUによる支援効果は明らかだ。IE9では最初にチョロっとCPUが働くと、その後は一切の負荷がなくなる(その間、画面上では派手にアイコンが飛び回る)。グラフィック専用プロセッサの方が処理効率も高いので、当然ながら省電力にも寄与する。

　他社との比較も圧倒的な差があったが、特に差が激しかったのは前述のテスト用ページ上で公開されているSpeed Readingというベンチマークだ。Chrome 7やFirefox 4のβ版との比較では、3桁ほどスコアが高い(実際の見た目も笑うほど違う)数字を出す。

　実際に自分でテストページ上のさまざまなサンプルを動かしてみるといいが、GPUを活かしたアニメーションや画面効果を見ていると、GPUの重要性が今後高まっていくことは間違いないだろう。

　このほか、Workshopでは開発者向けにWebアプリケーションの動作を分析するための、開発者モード(F12を押下げる)を紹介した。

　MicrosoftのIE9開発意図は、Webアプリケーションが中心の使い方でも、Windowsがベストなプラットフォームであると、ユーザーに感じてもらうことだ。

　Workshopにおいて、ある実際のWindowsユーザーが、どのようなアプリケーションを使っていたかを、タイムライン上に示すスライドが披露された。もちろん、WordやOutlookといったアプリケーションも立ち上げるが、もっとも頻繁に利用し、利用時間も長いのはWebアプリケーションなのだ。多くのPCユーザーは、Webブラウザ上で利用時間の大半を過ごしている。

あるWindowsユーザーが一日に利用したアプリケーションをタイムラインに沿って視覚化したもの。下段がWebアプリ	Webブラウザの利用のセッション

　このため、IE9はWebアプリケーションを単独のアプリケーションのように扱えるよう設計されている。タスクバーにWebアプリケーションを登録すると、そのアプリケーションのアイコンが表示され、以降はそれをクリックするだけでアプリケーションが利用可能になる。この際、汎用ブラウザとして立ち上げたIE9とは別のインスタンス(実行イメージ)としてOSには見えるようになっており、タスクバーにマウスカーソルを重ねると、そのアプリケーションと関係のないウィンドウは表示されない(Chromeにも同様の機能はあるが、ここまでの洗練された実装ではなかった)。

　さらにネイティブのWindows 7アプリケーションと同様に、タスクバー上のプレビューに操作ボタンを配置したり、ジャンプリストを登録してWebアプリケーション内の特定機能に直接ジャンプできる。Windows 7アプリケーションなら当然、期待されるだろう操作性をWeb上のアプリケーションも備えるようになる。

　タブをつかんでスナップイン/アウトする際に、動画が途切れずに動作するなどの点も自慢していたが、やはりWebアプリケーションであることを意識させないほど、OSと統合された動きをさせられることの方が、トピックとしては大きい。

タスクバー上のサムネイルでWebサービスの音楽再生をコントロールできる	ジャンプリストにも対応するので、アプリケーション内の任意の機能を直接呼び出せる

　URL欄に検索語を入れると、検索結果のプレビューが見える。WikiにしたりFacebookにしたり、いろいろ切り替えながら候補を見ることができる。

動作の遅いプラグインを検出して簡単に無効化できる機能を備えた

　そのほか、URL入力欄に検索ワードを直接入れられるのはもちろん、各種検索プロバイダと連携し、入力中のワードに対してジャンプすべきサイトがリアルタイムで表示される機能など、細かな操作性の改善は枚挙にいとまがない。質の低いプラグインを検出する機能も加わった。

　今後、Chrome 7やFirefox 4もパフォーマンスや操作性を改善してくるだろうが、Webアプリケーションを中心にPCを使うユーザー層に対して、まずは良い指標となるだけの出来に仕上がっているとは感じた。正式版までにさらにブラッシュアップされることを期待したい。

　なお、昨年末(2009年)のインタビューで対応の可能性について言及されていた、日本語レイアウトやフォントレンダリングを改善する件に関しては、大きく変化した様子は見られない。デフォルトのMSゴシックでは、一定以上のサイズでなければ画面上でスムージングがかからないため、メイリオなどに変更してレンダリングさせてみたが、若干、見やすく感じるもののIE8との有意な差は感じなかった。

　正式版に向けて改善の余地があるかないかも含め、この後も情報が入り次第、お伝えしていきたい。