ChromeやNode.jsで利用されているJavaScriptエンジン「V8」に、8年の歴史の中でも大きな変化が訪れました。8月3日にリリースされたバージョン6.1で、数年かけて進めてきたJavaScriptコンパイラーが世代交代を終えました。詳しい話は、V8のブログでも語られていますが、ここでは大きなトピックであるコンパイラーの世代交代についてお話します。

なお、この動きについては、昨年に開かれたカンファレンス「BlinkOn 6」でも語られており、Google I/O 2017でも、Seth Thompsonによるセッション「V8, Advanced JavaScript, & the next performance frontier」によって紹介されています。本記事では、これらの発表内容を補足してご紹介します。

V8のミッションとは？

Chromeで使われているJavaScriptエンジン「V8」ですが、そのミッションはとてもシンプルです。

「Speed up real-world performance for modern JavaScript, and enable developers to build a faster future web.(実世界での要求にあわせてモダンなJavaScriptのパフォーマンスを向上させること。そして、今後の変化していくWebに早く追従し、開発者がそれらをビルドできるようにすること)」

V8のパフォーマンス改善につきまとう2つのトレードオフ

V8とはなんでしょう？JIT(just-in-time compile)で動作させることができるJavaScriptのエンジンです。ブラウザがJavaScriptを受け取ると、ブラウザはそのコードをトランスレートして実行したり。また、コードを翻訳してコンピューターが理解できるネイティブコードにコンパイルしてから実行します。

ただ、そこにはいくつかのトレードオフが存在します。

1. コンパイルして生成されたネイティブコードは、実行されるピーク時の速度が早い一方で、コードの量が多いほど、最初に実行されるまでに遅延が発生する。一方で、トランスレーターを使った場合は、実行されるまでの遅延は小さいけど、実行時の速度が遅い。
2. JavaScriptエンジンは、パフォーマンスを良くしようとするとメモリの消費量が多くなる。一方で、省メモリを進めようとするとパフォーマンスは悪化する。

例えば、以下のような一行のfunctionを呼び出すコードについて考えてみましょう。

このコードでは、 function foo() は一度しか呼び出されていませんよね。このケースでは、実行されるまでの速さ（Fast Startup）を重視し、実行時のパフォーマンス（Peak Perf）は重要視しません。

しかし、以下のケース。

1万回も function foo() を呼び出しています。このケースでは、Fast Startupが遅れてでも、Peak Perfを重視する必要がでてきます。 foo() はネイティブコードにコンパイルされていなくてはいけません。そしてそれがデスクトップ型のコンピューターであれば、メモリも潤沢なので、大量のメモリ消費を犠牲にネイティブコードをさらに幾度に渡り最適化させます。

ただ、これはあくまでデスクトップ型コンピューターの場合。同じ1万回 foo() を呼び出すコードであっても、モバイルの場合は同じアプローチにはなりません。Androidデバイスはモバイルなので、デスクトップと同じようにメモリを扱うことはできません。

ネイティブのコードへコンパイルはされますが、メモリの消費量は抑えられるよう最適化は制限されます。

別のパターンについても考えてみましょう。それが以下のコード。

これはNode上で実行されているコードです。一度起動されたら、ずっと利用されるわけですから、当然、Fast Startupを犠牲にしてPeak Perfを改善しようとしますね。しかし…

IoTデバイス上で動作するとなると、同じ状況とは言えません。サーバー用マシンとは異なり、メモリ消費は抑えなくてはいけません。Peak Perfを上げるようにはしますが、それはメモリ消費が少なくて済むようなアプローチで進めます。

同じ一行のfunction呼び出しであっても、その最適化方法は無数にあり、コンテキストやデバイスの状況に強く依存するのです。そしてそれは、Fast Startupなのか、あるいはPeak Perfに最適化していくのか、メモリを富豪的に扱うのか、それとも小さくなるよう努力するのか、解決しなくてはいけません。

8年前のリリース時点から全てが変わろうとしているV8

V8エンジンは、ここまでに説明したあらゆる状況で最適化できるようにしたり、また新しいパターンのJavaScript（asm.js, WebAssembly等）に対応できるよう、2〜3年かけて実行パイプラインを作り変えました。

過去の変遷を見てみると。

2008年のリリース時点の段階では、シンプルなコードジェネレーターがあって、そこからやや最適化を行ったマシンコードが生成されるだけでした。あらゆるJavaScriptのコードは、この仕組を使って実行されます。

ただ、最適化には計算が必要なため、コードを実行できる状態にするまでに多くの時間を要します。大量のJavaScriptコードを扱う場合は、Startup Time短縮するために最適化の処理をスキップすることが求められます。

2010年にコンパイラ「Crankshaft」が追加されます。計算コストの高い最適化処理を分離し、Crankshaftにその責務が委譲されました。コードの生成だけであれば、Full-codegenは最小のコストでマシンコードを吐き出すため高速なため、Startup Timeが最適化されます。そして、CrankShaftを使ってコンパイルすれば、計算コストを犠牲にPeak Perfにとって最適なマシンコードが生成されます。

実行時に、CrankShaftが吐き出したコードを、Full-codegenが吐き出したコードへ置き換えることで最適化を図ります。

2015年。Crankshaftには限界が来ます。JavaScriptの仕様そのものが大きく変化する時代になりましたが、Crankshaftはその設計上、JavaScriptの機能をサポートしきれず、また新しいパターンのJavaScript（asm.js, WebAssembly等）にも十分に対応できませんでした。当時のフロントエンドエンジニアなら、V8のECMAScript標準への対応の遅れに苛立ちを感じたはずです。

V8開発チームは、それを改善しようと新たなコンパイラ「TurboFan」を追加します。

2016年。「Ignition」と呼ばれる仕組みを追加しました。Ignitionには、ソースコードをいきなりマシンコードにするのではなく、バイトコード(マシンコードほどハードウェアに依存しない「中間コード」と呼ばれるもの)を生成するコンパイラーと、それを実行するインタプリターが内包されています。

そして、TurboFanはバイトコードを扱う形へと作り変えられました。そして現在、最新のVersionである5.9では、この2つの仕組みは既に使われていません。内部にコードこそ存在していますが、バイトコードの生成と解釈するインタープリターIgnitionと、PeakPerfを改善するための処理をするコンパイラーTurboFanだけで動作しているという状況です。

そして、これからまもなくリリースされる6.0では、コードとして完全にV8から削除されます。

「Ignition Interpreter」とは？

中間コードを生成して実行するインタプリター。メモリ消費が小さく動く、Fast Startupも最適という特徴があります。

• モバイルなどのメモリの小さな環境で動かすのに最適。
• Startup Timeに最適化すべきコードの実行に向いている。
• TurboFanと組み合わせることで、実行速度を最適化できる。

「TurboFan」とは？

主として、最適化を行うことを目的としたコンパイラー。

• 使われ方としては、拡張的な感じ。ただ、あらゆる新しいJavaScript機能に対応していき、その場合も活用される。
• WebAssemblyのバックエンドでもある。
• 最近はtry/catch/finallyとか、ES2015+の最適化が可能になった。

まとめ

V8について、メモリ管理向けガーベジコレクター「Orinoco」など、さまざまな技術要素が進化し、語り尽くせないほどのトピックがあるのですが、それはまた別の機会にお話しましょう。TurboFanへの完全移行、実態としてすでにほとんど終わった状況といっても過言ではありませんが、8年前とは全く異なる、Web・JavaScriptの変化に追従する大きな変化です。今後も楽しみですね。

この記事は2017年5月17、18、19日に米国カリフォルニア州マウンテンビューにあるAmphitheatreで行われたGoogleの開発者向けカンファレンスGoogle I/Oの3日目に「DevTools: State of the Union 2017」というタイトルで行われたセッションの内容です。

はじめに

Google I/O、Chrome Dev Summitと日に日に進化をし続けているChromeのDevTools。Google I/O 2017でも多くの進化が報告されました。

登壇者はwebっ子ならば泣く子も黙るDeveloper AdvocateのPaul Irish。軽快なトークで淡々と新機能が話された40分をまとめてみました。

ConsoleでのDebug

ConsoleはDebugには欠かせない機能。なので、我々はConsoleの進化に対して投資を惜しまず、かつ、楽しんで行っています。

Object Preview

今までも、ConosleでObjectの値の閲覧は可能でしたが、要素要素でクリックしないと内容の閲覧はできませんでした。それを解消しました。

旧表示が左側、現在Canaryでの表示は右側のような表示になっています。

Autocomplete

開発者の皆さんにはConsoleでの作業はできるだけ素早く、ストレスなく行ってもらいたいと思っています。ですので、Consoleでは常にAutocompleteがされるようになっています。

例えば、document.head.childNodesの内容を参照したい場合、document.headの要素が何であるかをDevToolsは知っているのでchildNodesなど要素名をサジェストをすることもできましたし、続けて例えば0番目の要素にアクセスをするためにdocument.head.childNodes[0]と入力して内容を参照することも可能でした。

しかし、その先はどうでしょう。今までですと、続けて.を入力してdocument.head.childNodes[0].とし、その要素を参照しようとしても表示されずにエラーとなっていました。しかし、現在では要素へのアクセスも可能で、もちろん要素名もサジェストしてくれます。

そして、例えば要素名に「-(ダッシュ)」が入っているObject。今までであればclasses[まで入力してもサジェストは表示されなかったのですが、現在ではサジェストされるようになっています。

Consoleへ直接コードを入力する場合の便利機能

ObjectをMapに変換する場合、Consoleへキーボードから入力するだけで変換可能になりました。

また、コードを直接Consoleへ入力する場合、今までは1行で入力する必要がありましたが現在では改行もコードの一部として受け付けるようになりました。インテント、さらには、Syntaxのハイライトもつくようになりました。この機能は去年まではありませんでした。

また⌘キー（Ctrlキー） + Dキー で同一の引数を一挙に変更可能です。

非同期（Asynchronous）なJavaScriptのDebugに対応した新機能

例えば、非同期処理のPromisesのDebugはとても難しかった。しかし現在では下の図のように、例えばCallStackには4つのCo-Frameがありそのうち2つは非同期の処理がある、ということを容易に把握することが可能です。ここで重要なのは、どのように動作したかを目で確認できることです。

ここでの例は非常に短いサンプルの紹介ですのでシンプルですが、実際のアプリではもっと複雑です。例えば下の図のような形です。

先程も述べた通りでここで重要なのは「どのように動作したかを目で確認できること」で、このように長いStackにおいても、どのように処理が流れになっていることがパッと見で分かります。

ブラウザのアプリの処理はsetTimeout()、requestAnimationFrame()、Promisesなどの非同期処理が連なっている同期処理の塊によって成り立っている。例えば、つい最近新たに発表されたReact Fiberのアルゴリズムは大きな処理の塊を小さな塊に分割するように設計されています。

これがあるスクリプトの非同期処理の0.25秒間をどう動作したか表している図です。矢印が非同期処理の流れを示しています。非常に忙しいスクリプトです。

見ての通りDevToolsでは非同期処理から次に何が起こっているかを表示することも可能です。特定の呼び出しから、次はどこの処理に遷移したのかを知ることはとても重要です。

これを手動で調査するとなると、とても時間がかかりますが、DevToolsを使えば、この図を見るだけで把握が可能です。DevToolsでは全ての非同期の処理を記録しているので、ページロード時からの全ての非同期処理を追うことができています。

これによって、プログラムのどこのポイントにおいても非同期処理の履歴を完全に追うことが可能になり、どのように到達したのか、またなぜ到達したのかを知ることが可能になっています。

AsyncのDebug

BreakPointを1つ1つ使って進むDebugもよく行いますが、あまり効率的ではないです。これがリアルタイムにできるようになっています。

例えば、console.log('Processing')にBreakPointを置き、⌘キー（またはCtrlキー）を押すと次にジャンプできる箇所を青色でハイライトします（下図：左）。そしてそれらの1つをクリックすることでそこまで進めることができ、さらにそこでプログラムの動作は停止します。

もちろん、直前のresultの内容も見ることができる（下図：右）。

PromisesのDebug

Promiseの処理の中にインラインでBreakPointを置くことが可能になりました。
14行目にBreakPointを置くと、resultの値が何であったかの確認もすぐにできるようになっています。

さらに、これをもっと簡単に実現しています。
先ほどと同じく⌘キー（またはCtrlキー）を押すと青いハイライトと緑色のハイライトが出てきました。「その行にジャンプできる」という意味では同じですが非同期処理であることを示しています。これをクリックすることで非同期処理の内側で処理を停止することが可能です。

Performance Panel

パフォーマンスを測定するときは、Profiles Panel、Timeline Panel、Network Panelの3つもしくは組み合わせで使っていると思います。このように、ツールが分散しているのが現状ですが、実際のところはJavaScriptのダウンロードが終ってからいつメインスレッドでの動作につながるか、

つまりブラウザのパフォーマンスを見たいはずです。動作と動作の接続されている箇所、例えばJavaScriptの実行完了後、ブラウザはレイアウトを計算し表示するのがいつなのか見られるのがとても重要。ですので、これらを1つのタイムラインで並列に並べて1度に見られるPerformance Panelを作りました。

Profile Panelを使ってJavaScriptの開発をしていた方は、Mainスレッドを広げることでどの時間に何が処理されているのか見ることが可能です。下のペインの”Bottom-Up”のタブが全ての処理でどれだけ時間がかかったかを表す”Self Time”の列でソートされて表示されます。

セッションではこの機能を実際にNestのホームページを使って紹介していますのでぜひご覧になってください。（Nestのホームページを使ったPerformance Panelの解説）

Coverage Profiler

最も速いコードは実は動いていないコード、またそれより速いのはダウンロードすらされていないコード。そこで、何が実際に操作しているのかを何とかして提供することはできないかと考えた。そして実装したのがCoverage Profilerです。

Coverage Panelはここから開きます（下図：左）。

CSSを見てみます（上図：右）。サイトで使われている部分は緑、使われていない部分は赤で表示される。赤はCSSもJavaScriptでも現在のページで使われていない部分なので、動作させることで青に、つまり動作した部分はリアルタイムに反映される。

ユーザにとっては赤色になるByteは不要なのでを送らないようにしましょうね。

3rd Party Attribution

Consoleで⌘キー（またはCtrlキー）+Shiftキー+pキーを押し、Show third party badgesと入力して、一度Enterをします（下図：右）。その後にNetwork Panel等を開くと、Networkリクエスト左側にバッジが表示されます。（下図：左）このバッジが 3rd Party Attribution です。このバッジ内の文字列は3rd Partyの名称のイニシャルです。例えば「GA」ならGoogle Analytics。

Consoleのエラー等の表示にもバッジが表示されるようになっているので、エラー、警告等のConsole出力がどこの誰のスクリプトに由来しているかをひと目で確認できるようになりました（下図：下）。また、Performance Panelのタイムラインでは3rd Partyはグループとしてまとめて表示されるようになっています（下図：上）。

Authoring

Cookie Edithing

Cookieの編集がDevToolsで可能になりました。

Change Tracking

DevTools上で変更した箇所をファイルごとにdiff（差分ファイル）として全ての変更を提供することが可能になりました。まだExperimentalです。（セッションでは月曜日、そらく5月22日の月曜日、って言ってるけどまだ使えないっぽい？）

Screenshot

モバイルデバイスのフレームも入れたスクリーンショットも撮れるようになりました。

さらにフルサイズのスクリーンショットも撮れるようになりました。撮り方は⌘キー+Shiftキー+pキーを入力し”Capture full size screenshot”と入力しEnter。（”Capture Screen Shot”はブラウザウインドウサイズの画像）

Breakpoint Resolving

Breakpointを置いて、例えばそれより若い行に変更を加えた場合、Breakpointは消えてしまっていましたが、DevToolsではBreakpointを置いた行番号が動く変更がされたとしても、出来る限り追従することが可能になりました。

大きな変更が入った場合は恐らく追従できません。Best Effortでの追従ですのでご了承ください。

Auditing

LightHouseはChrome Extention、コマンドライン、Node.jsのモジュールで提供されているwebページの質の向上を上げる、サイトのインサイトを見るためのツールです。私はこのプロジェクトにいます。 多くの形式で提供されていますが、DevToolsから実行はできませんでした。これがDevToolsに組み込まれたらとてもよいです。ということで実装しました。

DevToolsを開き、Audiotsのタブを表示します。すると、ここでLighthouseが実行できるようになっています。Nexus5Xをエミュレートして、ネットワークの速度、CPUの速度の調節して計測しています。ページのロードのパフォーマンス、その他にも多くの計測を行ったり、PWAのアプリとしてどうかという計測等を行って結果を出します。

DevToolsですので、Lighthouseで表示結果の中で、指摘された場所をダイレクトに示すことができる。LightHouseとDevToolsの連携したことでwebサイトのインサイトを見る強力なツールになっています。

セッションでは実際にChrome Experimentsを使ってデモをしていますのでぜひ御覧になってください。 （Chrome Experimentsのページを使ったDevToolsに統合されたLightHouseのデモ）

Headless Chrome

画面を表示しない（Headless）C hromeを使うことで、異なった複数のセッティングでの自動検査を行うツール等を作ることができる。例えば、テキスト抽出、スクリーンショット、PDF生成、リグレッションテスト、ユニットテスト、インテグレーションテスト、セキュリティテスト、サーバサイドでのレンダリングなどの検査です。

Chromeチームではそういったシナリオを実現させたかったので現在使えるようになっています。Linux、macOS、Windows（60で対応）で動作可能です。Seleniumへも対応中です。
現状は低レイヤーのAPIしかありませんが、今後高レイヤーのAPIも実装されます。

Eric BidelmanがHeadless Chromeについて書いたブログポスト（日本語版）がありますのでそちらもご確認ください。

Node.js

去年Node.jsもDevToolsでDebug、Profileを出来るようになりました。ブラウザとNode.jsに多くの時間を使うのでとてもよいことです。ここ2年で進化したNode.jsを、私がLightHouseのプロジェクトで行っているDebug方法で実際にお見せします。

セッションでの実際のデモへのリンクです。併せてご覧になると分かりやすいと思います。

デモ動画

以下のコマンドをTerminalから入力して始めますが重要なのは--inspect-brkの部分です。次に出力されるURLをコピーして表示することも可能ですが、よりよい方法があります。

$ node --inspect-brk lighthouse-cli --pref http://example.com;/

Chromeのアドレスバーにabout:inspectと入力して “Open decicated DevTols for Node” のリンクをクリックします。するとNode.jsにのみ接続されている専用のDevToolsのウィンドウが表示されます。もちろんこのウィンドウ内でもDevToolsの全ての機能が利用可能です。

このNode.js専用DevToolsを開くもう1つのよりよい方法です。
DevToolsを開いておき先ほどと同じコマンドを入力します。

そして、DevToolsを見るとInspect ElementのアイコンのとなりにNode.jsのアイコンが現れます。このアイコンをクリックすることで先ほどと同じNode.js専用DevToolsを表示することが可能です。このNode.js専用DevToolsの良いところは、Debugをして再起動したとしても、Node.js専用DevToolsを再起動する必要がないところ。

まとめ

たくさんの新しい機能を説明してきました。
Twitter、定期的に更新しているドキュメント、バグの報告＆フィードバック＆機能追加のリクエストを行うリンクは以下になります。

• Twitter: @ChromeDevTools
• Docs: devtools.chrome.com
• File bugs & give feedback: new.crbug.com

ありがとうございました！

おわりに

今回も開発者視点で欲しい機能がたくさん追加されました。ブラウザであるはずのChromeですが、DevToolsだけに注目すると「ブラウザっていうか、どちらかというと開発ツールだよね？」と思う（もちろん良い意味で）ことも少なくありません。今までに磨きをかけて更にwebの開発をまたスピードアップできるのではないでしょうか？

セッションの中でPaul Irishは「ユーザからの声が多かった◯◯の機能」「◯◯の開発の手順（ワークフロー）を考えるとこの機能は重要で…」というように常に開発者視点に立った上で機能の追加を行ってくださっていますので、

• こんなツールがDevToolsに欲しい
• こういった開発の手順を考えるとこの機能はDevToolsに欲しい

などをフィードバックすることで、もしかしたらその機能が本当に実装されるかもしれませんので、要望のある方はぜひ上記のURLよりフィードバック、バグ報告等を行ってください!

この記事は2017年5月17、18、19日に米国カリフォルニア州マウンテンビューにあるAmphitheatreで行われたGoogleの開発者向けカンファレンスGoogle I/Oの3日目に「The Future of Audio and Video on the Web」というタイトルのセッションの内容です。

はじめに

タイトルをパッと見て、例えばWeb Audioの話も絡むのか！？と思いきや、内容はビデオでしたが、2000年からwebのみならずリビングにあるテレビ（動画）から、YouTube、SNSでの動画も含めて歴史を追った説明、デモをまじえ動画を中心としたwebサイトの現在できる最高のExperience、そして見えかけている未来のwebでの動画の拡がり、とwebで動画という切り口から幅広く説明をした中身の濃いセッションでした。

登壇したのはこのお二方。Product ManagerのJohn Pallettと、Developer Programs EngineerのFrancois Beaufortです。

それでは内容を見ていきましょう。

動画が机、リビングから手の上に乗り外に向けて歩き出す

2000年から10年はほとんど変わらなかった。 2000年は私(John Pallett)がHDのテレビを買った最初の年。この当時はHD動画を録画する機器すらなかったが、直後にHD録画機器も出始めSkypeも同じ頃に登場。2005年にYouTube、2007年にはAmazonのPrimeビデオ、Netflixがストリーミングサービスを開始。しかし、この頃は机、リビングで見るのが主でした。

2010年からは私の娘を軸に見ていきます。 2010年はタブレットが出始めた年。娘はこの頃から場所を選ばず受動的に動画、音楽を聞いたり、一方で能動的に録画、録音するようになっていました。

ちょうどその頃にはFaceTimeが登場し、ビデオチャットが気軽にできるようになり、2011年にはTwitchでゲーム動画の配信、2013年にはSnapchat、2014年にmusical.lyで若者が音楽ビデオを録り、さらにそれを友達同士で配信するようになった。さらに過去数年では、VR、AR、360度動画が出てきたりと、イノベーションがここ数年の動画の進化を加速。

この進化を裏付けるように、現在のインターネットのトラフィックの70%が映像（ビデオ）で、Cisco社は2020年までにこれが80%まで伸びるだろうと予測しています。

モバイルwebでの動画の過去と未来

先程挙げた、Twitch、Snapchat、musical.ly、これらのサイトに行くと実はアプリ（Android, iOS）のインストールを求められます。

しかし、モバイルwebでこれらのアプリを作ればアプリのインストールは不要、そしてすぐにやりたいことができるはずなのに、なぜそうなっていないのでしょう？少し奇妙です。

理由を考えると実はそれにはいくつかの問題、課題がありました。一言でいうと、モバイルwebは動画が得意ではなかったのです。その問題点を見ていきます。

Buffering

動画の提供側はFlashを第一に、第二にHTML5に向けて公開するという時代が続いていて、モバイルwebは眼中の外でした。なぜならモバイルwebで動画にアクセスすると動画のダウンロードに時間がかかり、再生までにかなりの時間がかかっていたからです。

映像のクオリティの低さ

「ダウンロードに時間がかかるのなら、映像のクオリティを落とし、ファイルサイズを小さくしよう！」となりますが、小さくすればするほど映像のクオリティは低下します。

いけてないレイアウト

動画の提供側はモバイルwebは眼中の外だったので、サイト全体のデザイン、レイアウトはデスクトップに最適化されていて、モバイルwebでは動画の一部しか表示されていなかったりした。しかし、この現象は防ぐためのAPIがなかったことが大きい要因で、対策はできなかったかもしれないというのも事実。

オフラインでは利用不可

オフラインでの利用はできなかった。もちろんChromeではOffline時には恐竜ゲームはできて楽しいけど、動画を観たいのに恐竜ゲームを例えば飛行機に乗って数時間するのは現実的ではありません。

では現在のモバイルwebでどうなっているかを紹介します。

デモアプリとしてDeveloper Relations TeamのPaul Lewisが書いたアプリを例に紹介します。アプリの名前は「Biograf」で、アプリとソースコードは以下のURLにあります。

• アプリ bit.ly/pwa-media
• ソースコード bit.ly/pwa-media-code-media

（セッションではここで実際にデモを行います。併せてご覧になると分かりやすいと思います。デモの動画）

（クリックでデモ部分の動画が再生可能です）

特徴は以下です。これはwebアプリですよ！

• Progressive Web App
• Nativeアプリのようにホーム画面からアイコンをタップして起動可能
• 起動アニメーション（Splash）が表示できる
• Chrome（ブラウザ）の枠はなく、全画面でアプリ全体を表示
• スクロールも非常にスムース
• 動画は再生をタップしてから一瞬で開始
• デバイスを横にするとフルスクリーンでも動画の表示が可能
• タイムラインをスクロールすると、サムネイルも表示可能
• フルスクリーン中にタップすると、「再生、停止、コマ送り・戻し」のコントロール画面が表示可能
• 通知エリアにもコントロールを表示することが可能
• 動画のダウンロード機能もあり、ダウンロードした動画はプラウザを閉じても、機内モードでも再生可能（Background Fetch）
• ロック画面からのコントロールも可能
• ロック画面で動画のサムネイルを背景としても表示可能
• 制限付き動画でもライセンスをハンドルして再生可能

これらのExperienceは動画の再生時「ページのロードが遅いとユーザはサイトから離脱してしまう」事実を元に考えると非常に重要な機能でもあります。Akamai社の調査では2秒で表示されないとサイトからの離脱が始まり、また動画の再生に関しては6秒以内に再生されないとユーザは再生開始を待たず離脱してしまうという調査結果を出しています。

では、このアプリを例にExperienceを1つ1つ見ていきましょう。

反応の速い再生(Fast Playback)

これはAdaptive Bitrate Streamingで実現しています。動画を再生するには動画のダウンロードは必須だが、モバイル環境下ではダウンロードするデバイスがトンネルを通ったり、帯域を失ったりする。Adaptive Bitrate Streamingがこれらのネットワークがコンスタントでない部分を解決します。

再生するビデオは複数のBitrateでエンコードして、それらがさらにある時間間隔で断片化して保存する。断片化されたファイルをダウンロードするアプリ側で低域等の状況に合わせてBitrateと断片の組み合わせの最適化を施すことで、反応の速い再生を可能にします。

これを実装したのがOpen SourceのShaka Playerです。

また、再生ボタンをクリック/タップしてからの再生の反応に関しては、Service Workersで動画をPre-Cacheすることで速くしている。これが実装されているのがTHEOPlayerです。Biografにも実装されているが、動画の説明等も一緒に、事前にキャッシュ（Pre-Cache）することで再生までの時間を短縮している。またService Workersを使うとサイト自体のスピードもアップすることが可能です。

VIACOM18のVootという動画サイト（5月25日現在、インドでの提供のみ）ではページロード時間が5倍速くなり、これによってユーザがが77%増加、日々に動画を再生するユーザは15％増加したという結果もあります。

Offline

Offlilneは例えば飛行機に乗っている時など、インターネットアクセスがない場所では非常に重要な機能。BiografではService Workersを使って、ページに表示する動画の説明、また動画に関してはリーズナブルなBitrateで事前にダウンロードしキャッシュとしてブラウザ側に保存することでどこでも再生できるようにしています。このBitrateは開発者側からService Workersのロジックの中で、またはユーザ側が例えばダウンロード開始時に選択することが可能。

Offlineはオーディオにも適応可能です。例えばオーディオブックを考えると、Service Workersを使って事前にブック内のプレイリストのオーディオを事前にキャッシュしておくことで、Offlineでも再生が可能になる。

Biografでは動画をキャッシュするためにBackground FetchというAPIを使っていますが、この機能は現在開発中でExperimental Web Platform features（Chromeのアドレスバーにchrome://flags/#enable-experimental-web-platform-featuresを入力すると変更可能です）をEnableにすることで利用が可能になります。このAPIに関するフィードバックをお待ちしています。

VP9

コーデックに関してです。クオリティを落とさずに2倍のコンテンツを保存できたらよいですよね。VP9は一般的なコーデックに比べると50％程圧縮率が高いので、質を落とさずにファイルサイズを50％減らすことができます。既に20億のデバイスがサポートされている状態なのでとてもよい選択肢。例えばYouTubeではVP9を使うことで他のコーデックで配信したときよりも再生までの時間を15〜80％縮めることができています。

User Experience

Media Session API

ロック画面、通知エリアでサムネイルをバックグラウンドに表示していたのと、コントロールボタンを表示していたのがこのAPI。ウェアラブル側にも表示されます。

実装は簡単でMetadataとしてタイトル、アーティスト、アルバム名、表示する画像を指定をし、コントロール（再生、ストップ等）のボタンが押された時のHandlerをそれぞれ書くことで実装が可能です。

Session Orientation API

デバイスを回転させたときの動作を指定できるAPI。Biografでは横にした場合に全画面表示にしている。縦、横になった場合のHandlerを書くことで実装が可能。

webでの動画の未来

タイトル通りの未来のお話をします。映像周辺の仕様の進化はディスプレイをよりリアルな表現の表示に近づけてくれます。

Wide Color Gamut

まずは色からお話します。現在のテレビ（4Kや8K）で実現されている色がモバイル、デスクトップのwebで表現できるようになります。

現在のディスプレイで表現できている色は目で見えているよりも色の表現は乏しい。その色は存在する色が外側の枠だとすると、最も内側にある三角枠が現在のディスプレイ（SRGB）の守備範囲。これがBT2020になると真ん中の三角枠まで表現できるようになります。

僕の履いている靴、実はこのディスプレイ（登壇者の背面にある）では正しい色で表示されていない。けども4K、8Kではより近い色が出てるはず。
（独り言：もしや登壇者のJohn Pallettさん、このために靴を新調したのかな？）

High Dynamic Range (Brightness)

いままでよりも明るいものは明るく、暗いものは暗く表示できるようになる仕様です。現在の一般的なディスプレイではSDR（Standard Dynamic Range）しか表現できません。これは現実の世界の明るさからするとかなりの差があります。

HDR(High Dynamic Range)をサポートしたディスプレイがこれから市場に出てきます。これはOTF（electric Optical Function、またはガンマFunctionともいう）を変えます。デジタルの数字からディスプレイでどれだけの明るさで表示するかのFunctionのことで、それが変更されるので映像・画像を扱う方はどのディスプレイが何をサポートしているか、またそのディスプレイの特性を知った上で選択する必要が出てくるということです。

Wide Color GamutとHigh Dynamic Rangeのコードは以下です。上部についてです。CSS Media Query Level4で可能になります。現在のChromeではcolor-gamutがサポートされていますが、デバイスでどの色が使えるかをクエリすることが可能で、それによって決定することが可能です。

また下部のコードではVP9がHDRとOTFでどの色で表示できるかをクエリによって決定することができます。

Alliance for Open Media(AOM)

アライアンスです。このアライアンスはYouTube、Google、Amazon、Twitch、Netflix、Microsoft、Mozilla、Hulu、BBCが参加していて、Open SourceでRoyalty-Freeの新しいCodecを作ろうとしています。

HDRだけでなく、Wide Color Gamut、また8K、4K、360どビデオも低いBitrateでも届けることができるようなCodecを考えています。なぜなら世界で皆が同じレベルのネットワークを使えるわけではないから。

このアライアンスではAV1という名前のCodecを開発している。数週間前はまだ開発も終えていないし、使えるフォーマットではなかったが、NetflixがVP9よりも20％高い圧縮率のフォーマットを実現することができたとの報告を受けている。

恐らく疑問に思うのは「AV1がどれだけのデバイスでサポートされているのか？」というところだと思います。ここがwebのユニークで面白いところ。1GHzと3GHzのデバイスでは再生のされ方が違う。ではそこをどうするか、VP9を例にコードを見てみます。Media Capabilities APIを使うことで以下のようにいろいろな値を指定することが可能です。

APIにResolution、Bitrate、再生したいCodecを渡すと、指定した形式をサポートしているか、指定した形式でスムースにつまらずに再生できるか、バッテリパワー的に効率的かを返してくれるので、この情報をどのタイプで再生するかのみならず、どのResolutionで再生するか等、ユーザに最適なExperienceを提供することができるようになる。

録音・録画とシェアとSNS

ここ数年、映像とオーディオに関してここ数年で飛躍的に前進している。私の娘がモバイルで音楽の制作、映像の撮影をしている。顔に飾り物をディスプレイ上でつけたりカスタマイズして、そのまま友達とSNSでシェアしてる。これは5、6年前では考えられなかったことです。SNSでは即座に撮影してシェアすることがキーになります。これはwebにはとても得意ところ。なので、ここでSNSやコミィニケーションについて話をします。

WebRTCはあたらしい技術ではないが、ここ数年で急速にブラウザベンダとアプリケーションプラットフォームとしての両方に適応されてきました。そしてWebRTCを使えばLiveStreamingもすることが可能です。

そしてユーザがシェアする動画・音楽の制作に関して、簡単に探せて、簡単に見ることができ、さらにそれを見た友達が動画・音楽の制作ができ…となれば、とてもよいサイクルが生まれます。

このサイクルの実現はwebでなら難しくはありません。それではこのサイクルがwebで実現できるかどうかを、デモを交えてフランソワから紹介してもらいます。

Mustache（髭）

映像とシェアに関わる部分で現在のwebでできることを盛り込んだデモをご紹介します。アプリは「Mustache」という名前です。

Progressive Web Appになっています。ホーム画面のアイコンから起動すると、起動アニメーション（Splash）が表示されます。このExperienceですと、既にwebアプリだと認識するのが難しいと思います。顔には髭、頭には帽子をかぶっています。動かしても映像はとてもスムーズです。動画の撮影も可能で、それをシェアすることももちろん可能です（上の画像の右側）。

Mustacheが利用しているAPI

映像を扱う(getUserMedia())

カメラを扱い、画面に表示するコードが以下になります。

getUserMeida()でカメラの映像と音声を取得します。Mustacheの場合は映像のみを利用します。その他の条件として利用するカメラ（前面、背面）、Framerate、サイズをしています。そして下部のコードで取得した映像を画面に表示しています。

形状の検知（Shape Detection API）

現在、実験中のAPIであるShape Detection APIを使っています。動いている顔へ髭、そして頭に帽子をと、このAPIが重ねる正しい場所を検知することを可能にしています。つい先週完成したばかりのAPIです。

コードは以下のようになります。とてもシンプルです。FaceDetector()に顔を取得するか、また、顔を最大いくつ検知するかの数を指定するだけです。ブラウザ側のAPIなのでインターネットへの接続は不要です。

このShape Detection APIはBarcode、QR Codeを検知するAPIと同時に9月にはChrome安定版でテスト利用という目的で利用可能になります。また、現在でも「Experimental Web Platform features」をEnableにすることで利用可能です。もし要望、バグがあったら知らせてください。

映像の録画（Media Recording API）

Mustacheでは、以下のようにMedia Recording APIを使っています。MediaRecorder()へCodecをVP9と指定して、映像を受け取ったら処理をするHandler、また録画を停止した時のHandlerを書いている。Chromeに公開されて1年になるのでAPIは安定しています。

シェア機能（Web Share API）

シェアボタンを押したときにAndroidのNativeのシェア選択画面が出てきていましたよね。自然過ぎてわからなかったかもしれませんが…。これはWeb Share APIを使っています。
コードは以下です。share()にタイトル、テキストと映像のURLを指定します。このAPIは今年末には利用できるようになるでしょう。

Mustacheは以下のURLで公開しています。
Chrome for AndroidのCanaryを使い、Experimental Web Platform featuresのEnableにして利用してください。

• Mustache

全てのAPIを1つのノードとしてみるとwebではPlug-inなしでこれらノード同士を無限につなげることができます。例えば、Media Streamを使えばカメラからCanvasに描画、アップロード、またマイクからWeb Audioそして、WebRTCのRTCPeerConnectionへと、たくさんのAPIと接続して利用することが可能です。

まとめ

デモに交えてたくさんのAPIを話しました。多くが現在でも利用可能なAPIです。

Biografでは、Service Workers、Media Session API、Full Screen API、Screen Orientation APIなどを使っています。フランソワがこちらに記事としてまとめてくれていますので詳しくはそちらを参照してください。

映像の再生等に関わるProgressive Web Appを書く場合はBiografのコードを参考にするとよりよいExperienceを提供できるでしょう。
そしてMustacheで使っているMediaStream Recording API、Media Capture API、Media Streams APIは現在でも利用可能です。

最後に、以下の3つは特にFeedbackをお待ちしています。

• Background Fetch
• Shape Detection API
• Web Share API

ありがとうございました！

おわりに

個人的に数年前から年に数回はFacebookをモバイルwebから使う儀式をしています。写真や動画を撮ってシェアしたりするのが特にですが不自由な点がありました。

また、QRコードの読み取りも必ずモバイルのNativeアプリ、またはインターネットへの接続が必須とされていました。それを元に考えると近年のWebブラウザの進化には目を見張るところがあり、また同時にその進化を肌で実感できるエキサイティングなプラットフォームの1つだと思います。

今後も映像のみならず、他の分野でのWebブラウザの発展、拡張も期待できそうですし、その進化から目が離せないですね。