今現在Webで起こっていること

Progressive Web App (goo.gl/WR7yJ3)

Service Worker、Add to Home Screen、App Manifest、Background Sync等を使い、NativeアプリのようなUXを提供するWebアプリを指す言葉です。 Chris氏いわく、23年間Webをやってきているけど、やっと理想だと思っていた世界、ユーザーとのエンゲージ率が高いUXを持つサイトがWebというPlatformのみで制作することが可能になっている。（作り方等の詳細はこちら「The Mobile Web: State of the Union」でとのこと）

けど、ここで話すのは既に利用可能なCutting Edgeな話ではなくて、「New Shiny」と呼んでるWeb PlatformのBleeding Edgeな話をします。なので、まだリリースされていない機能だったりCross-Browser、Cross-Deviceで動かない機能、Experimentalフラグの変更を必要とする機能も含まれます。

ただここではカバーしない機能もあり、その代表的なものの一覧はこちらです。

New Shiny（Bleeding Edge）

開発をより簡単に速くするための機能(導入済み)

Promise

非同期のAPIの記述を一貫性のあるパターンで書く方法です。Callbackのように混乱しやすかったり、散らかりやすくなく、同期APIをブロックすることもなくなります。Web開発はブロッキングをなくすようなデザインをするように考え方を変える必要があります。なのでPromiseは新たなWebのAPIをデザインするときには一般的な方法になっていて、以下はPromiseを使うAPIとしてデザインされている代表的なものです。

• HTMLMediaElement.play()：Promiseに書き換えられました
• Web Bluetooth
• Web USB
• Web MIDI

[実装状況]

Fetch

FetchもPromiseを使っています。FetchはXMLHTTPRequest(XHR)と似ていてNetworkリクエストを行います。XHRとの違いはPromiseを使って可読性が上がっているところ。Fetchで何をしているか分からなくても、見たら何となく内容を理解できるところです。Callback地獄からの脱却、XHRの複雑な部分から開放してくれる。例えば、直接JSONや他のデータ・タイプを扱うことも可能です。

左がFetch、右がXHR。パッと見、XHRとも悪くないけど、Stateのチェックとかしてないから悪くないのであって、本来はもっと長くゴチャゴチャするのでご注意してください。

そしてES6のアロー・ファンクションを使うと、さらにこんなにもキレイになります。

ただ、さらなるチャレンジ。問題はこのままだとデータを完全に取得してからでないとJSONとしてParseができないところ。つまりAtomicで割り込みができない。そこで実装中なのが、このFetchやその他のAPIの本当の能力を引き出す機能、それがStreamです。
[実装状況]

Stream

Streamは基本的な要素で、その使い道はいろいろあると思います。Jakeはこんなことを言ってます。「Streamは2016年の大きな1つの機能になるだろう」と。なぜならStreamはProgressiveなデータ転送を可能にするからです。全てのデータを受け取っていない状態でも、受け取った順に処理することができる。つまり、Progressiveなレンダリングだったり処理が可能になるのです。App Shellアーキテクチャを使う場合等は1度に複数の場所からデータを取得するので、とても重要な要素になります。

画像は左側の「Fetch」の全てが終わらないと真ん中の「Process」に進めない、それに引きづられて最終的な「Render」も遅くなってしまう、を表した図。

Jakeが作成したOffline Wikipediaのサイトで、Streamを使うとどれくらい差がでるかを比較したデモ動画です。左からServer Render、Service Worker Client Render、Service Worker Client+Hacks Render、一番右がStreamを使ったService　Worker Client Renerです。（画像が小さくてすみません。セッションでのビデオ再生はココから見られます）

初期のレンダリングは一番左のServer Renderが他よりも8倍くらい遅い、しかしレンダリング完了までだとnon Streamの真ん中の2つよりも速い。この理由は、真ん中の2つは全てのデータを取得するのを待ち、それから処理を始め、その後最終的にレンダリングされるからです。せっかくのハイパフォーマンスなProgressiveなWebアプリなサイトであるのに、表示が遅くては致命的とも言えるでしょう。実際に、現況ではApp Shellアーキテクチャのがコストが高い（時間がかかる）場合もあります。
[実装状況]

さらにパフォーマンスをテーマに話を続けます。ハイパフォーマンスなWebサイトを作るために実装しているエキサイティングなその他の機能を紹介します。

RequestIdleCallback

多くのWebアプリ、サイト上では多くのスクリプトが動いていることと思います。しかし全てのスクリプトがユーザーが見ている画面に直接関係のあるスクリプトではなかったりしますよね。例えば、Analyticsデータの送信です。スクロール中に動いてしまうとスクロールがロックしたりユーザー体験（UX）の質は下がります。そこで、そういったユーザーが見ている画面に直接影響を及ぼさない処理を空いている時間に走らせよう、という機能がRequestIdleCallbackです。

RequestAnimationFrameはできるだけ60fpsで表示ができるようその処理をスケジュールしています。そして、RequestIdleCallbackはRequestAnimationFrameと一緒に動作しています。レンダリングに関係しない処理を、レンダリング処理が空いているところにスケジュールしてくれる、という動きです。

実装は難しくないけど、ここで動かしたいタスク（処理）の1つ1つはリーズナブルな時間で終わるように分割されている必要があります。時間がかかるタスクは今まで通りWeb Workerで動作させることをおすすめします。ちなみにNetflex、Facebookはこの機能を既に導入しています。
[実装状況]

PassiveEventListener

新しいDOMの機能でChrome 51でShipされます(I/O後の2026年5月下旬にリリースされました)が、ユーザーによりよいスクロール機能を提供するための機能です。導入はすごく簡単。

スムーズなスクロールの機能はWebにとって、特にタッチデバイスでのWebにとってはとても重要です。モダンなブラウザは高コストなJavaScriptがUIスレッドで走っていたとしても、スクロールを別スレッドでハンドリングする機能を持っています。

なのですが、問題はそれがタッチやスクロールeventハンドラを持っていると、最適化で負けてしまうところです。なぜならそれらのハンドラは.preventDefaultをCallすることでスクロールを完全にブロックしてしまうからです。eventハンドリング中に.preventDefaultがCallされるかどうかは分からないので、高コストなJavaScriptの処理が完了するまで待つ必要が出てきてしまうのです。

そこでPassiveEventListenerでは、.preventDefaultをCallしないと宣言し、スクロールがeventによってブロックされないようにするのです。

Chrome for Androidではその80%のTouchEventがブロックされる必要はないのにブロックされている。その10％がスクロール開始までに最低100ms待ち時間が生じた。さらに、その1％は500msの待ち時間がスクロール開始までに生じている。

CNNのサイトで導入したのと、していないのとで比較をしてみます。（ビデオはこちらから：preventdefaultをcallしてないのに遅くなっているのとPassiveEventListenerを使った場合の比較ビデオ）

この違いを生むための実装は、たったこれだけです。

[実装状況]

Intersection Observer

特定のDOM Elementが画面内に入っているかどうかを見る、またその場所も簡単に得ることができるのがこのAPI。今までも実装は可能だったけど、効率的ではなかったし問題もいろいろあった。では、Intersection Observerのコードを見てみましょう。

画面内に入ったかを監視したいターゲットとなるElementを決めましょう。そしてIntersectionObserverのオブジェクトの生成時します。生成時には画面内に入った場合の動作についてのCallbackも渡します。最後に生成したオブジェクトでどのElementを監視するかを指定します。（デモページ：goo.gl/mNdYRv、Chrome 51以降で御覧ください）

デモページはとてもスムーズで超速な無限のスクロールを提供しています。コンテンツ表示はネットワークの遅さをシュミレートしているかのように遅れていますが、Service Workerを使ってキャッシュすると解決します。例えば、たくさんの画像を表示するページ等には持ってこいですね。
[実装状況]

<link rel=”preload”>

Chrome 50でShip済みで、リソースのPreload（事前読み込み）を行います。遷移先のページを事前取得する<link rel=”prefetch”>とは違い、現在のページ内のリソースを読み込む優先順位を指定ができる属性です。
[実装状況]

HTTP Clients Hints

HTTPヘッダにつけることで取得するコンテンツの種類を事前ネゴシエーションすることができる。ネゴシエーションの要求を出すことで、ユーザーのデバイス、環境によってサーバ側が提供されるコンテンツを差替えてServeすることが可能です。サーバ側に実装されるものであって、クライアント側のコードで指定するものではありませんが、以下の様な要求ができるように用意されています。

• DevicePixelRatio(DPR)
• Preferred widt
• viewport-width
• save-data: サーバにデータ転送を節約していることを知らせることができる

Canvas.toBlob

Chrome 50でShip済みで、クライアント側でCanvasをそのままBlobにすることができます。一説によるとこの機能が実現するまでに6年かかったそうです。.toDataURL()から得られるBase64の文字列を操作することなく、画像としてそのままサーバにアップロードしたり、IndexDBに保存したりできるので、より簡単に再利用することが可能になります。
[実装状況]

ImageBitmap

Chrome50でShip済みで、ImageBlobを他のCanvasにそのまま描くことも可能になっています。Canvasに描くために画像をデコードするのはとても一般的ですが、画像のデコードにCPUリソースをとても多く使ってしまうという問題点があります。しかし、Base64とデータの間での処理をすることなく扱えるようになったのです。そうすることで、例えば他の画像、エレメント、ビデオ等をCanvasに描くときと同じように扱えるようになりました。
[実装状況]

Unified Media Pipeline

クライアントではなくてChrome自体のコードの話です。デスクトップ版でもモバイル版でも全く同じ処理がされるようなMediaようにPipelineを持つようにしました。Chrome for AndroidにおいてもOSが持つAndroid Media Stackでの処理は行わないようにしました。これによりCross-Platformでも一貫した処理（例えばキャッシュ、エンコード、デコード）を行うようになっています。よって、Cross-Platformでのデバッグをより簡単にしています。

MediaRecorder

ビデオ、オーディオをキャプチャするだけでなく、エンコードして保存をすることが可能になりました。例えば、取得したオーディオをMP3にクライアント側で変換してサーバにアップロードすることが可能です。 （デモページ：simpl.info/mediarecorder、Chrome 49以降でご覧ください）

コードはこんな感じです。MediaRecorderのオブジェクトをOptionを渡して作成して、データを取得したときのCallbackを.ondataavailableに指定します。Callbackにはどう扱うかを書くのだけど、ほとんどの場合取得したデータ（Blob）をくっつけるだけです。そして、最後にどれだけの長さの動画を作るかを指定して完了です。サーバにアップロードする、ローカルに保存する等ができるようになります。Web Audioでの質問として何度か受けていますが、まさにこれがその解です。
[実装状況]

Media Session

Mediaの動作を操作のカスタマイズ、例えばラップトップのオーディオように用意されたキーを特定の機能に割り当てることができたり、モバイルでは通知エリア(Notification Area)、ロック画面にMedia操作用のUIを出すことができるAPI。もしMediaに関するアプリを作っている開発者であれば一度見てもらいたい。
[実装状況]

CSS Variables

正確にはCSS Custom Propertyとも言いますがChrome 49でShipされています。例えば、同じ属性を何度も繰り返し書くことの削減してくれたり、また色・見た目等のテーマの変更にもとても有効です。
[実装状況]

CSS Containment

CSSを隔離してパフォーマンスを最適化してくれる機能です。例えば、3rd Partyのウィジットを使った場合、そのウィジットのCSSを隔離することで自サイトのパフォーマンスに影響が出ないように最適化してくれます。
[実装状況]

CSS Font Loading API

最初に実装されたのはChrome 35でそこそこ前なんですが、Font LoadingのInterfaceはChrome 48でShipされたばかりです。1つ1つのFont Faceのチェック、またそれらのダウンロード状況を確認できるようになりました。これによりFontが実際にどれくらいダウンロードされたか、どんなFontであるかを知ることができるようになりました。
[実装状況]

Progressiveに速いスピードで短い説明で新しい機能を紹介しまくって、後で調べてね、と言っている感があるように聞こえるかもしれないですので、少し休憩というようなお話をしますね。

（後編の予告など）
ということで、この辺りで前編は終了です。後編はWeb Platformをより先に進めるためにここ1～2年Chromeチームが取り組んでいるアプローチ、Chris氏の大好きなアレ、そしてWeb Bluetoothについてお伝えします。

「今日は面白いのに話題になっていないよね、というHTML5のマニアックなAPIを紹介しようと思う」。冒頭でこう切り出して始まった羽田野太巳氏のセッション。テーマは「ようこそ、HTML裏APIの世界へ」。

HTML5のAPIはモテ系だけじゃない。非モテ系にも注目！

現在、HTML5の世界で世間の注目を集めているのはCanvasやWebGL、WebRTCなどのモテ系APIである。五感に訴えられる、派手で華やかなデモが作れるので仕事に結びつきやすい技術だ。「仕事に結びつきやすい」ことからモテ系と呼ばれているが、羽田野氏が紹介するのは非モテ系のAPI。

「語れる開発者仲間が少ないし、使ってもすごさがわからない。仕事になるかわからない。未熟なので仕様がなくなるかもしれない。でもいつか報われる日がくるんじゃないかと期待できる。そんな今はAPIを紹介する。ただ、さっきもいったようにハッピーエンドは期待をしないでほしい（笑）」

マニアレベル1「割とモテ系」の4つのAPI

羽田野氏は非モテ系APIをそのマニアック度から4つのレベルに分けて紹介。最初に取り上げたのはマニアレベル1（割とモテ系）のWebRTC DTMF(Dual-Tone Multi-Frequency)である。

WebRTC DTMFはいわばSkypeをブラウザで実現するためのAPIで、最大の特徴は映像、音声、データをP2Pで接続できること。IP電話の知識が必要になるため、「マニア心を揺さぶられる」（羽田野氏）という。「ダイヤルトーン音を発生させるできるため、自動音声装置（IVR）への応用が期待できる。

また将来的にはブラウザからコールセンターへ通話ができるようになるかも」と、ビジネス的にも注目されているAPIだという。実際にダイヤルトーン発信のデモを実施し、その実力を披露した。

次に紹介したのは「WebAudio API」。「音源の生成や合成ができるAPI。iOSなどで複数音源の同時再生に重宝する。高精度な再生タイミングが設定できるので、ゲーム系コンテンツにいい」と羽田野氏は説明する。

またこのAPIを使えば楽器のチューナーなど精度が求められるものには向いていないが、各種オーディオエフェクトやアナライザーなども作れるという。ただ「これはまだモテ系の機能。非モテ系の機能もある」と語り、非モテ系の機能の中からPannerNodeを使った立体音響のデモを実施。救急車のピーポー音のドップラー効果の例を再現。「仕事になるかどうかはわからないが」と言うものの、参加者の関心を大いにつかんだようだ。

三番目に紹介したのは「Media Souce Extensions（MSE）」で、「Internet Explorer（IE）11にしか実装されていない」APIです（もしかしたらChromeにも入っているかもしれないが試していないとのこと）。IEではMPEG-DASH（Dynamic Adaptive Streaming over HTTP）という国際標準のメディア・ストリーミングのプロトコルをサポートしている。

同APIの特徴は、HTTPアダプティブストリーミング配信。セグメントに分割されたビデオデータをVideo要素に流し込むだけのAPIで、低ビッドレートのストリーミングに途中で切り替えられるというもの。

「ファイルを取りに行くコードを一つ一つプログラマが書かなければならないなど、気が利かないAPI。プレイヤーを作るのは、プログラマの腕にかかっているので要注意。仕事にはならないAPIだが、チャレンジしたい人はぜひ」と羽田野氏と会場の笑いを誘った。さらにマニアレベル1では「Media Capture and Streams」も紹介。

これはChromeのみに実装されているAPIで、全画面がキャプチャーできるというもの。しかし「Windows上で実行するとOSが引きずられ大変なことになるので、今回はMacで紹介」と、Macでデモを実施。いろんなユースケースが考えられると、羽田野氏がその一例としてあげたのが、デジタルサイネージのリモート監視やヘルプデスク。「ビジネスにも応用できそうな面白いAPI」（羽田野氏）

縁の下の力持ち系。マニアレベル2のAPI

マニアレベル2（縁の下の力持ち系。目立たないので話題になっていない）で羽田野氏が取り上げたのは、「Encording」「Web Cryptography API」「DOMMatrix」「Transferable objects」という4つのAPI。「Encording」はブラウザに入っているAPIで、文字コードのデコード、エンコードに使えるAPI。

「Web Cryptography API」はIE11に実装されている、暗号論的擬似乱数列の生成やダイジェストの生成、公開鍵と秘密鍵の生成、デジタル署名の生成と照合、データの暗号化と複合化などの機能を持つAPIである。
「将来、ストレージに溜めたデータを暗号化したいというニーズはきっと出てくる。このAPIは単独で使えるのでそのときの有望株になるのでは」

ただ、暗号化の知識がないと使えないので、ハードルは高いAPIだそう。「DOMMatrix」は行列計算やグラフィックスにおける座標変換のためのAPI。元はCSSMatrixという名称だったとのこと。「Transferable objects」はデータ転送の機能を持つAPI。参加者で知っている人はたった一人というかなりマニアックなAPI。「ファイルサイズの大きい動画のリアルタイム処理などをするときに使うと有効だと思う」

「使い方がわからない」マニアレベル3のAPI

マニアレベル3とは、「きっとどこかに必要とする人がいるのだろうでも使い方がわからないというAPI。そこで羽田野氏が紹介したのは、「Clipboard API」と「Base64 utility methods」。

前者の「Clipboard API」はどんなものがペーストされたかが、リアルタイムで情報が取れるAPI。すべてのブラウザで実装していますが、「Web上でやる意味がいまひとつわからない。もちろん使ったこともありません」とのこと。

また「Base64 utility methods」はBase64エンコードとデコードの機能を持つAPI。ただ対応しているのはASCII文字だけで、バイナリーどころか日本語もNGとのこと。「利用シーンはまったく思い浮かばない。マニアの皆さんに考えていただきたい」と羽田野氏は参加者に呼びかけていた。

「きっといつかはモテ系に…」なマニアレベル4のAPI

マニアレベル4とは「きっといつかはモテ系APIになるだろう。でも利用できるブラウザが……」というレベルのもの。最初に紹介したのは「Screen Orientation」。これはAndroidやFirefox OSのFirefoxにしか実装されていないAPIで、オリエンテーションを固定できる機能を持っています。ただFullScreen APIを使ってフルスクリーンになっている状態でしか、使えません。「脱アップルストアを目指している人には魅力的なAPIでしょう」

「MediaStream Recoding」はFirefox Aurora（現在は音声のみ）しかサポートしていませんが、録画と録音機能を持つAPI。メディアストリームの記録を開始してから停止するまでの間に蓄積されたメディアデータをBlobオブジェクトとして取り出すことができる。 「Webアプリケーションの可能性を開くことが期待できるAPIだ」

最後に羽田野氏が紹介したのが「Web Animations 1.0」というタイムライン制御フレームワーク。連続処理や並列処理ができ、ビデオ再生のように扱えるというのが特徴だ。ただ「欠点は実装しているブラウザがまだ一つもないこと」と羽田野氏（Githubにて公開されているポリフィルがあるので紹介）。

「Githubではポリフィルが公開されており、私はそれを仕事で使っています。パフォーマンスも悪くない。もっと広まってほしいAPIです」 このようにマニア度の高いAPIを15個ほど駆け足で紹介し、羽田野氏のセッションは終了した。

【講演資料・セッション映像】