モダンブラウザーの中でGoogle Chromeは最後発ながら、その機能の潤沢さ、便利さ、高速さからシェアを大きく伸ばしている。そして、今やほとんどのブラウザーではWindowsの場合［F12］キーを押すことで（Macの場合は［Command］＋［Option］＋［I］キーで）手軽に各ブラウザー搭載のデベロッパー・ツールを利用できるが、特にChromeのデベロッパー・ツールは、非常に機能が豊富なため利用している人も非常に多い。

　本稿では筆者がよく使う機能や、使うと便利な機能を中心に、Chromeのデベロッパー・ツールについて紹介していく。

機能ふかん

　残念ながら、Chromeのデベロッパー・ツールは日本語化されていないため、メニューやメッセージが全て英語になってしまうが、それを踏まえてもあまりある豊富な機能が提供されている。まずはウィンドウ全体の構成から見ていこう。

　Chromeでどこかのページを表示した状態で［F12］キー（Windowsの場合。Macの場合は［Command］＋［Option］＋［I］キー）を押すと、デベロッパー・ツールが表示される（次の画面を参照）。

　上部に表示されているタブメニュー（1）が「パネル」と呼ばれるものだ。本稿では、このパネルを順に説明していく。2は、ウィンドウをChromeと統合するかどうかを切り替えるものである。3はConsoleウィンドウを表示するものだが、詳細は［Console］パネルで説明する。

　具体的には、以下のパネルを説明する（リンクをクリックすると該当箇所にジャンプできる）。最後の［Overrides］設定はパネルではないが、便利な機能なので紹介したい。

• ［Elements］パネル
• ［Resources］パネル
• ［Network］パネル
• ［Sources］パネル
• ［Timeline］パネル
• ［Profiles］パネル
• ［Audits］パネル
• ［Console］パネル
• ［Overrides］設定

　それでは、［Elements］パネルから説明していこう。

▲パネルの一覧に戻る

［Elements］パネル

　Elementsパネルは、タグの要素とスタイルを検証するための機能であり、Web開発者が最も多く使う機能である。まずはパネル内の機能から解説していこう。

　DOMエレメント・ツリー（1）は、ブラウザー部分で表示中のWebページのHTML要素をツリービュー形式で表示したものである。ここで選択された要素のCSSスタイルなどの情報がサイドバー（2）に表示される。また、現在表示している要素の階層はパンくずリスト（4）に表示される。

　ページ要素が多い場合、検証したい要素を探すために、ツリーを展開していって探すのは非常に面倒だが、虫眼鏡アイコン（3）をクリックすると、普段見ているWebページ上で検証したい要素をクリックして選択できる検証モードに切り替わる。次の画面は、実際に検証モードに切り替えて、Googleのタイトル画像をクリックして選択したところだ。

マウスによる各種操作

　そのほか、マウスを使って以下の画面のような操作も可能である。

要素の属性／スタイルの確認

　前述したとおり、マウスカーソルで要素を選択すると、選択された要素がアクティブになって、要素に設定されている属性やスタイルを確認できる。ここでは実際に、選択中の要素のスタイルを確認してみよう。次の画面は、サイドバー内のグループを分かりやすく表示したものだ（これまでの画面例では、サイドバー上部のタブとして表示されていたものと同じ）。

　これらのグループと目的は下記の表のとおり。

　ここでは、よく使うStylesグループと便利なDOM BreakpointsグループとEvent Listenersグループを説明しよう。

Stylesグループ

　Stylesグループでは、要素に適用されているスタイルの確認と編集が可能だ。Stylesグループのタブを開くと、以下の画面のように、要素に適用されているCSSスタイル（Style）がファイル別、HTML要素／CSSクラス別に表示される。

DOM Breakpointsグループ

　DOM Breakpointsグループは、その名のとおり、DOM（Document Object Model）のイベントに対するブレイクポイントである。Webアプリケーションでは、JavaScriptなどを使って動的に要素が変化するページが、「ほとんど」と言ってもよいほど多い。それに伴い、「これらの要素が変更されるタイミングでスクリプトをデバッグしたい」というケースも増えている。DOM BreakpointはDOM要素（＝DOMエレメント）にブレイクポイントを張れる機能である。

　次の画面は、<input>要素にブレイクポイントを張ろうとしているところだ。

Event Listenersグループ

　Event Listenersグループは、要素に関連付けられたイベントハンドラーを確認できる（次の画面）。

　このようにElementsパネルでは、HTMLコードとCSSコードを確認したり、編集して想定したデザインになるように編集したりできる。また、HTML要素のデバッグをすることもできる。

▲パネルの一覧に戻る

［Resources］パネル

　Resourcesパネルでは、ページを構成しているファイルやデータを確認できる。次の画面は、画像リソースを表示しているところ。

　Resourcesパネルのツリーに表示されている項目は以下のとおり。

　このようにページ内で使用されているファイルを一覧で確認したり、データを確認したりできる。そして、Cookie以外は値の編集も可能だ（次の画面）。

▲パネルの一覧に戻る

［Network］パネル

　Networkパネルは、Web開発をしていく中で最も使用するタブの1つである。ページのリクエストをしてからの通信内容を一覧で表示できるため、ページ表示が遅くなっている原因を特定するのに非常に有益だ（次の画面）。

　タイムラインの各項目上にマウスカーソルを当てるとさらに詳細な時間が表示される（次の画面）。

各通信項目の詳細表示

　一番左の［Name］列のファイル名をクリックすると、さらに詳細を確認できる。基本的に、下記の5つのタブが表示されるが、通信項目の種類によっては一部のタブは表示されない。

• Headersタブ
• Previewタブ
• Responseタブ
• Cookiesタブ
• Timingタブ

Headersタブ

　Headersタブでは、HTTPリクエストとレスポンスのヘッダーを確認できる（次の画面）。

Previewタブ

　Previewタブはテキストデータならレスポンスのテキスト、画像ファイルなら画像の情報が表示される（次の画面）。

Response／Cookies／Timingタブ

　Responseタブはレスポンス本文、Cookiesタブはリクエスト・レスポンスで使用されたクッキーを確認できる。そして、Timingタブがファイルの取得にかかった時間の詳細だ（次の画面）。

　特定のファイルのダウンロードが遅い場合、この情報を見て対応を検討できる。例えば［DNS Lookup］に時間がかかっている場合、DNSプリフェッチを検討できる。［Sending］や［Receiving］に時間がかかっている場合は、サーバーの物理配置の変更、CDNの検討、GZip圧縮の検討などが考えられる。［Waiting］に時間がかかっている場合は、Webサーバー側の処理をチューニングすることを検討する必要がある。

　このようにNetworkパネルを使用することで、ページが表示されるまでの時間を詳細に調査して、対応を検討できる。

▲パネルの一覧に戻る

［Sources］パネル

　Sourcesパネルは、CSSやJavaScriptのコードをデバッグできる機能である（次の画面はJavaScriptソースファイルが開かれている例）。Visual StudioやEclipseのようなIDEと同様にデバッグに必要な機能が備わっている。

　このパネルで便利な機能はコードの整形である。

コードの整形

　最近のJavaScriptライブラリは通信速度を高速化するため、コードのインデントや改行を削ったミニファイされたコードが返されることが多い。このようなコードは、プログラムとしては正しく動作するものの、人間がデバッグのために読もうとしてもなかなか読みづらいコードになっている。デベロッパー・ツールには、このような「コードを読みやすく整形してくれるボタン」が準備されている。以下の画面は実際にこのコード整形ボタンの実行前と実行後を比べたものだ。

デバッガー機能

　Chromeのデバッガーが他のブラウザーと比較して優れている点は、デバッグ機能が充実していることである。サイドバーを見ると（次の画面）、その充実ぶりが分かる。

　サイドバー上のグループの役割は次のとおりだ。

　サイドバーのメニューを見ただけでも豊富なデバッグ機能が提供されていることがご理解いただけたと思う。次にこれらを使ってデバッグに便利な機能をいくつか紹介していく。

Call Stackをさかのぼって、実行済みの呼び出し元をデバッグする機能

　まずはデバッグでブレイク（＝停止）したときにスタックを逆回転できる機能だ。具体的には、停止したときにCall Stackグループには関数の呼び出し履歴が表示されているので、停止している関数よりも前の処理を右クリックして、表示されるコンテキストメニューから［Restart frame］をクリックする（次の画面を参照）。この手順により、呼び出し元にさかのぼってデバッグできる。この機能はデバッグ機能の中でも非常に高度で有益な機能だ。

高度な条件付きブレイクポイント

　次に、ブレイクポイントについてはあえて説明は不要だと思うので、さらに高度な条件付きブレイクポイントの指定の仕方について、以下のスクリーンキャプチャ画像で説明しよう。

LiveEdit機能によるCSS／JavaScriptコードの直接編集

　またデベロッパー・ツールは「LiveEdit」と呼ばれる、CSSやJavaScriptのコードを直接編集できる機能が提供されている。この機能も、以下のスクリーンキャプチャ画像で説明しよう。なお、この機能は、ミニファイされたコードを整形していると使用できないので、注意してほしい。

▲パネルの一覧に戻る

［Timeline］パネル

　Timelineパネルは、UI（ユーザーインターフェイス）のパフォーマンスを計測して、チューニングするポイントを探し出すための機能である（次の画面）。このパネルは、初期状態では何も表示されず、［Record］（記録）ボタンを押してから、［Stop］（停止）するまでの情報が記録される。

Timelineパネルのモード

　また、Timelineパネルには、いくつかのモードが提供されている。それぞれのモードは、次の画面のように左上から選択できる。

　それでは、それぞれのモードを見ていこう。

Eventsモード

　まずはEventsモードの詳細を確認していく。次の画面に示すように、レコードされるイベントの種類は大きく4種類に色分けされている。

　このように表示されたタイムラインをフィルターなどで絞り込んでみて、時間がかかっている処理を見付け出してパフォーマンス・チューニングをしていくのだ。

Framesモード

　次は描画パフォーマンスを調べるFramesモードだ（次の画面）。

　この例では、一定の頻度で描画に負荷をかけている処理があることが分かる。その処理を特定してチューニングしていけば、Webページの体感速度を上げることができる。上の画面の例では、画面上部のサマリー領域を見ると、その一番右端に、上から［30 fps］［60 fps］と表示されている。要するに、横に引かれている上の線が30fpsで、中央の線が60fpsを意味するということが分かる。つまり、この画面のページでいえば、60fps以上であればスムーズに描画されるということになる。ほとんどのディスプレイは60Hzなので、ほとんどのケースで問題のない描画が行えると言えるだろう。

Memoryモード

　続いてMemoryモードを見ていこう（次の画面）。

　アプリを長時間稼働させる可能性がある場合は、このグラフを見て、メモリの使用量が増加し続けていないかを確認するとよいだろう。ただし、ここで確認できるのは増加しているかどうかだけなので、「何が増加している原因なのか」の詳細を確認するには、次に説明するProfilesパネルで確認する必要がある。

▲パネルの一覧に戻る

［Profiles］パネル

　Profilesパネルでは、CPUやメモリの情報を収集して詳細を確認できる。次の3つの情報を収集できる。

　　（1）Collect JavaScript CPU Profile： JavaScriptコードの関数が使用しているCPU利用率を収集する
　　（2）Take Heap Snapshot： JavaScriptコードとDOMノードが使用しているヒープメモリのスナップショットを採取する
　　（3）Record Heap Allocations： 確保したヒープを時間軸で記録する

　次の画面は、Profilesパネルを開いたところ。ここで、上記の3つのプロファイリングタイプの中から1つを選択できる。

（1）Collect JavaScript CPU Profile

　まずは、CPU Profileから見ていこう。

　［Collect JavaScript CPU Profile］ラジオボタンを選択した状態で［Start］ボタンを押すと収集が始まり、［Stop］ボタン（もしくは下部のステータスバーにある［●］ボタン）を押すまで収集される。

　収集が終わると、結果が一覧で表示される（次の画面を参照）。デフォルトでは関数の時間割合が多い順に表示される。

　また、次の画面のように、ビュー切り替えで［Flame Chart］に切り替えることでCPU利用率を視覚的に確認できる。

（2）Take Heap Snapshot

　次にTake Heap Snapshotを見てみよう。

　これはその名のとおり、その採取時点のメモリ状況を取得するものだ。実行するには、［Take Heap Snapshot］ラジオボタンを選択した状態で［Take Snapshot］ボタンを押せばよい。

　Snapshotなので停止ボタンを押すことなく、その時点のメモリ状況が一覧で表示される（次の画面）。

　次の画面に示すように、オブジェクトを展開して、その中の項目を選択すると、さらに詳細を確認できる。

　また、スナップショットを複数採取すると、スナップショット間の増分を比較できる。次の画面は2つのスナップショットを取った場合の例で、下部のステータスバーで［Objects Allocated between Snapshots 1 and 2］（＝スナップショット1と2の間の増分を比較）を選択しようとしているところ。

　このように複数のスナップショットを比較することで、任意のタイミングのメモリ使用状況を比較して、「何が増えているのか」を特定できるようになる。

（3）Record Heap Allocations

　Record Heap Allocationsは、時間の流れとともに確保されたオブジェクトとその保持状況を確認できる。次の画面は、［Record Heap Allocations］ラジオボタンを選択した状態で［Start］ボタンを押して、しばらくして［Stop］ボタン（もしくは下部のステータスバーにある［●］ボタン）を押した場合の表示例である。

　また、上部のタイムラインを選択することで、その時間に作られたオブジェクトの詳細を確認できる（次の画面）。

　このようにProfilesパネルでは、CPUやメモリの詳細を確認でき、パフォーマンスやメモリリークの原因を特定できる。

▲パネルの一覧に戻る

［Audits］パネル

　Audits（＝監査）パネルは、Webページを最適化するための推奨事項を提示してくれるユニークな機能である。

　オプションを選択して［Run］ボタンを押すと、次の画面のように検証結果が表示される。

　1つずつの詳細を解説することは避けるが、表示しているページでGZip圧縮を有効にすることを提案したり、未使用のCSS要素の削除を提案したりとページのパフォーマンスを改善するための提案をしてくれる。全てをうのみにして実施すればよいというものではないが、一般的にWebのパフォーマンスを劣化させる原因になるものを提示してくれるので参考にして損はないだろう。

▲パネルの一覧に戻る

［Console］パネル

　Consoleパネルは、非常に強力な機能であり、コマンドライン入力により、さまざまな操作ができるようになっている（次の画面を参照）。大きく分けると2つの役割を持っており、1つが「ログの閲覧」で、もう1つが「インタラクティブな操作」である。そして実は、Consoleパネルは全てのパネルからアクセスできるようになっている。そのため、Elementsパネルで要素を操作したり、SourcesパネルでJavaScriptのオブジェクトを操作したりと、デバッグに非常に便利な機能である。

　Consoleパネルでできることは非常に多い。表示しているページの状態確認やデバッグ、DOMを操作してページ内のエレメントを変更など、さまざまなことがコマンドからできるようになっている。そして、オートコンプリートが使えるため入力も楽にできるようになっている（次の画面は、JavaScriptのdocumentオブジェクトの次の入力項目がオートコンプリートにより表示されている状態だ。このように「>」の部分にコマンドを入力できる）。

　また複数行の入力もできるため、JavaScriptで関数（＝function）を書いてテストをしてみるという使い方もできる。次の画面はその例。

ログ表示

　ログメッセージを表示するメソッドはレベル別にいくつか用意されている（次の表を参照）。普段、アプリケーションを開発している方にはおなじみのレベル分けだろう。

　これらをJavaScriptコードの中に記述することで、次の画面例のように、Consoleパネルにログを出力できる。

DOMの操作

　ConsoleパネルからはDOM操作でページを直接編集できる。documentオブジェクトなどの基本的なJavaScript機能を操作できるだけでなく、jQuery構文も利用できるようになっている。次の画面は実際にjQueryを使って「masterNavigation」というHTML要素のテキストを更新している例だ。

　このようにConsoleパネルから直接、DOMを操作できるため、例えばテストなどで、繰り返し同じ操作をする場合などに非常に便利だ。

オブジェクトの内容を確認

　JavaScriptで作成されたオブジェクト（変数）の中身は、直接、変数名を入力することで確認できる。次の画面では「s」という変数を入力してところ。

　このように変数の中身が階層で表示されるので、状態を確認するのに非常に便利だ。もちろん、値の変更も可能なため、デバッグにも役に立つだろう。

時間の計測

　JavaScriptコードの処理に時間がかかっていて、その箇所の詳細を追うためにストップウォッチ（＝実行時間を計測する機能）を使いたいことも多いだろう。もちろん、そのためのメソッドが用意されている。恐らくインタラクティブに入力することは少ないと思うが、次の画面の例では簡易的に入力することにする。

　「console.group()」～「console.groupEnd()」でグループ化して、出力結果をまとめて表示できる。なお、groupメソッドは、タイマー以外の目的でも使用できる。

　「console.time()」～「console.timeEnd()」で、時間を計測できる。このとき、timeメソッドの引数にラベルを指定することで、複数の時間を計測できるようになるため、ネスト構造での計測も可能になっている（この例では「重い処理」と「軽い処理」の2つの時間をネスト構造で計測している）。

　パネルとしてはこれで全てだが、もう1つ便利な機能を紹介しよう。

▲パネルの一覧に戻る

［Overrides］設定

　ブラウザーごとに振る舞いを変えているサイトや、モバイルデバイスでは異なる見た目になるように作っているサイトのテストを、Chromeだけでできるようにする機能がある。具体的には次の画面のように、右下のギアマークの［Settings］アイコンから［Overrides］タブを開く。

　Overrides設定を有効にするには、［Enable］にチェックを付ける必要がある（次の画面）。

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

　では、まずユーザー・エージェント文字列の変更から見ていこう。

　［Overrides］タブ内の［User Agent］をチェックすると、次の画面に示すように、ドロップダウンからユーザー・エージェントを選択できるようになる。

　Internet ExplorerやFirefoxなどのPCブラウザーだけでなく、iPhoneやBlackBerry、Androidなどのスマートフォンを選択することもできる。残念ながら、日本特有のいわゆるガラケーはリストにないが、「Other」を選択するとユーザー・エージェント文字列を入力できるようになるため、カスタムのユーザー・エージェント文字列も可能だ。

　ここでは、［User Agent］として「iPhone - iOS 6」を選択して、＠ITを開いてみよう。＠ITは、ユーザー・エージェントによってレスポンスを変えているため、スマートフォン向けのサイトが返ってくることが分かる（次の画面）。

画面サイズ

　次にモバイルデバイスのサイズに合わせた表示を確認してみよう。

Device metrics

　［Device metrics］は、画面解像度をシミュレートできる機能だ。

　ここで画面解像度を指定すると、ウィンドウの中で設定されたサイズに表示されるようになる（以下の画面で、右上に表示されている赤文字で黒背景の領域のこと）。縦横を入れ替えるとデバイスを横向きにしたときの表示を確認できる。

Font scale factor

　［Font scale factor］は、画像はそのままで、テキストのフォント・サイズだけを変更する機能だ。モバイルによっては、フォントがPCよりも大きいこともあるため、テキストの倍率を切り替えて表示を確認できる。次の画面では、フォント・サイズを1.5倍にしている例だ。

位置情報

　［Override Geolocation］をチェックすると、緯度・経度を入力して、現在位置を使用するアプリケーションをテストできる（次の画面）。

　このように実際にその場に行かなくても位置情報を使用するアプリケーションをテストできる。また［Emulate position unavailable］をチェックすることで、逆に位置情報を取得できないデバイスの動作も確認できる。

デバイスの方向（Device Orientation）

　［Override Device Orientation］にチェックすると、デバイスの傾きを指定できる（次の画面）。

　デバイスの傾きを使用するアプリも、この機能を使ってテストできる。

タッチ

　［Emulate touch events］は、マウスでタッチ・イベントをテストするための機能だ。これをチェックしてタッチ・イベントに対応したページを操作すると、タッチ非対応のデバイスでもタッチ操作をテストできるようになる。次の画面は実際にこの機能を使って、マウス操作で、タッチ・イベントをエミュレーションしている例だ。

　タッチ対応のデバイスが用意できない場合には、非常に有益だ。

CSSメディア

　［Emulate CSS media］は、CSSメディアによって表示内容を切り替えるWebページに対して、各メディアのときの表示内容を確認するための機能だ。次の画面では、CSSメディアを「print」（＝印刷用）にしたときの表示内容を確認している。

　ほとんどの場合は、「print」時の表示内容を確認するために利用することになるだろう。印刷プレビューなどの操作をすることなく確認できるので便利だ。CSSやHTMLのコードを編集して、リフレッシュするだけで出力内容を確認できるため、コーディングの手間がかなり省ける。

まとめ

　Chromeデベロッパー・ツールについてパネルごとに説明してきたが、Webアプリのデバッグやチューニングに非常に役立つことがご理解いただけたのではないだろうか。ChromeのDeveloper Toolsは機能が非常に豊富なため、記事で全てを説明するのは非常に難しい。そこでWeb開発でよく使う、特に使える主要機能に絞って、スクリーンキャプチャ中心で簡潔に機能を紹介した。本稿がWeb開発者の一助になれば幸いである。