最新版のWebブラウザー「Internet Explorer 11」（以下、IE）は、2013年10月に正式リリースされ、その後のアップデートでも機能が少しずつ強化されてきた。例えば、2014年4月のWindows 8.1 Update 1提供と同時に機能が強化され、2014年8月のアップデート（August Update）でもさらに更新されている*1。

　そのIEにも、Chromeのデベロッパー・ツールと同様に、Web制作者向けのツール「F12開発者ツール」が標準搭載されており、そのツールもIE10以前からIE11のアップデートで大幅に変更されている。そこで本稿では、強化された新機能を中心に、最新のF12開発者ツールの主要機能（具体的には下記の機能）を一通り解説する。

• ウィンドウ全体
• ［DOM Explorer］ツール
• ［コンソール］ツール
• ［デバッガー］ツール
• ［ネットワーク］ツール
• ［UI の応答］ツール
• ［プロファイラー］ツール
• ［メモリ］ツール
• ［エミュレーション］ツール

　なお上記のアップデートでは、それぞれのアップデートのタイミングで、F12開発者ツールも更新されているが、本稿では、執筆時点の最新である2014年8月の更新（August Update）を使って紹介していく。

大幅に変更されたユーザーインターフェース

　F12開発者ツールは、その名の通りF12キーを押すか、メニューバーの［ツール］または右上にあるギアアイコンから［F12 開発者ツール］をクリックすることで起動できる（図1.1）。

　IE11のF12開発者ツールを開いた瞬間、見た目や雰囲気がIE10から大幅に変わっていることが分かるだろう（図1.2）。

　まずは、ウィンドウ全体を説明しよう。

▲ツールの一覧に戻る

ウィンドウ全体

　1でドキュメントモードを切り替えられる。ドキュメントモードとは、ブラウザーの描画エンジンのことで、最新を表す「Edge」や旧バージョンの「10」「9」「8」「7」「5」などから選択できる（詳細後述）。互換性を重視するIE特有の機能だといえる。

　2のボタンを押すことで、現在利用しているツールの下部に［コンソール］ツール（後述）を表示できる。［コンソール］ツールは、よく使う機能なので、どのツールを使っているときでも組み合わせて表示できるようになっているというわけだ。この下部表示だけでなく、F12開発者ツールの左端にある［コンソール］ボタンをクリックすることでウィンドウ全体に表示することもできる（図1.4）。

　左端に並んでいる3のボタン群は、ツールを切り替えるためのものだ。各ボタンの表記には、アイコンだけで名前がないので、最初は分かりにくいかもしれないが、上から順に［DOM Explorer］／［コンソール］／［デバッガー］／［ネットワーク］／［UI の応答］／［プロファイラー］／［メモリ］／［エミュレーション］ツールを表示するためのボタンになっている。

　それでは、ツールごとに使い方を説明していこう。

各ツールの機能

▲ツールの一覧に戻る

［DOM Explorer］ツール

　［DOM Explorer］ツール（以下、DOM Explorer）を使うと、現在表示しているページのHTMLとCSSを同時に確認でき、変更をリアルタイムに確認できる（図2.1）。まずは基本的な機能を紹介しよう。

A要素の選択

　［要素の選択］ボタンを押すと、IEのブラウザー上で要素を選択するモードになる。そこでマウスカーソルを当てた箇所がハイライトされて選択できる（図2.2）。

　この機能を使うと、HTMLソースの要素から掘り下げて探す必要がなくなり、調べたい箇所の要素にすぐに移動できる。F12開発者ツールの中でもよく使う機能の1つで、例えば、想定外に表示が崩れてしまっている原因の調査や、どうやって実現しているのかを調べたい場合などに便利な機能である。

　F12開発者ツールを起動してから選択する以外にも、ブラウザー側からF12開発者ツールを呼び出す方法もある。ブラウザー上で確認したい箇所を右クリックしてコンテキストメニューから［要素の検査］をクリックすると、右クリックした要素が選択された状態でF12開発者ツールが表示される（図2.3）。

BDOM要素の強調表示

　［DOM 要素の強調表示のオン］ボタンを押すと、DOM Explorerで選択されている要素が、ブラウザー上でハイライト表示されるようになる（図2.4）。

　要素から表示されている位置を探すのに便利な機能だ。このボタンはトグルするので強調表示をオフにするには、同じ位置に表示されている［DOM要素の強調表示のオフ］ボタンをクリックする。

Cカラーピッカー

　［カラー ピッカーの表示/非表示］ボタンをクリックすると、色の選択、生成、抽出を行える。

　カラーピッカーの上部左端に表示されているスポイトツールを使用すると、ページ内の画像や要素などからだけでなく、デスクトップ上のどこからでも色を抽出できる。例えば顧客に指定された色をOutlookのメール表示ウィンドウから抽出するといったことができる。またスポイトツールのアイコンの横に並んでいる色から選択したり、選択した色をベースに彩度や輝度を変更して適切な色を生成したりできる。

Dパンくず（階層リンク）

　パンくずは、現在選択されている要素を階層で表示しているものだ。

　このように選択されている要素が階層で表示されるため、「ある要素にスタイルを記述したい」と考えたときの階層の確認や、タグの閉じ忘れにより階層がずれたときに、ブラウザーでどのように解釈されているかを調べられる。

E要素ウィンドウ

　要素ウィンドウには、現在表示しているページのHTMLソースがリアルタイムに表示されている。例えばJavaScriptでスライダーをアニメーションさせているようなページでは、そのHTMLソースを見ることで座標が変わっていく様子を確認できる。また、要素ウィンドウの便利な点は、HTMLソースを編集して（図2.7）、その内容が反映されたWebページの表示内容をブラウザーで即座に確認できる点だ。

　このようにテキストやHTMLタグ内のテキストや属性を変更して、それが反映されたページ表示内容を確認できる。また、上の画像のように属性の変更時にはIntelliSense（＝入力候補の一覧）が表示されて候補から選択することもできる。これを使うことによって、例えば作成したHTMLページ上に長い文字列が入力されてもデザインが崩れないかを確認したり、他のCSSクラスを指定してみたらデザインがどのように変わるかを確認したり、ブラウザーで直接、変更内容を確認しながらデザインを決められる。

Fスタイルウィンドウ

　スタイルウィンドウも要素ウィンドウと同様に、現在表示されているページ上で選択されているタグに適用されているCSSスタイルを確認・編集できる。

　ここには［スタイル］タブに加えて、いくつかのタブが表示されている。まずは［スタイル］タブから順に、各タブの機能について見ていこう。

［スタイル］タブ

　この例では、reset.cssファイルに記述されているCSSスタイルがbase.cssファイルに記述されているもので上書きされ、それが<h1>タグに適用されていることが分かる。

　スタイルタブの中に「a:」の文字が表示されていることにお気づきだろうか？ これは「疑似状態」と呼ばれる状態をシミュレーションして表示できる機能である。以下はその利用例だ。

　［ホバー］チェックボックスをチェックするとマウスカーソルをホバーした状態の表示を確認できる。また、［表示済み］チェックボックスをチェックすると、表示済みリンクがどう表示されるかを確認できる。上の画面では、［ホバー］チェックボックスをチェックしている。ホバーした状態ではリンクの色が変更されて、アンダーラインが追加されることが分かる。

［属性］タブ

　［属性］タブでは、要素に最終的に適用されているCSSスタイルを一覧で確認できる。

　［属性］タブをアクティブにすると、要素に適用されているスタイルが表示される。ここで、人型のアイコン（＝ユーザースタイルのみを表示する機能）をクリックしてオフにすると、Webページ制作者が明示的に適用しているスタイルの他に、ブラウザーがデフォルトで持っており暗黙的に要素に適用されているスタイルも表示されるので、つまり全ての適用中のCSSスタイルを確認できる。これにより、なぜ要素がそのスタイルで表示されているのか、その原因を見つけ出せるようになっている。

［レイアウト］タブ

　［レイアウト］タブは、選択されている要素の幅や高さ、要素の余白を確認できる機能である。

　HTMLソースを書いていて、本当は1行で表示されてほしいのに、なぜか折り返されてしまったことがあると思う。そのようなときに、「なぜブラウザーがその幅だと決めたのか」を調べられる。また、表示されているテキストの余白を確認して編集することで、見た目がどのように変わるのかを確認できる（上の図2.11の例では、余白を「0」から「50」に変えてみている）。

［イベント］タブ

　［イベント］タブでは、要素のイベントに関連付けられているJavaScriptコードの処理を確認できる。

　このようにイベントに関連付けられている関数名と、スクリプトファイル名、行番号を確認でき、ファイル名（行番号）をクリックすると、後述のデバッガーツールでスクリプトの内容が表示される。

［変更］タブ

　［変更］タブでは、［スタイル］タブで変更した内容を確認できる（図2.13）。

　このように、どのファイルの、どの項目を変更したのかを確認でき、ブラウザー上で最適な表示になったスタイルを確認できるようになっている。また、［スタイル］タブでも同じく、変更した箇所を確認できる（図2.4）。

　このように［スタイル］タブでは、変更前の内容を見ることはできないが、追加されたスタイルは緑、変更されたスタイルはオレンジ、削除されたスタイルは赤のバーで、タブの左端に示される。

▲ツールの一覧に戻る

［コンソール］ツール

　［コンソール］は、エラーや情報などのログを表示、オブジェクトや要素の状態の確認と操作、JavaScriptコードを試しに実行してみるなど、さまざまなことができるツールである。コンソールは非常に多くの機能を持っているため、ここではよく使う便利な機能に絞って説明していく。

　まずは、ウィンドウ全体を見ていこう。

　例えばCをオフにすると、ページのリフレッシュや、他のページに遷移してもログを残せるようになる（図2.16）。

　このようにページを読み込み直してもログが残るため、比較したいときや、前のログを残して後で確認したいときに便利だ。

　では、ログの確認をしていこう。ページを表示して、想定通りの結果にならないときは、コンソールを確認してみるとエラーが出力されていることがある。次の画面は、その例だ。

　ページの表示で、エラーがあった場合、コンソールにエラーログが出力される。エラー内容に応じて、JavaScriptコードやHTMLソースを修正して、リリース時にはエラーが出力されない状態にするのが望ましい。

　参考までに［コンソール］ウィンドウ最下部にある入力ウィンドウから「情報」（info）、「警告」（warn）、「エラー」（error）を表示してみよう。図2.18では「console.lo」と入力中だが、ここでconsole.info／console.warn／console.errorの各メソッドを使用すればよい（入力ウィンドウではJavaScriptコードを実行できる）。

　このように、メッセージのレベルによってアイコンで区別できるようになっている。Web開発時に状態を出力したり、情報をコンソールに出力したりする場合には、それぞれの情報レベルに応じて、console.info（情報）／console.warn（警告）／console.error（エラー）メソッドを呼び出せばよいわけだ。

　また、入力ウィンドウへのJavaScriptコードの入力時には、IntelliSenseで入力補助が表示されていることが分かる（図2.18）。これのおかげでメソッドやオブジェクトを探すのが非常に楽になっている。この入力ウィンドウは、サイズを広げて複数行入力可能にすることもできる（図2.19）。

　複数行入力の場合は、Enterキーは改行のために使用されるため、入力したJavaScriptコードを実行するには、Ctrl＋Enterキーを押すか、右下の再生ボタン（）をクリックする必要がある。

　［コンソール］ウィンドウでは、現在表示しているページを直接操作できる。そのため、「ページ内の要素を操作するJavaScriptコードをページに読み込ませよう」と考えている場合は、事前にコンソールで動作確認してから、実際のJavaScriptファイルを作成するのがお勧めだ。こうすれば、「JavaScriptファイルを編集し、ページをリフレッシュして動作を確認し、再びファイルを修正する」といった一連の作業を簡略化して開発時間を短縮できる。実例を示そう。

　図2.20では、表示中のページの<title>要素のテキストを、初期状態の「コンソールを表示します。」から「Console updated」に変更している（※$("title").text("Console updated");というjQueryを用いたJavaScriptコードが、それを実現している箇所。前後のconsole.logメソッドの呼び出しは､テキストの変更を確認するためにログ出力しているだけだ。ちなみに、表示中のページでjQueryがインポートされていれば、この例のようにjQuery構文が使用することもできる）。

　もう1つ便利なのがJavaScriptのオブジェクトの表示／編集機能だ（図2.21）。

　この例では、「a」というオブジェクトを作成して、その状態をconsole.logメソッドで表示しているが、実際には、表示しているページで実行しているJavaScriptコードのオブジェクト状態を表示して、編集することもできる。これにより、デバッグ効率も良くなるだろう。

　もう1つよく使う機能は、タイマーだ。console.timeメソッドでタイマーを開始して、console.timeEndメソッドでタイマーを終了し、経過時間がコンソールに表示される。ページで処理されるJavaScriptコードのボトルネックを調査するときなどに役立つ。

　例えば「タイマーをネストさせたい」という要望も多いと思うが、そのときは、console.timeメソッドとconsole.timeEndメソッドをタイマーの名前を付けて呼び出せばよい（図2.22）。

　このようにタイマーで処理時間を計測できる。タイマーに名前付けない場合は、「default」で表示されていて、「a」「b」と名前を付けたタイマーは、それぞれ名前付きで表示されている。

　この他にもコンソールには、便利な機能がいろいろとあるので、ぜひヘルプサイトを参照してみてほしい。

▲ツールの一覧に戻る

［デバッガー］ツール

　［デバッガー］ツールを使うと、JavaScriptコードをデバッグできる。

　まずはウィンドウ全体を見ていこう。

　まず1と2について説明する。

　1をオフにすると、jQueryなどのライブラリを含めて、全てのコードがデバッグ対象になる。逆に、デフォルトのオンのままであれば、ステップインでコードの中に入っていったとしても、共通ライブラリを除いて、自分たちが書いたコードだけをデバッグできる。自分たちが書いたコードには問題がなくて、共通ライブラリ側が疑わしくなったときだけ、これをオフにしてトレースしていけばよい。

　2から、ページで読み込まれているJavaScriptファイルを選択できる。jQueryのファイルについては右側にアイコンが表示されている。このアイコンは、このファイルがユーザーコードではないと判断されており、デバッグ対象外になっていることを示している。一般的なライブラリは自動判別されるが、一般的ではないライブラリやプロジェクトで共通的に使われているライブラリでデバッグ対象外にしたい場合は、ファイル名の右端の部分をクリックすれば、デバッグ対象外にできる（図2.24）。

　3～5については、デバッグ時の動作を見てもらうと分かりやすい。以下ではJavaScriptコードのデバッグについて説明していこう。

デバッグ

　デバッグは、Visual StudioやEclipseなどのIDEと同等のことができると考えてよい。特にVisual Studioを使っている場合は、ショートカットキーが同じなので使いやすいだろう。デバッグ実行時のイメージを見てみよう。

　2の［ウォッチ］ウィンドウには、現在実行中のコードで使用されている変数が自動的に表示され、開発者が変数の変化を追いたいときは、［ウォッチ式の追加］ウィンドウでカスタム変数を追加できる。グローバル変数などで変化を常に追いたいときや、要素のテキストや属性値を追いたいときなどに追加すると便利だ。

　3の［呼び出し履歴］ウィンドウには、現在実行中のコードの呼び出し履歴が表示される。複数箇所から呼び出される関数をデバッグする場合などに、どこから呼ばれたのかを確認できる。

［ブレークポイント］ウィンドウ

　［呼び出し履歴］ウィンドウの隣にある［ブレークポイント］ウィンドウに切り替えると（図2.26）、開発者が設定したブレークポイント（後述）やトレースポイント（後述）を一覧で確認できる。また、ここからイベントにブレークポイントやトレースポイントを追加できる。

　なおブレークポイントは、対象の処理が実行されたときに一時停止されてデバッグできるようになるポイントであり、トレースポイントは、対象の処理が実行されても停止はせず、コンソールにログが出力されるポイントのことである。

　1には、下記のようなブレークポイントとトレースポイントが一覧で表示されている。

• ●： ブレークポイント
• ○： 無効化されているブレークポイント
• （＋）： 条件付きのブレークポイント
• ◆： トレースポイント

　次に、上に並ぶアイコンを説明していこう。2と3は、イベントに対してブレークポイントやトレースポイントを設定できるボタンである。各ボタンをクリックすると、次のようなダイアログが表示される。

　この機能があることで、自分が全体を把握していないコードでも、イベント発生時に実行されるコードを特定できるので、デバッグが容易になる。ブレークポイントにある「条件」とトレースポイントにある「トレース」については後述する。

　上記の4と5は、一括でブレークポイント、トレースポイントを操作できる機能である（図2.28）。デバッグを継続していくと、ブレークポイントを細かく設定しすぎることがよくある。そんなときは、いちいち全てのコードの対象箇所に移動しなくても、ここから一括で外すことができるので便利だ。

　このように一覧で表示されるため、デバッグのオン／オフを容易に指定できる。また、4ボタンを押すとブレークポイントを一括で無効にできる。また5のボタンで、ブレークポイントを全て削除できる。

ブレークポイント

　ブレークポイントの設定方法を、以下の画面で説明する。

　1つ目の方法は、コードの行番号の左に表示されているグレーのエリアをクリックするか、ブレークポイントを設定したい行にカーソルがある状態で右クリックしてコンテキストメニューから［ブレークポイントの挿入］を選択する（図2.29の上の画像）、もしくはそこでF9キーを押すことだ。これにより、ブレークポイントが設定される。ブレークポイントが設定されているコードの行には赤丸が表示され（図2.29の下の画像）、薄い赤でハイライトされるが、それと同時に［ブレークポイント］ウィンドウの一覧にも追加される。

　ブレークポイント一覧で、ブレークポイントを選択すると右端にアイコンが表示される（図2.30）。［×］アイコンはブレークポイントの削除、鉛筆アイコンは、ブレークポイントへの条件の追加だ。

　ブレークポイントへの条件とは、特定の条件のときだけブレークする「条件付きブレークポイント」と呼ばれる機能で、デバッグ時には非常に便利だ。実際の設定方法を見ていこう。

　これを実行することで、変数iの値が「2」のときだけ、ブレークポイントで停止するようになる。次の画面はその例である。

　これを使うことで、特定の条件が成立するときにだけ発生するバグを特定したいときなどで、条件になるまで毎回目視して、処理を流すといった面倒な作業が必要なくなる。

トレースポイント

　トレースポイントとは、ブレークはしないチェックポイントである。トレースポイントを設定して、通過したときにログを出力できる。トレースポイントの設定を見ていこう。

　コードを右クリックして、コンテキストメニューの［トレースポイントの挿入］をクリックすると、［トレース対象のメッセージ］ダイアログが表示される。ここでは、通過時に出力されるメッセージを設定する。変数の値だけを出力しても多くのログメッセージの中に埋もれてしまう可能性が高いため、「変数名などの文字列＋変数の値」を設定することをお勧めする。

　このようにトレースポイントを設定すると、コードの横にひし形のアイコン（◆）が表示され、通過時に［コンソール］ツールにログが表示される。

altJSのデバッグ

　IEのF12開発者ツールは、「altJS」と呼ばれるJavaScriptコードを生成する代替言語のデバッグができるようになっている。altJSで生成されたJavaScriptファイルを読み込んでいるページでは、altJSの元ソースが読み込まれてデバッグが実行される。以下に、altJSの1つであるTypeScriptを使用したWebアプリのデバッグ例を示す。

　図2.34では、ページ内でJavaScriptファイルであるapp.jsファイルが読み込まれているが、ソースの一覧にはTypeScriptファイルであるapp.tsファイルが表示されている。また、図2.35に示すように、このファイルを開いてブレークポイントを設定すると、きちんとデバッグできることが分かる。

　このように、JavaScriptコードにコンパイルされる前のaltJSのコード（上の例ではTypeScriptコード）でデバッグできる。これは、JavaScriptファイルと元のソースファイルをマッピングするファイルを読み込むことによって実現されている。仕組みを見てみよう。

　JavaScriptファイルの最後の行に、マッピングファイルである.mapファイルが指定されている（図2.36）。

　この記述があると、デバッガーはマッピングファイルを読み込む。マッピングファイルの中は、例えば、以下のようになっている。

　このように暗号のような内容が記述されているが、このファイルにはコンパイル済みのJavaScriptファイルと元ソースの行やカラムの位置情報が記述されている。もちろん、.mapファイルや元ソース（TypeScriptの場合は、.tsファイル）が存在しない場合は、JavaScriptのコードをデバッグすることになる。

　本番環境へのリリース後にデバッグしたいときなど、元のソースファイルやマップファイルを配置しないことも多いだろう。そのようなときには、デバッガー上で、ローカルのマップファイルを選択して、ソースをデバッグできるようになっている。JavaScriptソースを開いた状態で、タブを右クリックすると、コンテキストメニューに［ソース マップの選択］が表示される（図2.37）。これをクリックすると、ファイル選択ダイアログが表示されて、.mapファイルを選択できる。

　このJavaScriptファイルのコンパイル時に生成された.mapファイルを選択すると、開いているJavaScriptファイルの代わりにローカルにある元ソースが表示されて、元のソースでデバッグできるようになる。

ミニファイされたコードの整形

　［デバッガー］ツールの説明の最後に、非常に便利な機能を紹介しよう。

　jQueryなどのライブラリだけでなく、自分たちが作ったコードでも、ページ閲覧時の読み込みスピードを上げるためにコードの改行やタブ、スペースを除いて、JavaScript／CSSファイル内のコードを最適化しているケースも多いだろう。そのようなコードをデバッグするのは非常に困難だが、デバッガーツールには、改行やインデントで、コードを整形してくれる機能が提供されている。使い方は以下の通りだ。

　このように整形出力をオンにするだけで、人間が読めるコードに整形することが可能だ。

▲ツールの一覧に戻る

［ネットワーク］ツール

　［ネットワーク］ツールは、ページ全体を表示するまでのネットワーク通信内容を記録するツールだ（図2.39）。

　通常は、ページの表示が遅いときに、時間がかかっている箇所を特定するために使用される。一般的には、チューニングで最初に使用するのがこのツールである。

　1～6はそれぞれ以下のような働きをする。

• 1 ネットワークの記録を開始・停止する： 再生ボタン（）を押すことで、記録を開始して、停止ボタン（■）を押すことで、記録を停止する。記録中は、ツールをアクティブにしていなくてもバックグラウンドで記録される
• 2 キャプチャしたトラフィックをエクスポート： キャプチャした内容をXML形式やCSV形式で出力できる。特定の環境でのみ画像が表示されないといった問題が発生した場合、原因を切り分ける方法の1つとして、この機能を使ってキャプチャ内容をエクスポートしてもらい、メールなどで送ってもらうとよいだろう
• 3 常にサーバーから更新する： 画像やCSS、JSなどのファイルは、通常、ブラウザーにキャッシュされるが、このキャッシュを使わずに全てをダウンロードするかどうかを設定できる
• 4 ナビゲーション時にエントリをクリア： 表示しているページのパフォーマンスを計測するか、クリアされるまで表示を残すかを設定できる。例えば自動リダイレクトされる場合に、リダイレクト前のページも記録したいケースなどで使用する
• 5 要約： ページを表示するためにダウンロードされた全てのファイルを、要約して表示する。ここではダウンロードに時間がかかるファイルを特定して、［詳細］ビューでその理由を特定するといった使い方ができる
• 6 詳細： 「要約」で選択された行の詳細情報を確認できる

［要約］ビュー

　［要約］ビューでは、ネットワーク通信でダウンロードされたファイルの一覧とその概要を確認できる

　一覧には、左から順に［URL］／［プロトコル］／［メソッド］／［結果］（＝HTTPステータス）／［種類］（＝Content-Typeヘッダーに指定されたファイルの種類、いわゆるMIMEの内容）／［受信］（＝ファイルサイズ）／［所要時間］（＝ダウンロードにかかった時間）／［イニシエーター］（＝ダウンロードのきっかけになった記述）／［タイミング］が表示されている。

　一般的には、タイミングのバーが長いものはダウンロードに時間がかかっているため、「チューニングの対象となる可能性がある」と考える。例えば、画像ファイルの場合は圧縮率を上げたり、サイズを変更したりできないか。JSファイルの場合は、ミニファイできないか。また、Webサーバーの負荷の問題であったり、物理的な距離の問題だったりする場合は、CDN（コンテンツ配信ネットワーク）に退避できないかを検討する。

　この画面では、もう1つ気になる点がある。選択されハイライト表示されている行は、1つ上の行のダウンロードが終わってからしばらく待った後で、ダウンロードが開始されている。このような場合、ページのHTMLソースやJavaScriptコードの書き方に問題があって、ダウンロードが遅延されてしまっている可能性がある。そのときに、ページの描画が止まってしまっていると、利用者が表示されるまで待たされてしまうことになる。もしそのような場合は、遅延読み込みやHTMLソースの構造を変更するなどの対応が必要になってくる。そのウィンドウから、その対応が必要かどうかを判断していく。このケースでは、［イニシエーター］が「フレームの移動」になっており、ダウンロードしているファイルがPocketのページであるため、IFrameで表示されたボタンであることが特定でき、「遅延読み込みされているため、ページの表示には直接影響していない」と判断できる。

［詳細］ビュー

　［詳細］ビューでは、ファイルごとの詳細な通信内容を確認できる。このビューには［要求ヘッダー］［要求本文］［応答ヘッダー］［応答本文］［Cookie］［イニシエーター］［タイミング］の各タブがある。

　［要求ヘッダー］タブを以下に示す。ここではHTTPリクエストヘッダーの内容を確認できる。

　［要求本文］タブでは、サーバーへ送信されたリクエストの本文が表示される。

　［応答ヘッダー］タブでは、サーバーから返送されてきたHTTPレスポンスヘッダーの内容を確認できる。

　［応答本文］タブには、サーバーから返信されてきたHTTPレスポンスの本文の内容が表示される。

　［Cookie］タブには、通信中に送受信したCookieに関する情報が表示される。

　［イニシエーター］タブには、ファイルのダウンロード処理に関する詳細が記載されている。

　最後の［タイミング］タブには、ファイルのダウンロード要求に関連する情報が表示される。

　［タイミング］タブでは、このファイルがダウンロードされるまでの詳細な時間が視覚的に確認できるため、チューニングが必要なポイントを絞り込むことができる。

　［待機］行には、ページの読み込みが開始されてから、対象のファイルのダウンロードが開始されるまでの時間が表示される。このファイルがページの表示までに必要で、待機時間が長い場合、HTMLソースの構造や、ファイルの要求タイミングが遅い可能性がある。

　［開始］行に表示されるのは、要求が作成されてから送信されるまでの時間であり、この時間が長いということは、要求の送信に時間がかかっていることになる。サーバーの物理的な距離が遠かったり、サーバー側の負荷が高かったりといったことが考えられる。

　［要求］行には、要求を送信してから最初の応答があるまでの時間が表示される。この時間が長い場合、サーバー側の処理時間が長いと考えることができ、サーバーサイドの処理をチューニングする必要がある可能性が考えられる。

　［応答］行には、ファイルを全てダウンロードするまでにかかった時間である。この時間が長いということは、ファイルサイズが大きすぎる、ネットワーク回線が細すぎる、サーバーまでの物理的な距離が遠すぎるといった可能性が考えられる。

　［ギャップ］行には、ファイルのダウンロードが完了してから実際に描画されるまでにかかった時間が表示される。これにはさまざまな要因が考えられるため、これだけでは判断が難しいが、この時間が短いほど、ページの描画が速いといえる。

▲ツールの一覧に戻る

［UI の応答］ツール

　［UI の応答］ツールは、ページが表示されるまでのさまざまなイベントを視覚的に見ることができる機能である。

　1～7について、簡単に説明をしておこう。

• 1 プロファイリングの開始／停止： プロファイルは、手動で開始・停止する。そのため、ページの読み込み時だけでなく、ページが読み込まれた後のイベントだけの採取もできるようになっている。例えば、ゲームなど動的に描画する時のパフォーマンスを採取することもできる
• 2 プロファイリングセッションのインポート
• 3 プロファイリングセッションのエクスポート： プロファイルの結果をファイルに保存したり、ファイルから読み込んだりできる。これにより、「パフォーマンスが出ない」と言っているユーザーにファイルをエクスポートして送付してもらって、そのファイルをインポートして分析するといったことができる。ファイルは、「.diagsession」という拡張子のバイナリファイルである
• 4 ルーラーと診断セッションのイベント： 診断セッション中に発生したアプリライフサイクルイベント（＝ページ遷移やDOM読み込みなど）とユーザーマーク*2が表示される

• 5 ［CPU使用率］： ページの描画中に使用されたCPUの使用率とその詳細が表示される（図2.49）。ここで負荷の高い処理を絞り込んで、［タイムラインの詳細］で特定していくとよい。マウスカーソルで範囲を選択して、選択範囲のみの詳細を調べることもできる

• 6 ［視覚スループット］： 1秒あたりのフレーム数が表示されている。例えば、アニメーション処理中にフレームレートが落ちている場合は、処理をチューニングしてパフォーマンスを改善する必要がある
• 7 ［タイムラインの詳細］： ここには詳細なイベントが表示されているため、負荷の高い処理の詳細を調べられる

［タイムラインの詳細］

　［タイムラインの詳細］では、ページの描画の処理がかなり詳細に表示される（図2.50）。

　左ペインで処理を選択すると、右ペインに処理時間とその割合が表示される。左ペインの処理を展開していくと、どのタグの解析にどれだけ時間がかかっているかまで掘り下げて調査できる。

　処理中にHTTP要求があると、その処理時間と、画像であればそのプレビューが表示される（図2.51）。

　図2.52で示す［並べ替え］ドロップダウンで「継続時間 (包括)」を選択すると、処理の実行順序ではなく、処理時間の長い順に表示される。ページが表示されるまでの時間が長い場合は、上から順に改善を検討していくことで、効率的にページ表示速度を改善できる。

　図2.53に示すように、描画イベントをフレームごとにまとめることもできる。

　［イベントのフィルター処理］でチェックをオン／オフすることで、イベントの種別を絞り込むことができる。また、イベント処理継続時間が1ミリ秒以上のもののみの絞り込みもできる（図2.54）。

　このように、ページの表示処理にかかった時間の詳細が確認できるため、パフォーマンスチューニングに非常に有益であることがご理解いただけたのではないだろうか。

▲ツールの一覧に戻る

［プロファイラー］ツール

　［プロファイラー］ツールでは、JavaScriptコードの処理時間を計測できる。

［機能］ビュー

　図2.55は［プロファイラー］ツールの［機能］ビューである。

　［機能］ビューでは、JavaScriptの関数が詳細に表示されているため、処理時間が遅く、呼び出し回数が多い関数をチューニングすればページ全体の速度が改善されると考えられる。

［呼び出しツリー］ビュー

　だが、個人的には、［呼び出しツリー］ビュー（図2.56）の方が役に立つと考えている。

　［呼び出しツリー］ビューでは、関数の呼び出しが階層で表示されている。［包括時間 (ミリ秒)］列に表示されているのは、階層全体の処理時間なので、ここで処理時間が長い処理を掘り下げていくと、ユーザーコードの、どの関数の呼び出しが遅いかを特定できる。関数名（＝［機能］列）をダブルクリックすると、［デバッグ」ツールに遷移して、コードを確認できる。

▲ツールの一覧に戻る

［メモリ］ツール

　［メモリ］ツールは名前の通り、メモリの使用量を調査できるツールだ（図2.57）。

　プロファイリングセッションを開始（1）すると、終了（2）するまでメモリの合計（6）がグラフで表示される。5でメモリの状況を採取して、4でエクスポートし、3でインポートできる。

　5の［ヒープ スナップショットを作成します。］をクリックすると、そのクリック時点での、ページで使われているメモリの詳細情報（＝スナップショット）が採取される（図2.58）。

　このように、スナップショットを撮るたびにメモリやオブジェクトの増減を確認できる。また1～4のようなリンクをクリックすることで、その詳細を確認できる。例えば、オブジェクト数の増減を示している4をクリックしてみよう。すると次の画面のように表示される。

［種類］ビュー

　スナップショット間のオブジェクトが［種類］別にグループ化されて表示されていることが分かると思う（上の画面では［識別子］列の値が「Function」のような形でグループ化されているが、これを展開した後の各オブジェクトにおける［種類］列の値は「Function」となっている）。単純なメモリ使用量調査するのであれば、この［種類］ビューが使える。

［ルート］ビュー

　［ルート］ビューでは、オブジェクトがルートオブジェクトごとにグループ化されて表示される（図2.60）。

　［ルート］ビューを使うと、ルートオブジェクトから階層で表示されるため、依存関係を見ながらオブジェクトを調べられる。強い依存関係を持ったオブジェクトは、ガベージコレクターで解放されにくいので、メモリ使用量が多いオブジェクトが階層で表示された場合は、明示的に依存関係を切るといった対応を検討した方がよい。

［ドミネーター］ビュー

　［ドミネーター］ビューでは、より詳細なオブジェクトの状態を参照できる。

　［ドミネーター］ビューでは、オブジェクトごとの詳細な情報まで見ることができるため、具体的にどのオブジェクトがどういう状態で、メモリを多く使用しているのかを特定するのに便利だ。

　このようにF12開発者ツールでは、メモリの詳細情報まで追えるようになっている。そのため、作成したページのメモリ使用量が多い場合や、使っているうちに次第にメモリ使用量が増えていく場合などで、問題がどこにあるのかを特定する際に役に立つ。

▲ツールの一覧に戻る

［エミュレーション］ツール

　［エミュレーション］ツールは、IEの以前のバージョンを含む他のブラウザーでの動作を確認したり、位置情報を偽装してGPSを使ったアプリの動作を確認したりできる機能である（図2.62）。

　［モード］セクションでは、ブラウザーの設定を変更して表示を確認できる。

ドキュメントモード

　まずは［ドキュメント モード］から見ていこう。

　「ドキュメントモード」とは、前述したようにページの描画エンジンのことであり、例えば「7」を選択すると「IE7の描画エンジンを使用して描画する」という意味になる。これは、他のモダンブラウザーには存在していない、IE特有の機能だ。ページで選択されているドキュメントモードには、「(既定)」と表示されており、そのドキュメントモードが選択された理由が、ドロップダウンの下に表示される。

ブラウザープロファイル

　［ブラウザー プロファイル］は、あらかじめ登録されているブラウザーの設定に素早く切り替えることができる機能である（図2.64）。

　この画面では［ブラウザー プロファイル］には、「デスクトップ」（デフォルト）／「Windows Phone」／「エンタープライズ」の3つが登録されている（※エンタープライズモードについては後述）。

　日本ではWindows Phoneは一般的ではないが、素早くスマホ表示に切り替えられる機能だと考えるとよいだろう。では、実際に切り替えてみよう。

　上のように「Windows Phone」に切り替えると、［ユーザーエージェント文字列］がWindows Phoneのものに変わり、［ディスプレイ］が4.5インチの横向きに変わっていることが分かる。ユーザーエージェント文字列で応答を切り替えているページやレスポンシブUIで、ページの表示を切り替えている場合などの表示を確認できる。

　次に「エンタープライズ」に変更してみよう。

　「エンタープライズ」を選択することで、IE11で新しく追加されたエンタープライズモードに切り替えてみることができる。エンタープライズモードは、企業内の標準ブラウザーをIE11に切り替えてもらうため、互換性を維持しつつ、最新機能も使えるように設定された機能だ。

　しかし、実際に古いブラウザー向けに作られたページがIE11でも正常に使えるかどうかはテストが必要になるだろう。そんなときには、いきなりActive Directoryなどで設定変更するのではなく、上記の［ブラウザー プロファイル］を変更して、挙動を試してみるのがよいだろう。

ユーザーエージェント文字列

　［ユーザー エージェント文字列］では、ページを要求するときのユーザーエージェント文字列を指定できる（図2.67）。ユーザーエージェントごとに応答を変更しているページのテストに役に立つ機能である。

　図2.67を見ると分かるように、最初から多くのユーザーエージェント文字列が用意されている。日本では、これらからの選択の他に、いわゆるガラケーでのテストが必要になるケースもあるだろう。その場合は「カスタム」を選択すると、テキストボックスが表示されて、ユーザーエージェント文字列を入力できるようになる（図2.68）。

　この機能より、表示内容が完全に再現されるわけではないが、ユーザーエージェント文字列ごとの応答の違いを、ブラウザーを切り替えることなく確認できる。

ディスプレイ

　［ディスプレイ］では、スマホやタブレットだけでなく、使用しているPCよりも高解像度のディスプレイで表示したときの見え方まで、あらゆるディスプレイでの表示結果をチェックできる（図）2.69。

　例えば、4インチ（800×480）のスマホで、縦と横の表示を試してみた場合、以下のような表示になる。

　このように実機を用意しなくても、取りあえず表示を確認できる。スマホからの要求時にスマホ用のHTMLソースを返している場合は、［ユーザー エージェント文字列］を変更しつつ、解像度を変更して表示を確認するとよいだろう。

位置情報

　［位置情報］では、地図アプリのような位置情報を使用するアプリに対して、緯度・経度を指定して想定通りの位置が表示されるかどうかを確認できる（図2.71）。

　［GPS のシミュレート］を［有効］にすると、［緯度］［経度］が入力できる状態になる。デフォルトでは、シアトルのユニオン湾周辺の位置情報が入力されている。この状態で、Googleマップを表示して、現在地に移動してみると、入力された「緯度」「経度」の位置が表示されることが分かる（図2.72）。

　この機能を使うことで、実際にその場所に移動して表示を確認しなくても、アプリの動作を確認できる。

　［有効 (ただしシグナルなし)］を選択すると、GPS機能は付いているが、位置情報が正しく取得できない場合の動作を確認できる。

　このオプションでは、位置情報が正しく取得できないときに適切な処理がされるかをテストしてみることができる。

まとめ

　いかがだっただろうか。今まであまり気に留めてなかったIE11のF12開発者ツールにも豊富な機能が提供されていることを発見していただけていれば幸いだ。

　本稿では、主要な機能に絞って説明したのだが、これだけのボリュームになってしまった。IE11からは、（IE12のような）メジャー・バージョンアップだけでなく、Windows Updateなどで配布されるアップデートでも機能が随時更新されており、本稿は執筆（2014年9月）時点の最新状態で書いている。今後もアップデートで機能が追加されていく可能性があるため、ぜひウォッチし続けてほしい。