Chrome DevTools の 10 年の歩み
2018年11月30日金曜日
この記事は Chrome DevTools チームによる Chromium Blog の記事 "10 Years of Chrome DevTools" を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。
Chrome が 10 周年を迎えました！オープンで協調的、協力的なウェブ開発コミュニティが実現していることを皆さんに感謝します。DevTools は、たくさんのプロジェクトからインスピレーションを得ています。ここでは、DevTools がどのように登場し、年とともにどう変化してきたのかを振り返りたいと思います。
レイアウトの問題や、ネットワークのエラーはどうでしょう。ここでも、実際に行えるのは、コードの中で骨の折れる実験を行うことだけでした。2006 年までは、それがウェブ開発の現実でした。その後、Firebug というちょっとしたツールが登場し、すべてが変わりました。
Saying Goodbye to Firebug より転載した Firebug の Net パネルのスクリーンショット（出典およびライセンス）
Firebug は、ページのデバッグ、編集、監視をリアルタイムに行える Firefox の拡張機能です。その途端、ページについて何もわからない状態にあったウェブ デベロッパーは、現在のデベロッパー ツールの実質的な中核機能を使えるようになりました。Firefox がなぜそのような動作になるかを厳密に理解できるようになったことで、ウェブに創造性があふれることになりました。Firebug がなければ、Web 2.0 の時代は到来しなかったことでしょう。
Firebug の Net パネルと同じように、この最初の Web Inspector も見覚えがあるでしょう。ほとんどの機能は、現在の Chrome DevTools の Elements パネルに受け継がれています。Web Inspector は Firebug の数日後にリリースされ、Safari はデベロッパー ツールが直接バンドルされた初めてのブラウザになりました。
Chrome が 10 周年を迎えました！オープンで協調的、協力的なウェブ開発コミュニティが実現していることを皆さんに感謝します。DevTools は、たくさんのプロジェクトからインスピレーションを得ています。ここでは、DevTools がどのように登場し、年とともにどう変化してきたのかを振り返りたいと思います。
はじめに Firebug ありき
デベロッパー ツールが搭載されていなかったブラウザを想像してみてください。その場合、JavaScript をどうやってデバッグするのでしょうか。基本的には、3 つの選択肢があるでしょう。- コードのあちこちで window.alert() を呼び出す
- コードの一部をコメントアウトする
- JavaScript の神様が解決策を授けてくれるまで、じっとコードを見つめる
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 のバックボーンであり続けています。
リモート デバッグは正しい方向に向かう一歩であり、現在も実際のモバイル端末でサイトが問題なく動作することを確認する主なツールであり続けています。しかし、時間とともに、リモート デバッグはやや煩雑に感じるようになりました。サイトや機能の構築の初期段階にある場合、一般的に必要になるのはおおまかなモバイル機能だけです。そこで、次のようなモバイル シミュレーション機能を作ることにしました。
これらの機能は、まとめて Device Mode と呼ばれています。
Device Mode の初期プロトタイプ
モバイルの時代が幕を開け、Gmail などの大型アプリがウェブ機能の限界を突破していきました。その一方で、Gmail 規模のバグには、Gmail 規模のツールが必要となりました。そこで、Chrome がページを表示するために必要な処理について、すべての内訳を順を追って厳密に表示するようにしました。これは、私たちが行ったツール エコシステムに対する最初の大きな貢献の 1 つとなりました。
こういったツールは正しい方向に向かう一歩でしたが、最適化できる場所を見つけるためには、ブラウザの動作について細かい部分まで把握し、たくさんのデータを分析する必要がありました。そこで先日、この機能をベースにして開発を行い、パフォーマンスについての詳しい分析を提供できるようにしました。新しい Lighthouse エンジンは、Audits パネルで活用され、さらに CI システムと統合できる Node モジュールとしても利用できるようになっています。
Node が登場して最初の数年間、Node デベロッパーは、Firebug が登場する前のウェブ デベロッパーや、Timeline パネルが登場する前の Gmail デベロッパーのような状況にありました。つまり、Node アプリの規模が Node ツールの規模を上回っていたのです。Node が Chrome の JavaScript エンジンである V8 で動作していることを考えれば、DevTools がこの溝を埋める候補となることは自然なことです。Node のデバッグをサポートし、ブレークポイント、コードのステップ実行、ブラックボックス化、トランスパイルされたコードのソースマップなどの通常の DevTools 機能を利用できる DevTools は、2016 年に登場しました。
Node Connection Manager
Chrome DevTools Protocol（CDP）という名前を聞くと、DevTools のみが使う API であるように思うかもしれません。しかし実際はそれよりも汎用的で、プログラムから Chrome にアクセスできる API になっています。ここ数年間で、このプロトコル エコシステムに加わるサードパーティ製のライブラリやアプリケーションがいくつか登場しています。
うれしいことに、これらのパッケージを使って Chrome と高度なインタラクションを行うたくさんのプロジェクトが登場しています。ツールの開発や自動化のビジネスに携わっている方は、ぜひこのプロトコルを確認し、皆さんの領域で新たなチャンスを開くことができないかを調べてみてください。たとえば、VS Code チームや WebStorm チームは、それぞれの IDE で JavaScript デバッグを実現するために、この機能を使っています。
このような活発なコミュニティを実現していただき、ありがとうございます。皆さんとともにウェブを作り上げる次の 10 年間を楽しみにしています。
Reviewed by Eiji Kitamura - Developer Relations Team
モバイルの時代
DevTools プロジェクトの最初の数年間で行ってきたのは、本質的に Firebug や Web Inspector から始まった物語にいくつかの章を追加するような作業でした。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 年に登場しました。
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 デバッグを実現するために、この機能を使っています。
次のステップ
私たちのミッションの中心にあるのは、皆さんがウェブですばらしい体験を構築するために役立つツールを開発することです。どんなプロダクトや機能を開発するかという判断にあたっては、皆さんのフィードバックを非常に重視しています。- 新機能についての投稿に注目してください
- メーリング リストで新機能を提案してください
- Chromium Bug Tracker でバグを送信してください
- Twitter をフォローし、新機能や小さなワークフローについての情報を確認してください
- Stack Overflow で質問し、DevTools を使う際に役立ててください
- 自ら問題に対処し、DevTools に貢献してください
このような活発なコミュニティを実現していただき、ありがとうございます。皆さんとともにウェブを作り上げる次の 10 年間を楽しみにしています。
Reviewed by Eiji Kitamura - Developer Relations Team
