ブラウザーのパフォーマンス評価における一般的問題更新日: 2009 年 1 月 23 日 翻訳元: Common Issues in Assessing Browser Performance (英語) 本記事は、Internet Explorer 開発チーム ブログ (英語) の翻訳記事です。本記事に含まれる情報は、Internet Explorer 開発チームブログ (英語) が作成された時点の内容であり、製品の仕様や動作内容を保証するものではありません。本記事に含まれる情報の利用については、使用条件をご参照ください。また、本記事掲載時点で、Internet Explorer 開発チームブログ (英語) の内容が変更されている場合があります。最新情報については、Internet Explorer 開発チームブログ (英語) をご参照ください。 IE チームでブラウザーのパフォーマンスに主に携わっているプログラム マネージャーの Christian Stockwell です。 Web サイトと Web ブラウザーの全体的なパフォーマンスを計測する事は、ユーザーが競合関係にあるブラウザーを比較するためにも、開発者がダウンロード時間や応答性を最適化するためにも、ブラウザーのベンダーがコードの変更とパフォーマンスの変化の関連性を調査するためにも、そしてWeb サイトのパフォーマンスを理解する事に興味を持つすべての人にとっても、重要な事です。 今回は私の以前の投稿をフォローアップし、ブラウザーのパフォーマンスのテストに影響のある問題やブラウザーのパフォーマンスを効率的に計測するためのテクニックについて、俎上に載せたいと思います。 ブラウザーのパフォーマンス計測一般的なパフォーマンス テストのアプローチは、特定のベンチマーク スイート (パッケージ) に集中する事です。これは有効な計測方法ですが少数の目標となるベンチマークだけに依存しているため、ユーザーが感じるパフォーマンスについて理解を誤る可能性があります。ブラウザー パフォーマンスを計測する最も正確な方法には、実際によく行われているブラウジングのシナリオでの計測が含まれるべきです。実際のサイトで計測を行う事により、他のベンチマークでは抽出できない要素が捕捉でき、総合的なパフォーマンスの観点が得られます。現実世界のサイトに対してブラウザーのテストを行う事はいくつかの重要な挑戦を必要としますが、この投稿で私たちが開発の過程で IE のパフォーマンスを効率的に計測するのに採用した解決方法を示します。 この投稿について深く探求する前に、パフォーマンスのベンチマークを有効に行うのは驚くほど困難であるという事をお伝えしたいと思います。IE チームは、毎日数千もの独立したテストを多数のサーバーに対して行うための、数百のデスクトップとラップトップからなる検証とパフォーマンス計測のための実験環境を構築する作業に膨大な労力を注ぎました。そしてパフォーマンス データの信頼性、精度、明確性を改善できる新しいアイデアなしに一日の仕事を終える事はほとんどありませんでした。 ブラウザー パフォーマンスの計測における挑戦の一つは、ブラウザーの使われ方の違いが膨大な数に上る事です。ユーザーは毎日幅広い範囲のサイトをブラウズしており、その中には Flicker のようなコンテンツ量の多いサイトから、Google のように最小化されたサイトまで含まれています。Windows Live Hotmail のような対話的 AJAX サイトも訪問しますし、Craigslist のような単純で静的な HTML のサイトも訪問するでしょう。それだけでなく、ブラウザーをミッション クリティカルなアプリケーションで仕事をするために使う人もいるでしょう。 こうしたそれぞれのカテゴリーのサイトでのパフォーマンスは、多くの場合ブラウザー内の異なるサブシステムに依存します。たとえばイメージの多いサイトではブラウザーのダウンロードとイメージの展開の速度に依存するでしょう。対照的に、単純なサイトでのパフォーマンスは HTML レンダリングの速度が主な要素となるでしょう。別の例として、AJAX Web サイトのパフォーマンスでは JavaScript エンジンとCSS エンジン、DOM がどれだけ緊密に統合されているかが、個々のサブシステムの個々の速度以上に重要な要素となるでしょう。Flash や Silverlight のようなサードパーティのコントロールが組み込まれていると、多くの場合パフォーマンスはコントロールがどれだけ効率的にブラウザーと統合しているかに関連します。 ここで紹介するアプローチのいくつかは、IE8 で行われたパフォーマンスの改善についての背景につながり、また私たちの開発工程についての見識を与える事になると思います。これらを通じて、この投稿からブラウザーとサイトのパフォーマンスについて計測し検討する方法を向上させるためのアイデアを得ていただければと思います。 キャッシング動作すべてのブラウザーは本質的にネットワークに依存しており、どのようなテストでもパフォーマンスの計測を十分に行うには、その現実を反映させる必要があります。 ブラウザー パフォーマンスに影響を与える可能性のあるインターネットの性質の一つの側面は、インターネットを構成するさまざまなレベルのサーバーでのコンテンツの保存のされ方です。こうした保存動作はキャッシングと呼ばれます。 ブラウザー パフォーマンスの計測という視点から言えば、これは www.microsoft.com を表示しようとした場合、ブラウザーはこのコンテンツを、会社内のプロキシ サーバーやローカルのサーバー、世界中の数多くのサーバーなど複数のサーバーに要求するという事です。 ブラウジングのスピードを向上し、Web ページを提供する作業を分散化するため、表示したページの部品を一時的に保存し、他のユーザーがその部品をより早く取得できるようにします。たとえば貴方が朝一番の仕事として手早くニュースをチェックするため www.msnbc.com (英語) を訪問する場合、最初に会社のプロキシ サーバーにリクエストします。プロキシ サーバーは最終的に遠隔地のサーバーからページを取得する前に、ローカル サーバーにそのリクエストを中継します。ページの取得が完了すると、プロキシ サーバーまたはローカル サーバーはコンテンツの一部を保存しようとします。この時同僚の Tracy が 10 分遅れで出社して、www.msnbc.com (英語) にアクセスすると、遠隔地のサーバーではなくプロキシ サーバーから直接コンテンツが取得されるのでサイトを表示するのに必要な時間が劇的に短縮され、Tracy はとても幸せになります。 同様に、複数のブラウザーでパフォーマンスを計測する場合、キャッシングの影響を考慮する事が重要です。たとえば一つ目のブラウザーの 10 個のタブで 10 の異なる Web サイトを開いた後、二つ目のブラウザーでも同じ 10 個のタブを開くと、二番目のブラウザーが早いという間違った結果が得られます。実際にはこの違いは主に、最初のブラウザーがページをリクエストした際にコンテンツが近くのサーバーに保存された事によっています。 サーバーがどのようにキャッシュするのかを厳密に制御する事は困難ですが、パフォーマンス計測の一般的な原則は、どのような場合も一度だけの計測で済ませてはならないという事です。上流でのキャッシングの影響を特に計測しようとしているのでなければ、パフォーマンス データの収集を開始する前に計測したいサイトを一度は訪問しておくべきです。実際には、プロキシはユーザー エージェント (ブラウザー) ごとにコンテンツをキャッシュするので、テストしたいサイトのそれぞれを、テストするすべてのブラウザーで訪問すべきです。 ここまでのキャッシュ動作の概要は単純化したものです。より詳しい情報が必要なら、動作が詳細に解説された重要なリソースが多数あり、HTTP プロトコル規格 自体もその一つです。HTTP プロトコル規格 (英語) はとても良い寝る前の読み物で、またどんなパーティでも会話の糸口にもなるでしょう。 サンプルの量正確に言えば、ブラウザー パフォーマンスに影響を与える要素は非常に多岐にわたるため、パフォーマンス計測の回数によってその結果に大きな違いが出る場合があります。 前述のように、パフォーマンス計測の一般的原則は、何事も一度だけの計測で済ませてはならないという事です。この原則を「何事も十分な回数計測しなければならない」と拡張したいと思います。「十分な回数」が何を意味するかについては、信頼区間や標準偏差、その他の統計学上の興味深い応用に基づく異なる考え方が多数あります。 私たちが収集した多数のパフォーマンス データに関しては、ほとんどの場合、実用的なアプローチを採用してそれらの比較的複雑な課題を避ける事で十分であると分かりました。検証環境においては 7 から 10 回の反復で信頼性のあるデータのセットが収集でき、傾向を識別できる事を確認しています。ただし検証する環境の制御がより不十分な場合は、より多くの回数が必要となるでしょう。 パフォーマンス データが収集できたら、結論を導くため結果を要約する事になります。算術平均 (英語)、調和平均 (英語)、幾何平均 (英語)、またはその他のどのような方法を使用する場合であっても、データの要約方法によって結果が分岐する事を十分に理解している必要があります。 例として、二つのブラウザーから単一の Web ページを表示するテストで収集された点数のデータを見てください。
このわざとらしい例で明確になるのは、データをどのように要約するのかによってデータの解釈が変わってしまうという事です。この例では、算術平均はブラウザー B がブラウザー A より早いと示しているのに対して、幾何平均と調和平均ではその反対の結果が導き出されています。 帯域幅の競合ネットワークを他のユーザーと共用するという事は、明らかに Web ブラウザーが同じ動作をするのにより多くの時間を要する事になります。 Microsoft のような大企業で仕事をしている場合の利点の一つは、従業員が多数であるため特定の現象が計測可能で信頼できるものになる事です。たとえばページのダウンロードに要する時間を一日を通じて計測すると、多くの Microsoft 従業員は午前 8 時から午前 9 時の間に仕事を始め、午後 5 時から午後 6 時の間に退出する事がはっきりします。 その理由として明確に言えるのは、多くの Microsoft 従業員は一日を通じてほとんど絶え間なくネットワークにアクセスしているという事です。MSDN を参照したり、SharePoint 上のドキュメントを読んだり、最新の Xbox のゲームの厳格なテストを行ったりする事で、帯域幅を競合して使っているのです。そうした共有は、ブラウザーのパフォーマンスを計測するには会社全体が業務を開始し電子メールを送信し始める午前 9 時ではなく、午前 6 時に行った方が一貫した結果を確実に得られる事を意味しています。 企業の違いにより可能なネットワーク構成の種類も幅広いため、帯域幅の競合の影響を予想する事は困難です。これが結果をゆがめる事を防ぐためにお勧めできるのは、仕事場でパフォーマンス データを収集する場合には主な業務時間以外でパフォーマンス データの収集を行う事です。 自宅でパフォーマンス データの収集を行う場合もまた、家族や近隣の人と帯域幅を共有している事になります。そうした場合、ビジネス アワーや深夜、あるいは早朝など他の人があまりブラウジングをしていない時間帯に合わせて計測を行うと良いでしょう。 リソースの競合コンピュータ上のリソースに対するアプリケーション間の競合も、帯域幅の競合と同様にブラウザー パフォーマンスに大きく影響します。 複数のアプリケーションが同一の外部アプリケーションやプラットフォームに依存している場合、これは特に間違いのない事実です。たとえば、アンチ ウイルス製品には複数のブラウザーと異なった方法で統合するものがありますが、そのパフォーマンスに与える結果は不明です。 二つのブラウザーを並行してテストすると、非常に正しくない結果となる場合があります。たとえば、Windows プラットフォームではアウトバウンドのソケット リクエストは同時に 10 までに制限されています。さらにリクエストは接続要求が成功または失敗するまで順番待ちをします。二つのブラウザーを並行してテストすればこの制限に容易に達するでしょう。その結果、どちらか一方のブラウザーが、数ミリ秒だけ早く実行を開始したために、不当に優位となる結果が出てしまいます。 ここでは二つの単純な例をあげましたが、それ以外にも問題は確実に存在しています。これについてより詳細には論じませんが、ブラウザー パフォーマンスを計測しようとする際の複数アプリケーションの実行に対して、明瞭なアドバイスになっていると思います。 最低でも、他のアプリケーションからの影響を軽減するため、以下の二つのステップを踏むべきです。
サーバーの相互作用コンピュータやネットワークのリソース共有による干渉を乗り越えても、パフォーマンスの結果はアクセス対象のサーバーの内部的な動作で影響を受けます。 パフォーマンス計測での包括的な原則の一つは、テストを通じて一定の状態を保とうとする事です。キャッシュ管理ではパフォーマンス データ収集の前に上流のサーバーを既知の状態にすべきだという事であり、またネットワークでは外部的な要素の影響を低減するために一定の環境でテストが行われるよう管理に努めるという事です。 ベンチマークに影響を与えるアプリケーション設計の特性の例として、オンライン バンキングのアプリケーションを取り上げましょう。セキュリティ上の理由で、バンキング アプリケーションは適切な資格情報が提示された場合にだけアカウント情報へのアクセスを許可するでしょう。二つ (またはそれ以上) のブラウザーをこのオンライン バンキング Web サイトでベンチマーク テストするのであれば、どのブラウザーに対してもアプリケーションを確実に同一の状態する事が重要です。設計上、ほとんどのオンライン バンキング アプリケーションは同時に二つのセッションでユーザーがログインできないようになっています。一方でログインすると、他方ではログアウトされます。二番目のブラウザーのテストを開始する前に Web アプリケーションの状態をリセットするのに失敗すると、サーバー ベースのアプリケーションは二番目のリクエストを解析し、最初のセッションを終了して新しいセッションを開始するために余分な時間を要してしまいます。 このように開始処理と終了処理はベンチマークに影響を与えます。これはオンライン バンキング アプリケーションに限った事ではないので、こうした要素を取り除くようにするべきです。もっと一般的に言えば、パフォーマンス テストに使用する前に、対象となるサイトの動作を理解すべきです。 観察者効果多くの分野において、計測する作業自体が計測しようしている対象を変化させてしまう潜在的な可能性があります。この現象は観察者効果 (英語) と呼ばれています。 特定のブラウジングのシナリオの計測のタスクを単純化するため、数多くのフレームワークのいずれかを使用する事ができます。これらのフレームワークは典型的には開発者や技術者を対象としています。そうしたフレームワークの一例としては Jiffy (英語) があります。 どのようなインフラストラクチャーであれ計測しようとしている結果に直接影響を与えるのであれば、注意深くアクセスし、計測に使用するフレームワークによるパフォーマンスの変化を招く潜在的可能性を最小化すべきです。 余談ですが、IE チームでは内部的なテストに ETW トレース ロギング インフラストラクチャーを使用しています。これは ETW がスケーラビリティーの高いロギング インフラストラクチャーで、結果をゆがめる観察者効果の可能性を最小化する事ができるからです。 コンピュータの構成人と同様に、厳密に同一のコンピュータは二つと存在しません。 前述のように、IE のパフォーマンス検証環境では日々刻々パフォーマンス テストを実行している大量のコンピュータを保有しています。検証環境の柔軟性を最大にするため、IE8 の初期に、首尾一貫したパフォーマンス データのセットを作り出すための、交換可能な "まったく同一" なコンピュータのひと揃いを作ろうと企てました。これらのコンピュータは連番のシリアル ナンバーが付けられており、同じ組み立てラインで生産され、それぞれのコンポーネントは "まったく同一" でした。こうした努力にもかかわらず、ひと揃いのコンピュータから収集されたデータは明らかにまちまちだったため、別々のコンピュータからのパフォーマンスの結果を直接比較する事は避ける事になりました。 これは驚くような事ではありませんが、異なるプラットフォーム間でブラウザーのパフォーマンスはまちまちになるので、すべてのブラウザーのテストを単一のコンピュータで実行するべきだという事を知っていただきたいのです。 コールド スタート対ウォーム スタートブラウザーを開始するのに要する時間の総計は、ブラウザーの管轄外の多数の要素に依存しています。 キャッシュ動作のように、ブラウザーを開始するスピードは外部の要素の影響を受けやすいのです。これは特に初回のブラウザーの起動に顕著です。ブラウザーが Web サイトに遷移を始める以前に、まず自分自身のパーツをメモリーに読み込むという、時間のかかる動作が必要です。初回のブラウザーの起動では、どれだけの部分が既にメモリーに読み込まれているのかを正確に知る事は困難です。特に IE では多くのコンポーネントが他のプログラムと共有されるため、とても難しいのです。 一貫性のあるデータを収集するためには、テストの開始前に対象となるブラウザーをそれぞれ一度起動して終了します。ブラウザーに必要なコンポーネントの一部をオペレーティング システムがメモリーに読み込むような動作をする他のアプリケーションが無ければ、結果の正確さと一貫性は向上します。Windows Superfetch (英語) のような普段よく使うブラウザーに有利になるかもしれない機能についても特に考慮するなら、ブラウザー間の比較も公正になるでしょう。 Web サイトのコンテンツWeb サイトは常に変化しています。残念な事に、パフォーマンスのテストを試みている間もその例外ではありません。 IE チームのパフォーマンス検証環境では、すべての Web サイトのコンテンツはテストの期間中キャッシュ済みになっていました。キャッシュ動作の影響の一つは、テストの繰り返しの毎回、ブラウザーへ正確に同じコンテンツが提供される事です。実際の世界では、これはそう頻繁に起きる事ではありません。 一例ですが、ニュース サイトは話題が知れ渡るにつれコンテンツを更新するでしょう。Facebook や MySpace を二度訪問すれば、友人が新しい写真を追加したり状態を更新していたりするので、まったく異なるエクスペリエンスが得られるでしょう。広告は多くの Web サイトでは頻繁に変更されるので、お気に入りのサイトを二度表示すれば、間違いなく異なっているでしょう。 検証環境でなければ、こうした変更を制御する事は困難です。これに対するアプローチは確かに存在しています。Fiddler のようなツールを使ってブラウザーが受け取るコンテンツを操作する事が可能です。しかしながらこうしたアプローチは、パフォーマンスの結果に影響を与える可能性が大きいのです。結果として、現実的な解決方法はサンプルの量について指摘した際のアドバイスと同様です。ページを数回表示するごとに非常に重い広告が表示されるような場合、整合性のある一連の結果を得るために計測を相当回数繰り返すという方法は正しいと考えられます。 Web サイトの設計Web サイトはアクセスごとに変化するだけでなく、異なるブラウザーにはそれぞれまったく違うバージョンの Web サイトが製作者によって用意されている場合もあります。 テストごとに Web サーバーから確実に同じコンテンツが提供されるようにする上でやっかいな問題の一つが、異なるブラウザーに対して明らかに異なるコードを返す、そのようなサイトです。多くの場合、そうした差異はユーザーが異なる Web サイトを訪問した際のエクスペリエンスを正当に反映していると考え、ブラウザー パフォーマンスの計測では差異を無視するべきでしょう。 とはいえ、Web サイトが提供する機能がブラウザー間で広汎に異なり、ブラウザー間の比較が意味をなさない場合もあります。たとえば、最近お客様から Web サイトの利用に IE8 を使うと競合関係の他のブラウザーを使った場合より時間がかかるという報告をいただき、調査した事があります。調査の結果、その Web サイトは IE を使うと IE 以外を使った場合に比べてよりリッチな機能を提供するフレームワークを使用している事がわかりました。幸いにも Web サイトはそうしたリッチな機能に依存していなかったので、フレームワークの使い方をわずかに変更し、どのブラウザーでも同じ早さで動作するようにできました。 この例のように Web サイトがフレームワークの提供する拡張機能を使用しておらず、サイトを更新できる場合もありますが、多くの場合ブラウザーの種類に依存してまったく異なるユーザー エクスペリエンスを提供しています。このような Web サイトの評価は概ねケース バイ ケースの問題ですが、こうしたサイトはブラウザーのパフォーマンスよりサイト開発者の意図がパフォーマンスに大きく反映されるので、一般的には直接の比較には向かないと考えています。 ブラウザーを区別するサイトを識別するのは単純ではありません。しかもこの場合 Web 開発者は調査担当者の上を行くことができます。Web 開発者はプロファイラーやデバッガー、その他のツールを使い、ブラウザーごとに Web サイトがまったく異なるエクスペリエンスを提供するための識別方法を自由に決める事ができます。 調査担当者やより技術に詳しくないユーザーは、利用してみて明らかに見かけや動作の異なるサイトでの複数ブラウザー間のパフォーマンスの計測は避けるべきです。そうしたサイトを使ったテストでは、ブラウザーのパフォーマンスを Web サイトの設計の影響から切り分ける事は困難です。 「ページが表示されました」「ページが表示されました」という表示の意味を正確に定義できるでしょうか。複雑でインタラクティブな AJAX サイトではどうでしょう。 パフォーマンス計測について驚くほど厄介な問題の一つが、ページへの遷移において「完了」とは何を意味するのかを定義する事です。この厄介な問題は、Web サイトが複雑化し非同期的になるほどよりいっそうひどくなります。ブラウザーがページへの遷移を完了した事を示す標識として HTML "onload"(英語) イベントを使う Web 開発者もいるでしょう。しかしこのイベントの定義は残念な事に、異なるブラウザーによって異なる解釈がされています。 IE チームの内部では、いろいろなサイトでのページ読み込みを計測するために内部的なイベント記録を利用しています。この記録は IE に特化したものなので、残念ながらブラウザーごとのページ読み込みのパフォーマンスを計測するためのクロス ブラウザーの簡単な解決策にはなりません。サイト開発者が各々のシナリオの「完了」を定義するのに役立つ Jiffy (英語) や Episodes (英語) のようなフレームワークは存在しますが、それらの示すものは一般のユーザーに幅広く受け入れられるものではありません。 特定のコードレベルによる識別ではなく、ブラウザーの進捗インジケーター (砂時計、青いドット、プログレス バー、テキスト ボックスやその他のユーザー インターフェイス要素) をページのダウンロード完了の通知に使用する人もいます。しかしこれらの要素はどのような標準にも律せられておらず、ブラウザーの製造者はこれをいつ表示するか (さらには表示するかしないかも) 独自に決定できます。 こうした現実に直面した上で調査担当者やユーザーに採用をお勧めできるのは、実際の Web ページの動作に対応している事が確認できる分には、ブラウザーの進捗インジケーターを使用する事です。たとえば特定の Web ページがどれだけ速やかに読み込まれるのかをテストするなら、最初の読み込みの際にブラウザーの進捗インジケーターを使ってみましょう。もし進捗インジケーターが完了を示す前に Web ページが読み込まれ操作可能になったように見えるのであれば、インジケーターは無視してページの見え方を計測のために使用します。あるいはさまざまなブラウザー間でページのダウンロードの早さを初期的に評価するだけなら、進捗インジケーターで十分かもしれません。実際のページ読み込みとブラウザーのインジケーターの表示がどれだけ一致しているかを評価することなしには、パフォーマンスの計測の際にインジケーターを信頼すべきか判断できません。 ブラウザーのアドオンブラウザーのテストをする際にアドオンを動作させると、ブラウザーのパフォーマンスだけをテストしているとは言えなくなります。 4 月の投稿でも論じたように、アドオンはブラウザーのパフォーマンスに非常に大きな影響を与えます。Microsoft のデータ経路を通じて受け取ったデータでは、数十のアドオンがインストールされたブラウザーは珍しくなく、おそらく Mozilla corporation で私と同じ立場の人間も彼らのブラウザーについて同じような事を言うと思います。 こうしたアドオンはどれも、ブラウザー内で独自の活動を行います。この影響について逸話的に説明すると、良く使うブラウザーを持っているユーザーが、他のどんなブラウザーでも普段のブラウザーよりそちらの方が早いと感じるのは、単に新しいブラウザーはクリーンな状態だからだと気付きました。たとえば、いくつものアドオンがインストールされている Firefox のユーザーが IE に変更するとすばらしくパフォーマンスが向上しているように感じますし、IE のユーザーが Firefox に移行した場合も同じようなパフォーマンスの向上を感じるでしょう。この結果は決して矛盾しておらず、ブラウザーのアドオンの影響の大きさを反映しているのです。 結果として、私たちのパフォーマンス検証環境では、クリーンなブラウザーのインストールと、一般的によく使われるアドオンをインストールしたブラウザーの両方についてテストしました。IE8 でアドオンを無効にするには、"ツール" メニューをクリックして "アドオンの管理" を選択します。アドオンの管理の画面では、まず "表示" で "すべてのアドオン" を選択し、次に表示されたアドオンを一つずつ無効にします。または、コマンド ラインになじみがあるならアドオンを無効にした IE を "iexplore.exe -extoff" コマンドで起動できます。 ほとんどのブラウザー メーカーはブラウザーをアップグレードしてもアドオンが正しく機能し続ける事が保証されるよう力を尽くしています。しかしどのようなパフォーマンスの向上であってもただ一つの不作法なアドオンのために台無しにされてしまうかもしれませんから、上記のような手順を踏む事は非常に重要です。 この投稿は少し長くなりすぎたかもしれませんが、私たちが IE のパフォーマンスを計測する際のいくつかのテクニックに触れた事で、それらを皆さんのニーズに応用していただければ幸いです。また私たちがパフォーマンス テストについてどのように考えているのかを理解していただく事で、私たちのブラウザー パフォーマンスへのプロセスとアプローチをより良く理解していただけると思います。最後になりましたが、IE8 の提供過程の背後で、どのような取り組みが成されているのかについて少しでも分かっていただければなお幸いです。 Christian Stockwell |
ページのトップへ