Internet Explorer パフォーマンス ラボ: ブラウザーのパフォーマンスを信頼性の高い方法で計測する

このブログでは、Windows 8 のエンジニアリングの舞台裏に立ち入って、作業の詳細をご紹介しています。今回のテーマは、私たち全員がエンジニアとしてもエンド ユーザーとしても深い関心を寄せている点、つまり実際的な Web パフォーマンスです。私たちは、基本的な操作性のレベルを超えて、高パフォーマンスの Web ブラウジングを実現するために、多くの努力を費やしています。パフォーマンスは、チームのだれもが取り組んでいる課題ですが、この記事は、Matt Kotsenas、Jatinder Mann、および Jason Weber が執筆しました。--Steven

Web パフォーマンスはすべての人にかかわる問題であり、Internet Explorer のエンジニアリングの目標 (英語) の一つは、世界最速のブラウザーになることです。この目標を達成するには、ユーザーにとって現実的なシナリオに沿って、ブラウザー パフォーマンスの確実な計測を行う必要があります。過去 5 年にわたって、私たちは Internet Explorer パフォーマンス ラボ (英語) を設計し、構築してきました。これは、世界で最も洗練された Web パフォーマンス計測システムの一つです。

IE パフォーマンス ラボでは、開発サイクル全体にわたって意思決定に利用できる、信頼性が高く正確で実用的なデータを収集しています。Internet Explorer のパフォーマンス計測は 1 日あたり 200 回にのぼり、毎日 570 万以上の計測値と 480 GB のランタイム データが収集されます。Internet Explorer に対して行われた変更の影響はすべて把握し、高速化の流れが止まることのないよう注意を払っています。この記事では、IE パフォーマンス ラボがどのように設計されているかと、Web をより高速にしていく上で、ラボがどのように利用されているかについて、詳しくご紹介します。

この記事の内容は、次のとおりです。

• IE パフォーマンス ラボの概要
• ラボのインフラストラクチャ
• 計測の対象と方法
• シナリオのテスト
• 結果の調査
• サード パーティ ソフトウェアのテスト
• ユーザーのための高速ブラウザーの構築

IE パフォーマンス ラボの概要

Web パフォーマンスを長期にわたって確実に計測するには、ユーザーの現実的なシナリオを、再現性のある方法でシステムがシミュレートできる必要があります。つまり、"インターネットの小型版" を作成することになります。

IE パフォーマンス ラボは、パブリック インターネットからも Microsoft イントラネット ネットワークからも完全に隔離されたプライベート ネットワークであり、140 台以上のマシンが接続されています。ラボには、現実のインターネットの主要な要素である Web サーバー、DNS サーバー、ルーターや、ユーザーのさまざまな接続シナリオをシミュレートできるネットワーク エミュレーターが備えられています。

一見、複雑そうに見えるかもしれませんが、このアプローチであれば、差異のすべての原因を取り除くことができます。ネットワークのすべての要素を、個々のパケット ホップ (英語) やレイテンシに至るまで制御することによって、テストの決定性と再現性が確保されます。このことは、結果を実用的なものにするうえで重要です。IE パフォーマンス ラボでは、アクティビティは 100 ナノ秒単位で計測されます。

このようなネットワーク構成は、高い柔軟性も備えています。現実的な設定をシミュレートするために、ラボにはほぼすべての種類のテスト マシンや Web サイト コンテンツを取り込むことができます。x86、x64、および ARM プロセッサのデスクトップ、ラップトップ、ノート、およびタブレットを、すべて同時にサポートします。同様に、ラボでは Windows Performance Tools (WPT) (英語) を使用しているため、同じテストを別の Web ブラウザー、ツール バー、ウイルス対策製品、または他のサード パーティ ソフトウェアを使って実行し、結果を直接比較できます。

WPT を利用すると、使用されているハードウェアの詳細情報を得ることができます。また、高レベルの CPU および GPU アクティビティから低レベルの情報 (キャッシュ効率、ネットワーク統計、メモリ使用パターンなど) に至るまで、あらゆるデータを捉えることができます。WPT では、ハードウェア、デバイス ドライバー、Windows オペレーティング システム、および Internet Explorer をすべてまとめて効率的に最適化できるように、スタック全体にわたってパフォーマンスを計測および最適化できます。

1 つのテストを完了するのには 6 時間かかり、その間に 22 GB 以上のデータが生成されます。この高度に自動化されたシステムは、操作の監視、結果の分析、および新しいインフラストラクチャ機能の開発を行う小規模なチームによって運用されています。

ラボのインフラストラクチャ

パフォーマンス ラボのインフラストラクチャは、3 つの主なカテゴリに分類できます。それは、(1) ネットワークとサーバー、(2) テスト クライアント、(3) 分析とレポートです。各カテゴリは、コンポーネント間の相互作用を最小化するように設計されているので、テストのスケーラビリティが向上すると同時に、ラボ環境でノイズが発生する可能性が低くなります。

これが IE パフォーマンス ラボの室内風景です。多くのテスト用、分析用のマシンが、プライベート ネットワークで接続されています。

ネットワークとサーバーのインフラストラクチャ

まずは、DNS サーバー、ネットワーク エミュレーター、およびコンテンツ サーバーについて説明します。これらが一体となって、小型版インターネットが構成されています。次の 3 つのセクションで、アーキテクチャの図の構成要素を、右から左へ順番に説明していきます。

コンテンツ サーバー

コンテンツ サーバーは、実際のインターネットでの何百万もの Web ホストに相当する Web サーバーです。各コンテンツ サーバーは、ローカルにキャプチャされた実際の Web ページをホストしています。キャプチャされたページには、私たちが "消毒" と呼んでいる処理が施され、再現性と決定性が確保されるように、Web コンテンツの一部が微調整されます。たとえば、JavaScript の日付関連の関数や Math.Random() 呼び出しは、静的な値に置き換えられます。また、広告フレームワークによって作成される動的な URL は、フレームワークによって最初に使用された URL に固定されます。

消毒後のコンテンツは、静的なコンテンツと同様に、URL のハッシュとコンテンツをマッピングする ISAPI フィルターを通じて利用され、瞬時の検索が可能になります。ばらつきを最小限に抑え、コンテンツをメモリ上に保持できる (ディスク アクセスが必要ない) ようにするため、各 Web サーバー (英語) は、16 GB の RAM を持つ 16 コアのマシンに統一されています。

コンテンツ サーバーは、Outlook Web Access や Office Web Apps のような動的な Web アプリもホストできます。その場合は、実際のインターネット環境と同様に、アプリケーション サーバーと多層の従属要素がラボ内の専用サーバーでホストされます。

ネットワーク エミュレーター

ばらつきの原因となる要素の多くが排除されているため、ネットワークの速度は、より低速な接続を利用している多くのユーザーの状態とは大きく異なってしまっています。実際のユーザー環境をシミュレートするために、テストではネットワーク エミュレーションの機能を利用して、今日使用されているさまざまなネットワークのパフォーマンスを再現します。ラボでは、いくつかの DSL 構成、ケーブル モデム、56 k モデムや、WAN、4G 環境のような高帯域幅、高レイテンシの環境のエミュレーションをサポートしています。エミュレーターは HTTP 要求を受け取ると、パケットの遅延や並べ替えなどのネットワークの特性をシミュレートしてから、要求を Web ホストに転送します。応答を受け取ると、再度エミュレーションが行われ、テスト クライアントに送り返されます。

ネットワーク エミュレーションに専用ハードウェアを使用することで、最も現実的なテスト環境が実現でき、観測による影響を大幅に低減できます。専用ハードウェアは、プロキシやソフトウェアによるソリューションに比べるとコストや複雑さが増加しますが、パフォーマンスを正確に計測できる唯一の方法です。ブラウザーには、プロキシの飽和を避けるための同時プロキシ接続数の制限があるので、ネットワーク エミュレーションにプロキシを使用すると、Web ページによって行われるドメイン シャーディング (英語) やその他の最適化の回避など、意図しなかった影響が生じます。また、ローカル ネットワーク エミュレーションでは、ローカル マシン リソースをブラウザーと取り合うことになります。これは低電力マシンの場合に特に顕著です。

DNS サーバー

実際の DNS サーバーのように、ラボの DNS サーバーはコンテンツ サーバーをテスト クライアントにリンクしています。また、ラボでは、ネットワーク エミュレーターごとに異なる DNS サーバーを使用しているため、ネットワークの速度の切り替えは、DNS サーバーの切り替えと同じくらい簡単に行うことができます。この場合、DNS サーバーはドメイン名を Web ホストに解決するのではなく、すべてのドメイン名を、関連付けられているネットワーク エミュレーターに解決します。

テスト クライアントの構成

私たちは、Internet Explorer がどのクラスのコンピューター ハードウェア上でも常に高速に動作するようにしたいと思っています。ラボには、Internet Explorer のパフォーマンスの計測に使用されているコンピューターが 120 台以上あります。それらはテスト クライアントと呼ばれ、その種類はハイエンドの x64 デスクトップから低電力のノートや、タッチ主導のタブレット デバイスにまでわたっています。計測の再現性は最重要課題なので、テスト クライアントはすべて物理マシンです。

Internet Explorer パフォーマンス ラボの変更比較マシン プール

さままざまなデバイスから成るエコシステム全体にわたって、常に Internet Explorer がハードウェア アクセラレーションをフル活用できるようにするため、異なるマシンのクラスごとに独立型と統合型の両方のグラフィック プラットフォームが用意されています。上の写真が、私たちのメイン マシン プールです。これらの PC は、Windows 7 または Windows 8 PC の寿命を通じた平均的なユーザー エクスペリエンスとほぼ同等なものです。マシンは、同一になるように、OEM に注文しています。すべてが同じ生産ロットで製造され、使用前にパフォーマンス特性が検査されます。

ラボは 24 時間体制で無休で運用されているので、ハードウェアの故障は避けられません。故障したコンポーネントを別の生産ロットからの同じ部品に取り換えると、たいていは修理したコンピューターがプール内の他のマシンよりも高速になってしまいます。この差異は、通常は意識されませんが、100 ナノ秒単位の計測を行う場合には、数サイクルの違いさえ、結果に影響してしまいます。修理によってマシンの性能がプールの他のマシンと異なってしまった場合、そのマシンはラボから取り除かれます。そのため、プールのサイズは常に縮小していきます。その対応策として、ラボでは余分な "バッファー" マシンを含めて購入しているので、プールから故障したマシンが取り除かれても余分なキャパシティによって影響が吸収され、ラボの運営には問題が生じません。

ハードウェアの範囲を広げるために、さまざまなユーザー シナリオに対応した追加のマシン プールも用意しています。これらのマシンで優れたパフォーマンスを実現することができれば、IE は PC エコシステム全体にわたってハードウェアを効果的に使用できていることになります。

低電力のテスト マシン。それぞれがテストの異なる状態。

さらに多様なマシンが必要になる場合、IE パフォーマンス ラボは Windows グラフィック ラボを利用することもできます。Windows グラフィック ラボには、製造されているほぼすべてのグラフィック チップセットが用意されています。考えられるほぼすべての組み合わせで PC を構成して、パフォーマンス テストに使用できます。Windows グラフィック ラボは、チップセットとドライバーのリビジョンに関するグラフィックの問題を診断するうえで、非常に有益です。

分析およびレポート サーバー

テスト結果の収集と分析は、2 つの個別の手順に分けられます。分析を専用マシンにオフロードすることで、テスト クライアントはより早く次のパフォーマンス テストに着手することができ、分析はより強力なサーバー クラス マシンを使用して短時間で行うことができます。分析が短時間で終わるほど、パフォーマンスの変化をより効率的に特定できます。

分析には、11 台のサーバー クラス マシン (英語) を使用しており、それぞれが 16 のコアと 16 GB の RAM を備えています。分析では、各トレース ファイルが検査され、数千の指標値が抽出されて、SQL サーバーに送られます。これらの分析マシンは、傾向分析に使用されるトレースを 24 時間に 15,000 以上検査します。

上の写真は、いくつかあるサーバー ラックのうちの 2 台で、ファイル サーバー、SQL サーバー、何台かの分析およびコンテンツ サーバーが収納されています。

毎日収集される約 600 万の計測値を格納するために使用されている SQL Server (英語) は、64 GB の RAM を備えた 24 論理コアのマシンです。レポートは、SQL から直接生成できます。また、HTML ベースの比較アプリケーションや、XML または JSON 形式のレポートを提供する WCF サービスを使用して、結果を検査することもできます。

計測の対象と方法

インフラストラクチャの話はこのくらいにして、パフォーマンス ラボで計測されるさまざまな種類のシナリオと、指標値の収集に使用しているツールについて説明することにしましょう。

毎日計測されているシナリオ

パフォーマンス ラボでは、ユーザーにとって重要な、現実的なシナリオに集中的に取り組んでいます。そのため、20,000 以上のテストを毎日行っています。これらのテストは、重複する部分もありますが、次の 4 つのカテゴリに分類できます。

コンテンツの読み込み – ページからページへの移動は、今も Web ブラウザーでの最も一般的なアクティビティです。Web コンテンツの読み込みは、ブラウザーの 11 のサブシステム (英語) のほとんどに関与する、唯一のカテゴリでもあります。シナリオの他のカテゴリにとって、Web コンテンツの読み込みは前提条件になります。

インタラクティブな Web アプリ – このカテゴリには、コンテンツ作成、AJAX アプリケーション、または Web 2.0 サイトと呼ばれるようなものが入ります。一般的なニュースやソーシャル ネットワーキングのサイトとの相互作用や、Outlook Web Access、Office Web Apps のようなメールおよびドキュメント アプリケーションとの相互作用が含まれます。

IE アプリケーション自体 – 重要なのに忘れられがちなのが、ブラウザー自体の操作に関連するシナリオです。一般的な操作としては、ブラウザーの開始と終了、タブの切り替え、履歴やお気に入りのようなブラウザー機能の使用、マウス/キーボードとタッチ操作の両方におけるパンとズームなどが挙げられます。

総合的なベンチマーク – 忘れられることはないものの、しばしば過大評価されるのが、WebKit SunSpider のような総合的なベンチマークです。ベンチマークは、個々のブラウザー サブシステムに負荷をかけ、ブラウザー間の差異を強調するように設計されているので、便利なエンジニアリング ツールに成り得ます。ただし、このような差異を最大化するために、特殊な使用パターンや極端な事例が使われることがよくあります。

現実的なパターン

パフォーマンスの計測では、テストが現実的な使用パターンに基づいていることが重要です。多くのソフトウェア エンジニアリングの教科書で "作業負荷モデリング" (英語)、または "アプリケーション使用モデリング" と呼ばれるプロセスです。パフォーマンス ラボでは、現実的なパターンを計測するために、現実的なパターンを示す実際の Web ページを使用して、さまざまなブラウザー サブシステムを試しています。

テストに使用するサイトを決めるために、定期的に何百万ものサイトをクロールして、サイトの属性やコーディング パターンのリストを作成しています。サイト間の共通性を判断するためには、68 のデータ ポイントを使用しています。たとえば、結果の DOM の深さや幅、CSS レイアウトのパターン、使用されている一般的なフレームワーク、国際化機能 (英語) などです。その結果に基づき、一般的なパターンや、より広い Web の多様性を最もよく示しているサイトを選択しています。

エンジニアリング指標

パフォーマンスは多次元的な問題です。パフォーマンスを正確に認識するための唯一の方法は、テストしているシナリオを理解し、ハードウェアおよび OS がブラウザーとどのように相互作用しているかを知ることです。ここでは、人気のあるスポーツ サイトを初めて読み込むというコンテキストで、5 つの重要なパフォーマンス指標について詳しく見てみましょう。

表示時間 - 表示時間は、ユーザーが操作を行ってから、ユーザーがその操作の結果を画面上で見るまでの時間の計測値です。

経過時間 - 多くのサイトでは、コンテンツが画面に表示された後も、バックグラウンドでの作業を継続しています。たとえば、Web メール アプリケーションで次の電子メールのダウンロードをしていたり、分析をプロバイダーに送信していたりします。ユーザーの観点からはサイトの動作が終了したように見えても、かなりの量の作業が発生していることがよくあり、全体的な応答性に影響を与える場合があります。

CPU 時間 - 現在の Web ブラウザーを制限する要素は、ほぼ CPU の速度だけです。負荷を GPU にオフロードして、CPU をより効率的に利用すると、パフォーマンスが大幅に変化します。

リソース使用率 - 高速なブラウザーを構築するには、PC 全体のリソースを協調的に機能させる必要があります。たとえば、ネットワーク使用率、メモリの使用パターン、GPU 処理、グラフィック、メモリ、その他のさまざまな面を考慮しなければなりません。ユーザーは PC で同時にいくつかのアプリケーションを実行するので、ブラウザーではこれらのリソースを他のアプリケーションと適切に共有できるようにすることが重要です。

電力消費 - 電力効率を高めると、モバイルのシナリオではバッテリの寿命が長くなるほか、デバイスの電力コストが低下し、環境への影響が小さくなります。

1 つの指標だけに集中すると、パフォーマンスを過度に単純化して捉えることになります。特定の指標に注目しているうちに、自然にその指標を偏重して、他の同様に重要な指標を無視しがちになります。このような傾向に抗するための唯一の方法は、パフォーマンスのすべての面を計測した上で、暗黙的にではなく、意識的にトレードオフを行うことです。

パフォーマンス ラボでは、合計すると、850 以上の指標を計測しています。それぞれの指標が、ブラウザーのパフォーマンスの全体像の一部を示しています。どのような計測を行っているかを知っていただくために、主な指標の一部を挙げておきましょう。プライベート ワーキング セット、トータル ワーキング セット、HTTP 要求数、受信 TCP バイト、読み込みバイナリ数、コンテキスト切り替え数、DWM ビデオ メモリ使用量、GPU 使用率、描画回数、JavaScript のガベージ コレクションの CPU 時間、JavaScript 解析の CPU 時間、平均 DWM 更新間隔、ピーク トータル ワーキング セット、ヒープ割り当て数、ヒープ割り当てサイズ、未処理のヒープ割り当て数、未処理のヒープ割り当てサイズ、レイアウト サブシステムの CPU 時間、フォーマット サブシステムの CPU 時間、レンダリング サブシステムの CPU 時間、HTML 解析サブシステムの CPU 時間、アイドル CPU 時間、スレッド数などです。

Windows イベント トレーシング インフラストラクチャ

指標は、Windows イベント トレーシング インフラストラクチャ (ETW) (英語) と VMMap を使って収集されます。ETW は Windows 全体を対象にしたイベント ログ作成システムであり、Windows イベント ログ (英語) など、多くの Windows コンポーネントとサード パーティ アプリケーションによって使用されています。ETW ログ作成 API は、非常に低レベルかつ低オーバーヘッドであり、このことはパフォーマンス テストにとって重要です。

WPT に含まれているトレース ビューアーである xperfview.exe は、カーネル、CPU、GPU、I/O、ネットワーキングなどのイベントを関連付けたり総合したりすることができる、強力なビジュアライザーです。WPT では、"スタック ウォーキング" (英語) もサポートされています。スタック ウォーキングでは、プログラムの呼び出し履歴のスナップショットが定期的に作成され、履歴がトレースの一部として保存されます。ETW イベントを履歴と関連付けることで、WPT はどの作業が行われていたかだけでなく、その作業に関連している呼び出し履歴と、その作業に費やされた時間 (10 マイクロ秒単位) も表示します。スタック ウォーキングは、ETW イベントを使用していないプロセスも含めて、任意のプロセスで有効にできます。スタック ウォーキングの難点は、スタックをデコードするためにデバッグ シンボルを必要とし、エイリアシングの影響を受けやすいことです。

シナリオのテスト

最後の問題は、実際のテストのプロセスです。テストは、3 つのフェーズに分けることができます。それは、セットアップ、実際のテスト、およびエラーとクリーンアップです。以下に示すのは、プロセス全体のフローチャートです。

セットアップ

プロセスは、ユーザーがラボの Web サイトまたは自動化フレームワークを通じて実行を要求したときに始まります。実行は、他の保留中の実行と共に、優先キュー内に置かれます。テスト クライアントが使用可能になると、キューが確認され、開始可能な最も優先度の高いジョブが開始されます。まず、テスト クライアントが、指定されたテスト OS をインストールします。IE パフォーマンス ラボでは、Vista、Windows 7、および Windows 8 でのテストをサポートしています。テスト クライアントは、マシンが常に既知の正常な状態で起動されるように、実行ごとにテスト OS の新しいコピーをインストールします。

テスト OS がインストールできたら、クライアントは WPT、VMMap、およびテスト ハーネスを構成します。ホームページ、おすすめサイトの使用、InPrivate ブラウズなど、多くの IE 設定も指定されます。サード パーティ ソフトウェアも、この時点でインストールおよび構成されます。

テスト前の最後のステップは、テストへの影響が最小限になるように、テスト クライアントがアイドル状態になっているのを確認することです。Windows では、アイドル タスク (英語) という概念が定義されています。アイドル タスクを利用すると、Windows や開発者は、緊急でない作業を後でユーザーがリソースを取り合っていないときに実行するように予定できます。OS のアイドル タスクとしては、OS のバージョンと構成されているサービスに応じて、プリフェッチまたはスーパーフェッチ、ディスクの最適化、検索インデックスの更新などが挙げられます。テスト中にアイドル作業が行われないようにするために、アイドル タスク キューがフラッシュされます。また、Windows Defender は一時停止され、テスト ハーネスのログの場所は Windows インデックス サービスから除外するようにマークされて、テスト実行中にログおよびトレース ファイルによってインデクサーが開始されないようになります。テストは、必要なプロバイダーの数を最小限にするために、複数のパスで実行されます。これは、余分なプロバイダーがあると観測による影響 (英語) が増大するためです。最初のパスは、常にウォームアップ パスです。ウォームアップによって、ブラウザーのバイナリは "ウォーム" な状態になり、キャッシュ可能なページ コンテンツができるだけ多く WinINET キャッシュ内に準備されます。その後のそれぞれのパスでは、スタック ウォーキング、メモリのトレース、I/O およびレジストリのトレースなど、特定の種類の計装に焦点が当てられます。

エラーとクリーンアップ

テスト中のどの時点でも、ブラウザーがクラッシュすると、テスト パスは失敗と見なされ、実行は次のテスト パスに移ります。テスト中のどの時点でも、Windows がクラッシュすると、コンピューターは再起動され、その状態が正常であることが保証できないので、OS が再インストールされます。再試行の回数がしきい値を超えると、実行全体が失敗と見なされ、不安定なビルドのテストを無限に繰り返さないように、マシンは他の実行に移ります。

すべてのテスト ケースが終了すると、テスト クライアントは分析用にログとトレースをアップロードします。その後、テスト クライアントはアイドル状態に戻り、新しい実行のためのポーリングを開始します。

結果の調査

各指標は、"変化の変化" まで追跡されます。サンプル データを入手するために、各テスト ケースは最低でも 10 回実行され、実行は少なくとも 2 台の異なるマシンで繰り返されます。統計ツールにより、典型的でない結果があれば、自動的に調査のためのフラグが設定されます。分散変動も、機能低下と見なされます。IE を操作するユーザーは、さまざまな状況でさまざまなハードウェアを使用しているので、私たちの目標の一つは、毎回スムーズで予測可能なエクスペリエンスを実現することです。

自動化された分析のほかに、トリアージ (重要度の判定) チームが毎日の結果を調査し、傾向や興味深い動きを監視しています。多くの統計ツールでは、正規分布と、すべてのサンプルの独立が前提となっているので、手動での調査もやめることはできません。どちらの前提も、私たちの計測においては、厳密に正しいとは言えません。IE の一部のアクティビティは OS のタイマーによって起動されるので、結果はいつ (タイマーのサイクルに応じて) ページの読み込みが始まるかにも依存します。タイマー割り込みの直前または直後に開始されるページ読み込みは、より多くのまたはより少ない作業を行うことになります。これは、IE がページ読み込み処理の異なる時点で割り込みに対処しなければならないためです。この割り込みは、二峰分布 (英語) につながる波及効果を持つ場合があります。また、私たちは反復検査を行っており、繰り返しの間にマシンの初期化は行わないので、次の検査は前の検査の影響を受けることになります。次のグラフは、Bing 地図で "変化の変化" を比較した、経過時間のサンプルを示しています。

赤の系列は各テスト実行の中央値を示し、灰色の棒は範囲を示しています。テスト実行にマウス ポインターを合わせると、各繰り返し実行時のその指標のデータ ポイント (青い印) と、最小値、中央値、最大値の正確な値や、前回のテスト実行との絶対的または相対的な差異を示したヒントが表示されます。この図で示されているヒントには、その他のコンテキストとして、テストされているビルドの情報や、ビルドでの変更点を確認するためのソース管理システムへのクイック リンクも含まれています。

自動化された分析と手動の調査の組み合わせによって、IE チームはパフォーマンスの調整を行うための信頼性が高く実用性のあるデータを入手できます。

サード パーティ ソフトウェアのテスト

多くのサード パーティ アプリケーションは、Trident、ネットワーク スタック、およびその他の IE コンポーネントに依存しています。BHO (英語) やツール バーのような拡張は、IE のコンテキスト内で読み込まれます。また、セキュリティ ソフトウェアのように、IE のコンポーネント間に入り込んで動作するアプリケーションもあります。このようなアプリケーションは IE スタックの一部になり、パフォーマンスの低下の原因となる場合があります。パフォーマンス ラボでは、制御された環境内で、実際のコンテンツのブラウズに対するサード パーティ ソフトウェアの影響を計測できます。ユーザーは通常、一般的なソフトウェアが自分のブラウジング エクスペリエンスにどの程度の影響を与えるかを調べられないので、このような調査は、IE およびエコシステムにとって重要です。

サード パーティ ソフトウェアの影響をテストするときには、サード パーティ ソフトウェアがインストールされている状態での実行と、IE だけがインストールされているクリーンな状態での実行とを比較し、ソフトウェアの影響を判断します。私たちが特に注目している 2 つの計測指標は、起動時間とナビゲーション時間です。起動時間の場合は、ブラウザーを起動して URL に移動するまでにかかる時間を計測します。一方、ナビゲーション時間の場合は、ブラウザーが既に起動されている状態で、URL への移動にかかる時間を計測します。起動時間には、サード パーティ アプリケーションによる IE 拡張の読み込みにかかる時間も含まれます。

キャッシュされたコンテンツを使用すると、計測の再現性が高まります。さらに、キャッシュされたサイトを計測することで、パフォーマンスの低下がサイトの違いによって起きたのではなく、サード パーティ ソフトウェアによって引き起こされたと断定できるようになります。サード パーティ ソフトウェアの影響を計測する場合は、常にインターネットへの直接接続上でも起動およびナビゲーションをテストして結果を検証し、テスト環境が差異の原因になっていないことを確認しています。

多くのサード パーティ アプリケーションは、ページの移動中に、クラウド サービスに作業をオフロードしています。作業の並列化とクラウド サービスの使用は、パフォーマンスを向上させるための優れた手法ですが、一部のアプリケーションはネットワークからの結果を同期的に待機し、進行中の移動をブロックしてしまいます。このようなパターンでは、厳格なファイアウォール、WAN 接続、オフラインなどの多くの実際のシナリオで、ユーザーのパフォーマンスが低下します。サード パーティ ソフトウェアは、IE またはユーザーのアクションに応じて同期的な処理を行うべきではありません。また、UI および DOM の更新は、中断を最小限にするために、バッチ処理するべきです。

ユーザーのための高速ブラウザーの構築

実際の使用において、ブラウザーのパフォーマンスは重要です。パフォーマンスの正確な計測は、大きなコストがかかるフルタイムの仕事ですが、その努力に見合った結果を得ることができます。Internet Explorer パフォーマンス ラボで収集されたデータは、ブラウザーのパフォーマンスと、基盤となる PC ハードウェアを理解し、高速でスムーズな、応答性の高い Web エクスペリエンスを開発するうえで重要な役割を果たしています。

— Internet Explorer パフォーマンス チーム: Matt Kotsenas、Jatinder Mann、Jason Weber