私はHTML5 Experts.jpで、過去2年ほどGoogle I/Oの情報を発信し、Web技術の変化についてお伝えしてきました。振り返るとGoogleは、2014年にモバイルWebの提唱と技術要素の拡大を図り、2015年からは「RAIL（モバイルWebが目指すべきパフォーマンス指標）」や「Progressive Web Apps（アプリのように振る舞うWeb）」といった、モバイルとの親和性が高いWebを作り出すための”考え方”を推し進めました。今年2016年は、さらにそれを踏み込んでいったという感じがします。

今回のI/Oで取り上げるのもそのひとつ。毎度お馴染みGoogle Developer AdvocateのPaul Lewis氏による 「High performance web user interfaces」です。彼は、モバイルにおいて、時にアプリのように振る舞うことが求められる昨今のWeb、すなわち「Progressive Web Apps」について、UIで起こりがちなパフォーマンス問題と、その改善方法について紹介しています。

※ この講演、動画無しでは説明が難しかったり、前提知識も多かったりするので、私でかなりアレンジ・要約して紹介しています。より詳細に内容を知りたい場合は、ソースをみることをオススメします！

Webは時として、モバイルアプリのような体験が求められる

モバイルにおいて、ホームスクリーンは重要な場所だ。人々はホームスクリーンから、目的を達成するためのアプリを起動する。Webは、Add to Homescreenを使うことで、ホームスクリーンからWebサイトへアクセスすることができるようになった。

するとどうなるか。このホームスクリーンをよくみてほしい。どれがWebで、どれがネイティブアプリなのかは見分けがつかないだろう。Google Mapsなんかはネイティブにみえるけれど、他はまったく想像がつかない。しかしこれらが、Google Mapsと同様にネイティブアプリにみえるなら、Webはネイティブアプリのように振る舞うことが求められている。

パフォーマンスモデル、インタラクションモデルの2つによって、Webはモバイルネイティブアプリのような振る舞いをえることができる。Progressive Web Appsを実現することができる。今日はこの2つのモデルのうち、パフォーマンスモデルの話をしたい。

昨年は、Paul IrishやIlya Grigorikなどの私のチームのメンバーが、「RAIL」というパフォーマンスモデルについて話した。RAILとは、Responseは0.1秒、Animationは16ミリ秒、Idleは50ミリ秒、Loadは1秒で動作すべきというもの。ただ、それを聞いた人々は、たまに勘違いをする。この4つの要素は、どれも全て、最も重要なこととして語ってしまうのだ。それは間違っている。

例えば、Webサイトにおいて、タップした時に求められるのは、4つの要素のうちLoadが重要になる。Idleが重要になることはそこまでない。そして、ホームスクリーンからタップして起動されるProgressive Web Appsでは、ResponseやAnimationが重要になる。Webサイトをつくるのと、Progressive Web Appsをつくるのでは、求められることが違う。

さて、このようにパフォーマンス面で求められることが異なるProgressive Web Apps。そこに、3つのコンポーネントがある。Side Navigation、Swipeable Cards、Expand an Collapse。これらを実現するセオリーを紹介しよう。

1. Side Navigation

まずは、このコンポーネント。メニューボタンをタップすると左からスライドインするバー。これは、2つのElementによって構成される。半透明の黒い背景と、サイドメニューを表示する領域だ。

このサイドメニューの部分のCSSは非表示の時、CSSにpointer-events: none;を指定する。そして、表示されたタイミングでpointer-events: auto;を指定する。

そしてここからが大事な話。左から右、あるいは右から左に移動させる際に、transformを使う。ブラウザがDOMの位置を変更する際に、CPUを使ったレイアウト変更してはいけない。GPUの力を借りて、描画位置を変更することで、最適なパフォーマンスを得ることができる。

例えば、一昔前。サイドメニューが左に消えている時にCSSは

.side-nav {
  position:       fixed;
  left:           -102%; /* DOMのレイアウト位置を左にずらしてメニューを隠す */
  top:            0;
  width:          100%;
  height:         100%;
  over-flow:      hidden;
  pointer-events: none;
}

と、left: -102%で隠す。これは一般的な方法だった。しかし、描画を高速に処理できるGPUの恩恵を受けたいなら、transformを使って以下のように記述する。

.side-nav {
  position:       fixed;
  left:           0;                 /* DOMのレイアウト位置は常に0のまま */
  top:            0;
  width:          100%;
  height:         100%;
  over-flow:      hidden;
  pointer-events: none;
  transform:      translateX(-102%); /* 描画の位置を左にずらすことでメニューを隠す */
  will-change:    none;              /* <- これは何！？ */
}

サイドメニューのDOMのレイアウト位置としては、x位置のleftもy位置のtopも、0のまま。横幅widthも縦幅heightも、100%ということで、全面を覆っているという扱いになる。しかし、transform: translateX(-102%);で描画の位置自体を、左に寄せている。

そして、ここで登場するのがwill-chanage: none；だ。

一昔前にtransform: translateZ(0);をCSSプロパティに指定して、パフォーマンスを改善するというハックが出回ったのをご存知だろうか。このCSSが指定されると、描画には必然的にGPUの力が必要になるため、強制的にGPUに描画を依頼することになる。GPUの恩恵を受けるために活用されたこのバッドノウハウは、will-chanage: transform；という新しいCSSプロパティをWeb標準として追加することによって、同様のことを実現できるようにした。(※注:実態はブラウザ対応の問題もあり、今もtransform: translateZ(0);を使うのが一般的)

ただ、transform: translateZ(0);やwill-chanage: transform；といったCSS指定は、常時ビデオカード上のRAMメモリーに描画結果をテクスチャーとして保存することになる。モバイル環境では、バッテリー消費などに悪影響を及ぼすことになる。動作するタイミングだけwill-chanage: transform；を指定し、動作しない時は無効化will-chanage: none；するといい。これが、バッテリー消費パフォーマンスと描画速度パフォーマンスのトレードオフ問題に対する、落とし所だ。

黒背景については、will-change: opacity;というプロパティがあり、transformと同様の方法で、高いパフォーマンスで描画させることができる。(※ JSの実装については、「2. Swipeable Cards」にノウハウが似ているので割愛)

2. Swipeable Cards

CSSを使ったパフォーマンス改善のテクニックの他に、注意しなくてはいけないのが、スワイプ操作時のコンポーネントの移動処理。ユーザーからの指の位置状況を入力し、それをスクリーン上に反映しなくてはいけない。この際、有用なのが「ゲームループ」のノウハウだ。

描画のイベントは常に、1/60秒ごとに発生する。対してスワイプのイベントは、常に一定には発生しない。描画のタイミングにはあわせてくれないのだ。

そこで、スワイプにより発生するイベントについては、変数に位置情報だけを記録する。そして、描画時のイベントでは、記録された位置情報を元に、CSSを通じて描画位置変更をおこなう。

スワイプの開始時・移動時・終了時は以下の通り。this.startX、this.currentX、this.targetXといった変数に、現在の位置や、移動すべき位置を記録している。

/**
 * スワイプ開始
 */
onStart(evt) {

  // スワイプの開始位置を記録する
  this.startX = evt.pageX || evt.touches[0].pageX;
  this.currentX = this.startX;

  // cardの移動が開始されたことを記録する
  this.draggingCard = true;

  // will-change: transform; を有効にする
  this.target.style.willChange= ‘transform’;

  // カード上の要素にイベントを伝播させないように
  evt.preventDefault();

  // アニメーションを開始する
  requestAnimationFrame(this.update);
}

/**
 * スワイプ移動時
 */
onMove(evt) {

  // スワイプの現在地点を記録する
  this.currentX = evt.pageX || evt.touches[0].pageX;

}

/**
 * スワイプ終了時
 */
onEnd(evt) {

  // cardを削除すべきかどうか判定する
  let translateX = this.currentX - this.startX;
  const threshold = this.cardWidth * 0.35;
  if( Math.abs(translateX) > threshold ) {

    // cardの移動先をスクリーンの外へ(※cardは削除)
    this.targetX = (translateX > 0) ? this.cardWidth : -this.cardWidth;

  } else {

    // cardの移動先を最初の位置へ(※cardは削除されない)
    this.targetX = 0;

  }

  // cardの移動が終了されたことを記録する
  this.draggingCard = false;
}

描画のタイミングにrequestAnimationFrameから呼び出されるコールバックで、先ほどの位置情報を元に反映していく。

/**
 * 描画内容の変更
 */
update(evt) {

  // 次の描画タイミングでも自身を呼び出す
  requestAnimationFrame(this.update);

  // スワイプ中の場合
  if( this.draggingCard ) {

    // 現在の位置を描画させる
    this.translateX = this.currentX - this.startX;

  // スワイプが完了している場合
  } else {

    // カードを削除するかしないかに応じて指定の場所に能動的に移動する
    this.translateX += (this.targetX-this.translateX)/4;

  }

  // CSSプロパティを経由してGPUに変更を伝える
  this.target.style.transform = `translateX(${this.translateX}px)`;
}

(※ この後の処理については、「3. Expand and Collapse」にノウハウが似ているので割愛。)

3. Expand and Collapse

タップすると、領域が広がり全体化されるUIコンポーネント。CSSではどうするのか？もちろん、ここまで説明してきた「transform」を活用する！では、JSについてはどうか？実は、「2. Swipeable Cards」とは異なり、スワイプ操作でなくタップによって、自動的にアニメーションする。この点で、より効率的な実装が求められる。

まず、アニメーションについて、動作中の状態はJS上で持たない。動作前後の状態だけを、CSSプロパティを通じてGPUに指示する。

// 変化量を計算する
invert.x = first.left - last.left;
invert.y = first.top - last.top;
invert.sx = first.width / last.width;
invert.sy = first.height / last.height;

// 変化後の状態をCSSプロパティを通じてGPUに指示
card.style.transformOrigin = ‘0 0’;
card.style.transform =
    `translate(${invert.x}px, ${invert.y}px)
      scale(${invert.sx}, ${invert.sy})`;

そのままでは、タップした要素は一瞬にして全体化されてしまう。どのようにして何ミリ秒もかけて徐々に広げていくか？その方法は、CSSで指定する。JSではない。原理的には、従来よく使われているCSSアニメーションだ。

.cards {
  transition: transform 0.2s cubic-bezier(0,0,0.3.1); // アニメーションさせる
}

ここまで、Progressive Web Applsのパフォーマンス改善の話をしてきたが、「Google DevelopersのRendering peformance」が役に参考になる。一読するといいだろう。

Progressive Web Appsのパフォーマンス改善。要はこう言いたかった

いかがでしたでしょうか？文字数の制限やコンテキストの高さもあり、多くのエンジニアに伝わるようかなりアレンジしてみましたが、ご理解いただけましたでしょうか？

Paul Lewis氏が言いたかったことは単純な話です。先ほどのGoogle Developersの記事にもありますが、Progressive Web AppsにおけるAnimationやReactionの課題は、いかにしてブラウザのレンダリング処理における「レイアウト」を減らすか、という話です。この講演は、そのTIPS集といえます。

今日のノウハウ、特に新しいというわけでもなく2年前には既に実践されていたことです。実際のところ多くの現場では、OnsenUIやIonicのようなUIライブラリを活用することになり、このあたりの話を意識することはないのでしょう。ただ、Webのサービスを作っているフロントエンドエンジニアにとっては、ライブラリの有無に関係なく知っておくべき知識のように思えます。サイドメニューについては、Webサイトであっても鉄板のUIコンポーネントなので、Progressive Web Appsか否かはもはや関係ないノウハウだったに違いありません。

Webがモバイルに順応していくことは、今後もさらに求められていきます。これは、フレームワークやライブラリに限った話ではなく、トータルにみたWeb、フロントエンドへの要求に変化を与えるに違いません。

今後も、モバイルとWebの関わりに、目が離せませんね。

2016年5月18～20日の3日間、Googleの本社ビルのすぐそばにあるショアライン・アンフィシアターでGoogle I/O 2016が開催されました。

例年5千名程の参加者から大幅に増えて、今年は実に約7千人の人々が参加していたようです。屋外イベント施設ということもあり、まるで野外フェスのような雰囲気でした。

本レポートではGoogle I/O最初のセッションである、基調講演の内容について紹介します。

Google Assistant

まず最初にスンダー・ピチャイ氏に紹介されたのが、Google Assistantです。

Google Assistantは新しい対話型のボイスアシスタント機能です。Google製のアシスタント機能といえばGoogle Nowがありますが、これを進化させ、対話型のシステムとしたのがGoogle Assistantのようです。コンテキストを認識し、ユーザーが質問すると現在地や直近のクエリーなどに応じて、適切に答えを返します。

例えば、有名な建築物の前で「これを設計したのは誰？」と質問すると、その場所の情報に応じて回答してくれます。

デモでは、ユーザーが「今夜やってる映画は？」と聞くと、Google Assistantは近くの映画館で上映しているタイトルをいくつか提示し、さらにユーザーが「子どもと一緒に行きたい」と言うと、子どもと一緒に鑑賞するのにふさわしいと思われる映画を提案していました。さらに「4枚チケットが必要ですか？」とGoogle Assistantが尋ねてくるので、ユーザが映画のタイトルや枚数を答えると、自動で予約し、チケットの情報を提示する、というデモが行われました。

このように、『提案をしてくれる』というのがGoogle Assistantの大きな特徴です。Google Assistantは基調講演の中で発表されたGoogle HomeやGoogle Alloなどの製品にも組み込まれるようです。

Google Home

続いてGoogle Assistantの機能を組み込んだGoogle Homeという製品が紹介されました。

Google Assistantのボイスアシスタント機能の他にWifiスピーカーとしての機能もあり、クラウドから音楽のストリーミング再生もできるようです。プレイリストやアルバムへのアクセスもボイスコントロールでき、Google Castを通して、AndroidやiOSのデバイスから音楽を送信することもできるとのことでした。

Amazon Echoと似たような製品のようです。大きさは手のひらに乗るくらいの小さなデバイスでした。今年の後半から使えるようになるとのことです。

Google Allo

次にAlloというモバイル用のメッセージングアプリが紹介されました。見た目はLineやFacebook messenger等と大差なく見えます。

文字や絵文字の大きさを自由に変えることができることが紹介されました。地味だが良い機能、ということで会場が少し盛り上がります。

しかし当然のことながら、ただのメッセージングアプリではありません。このAlloにはGoogle Assistantの機能が組み込まれており、なんとチャットのテキストや画像を解析して、返信用のテキストを複数提案してくれます。

例えば「Dinner later?」とチャットの相手が送ると、「I’m in!」「I’m busy」という返信用のメッセージが表示されます。ユーザは選んでクリックするだけでメッセージを送信することができます。

またチャット内の画像も解析されるので、誰かが犬の写真をアップロードすると、犬種も識別された上で、「Cude dog!」「Aww!」「Nice bernese mountain dog」といった返信メッセージが提示されます。

またGoogle Asisstantのbotががチャットの中に存在するようなかたちになっており、店のお店のサジェストや予約、検索等も対話形式でチャットの中で行うことができるようです。

さらにChromeのようにIncognito Modeが搭載されており、エンドツーエンドでの暗号化やNotificationの制御、メッセージの期限などを設定できるようになっているとのことです。

Google Duo

続いてDuoというビデオチャットアプリの紹介です。

ビデオチャットを実現するアプリは数多く世に出ていますが、このDuoにはビデオコールをかけられた側は、応答する前にそのビデオストリームを見ることができるという特徴があるようです。この機能は『Knock Knock』と呼ばれているそうで、これにより着呼側は誰が、どんな状況でコールしてきたのかを知ることができます。

コール先は電話番号に紐づくとのことで、AppleのFaceTimeの競合として考えられそうです。

DuoはWebRTCとQUICを使用したWebプロトコルベースのアプリと紹介されました。

AlloとDuoはAndroidとiOSで2016年夏頃リリースされる予定で、Android版では事前登録が開始されています。

• Google Allo
• Google Duo

Android N

続いてAndroid Nについての発表が行われました。

GoogleがAndroidの開発を行うようになってから、10年が経過したようです。今やAndroidはスマートフォンだけではなく、Android Wear、Android TV、Android Autoなど、多くのプラットフォームが登場しています。

Androidの最新バージョンであるAndroid Nは現在プレビュー版(6/28現在Developer Preview 4)が公開中です。こちらで名前の募集も行われていましたが、現在は終了し近日中に公開されるようです。

Android Nでは、新しいOSのアップデートがあると、自動的にソフトウェアをバッググラウンドでダウンロードし、次回Androidの電源を入れた際にシームレスで新しいソフトウェアイメージに切り替わるようです。

またマルチウィンドウが正式に採用され、スマートフォンでYoutubeを見ながら他のタスクを行ったり、Android TVでは映像を見ながら検索などの他の作業を行うことができるようになります。

現在はAndroid NのDeveloper Preview 4がリリースされており、Nexus 6やNexus 5X等の一部の対応した機種であれば、Android Nを試用することができます。(Android Developers Blog)

Daydream

続いてI/O開催前から噂が絶えなかったVRに関する発表です。

Androidスマートフォンで高品質なVR体験を提供可能であるDaydreamというプラットフォームが発表されました。

どのようにAndroidスマートフォン上で、高品質なVR体験を可能にするのか、講演では3つの要素が挙げられていました。 まずはスマートフォン本体、次にヘッドセットコントローラのリファレンスデザイン、そしてアプリで、ぞれぞれが協調してエンドツーエンドのユーザ体験を提供するために設計されています。

ハイパフォーマンスセンサーやヘッドトラッキング、表示のレスポンスの速さなど、VR用に作られた仕様を満たしたスマートフォンは、Daydream-readyと呼ばれ、高いクオリティのVR体験を提供することができます。Daydream-readyなスマートフォンは、SamsungやAlcatel、Asusなどの企業から、2016年秋以降リリースされるようです。発表された中に日本の企業はありませんでした。

リファレンスデザインとして紹介されたヘッドセットとコントローラは非常にシンプルなものでした。コントローラはボタンは少なくクリッカブルなタッチパッドがついており、スクロールやスワイプができます。オリエンテーションセンサーも内蔵しており、ユーザがどこをポインティングしているかが分かります。

アプリに関しては、VR用のGoogle Playが開発されており、ユーザーがアプリを探し、購入、インストールがVR上で可能になることが発表されました。またGoogle Play MoviesやGoogle Mapsのストリートビュー、Google Photos、YouTubeもVR上で鑑賞できるようになります。

Daydreamが使えるようになるのは2016年秋になるとのことですが、Android NのDeveloper Previewを使用することでアプリなどの開発は今から行うことができます。

Android Wear 2.0

Android Wearは2年前のGoogle I/Oで初めて発表されましたが、今回は初めて大幅なアップデートとなるAndroid Wear 2.0が発表されました。

大きな変化としては、今までAndroid Wearのアプリがインターネットにアクセスするためには母艦となるAndroidやiOSスマートフォンが必要であったことに対し、Android Wear 2.0ではスタンドアロンで動作することが可能になることが挙げられます。アプリが直接BluetoothやWi-Fi、LTEなどを通してインターネットにアクセスできるようになり、ペアリングされたスマートフォンが電源を切っている場合でも、アプリは引き続きフル機能を提供できるようになります。

その他にもUIの刷新や、手書き入力の対応等も発表されました。

Android Wear 2.0はプレビュー版が公開されおり、秋には正式リリースとなるようです。

Progressive Web AppsとAccelerated Mobile Pages

基調講演も終盤に差しかかり、ここで初めて、わずかですがWebについての発表がありました。 モバイルデバイス上でWebをより快適にするための取り組みとして、Progressive Web AppsとAccelerated Mobile Pagesの2つの紹介です。

Progressive Web Apps、略してPWAppsは、オフライン状態でも動作可能、エンゲージメントを高めるための通知、ホームスクリーンにアイコンを登録、といったネイティブアプリのような振る舞いを実現したWebアプリのことを指します。ChromeにはServiceWorkerをはじめとする、Progressive Web Appsを実現するための仕組みが実装されています。

Accelerated Mobile Pagesは、既存のWeb標準に基づいた非常に速いモバイルWebサイトを作るための、オープンソースのプロジェクトです。

特に新規発表はなく、基調講演内ではわずか1分程度の紹介でしたが、Google I/O全体では多くのPWAppsやAMPのセッションが行われていました。HTML5 Experts.jpでもGoogleが新たに提唱するProgressive Web Appsの新たな開発パターン「PRPL」とは？という記事を公開していますので、そちらをご覧ください。

Android Studio

Android Studio 2.2 Previewが公開されたと発表がありました。

Android Studio 2.2では、ビルドが10倍、エミュレータも3倍速くなっているそうです。また、新しいレイアウトデザイナやAPKアナライザーが搭載されるとのことでした。

Firebase

続いてFirebaseの新バージョンが発表されました。

FirebaseはGoogleが2014年の10月に買収したBaaSサービスです。モバイルアプリに特化した分析ツールである、Firebase Analyticsが発表されました。ユーザがアプリ内で何をしているか、ユーザがどこからきたのかなど分析することが可能です。Android AnalyticsはAndroidでもiOSも扱うことができ、無制限に無料で使用することができると発表されました。

Android Instant Apps

今回の基調講演の後半で一際注目を集めたのがこのAndroid Instant Appsではないでしょうか。

Webアプリの場合、ユーザはリンクをクリックするだけでアプリを使用することができますが、Androidアプリはインストールを必要とするため、ユーザがそこで離脱してしまうことが多くあります。その課題を解決する一手となるのが今回発表されたAndroid Instant Appsのようです。

今回発表されたAndroid Instant Appsでは、AndroidアプリがWeb等のリンクからインストールレスで使えるようなるとのことです。

講演中のデモの中では、いくつかのAndroidアプリをURLから起動し、実際にアプリを使用できることが示されていました。 アプリの中の直近で必要になるモジュールだけをフェッチしているらしく、起動も素早く行われ、アプリを使用してからのインストールも非常にスムーズに行えるようです。

これにより、Androidアプリ開発者は、より多くのユーザにリーチできるようになります。AndroidアプリとWebとの親和性が高くなり、Androidアプリのユーザ体験が大きく変わる機能となるのではないでしょうか。

おわりに

今年はGoogleのAIの技術力を発揮した製品やサービスが多く発表されました。

基調講演内でWebやChromeに関する発表は非常に少なかったのですが、Google I/O全体では33ものモバイルWebに関するセッションが行われていました。

既に公開されている

• 今、Webの最先端では何が起こっているのか？──最新機能目白押し！Google I/O 2016セッションレポート【前編】
• Webの最先端では何が起こっているか、今Googleが取り組んでいることは？──Google I/O 2016セッションレポート【後編】
• Googleが新たに提唱するProgressive Web Appsの新たな開発パターン「PRPL」とは？

以外にもセッションレポートを公開していく予定です。お楽しみに。

今現在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についてお伝えします。