レイアウトの問題や、ネットワークのエラーはどうでしょう。ここでも、実際に行えるのは、コードの中で骨の折れる実験を行うことだけでした。2006 年までは、それがウェブ開発の現実でした。その後、Firebug というちょっとしたツールが登場し、すべてが変わりました。

Saying Goodbye to Firebug より転載した Firebug の Net パネルのスクリーンショット（出典およびライセンス）

Firebug は、ページのデバッグ、編集、監視をリアルタイムに行える Firefox の拡張機能です。その途端、ページについて何もわからない状態にあったウェブ デベロッパーは、現在のデベロッパー ツールの実質的な中核機能を使えるようになりました。Firefox がなぜそのような動作になるかを厳密に理解できるようになったことで、ウェブに創造性があふれることになりました。Firebug がなければ、Web 2.0 の時代は到来しなかったことでしょう。

WebKit Web Inspector

Firebug のリリースとほぼ同時期に、何名かの Google エンジニアがやがて Chrome となるプロジェクトに着手しました。Chrome は、最初からさまざまなコード ライブラリのマッシュアップでした。Chrome エンジニアは、レンダリングにオープンソース プロジェクトである WebKit を使いました。WebKit は、現在も Safari で利用されています。WebKit を使うメリットの 1 つに、Web Inspector という便利なツールが付属していたことがあげられます。

Web Inspector Redesign から転載した Web Inspector のスクリーンショット（出典およびライセンス）

Firebug の Net パネルと同じように、この最初の Web Inspector も見覚えがあるでしょう。ほとんどの機能は、現在の Chrome DevTools の Elements パネルに受け継がれています。Web Inspector は Firebug の数日後にリリースされ、Safari はデベロッパー ツールが直接バンドルされた初めてのブラウザになりました。

「Inspect Element」の時代

Chrome は、ブラウザ エコシステムに多くの革新的なアイデアをもたらしました。たとえば、検索とアドレスバーを組み合わせたオムニボックス、1 つのタブがハングしてもブラウザ全体がクラッシュしないようにするマルチプロセス アーキテクチャなどです。しかし、私たちが最も満足しているイノベーションは、すべてのビルドですべてのユーザーにデベロッパー ツールが提供され、マウスのクリックだけで使えるようになったことです。

2010 年の「Inspect Element」


Chrome 以前のデベロッパー ツールはオプトイン機能であり、Firebug のように拡張機能をインストールするか、現在の Safari のようにフラグを設定しなければなりませんでした。Chrome は、すべてのブラウザ インスタンスでデベロッパー ツールを使えるようにした初めてのブラウザです。私たちは、最初からデベロッパーが親しみやすいブラウザを作るという壮大なビジョンを持っていました。しかし、実際問題として、初期の Chrome にはたくさんの互換性の問題（誰も Chrome 向けに構築していなかったので、これは当然のことです）があり、そういった問題を簡単に修正できる方法をウェブ デベロッパーに提供する必要がありました。ウェブ デベロッパーから便利な機能だという声が寄せられたので、この機能はその後も継続されることになりました。

モバイルの時代


DevTools プロジェクトの最初の数年間で行ってきたのは、本質的に Firebug や Web Inspector から始まった物語にいくつかの章を追加するような作業でした。DevTools へのアプローチにおいて次の大きな転換点は、明らかなスマートフォン時代の到来です。
このすばらしい新世界における私たちの最初のミッションは、デベロッパーが開発マシンから実際のモバイル端末のデバッグを行えるようにすることでした。この仕組みは、リモート デバッグと呼ばれています。実は、DevTools はリモート デバッグを処理する上で絶好の位置にありました。これは、Chrome のマルチプロセス アーキテクチャが生んだもう 1 つの成果です。私たちは、DevTools プロジェクトの初期のころから、デバッガがマルチプロセス ブラウザに確実にアクセスする唯一の方法は、ブラウザをサーバー、デバッガをクライアントとして、クライアント サーバー プロトコルを使うことであるという点に気づいていました。このプロトコルは、モバイル Chrome の登場時点で既に組み込まれていました。そのため必要なことは、開発マシンで実行されている DevTools がこのプロトコルを使ってモバイル端末で実行されている Chrome と通信できるようにすることだけでした。このプロトコルは、Chrome DevTools Protocol と呼ばれており、現在も DevTools のバックボーンであり続けています。

リモート デバッグ

リモート デバッグは正しい方向に向かう一歩であり、現在も実際のモバイル端末でサイトが問題なく動作することを確認する主なツールであり続けています。しかし、時間とともに、リモート デバッグはやや煩雑に感じるようになりました。サイトや機能の構築の初期段階にある場合、一般的に必要になるのはおおまかなモバイル機能だけです。そこで、次のようなモバイル シミュレーション機能を作ることにしました。
  • タッチベースの入力、端末の画面の向きのシミュレーションを含む厳密なモバイル ビューポートのエミュレーション
  • ネットワーク接続の帯域を絞ることによる 3G のシミュレーション、CPU の制限による能力の低いモバイル ハードウェアのシミュレーション
  • ユーザー エージェント、位置情報、加速度計データなどの偽装

これらの機能は、まとめて Device Mode と呼ばれています。





Device Mode の初期プロトタイプ



2018 年時点の Device Mode

パフォーマンスの時代


モバイルの時代が幕を開け、Gmail などの大型アプリがウェブ機能の限界を突破していきました。その一方で、Gmail 規模のバグには、Gmail 規模のツールが必要となりました。そこで、Chrome がページを表示するために必要な処理について、すべての内訳を順を追って厳密に表示するようにしました。これは、私たちが行ったツール エコシステムに対する最初の大きな貢献の 1 つとなりました。

Chrome デベロッパー ツールの機能強化で発表された最初の Timeline パネル


2018 年時点の Performance パネル

こういったツールは正しい方向に向かう一歩でしたが、最適化できる場所を見つけるためには、ブラウザの動作について細かい部分まで把握し、たくさんのデータを分析する必要がありました。そこで先日、この機能をベースにして開発を行い、パフォーマンスについての詳しい分析を提供できるようにしました。新しい Lighthouse エンジンは、Audits パネルで活用され、さらに CI システムと統合できる Node モジュールとしても利用できるようになっています。

Audits パネルに表示されるパフォーマンス提案

Node.js の時代

2014 年頃まで、私たちは DevTools が主に Chrome ですばらしい体験を構築するためのツールだと考えていました。しかし、Node の台頭によって、ウェブ エコシステムにおける私たちの役割の再考が求められることになりました。

Node が登場して最初の数年間、Node デベロッパーは、Firebug が登場する前のウェブ デベロッパーや、Timeline パネルが登場する前の Gmail デベロッパーのような状況にありました。つまり、Node アプリの規模が Node ツールの規模を上回っていたのです。Node が Chrome の JavaScript エンジンである V8 で動作していることを考えれば、DevTools がこの溝を埋める候補となることは自然なことです。Node のデバッグをサポートし、ブレークポイント、コードのステップ実行、ブラックボックス化、トランスパイルされたコードのソースマップなどの通常の DevTools 機能を利用できる DevTools は、2016 年に登場しました。
Node Connection Manager



DevTools プロトコル エコシステム

Chrome DevTools Protocol（CDP）という名前を聞くと、DevTools のみが使う API であるように思うかもしれません。しかし実際はそれよりも汎用的で、プログラムから Chrome にアクセスできる API になっています。ここ数年間で、このプロトコル エコシステムに加わるサードパーティ製のライブラリやアプリケーションがいくつか登場しています。
  • プロトコルへの低レベル JavaScript アクセスを提供する chrome-remote-interface
  • 1 段階上の抽象化を提供し、最新の JavaScript API と自動更新に対応したヘッドレス Chrome ブラウザの自動化を実現する Puppeteer
  • ページのパフォーマンスと品質を改善する方法を見つける処理を自動化する Lighthouse

うれしいことに、これらのパッケージを使って Chrome と高度なインタラクションを行うたくさんのプロジェクトが登場しています。ツールの開発や自動化のビジネスに携わっている方は、ぜひこのプロトコルを確認し、皆さんの領域で新たなチャンスを開くことができないかを調べてみてください。たとえば、VS Code チームや WebStorm チームは、それぞれの IDE で JavaScript デバッグを実現するために、この機能を使っています。


次のステップ

私たちのミッションの中心にあるのは、皆さんがウェブですばらしい体験を構築するために役立つツールを開発することです。どんなプロダクトや機能を開発するかという判断にあたっては、皆さんのフィードバックを非常に重視しています。

このような活発なコミュニティを実現していただき、ありがとうございます。皆さんとともにウェブを作り上げる次の 10 年間を楽しみにしています。

Reviewed by Eiji Kitamura - Developer Relations Team


実際のデバイスにおけるパフォーマンスを計測したい場合はどうでしょう？

ChromeOS を含む Chrome Beta で、USB で接続されたデバイスの検知がネイティブでサポートされるようになりました。「ツール」 > 「デバイスを検証」メニューを選択するか、about:inspect を開いてください。設定は必要ありません。これまでのように adb コマンドラインツールを使ったり、拡張機能を入れる必要もありません。(*2)

USB で接続されている間、デバイスから DevTools に画面全体のスクリーンキャストを送信することが可能です。スクリーンキャストが利用可能な場合、Elements タブの横に専用のアイコンが表示されます。


キーボードやマウスのイベントも DevTools からデバイスに送信されるため、アプリのテスト中にデバイスに触れる必要もありません。




これら モバイルエミュレーション、USB デバッグ機能、スクリーンキャストによって、DevTools を使った開発や調査、デバッグはさらに手軽になることでしょう。Chrome Dev Summit 2013 で行われた Paul Irish のセッション動画 ã§ã“れらの機能のデモをご覧頂くことができます。

*1: DevTools の Settings > Overrides で 'Show Emulation' をチェックする必要があります。
*2: Windows ユーザーの方は USB デバイスドライバーをインストールする必要があります。