Deep Insider の Tutor コーナー
>>  Deep Insider は本サイトからスピンオフした姉妹サイトです。よろしく! 
Internet ExplorerのF12開発者ツールの使い方

Internet ExplorerのF12開発者ツールの使い方

Web制作で使いこなしたいIE開発者ツールの最新機能

2014年10月14日

強化された新機能を中心に、最新のF12開発者ツールの主要機能を一通り解説。このツールを使いこなすためのポイントを取り上げる。

尾崎 義尚
  • このエントリーをはてなブックマークに追加

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

  • *1 以前のIEでは、IE5/IE6/IE7のようなメジャー・バージョンアップのタイミングで新機能が搭載されていたが、現在のIEでは他のマイクロソフト製品と同じく、1年の間に何度もアップデートが行われるようになっている。

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

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

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

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

図1.1 F12開発者ツールの起動
  • 1 キーボードのF12キーを押す。
  • 2 メニューバーの[ツール]-[F12 開発者ツール]をクリック(画像左)。
  • 3 ギアアイコン-[F12 開発者ツール]をクリック(画像右)。

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

図1.2 IE10(画像上)とIE11(画像下)のF12開発者ツール

ぱっと見で、見た目が大きく変わっていることが分かる。

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

▲ツールの一覧に戻る

ウィンドウ全体

図1.3 F12開発者ツールのウィンドウ
  • 1 [ドキュメント モード]ボタン: クリックすると、バージョンが表示されるので、ここでドキュメントモードを切り替える。
  • 2 [コンソールの表示]ボタン: F12開発者ツールのウィンドウ下部にコンソールを表示する。
  • 3 ツールの切り替えボタン(以下を参照)

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

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

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

図1.4 ウィンドウ右上の[コンソールの表示]ボタンを押すことで、どこからでもコンソールウィンドウを表示できる

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

各ツールの機能

▲ツールの一覧に戻る

[DOM Explorer]ツール

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

図2.1 [DOM Explorer]ツール
図2.1 [DOM Explorer]ツール
  • A [要素の選択]ボタン。
  • B [DOM 要素の強調表示のオン/オフ]ボタン。このボタンはトグルでオン/オフが切り替わる。
  • C [カラー ピッカーの表示/非表示]ボタン。
  • D 階層リンク(いわゆる「パンくず」)。
  • E 要素ウィンドウ。
  • F スタイルウィンドウ。
A要素の選択

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

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

[要素の選択]ボタンを押す

[要素の選択]ボタンを押す

ブラウザー上でカーソル移動し、ハイライトされた状態の要素をクリック

ブラウザー上でカーソル移動し、ハイライトされた状態の要素をクリック

図2.2 要素の選択

要素に対応するHTMLソースが選択される

図2.2 要素の選択

[要素の選択]ボタンを押すと、ブラウザー上でカーソルを移動したときに、そのカーソル位置の要素がブラウザー上でハイライトされるようになる。確認したい要素がハイライトされた状態でそれをクリックすると、DOM Explorer上のHTMLソースで対象の要素の部分が選択された状態になる。

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

[要素の検査]をクリック

[要素の検査]をクリック

図2.2 要素の選択

要素に対応するHTMLソースが選択される

図2.3 要素の選択

確認したい箇所を右クリックしてコンテキストメニューから[要素の検査]をクリックすると、要素が選択された状態でDOM Explorerが表示される。

BDOM要素の強調表示

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

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

図2.4 DOM要素の強調表示

DOM Explorerで選択されている要素がブラウザー上でハイライト表示される。

Cカラーピッカー

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

図2.5 カラーピッカーの表示

カラーピッカーは、さまざまな方法で色を選択できる。

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

Dパンくず(階層リンク)

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

図2.6 階層リンク(パンくず)

階層リンクには、タグが階層で表示されていて、選択されている要素の階層を確認できる。

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

E要素ウィンドウ

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

図2.7 要素ウィンドウでテキストや属性を変更できる
図2.7 要素ウィンドウでテキストや属性を変更できる
図2.7 要素ウィンドウでテキストや属性を変更できる

ここで変更した内容は即座にブラウザーで確認できる。
上の画像ではお勧め記事のタイトル部分(=HTMLのタグの外にあるテキスト部分)を直接「尾崎参上!」に変更し、下の画像ではそのclass属性(=HTMLのタグの中身)を変更しようとしている。

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

Fスタイルウィンドウ

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

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

[スタイル]タブ
図2.8 選択されている要素のスタイルを確認

要素ウィンドウで選択されている要素に適用されているCSSスタイルを確認できる。

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

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

[a:]をクリック

[a:]をクリック

通常時のスタイル定義。ここで[ホバー]チェックボックスをチェックすると、マウスカーソルがホバーしている状態のスタイルが表示される

通常時のスタイル定義。
ここで[ホバー]チェックボックスをチェックすると、
マウスカーソルがホバーしている状態のスタイルが表示される

図2.9 [a:]ボタンをクリックすると「疑似状態パネル」が表示される

図2.9 [a:]ボタンをクリックすると「疑似状態パネル」が表示される

[ホバー]などの疑似状態をチェックすることで、状態によって変化したスタイルを確認できる。

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

[属性]タブ

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

人型のアイコンがオンの状態では、ユーザー定義のスタイルのみが表示される。人型のアイコンをオフにすると全てのスタイルが表示される

人型のアイコンがオンの状態では、
ユーザー定義のスタイルのみが表示される。
人型のアイコンをオフにすると全てのスタイルが表示される

図2.10 [属性]タブには要素に適用されているスタイルのみが表示される
図2.10 [属性]タブには要素に適用されているスタイルのみが表示される

デフォルトでは明示的に指定された「ユーザースタイル」のみが表示されており、人型のアイコンをオフにすることで全てのスタイルを確認できる。

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

[レイアウト]タブ

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

図2.11 [レイアウト]タブでは要素の幅/高さ/余白を確認できる

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

[イベント]タブ

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

図2.12 要素のイベントに関連付けられている処理を確認できる
図2.12 要素のイベントに関連付けられている処理を確認できる

イベントに関連付けられている関数と、ファイル名、行番号が表示されている。

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

[変更]タブ

 [変更]タブでは、[スタイル]タブで変更した内容を確認できる(図2.13)。

図2.13 [変更]タブ
図2.13 [変更]タブ

[スタイル]タブで変更した内容が緑、変更前が赤で表示されている。

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

図2.14 [スタイル]タブで変更内容を確認できる

スタイルを変更した箇所の左端のバーに色分けして表示される。

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

▲ツールの一覧に戻る

[コンソール]ツール

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

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

図2.15 [コンソール]ツール
  • A F12開発者ツールの左端にある[コンソール]アイコンにはエラー数が表示される。
  • B 表示するメッセージのレベルを「エラー」「警告」「情報」の中から絞り込める。
  • C ページ遷移してもメッセージを残すかどうかを指定できる。
  • D 表示されているログをクリアする。
  • E ログのターゲットフレームを絞り込む。例えばFacebookの[いいね]ボタンは、<iframe>タグ(=インラインフレーム。以下、IFrame)で実装されているので、ドロップダウンで絞り込み対象になる。

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

図2.16 「ナビゲーション時のクリアを無効」にした状態

ページをリフレッシュすると、ログに境界線が表示され、リフレッシュ前のログが残った状態で新しいログが表示される。

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

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

図2.17 [コンソール]でログを確認する

左の[コンソール]アイコンにエラー数が表示される。ここで、[コンソール]をアクティブにするとエラー内容を確認できる。

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

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

図2.18 コンソールに情報、警告、エラーを表示してみる

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

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

図2.19 入力ウィンドウは、境界をマウスでドラッグすることで、幅を広げることができる

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

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

図2.20  [コンソール]でJavaScriptコードの挙動を確認しているところ

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

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

図2.21 [コンソール]上で、オブジェクトの編集と表示が可能

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

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

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

図2.22 console.time/console.timeEndメソッドの呼び出しで処理時間が表示される

また、タイマーに名前を付けて処理ごとの時間やネスト構造のタイマー計測も可能だ。

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

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

▲ツールの一覧に戻る

[デバッガー]ツール

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

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

図2.23 [デバッガー]ツール
  • 1 ユーザーコードのみをデバッグするか、全てのコードをデバッグするか。
  • 2 JavaScriptファイルの一覧。
  • 3 コード表示。
  • 4 ウォッチの一覧。
  • 5 呼び出し履歴、ブレークポイント。

 まず12について説明する。

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

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

図2.24 自動判別されなかった共通ライブラリをライブラリコードとして指定できる
図2.24 自動判別されなかった共通ライブラリをライブラリコードとして指定できる

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

デバッグ

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

図2.25 デバッグ時のイメージ
  • 1 スクリプトウィンドウにはデバッグ中のコードや選択されたスクリプトファイルが表示される。
  • 2 [ウォッチ]ウィンドウには現在実行されているコードで使用されている変数と、開発者が追加したウォッチ式が表示される。
  • 3 [呼び出し履歴]ウィンドウには、スクリプトが停止しているときに、停止箇所の呼び出し履歴(=スタック)が表示される。[ブレークポイント]ウィンドウには、登録されているブレークポイントの一覧が表示される。

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

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

[ブレークポイント]ウィンドウ

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

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

図2.26 [ブレークポイント]ウィンドウ
図2.26 [ブレークポイント]ウィンドウ
  • 1 ブレークポイントの一覧。
  • 2 [イベント トレースポイントの追加]ボタン。
  • 3 [イベント ブレークポイントの追加]ボタン。
  • 4 [すべてのブレークポイントの有効化]ボタン/[すべてのブレークポイントの無効化]ボタン。
  • 5 [すべて削除]ボタン。

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

  • : ブレークポイント
  • : 無効化されているブレークポイント
  • (+): 条件付きのブレークポイント
  • : トレースポイント

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

[イベント]ドロップダウンを開く

[イベント]ドロップダウンを開く

図2.27 イベントに対するブレークポイント/トレースポイントの追加ウィンドウ

マウス、キーボード、ウィンドウなどのイベント発生時に実行されるコードにブレークポイントやトレースポイントを設定できる。
上の左は3の[イベント ブレークポイントの追加]ボタンをクリックすると表示されるダイアログ。
上の右は2の[イベント トレースポイントの追加]ボタンをクリックすると表示されるダイアログ。
これらのダイアログの[イベント]ドロップダウンを開くと、下のようなイベント一覧が表示される。

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

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

図2.28 ブレークポイントの一覧表示

ブレークポイントの一覧表示(A)、個別無効化(B)、一括無効化(C)、一括削除(D)ができる。

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

ブレークポイント

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

ブレークポイントを設定したい行を右クリックしてコンテキストメニューから[ブレークポイントの挿入]を選択。ブレークポイントが設定されると、左端のグレーのエリアに赤丸が表示される。

ブレークポイントを設定したい行を右クリックして
コンテキストメニューから[ブレークポイントの挿入]を選択。
ブレークポイントが設定されると、左端のグレーのエリアに赤丸が表示される。

図2.29 ブレークポイントの設定方法
図2.29 ブレークポイントの設定方法

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

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

図2.30 ブレークポイント選択時に表示されるアイコン
図2.30 ブレークポイント選択時に表示されるアイコン

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

図2.31 [条件付きブレークポイント]の設定
図2.31 [条件付きブレークポイント]の設定

ここでは、変数iの値が「2」のときのみブレークするように設定している。JavaScript構文なのでイコールが2つの==であることに注意してほしい。

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

図2.32 条件付きブレークポイントで実行が中断した状態

条件付きブレークポイントは、赤丸の中に「+」が表示されるため、アイコンで区別できる。

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

トレースポイント

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

トレースポイントを設定したい箇所を右クリックしてコンテキストメニューから[トレースポイントの挿入]を選択

トレースポイントを設定したい箇所を右クリックして
コンテキストメニューから[トレースポイントの挿入]を選択

トレースポイントが実行されるたびに出力するメッセージを指定する

トレースポイントが実行されるたびに出力するメッセージを指定する

図2.33 トレースポイントの設定

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

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

altJSのデバッグ

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

図2.34 ページ内で読み込んでいるファイルは「app.js」だが、ファイルの一覧には元ソースである「app.ts」が表示されている

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

図2.35 ページ内で読み込まれているJavaScriptファイルの元ソースであるTypeScriptコードを使ってデバッグできる

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

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

図2.36 jsファイルの最後の行に「//# sourceMappingURL=app.js.map」としてマッピングファイル名が記述されている

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

JSON
{"version":3,"file":"app.js","sourceRoot":"","sources":["app.ts"],"names":["Greeter","Greeter.constructor","Greeter.start","Greeter.stop"],"mappings":"AAAA;IAKIA,iBAAYA,OAAoBA;QAC5BC,IAAIA,CAACA,OAAOA,GAAGA,OAAOA;QACtBA,IAAIA,CAACA,OAAOA,CAACA,SAASA,IAAIA,eAAeA;QACzCA,IAAIA,CAACA,IAAIA,GAAGA,QAAQA,CAACA,aAAaA,CAACA,MAAMA,CAACA;QAC1CA,IAAIA,CAACA,OAAOA,CAACA,WAAWA,CAACA,IAAIA,CAACA,IAAIA,CAACA;QACnCA,IAAIA,CAACA,IAAIA,CAACA,SAASA,GAAGA,IAAIA,IAAIA,CAACA,CAACA,CAACA,WAAWA,CAACA,CAACA;IAClDA,CAACA;IAEDD,0BAAAA;QAAAE,iBAECA;QADGA,IAAIA,CAACA,UAAUA,GAAGA,WAAWA,CAACA;mBAAMA,KAAIA,CAACA,IAAIA,CAACA,SAASA,GAAGA,IAAIA,IAAIA,CAACA,CAACA,CAACA,WAAWA,CAACA,CAACA;QAA9CA,CAA8CA,EAAEA,GAAGA,CAACA;IAC5FA,CAACA;;IAEDF,yBAAAA;QACIG,YAAYA,CAACA,IAAIA,CAACA,UAAUA,CAACA;IACjCA,CAACA;IAELH,eAACA;AAADA,CAACA,IAAA;;AAED,MAAM,CAAC,MAAM,GAAG;IACZ,IAAI,EAAE,GAAG,QAAQ,CAAC,cAAc,CAAC,SAAS,CAAC;IAC3C,IAAI,OAAO,GAAG,IAAI,OAAO,CAAC,EAAE,CAAC;IAC7B,OAAO,CAAC,KAAK,CAAC,CAAC;AACnB,CAAC"}
app.js.mapファイルの内容

先頭にファイル名やクラス名の記述があり、mappingsにコードのマッピングが書かれている。

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

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

図2.37 コンパイルされたJavaScriptファイルから、ソースマップを選択して、元ソースをデバッグできる
図2.37 コンパイルされたJavaScriptファイルから、ソースマップを選択して、元ソースをデバッグできる

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

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

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

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

ツールバーにある[整形出力を有効化]ボタンをクリックする

ツールバーにある[整形出力を有効化]ボタンをクリックする

図2.38 ツールバーにある[整形出力の有効化]ボタンをクリックして、整形出力を有効化するとコードを整形して表示できる

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

▲ツールの一覧に戻る

[ネットワーク]ツール

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

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

図2.39 [ネットワーク]ツール
  • 1 ネットワークの記録を開始/停止する。
  • 2 キャプチャしたトラフィックをエクスポート。
  • 3 常にサーバーから更新する。
  • 4 ナビゲーション時にエントリをクリアする。
  • 5 [要約]ビューを開く。
  • 6 [詳細]ビューを開く。

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

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

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

図2.40 [要約]ビュー

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

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

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

[詳細]ビュー

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

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

図2.41 [詳細]ビューの[要求ヘッダー]タブでは、ファイルをダウンロードするためのHTTPリクエストヘッダーを確認できる

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

図2.42 [要求本文]タブでは、ここには表示されていないが、HTTP POSTなどでPOSTされたフォームの内容を確認できる

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

図2.43 [応答ヘッダー]タブでは、サーバーから返ってきたHTTPレスポンスのヘッダーを確認できる

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

図2.44 [応答本文]タブでは、HTTPレスポンスで返ってきた本文を確認できる

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

図2.45 [Cookie]タブでは、通信の中で送受信したCookieのキーと値を確認できる

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

図2.46 [イニシエーター]では、このファイルをダウンロードするきっかけを確認できる。例えば、<img>タグに記述されていた、JavaScriptコードで指定された、などをここで確認できる

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

図2.47 [タイミング]では、ファイルのダウンロードにかかった時間の詳細を確認できる

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

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

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

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

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

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

▲ツールの一覧に戻る

[UI の応答]ツール

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

図2.48 [UI の応答]ツール
  • 1 プロファイリングを開始/停止する。
  • 2 プロファイリングセッションをインポートする。
  • 3 プロファイリングセッションをエクスポートする。
  • 4 ルーラー。ルーラーには診断セッション中に発生した各種のイベントなどが表示される。
  • 5 [CPU使用率]。
  • 6 [視覚スループット]。
  • 7 [タイムラインの詳細]。

 17について、簡単に説明をしておこう。

  • 1 プロファイリングの開始/停止: プロファイルは、手動で開始・停止する。そのため、ページの読み込み時だけでなく、ページが読み込まれた後のイベントだけの採取もできるようになっている。例えば、ゲームなど動的に描画する時のパフォーマンスを採取することもできる
  • 2 プロファイリングセッションのインポート
  • 3 プロファイリングセッションのエクスポート: プロファイルの結果をファイルに保存したり、ファイルから読み込んだりできる。これにより、「パフォーマンスが出ない」と言っているユーザーにファイルをエクスポートして送付してもらって、そのファイルをインポートして分析するといったことができる。ファイルは、「.diagsession」という拡張子のバイナリファイルである
  • 4 ルーラーと診断セッションのイベント: 診断セッション中に発生したアプリライフサイクルイベント(=ページ遷移やDOM読み込みなど)とユーザーマーク*2が表示される
  • *2 ロジック中にperformance.mark(markName);を記述するとマークされる。
  • 5 [CPU使用率]: ページの描画中に使用されたCPUの使用率とその詳細が表示される(図2.49)。ここで負荷の高い処理を絞り込んで、[タイムラインの詳細]で特定していくとよい。マウスカーソルで範囲を選択して、選択範囲のみの詳細を調べることもできる
図2.49 負荷の高い箇所や気になる範囲を選択して、表示を絞り込める
  • 6 [視覚スループット]: 1秒あたりのフレーム数が表示されている。例えば、アニメーション処理中にフレームレートが落ちている場合は、処理をチューニングしてパフォーマンスを改善する必要がある
  • 7 [タイムラインの詳細]: ここには詳細なイベントが表示されているため、負荷の高い処理の詳細を調べられる
[タイムラインの詳細]

 [タイムラインの詳細]では、ページの描画の処理がかなり詳細に表示される(図2.50)。

図2.50 処理内容とその時間の詳細が表示される

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

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

図2.51 HTTP要求の詳細を選択すると、ダウンロードにかかった時間と、画像の場合はそのプレビューが表示される

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

図2.52 並べ替えで「継続時間 (包括)」を選択すると、処理時間の長い順に表示される

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

図2.53 [最上位のイベントをフレームごとにグループ化]をオンにすると、描画イベントをフレームごとにまとめられる

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

図2.54 [イベントのフィルター処理]でイベントの種別ごとにフィルターできる

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

▲ツールの一覧に戻る

[プロファイラー]ツール

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

[機能]ビュー

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

図2.55 [プロファイラー]ツールの[機能]ビュー

プロファイリング中に呼び出された処理と回数、時間が表示されている。

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

[呼び出しツリー]ビュー

 だが、個人的には、[呼び出しツリー]ビュー(図2.56)の方が役に立つと考えている。

図2.56 [呼び出しツリー]ビュー

JavaScriptの関数が階層で表示されている。

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

▲ツールの一覧に戻る

[メモリ]ツール

 [メモリ]ツールは名前の通り、メモリの使用量を調査できるツールだ(図2.57)。

図2.57 [メモリ]ツール
  • 1 プロファイリングセッションの開始。
  • 2 プロファイリングセッションの終了。
  • 3 プロファイリングセッションのインポート。
  • 4 プロファイリングセッションのエクスポート。
  • 5 ヒープスナップショットの作成。
  • 6 メモリ合計。

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

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

図2.58 ヒープスナップショットの作成でメモリの状況を記録できる
図2.58 ヒープスナップショットの作成でメモリの状況を記録できる
  • 1 ページ内のメモリ使用量。
  • 2 ページ内で保持しているオブジェクト数。
  • 3 メモリ使用量と前回のスナップショットからの増量が表示される。
  • 4 オブジェクト数と前回のスナップショットからの増減数が表示される。

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

[種類]ビュー
図2.59 [種類]ビュー

「スナップショット #2」のオブジェクト数表示のリンクをクリックすると、1つ前のスナップショットとの差分が表示される。

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

[ルート]ビュー

 [ルート]ビューでは、オブジェクトがルートオブジェクトごとにグループ化されて表示される(図2.60)。

図2.60 [ルート]ビュー

オブジェクトがグループ化されて表示される。

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

[ドミネーター]ビュー

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

図2.61 [ドミネーター]ビュー

オブジェクトごとの詳細な情報が表示される。

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

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

▲ツールの一覧に戻る

[エミュレーション]ツール

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

図2.62 [エミュレーション]ツール
  • 1 ページをリフレッシュした後でもエミュレーションの設定を維持するかどうかと、エミュレーション設定のクリアボタン。
  • 2 [モード]セクションでは、他のブラウザーに偽装できる。
  • 3 [ディスプレイ]セクションでは、スマートフォンやタブレットなどの向きや解像度をシミュレーションして表示できる。
  • 4 [位置情報]セクションでは、緯度・経度を偽装して、位置情報を利用するアプリのデバッグに使える。

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

ドキュメントモード

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

図2.63 [ドキュメント モード]の切り替え

現在のドキュメントモードが選択されている理由が下に表示されており、ドロップダウンでドキュメントモードを切り替えられるようになっている。

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

ブラウザープロファイル

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

図2.64 [ブラウザー プロファイル]の切り替え
図2.64 [ブラウザー プロファイル]の切り替え

あらかじめ登録されている設定に切り替えて表示を確認できる。

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

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

図2.65 プロファイルを「Windows Phone」に切り替えたところ

図2.62と見比べると、[ユーザーエージェント文字列]やディスプレイの設定が変更されていることが分かる。

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

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

図2.66 プロファイルを「エンタープライズ」に切り替えたところ

[ドキュメント モード]が変更されて表示されていることが分かる。

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

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

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

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

図2.67 ドロップダウンからユーザーエージェント文字列を選択できる

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

図2.68 「カスタム」を選択すると、ユーザーエージェント文字列を入力して指定できる
図2.68 「カスタム」を選択すると、ユーザーエージェント文字列を入力して指定できる

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

ディスプレイ

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

図2.69 [ディスプレイ]の[向き]と[解像度]を指定して表示を確認できる

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

図2.70 「4インチ(800x480ドット)」のスマホで、「縦」(上)と「横」(下)の表示を試してみた結果

解像度から外れた部分が白く表示される。

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

位置情報

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

図2.71 [位置情報]のシミュレーション
図2.71 [位置情報]のシミュレーション

[有効]を選択すると、位置情報として[緯度][経度]に入力された位置情報が送信される。

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

図2.72 Googleマップで現在地を表示したところ

「緯度」「経度」で入力された位置が表示される。

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

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

図2.73 [GPS のシミュレート]で[有効 (ただしシグナルなし)]を選択
図2.73 [GPS のシミュレート]で[有効 (ただしシグナルなし)]を選択

GPS機能は付いているが、位置情報が取得できない状態をテストできる。

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

まとめ

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

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

サイトからのお知らせ

Twitterでつぶやこう!