Google Developers Summit Tokyo 2016 | Progressive Web Apps | 参加まとめ


## 概要
| イベント名 | [Google Developers Summit Tokyo 2016 : Progressive Web Apps](https://events.withgoogle.com/google-developers-summit-tokyo-2016-progressive-web-app/) |
|:--|:--|
| 日時 | 2016年4月26日（火）　13:30 - 18:30（受付開始 13:00） |
| 会場 | コクヨホール （東京都港区港南 1-8-35） |
| ハッシュタグ | [#GDSTokyo](https://twitter.com/hashtag/GDSTokyo?src=hash) |
| 備考 | 同時翻訳あり |


## 発表一覧 
| 発表タイトル（スライドへのリンク） | 発表者 |
|:--|:--|
| (1) [Introduction to Progressive Web Apps](http://fr.slideshare.net/robnyman/progressive-web-apps-keynote-google-developer-summit-tokyo-japan) | Robert Nyman ([@robertnyman](https://twitter.com/robertnyman)) |
| (2) Security for all | Yoichiro Tanaka ([@yoichiro](https://twitter.com/yoichiro)) |
| (3) Instant loading | Masataka Yakura ([@myakura](https://twitter.com/myakura)) |
| (4) Offline first experiences | Eiji Kitamura ([@agektmr](https://twitter.com/agektmr)) |
| (5) Make it installable and engaging | Paul Kinlan ([@Paul_Kinlan](https://twitter.com/Paul_Kinlan)) |
| (6) Hey, look at me, I’m a notification | Pete LePage ([@petele](https://twitter.com/petele)) |
| (7) Putting the Progressive in Progressive Web Apps | Sam Thorogood ([@samthor](https://twitter.com/samthor)) |
| (8) SUUMO における Progressive Web Apps の活用事例 | Yusuke Katayama |
| (9) Better mobile experience with AMP | Yoshifumi Yamaguchi ([@ymotongpoo](https://twitter.com/ymotongpoo)) |

*※スライドのURLをご存知の方はコメント欄にご一報いただけると幸いです*

## 用語
| 略名 | 名称 |
|:--|:--|
| PWA | Progressive Web Apps |
| AMP | Accelerated Mobile Pages |

## TL;DR
* PWA対応により、オフラインアクセスや通知などの機能を利用することができる
* HTTPSが前提となるので、SSL化対応が必須
* ユーザ体験を損ねさせないために、通知やプロンプトはタイミングや条件に気をつける


## (1) Introduction to Progressive Web Apps

### Webの歴史
* HTMLの誕生からService Workerまで
* WIRED
	* 2010年: Webは死んだ
	* 2016年: Webは死んでなかった
	* それどころか、どんどん注目を浴びてきた

### ネイティブとWebは共存していく
* Webの通信料はネイティブの2倍
* アプリに費やしている時間は、全体の90％と言われている
	* アプリ利用は、明らかに特定の1〜6つ程度のアプリに偏っている
	* アプリが並んでるが、ほとんど使われない
	* 使いたい時その瞬間でいい
	* WebはシンプルでURLがあればアクセスできる

### SLICE
* Secure - IFrameの中でどこへでもアクセスできてはいけない
* Linkable - URLにリンクを貼れる, コンテンツへのリンク
* Indexable - 情報に触れる権利は誰もが得られる
* Composable - 3rd Partyなどの組み合わせ
* Ephemeral - 儚さ, サクラのように一過性のあるもの, 一度何かをやればいい

### ネイティブで開発を行う理由
* パフォーマンス
* オフラインアクセス
* バックグラウンドプロセス
* 通知
* センサー
* OS固有の機能

### そのほとんどはPWAで実現可能
* オフラインアクセス
	* Service Worker
* 通知
	* Web Push APIで実現できる
* OS固有の機能
	* manifestファイルの定義で実現
	* ホーム画面への追加
	* 向き
* その他
	* XX APIで取得できるようになっていく

### 実例
* [Flipkart](http://www.flipkart.com/)
	* PWA対応(ServiceWorkerによる高速化、ホーム画面追加など)の効果
		* 滞在時間が3.5倍に
		* PWA利用者の40％が再訪問

### PWAでの体験価値
* Relieable
* Fast
* Engaging

## (2) Security for all

### HTTPS
* 決済する際に鍵のマークがあるかどうかはみんなみる
* コンテンツを保護する観点もある
	* 自分の書いたコードだけで成り立っているサービスは少ない
	* [外部のコンテンツが内部のコンテンツを壊す可能性もある](https://paul.kinlan.me/detecting-injected-content/)

### 何か便利なAPIを使う際には、HTTPSが前提となってる時代となってきている
* Service Worker
	* Offline
	* Push
	* HTTPSが前提
* AndroidのChrome
	* サジェスト機能（ユーザに対してホーム画面に置きませんかという提案）にはHTTPSが前提
* その他
	* getUserMedia
	* Geolocation
	* Web APIもHTTPSが前提になってきている

### 自分で作ったサービスをHTTPSにするにはどうすればいいか
* 最初：ネットで調べればいけるでしょ、証明書買えばいいんでしょ、サーバに設定すればいいんでしょ
* 結果：証明書の設定が上手くいかない、弱いアルゴリズム
* ネットの情報は古くなっている、穴ができてしまう
* HTTPSを要求するAPIの場合どうすればいいの？
	* localhostを使って開発すれば問題ない
* HTTPSの環境を構築するのは難しい
	* GitHubPages, Firebase, GCPを使えば、ボタンひとつでHTTPS化できる
		* 日々アップデートしてくれるので、セキュリティリスクが減る
	* 自分のサーバに証明書を入れるには
		* Let's Encrypt
			* 有効期間が短い（あえて）
			* [設定ファイルの作り方](http://bit.ly/ssl-config-gen)
* HTTPS化した後
	* [SSL Server Test](http://bit.ly/ssl-labs)

> Webを安全にしていきましょう

## (3) Instant loading

* アプリに到達するステップ（インストール, ローディング, 登録...）が増えるごとに、20％の離脱が発生する
	* Webはインストールの手間が無い分、ネイティブより有利

### 読み込みの時間を短くするには
* Service Workerを使えばいい
* データ量を小さく保つ
	* 全体の質を下げずにアプリ全体のサイズを小さくする
* 必要なものだけをダウンロードさせる
* キャッシュさせる

### 圧縮
* すぐに導入できてコストがかからない
* 最小化と圧縮を組み合わせる
* WebP

### 遅延回避
* 遅さの原因はネットワークの遅延
* 場所などの様々な要因で影響が出る
* [Resource Hints API](https://blog.jxck.io/entries/2016-02-11/resource-hints.html)
	* dns-prefetch
	* preconnect
	* preload
	* prefetch
* CDNを設定
	* Round Trip Timeは距離に依存するので、CDNを設定する
	* CDNは近い場所から読み込んでくれる

### Be Interactive
* 枠だけを先に出す
* ファーストビューはすぐに読み込む

### JS
* scriptタグにdefer, asyncを指定する

### CSS
* filamentgroup/loadCSS
* regioning css
* critical css

### キャッシュ
* etag
* last modified
* cache-control
* unicorn

### HTTP/2で変わること
* リクエストの多重化、共通化が可能に
* 圧縮がかなり効くようになる
* ファイル結合や画像のスプライト化はベストプラクティスでなくなる可能性

## (4) Offline first experiences

### Service WorkerがWebのあり方を変える
* [ブラウザ対応状況](https://jakearchibald.github.io/isserviceworkerready/)
* オフラインを前提とした処理の例
	* リクエストを投げて、404だったら、ServiceWorker側からページを表示する
	* 端末が、オフラインだったら、オフライン用のページを表示する
	* 端末の機種を判断して、適切なリソースをプリロードする
	* リクエストをキャッチして、既にキャッシュ済みだったら、ローカル上のリソースを返す

### Googleが提供しているライブラリ
* [sw-prechache](https://github.com/GoogleChrome/sw-precache)
	* GruntやGulpのビルド時に使える
	* 必要なリソースをオフラインキャッシュ用にまとめることが可能
	* 自動的にバージョニング
* [sw-toolbox](https://github.com/GoogleChrome/sw-toolbox)
	* ローカルにキャッシュがあればそれを使う、無ければネットワークにリクエストを投げる
	* 処理が型化されている

### [Application Shell](https://developers.google.com/web/updates/2015/11/app-shell)
* 共通のUIパーツはプリキャッシュしておく
* コンテンツは動的ロード

## (5) Make it installable and engaging

### ホーム画面にWebアプリケーションを追加
* apple-touch-icon
* 2012年にAndroidにもホーム画面に表示できるようにアイコンを追加できるようになった
	* [サンプル](https://airhorner.com/)(Android Chromeで見ると、ホーム画面への追加の許諾が出る)

### install != bookmark
* ホームスクリーン起動はアドレスバーなし
* オフラインモード
* フルスクリーン起動
* スプラッシュスクリーンの自動生成
	* nameとiconからスプラッシュスクリーンを生成
	* theme_color, background_colorから色を作成

### インストールを促すプロンプトについて
* ユーザがよく見るサイト
* よほどいい体験でなければ、プロンプトは出さない
* 下記条件が整っていること
	* HTTPS化している
	* マニフェストを配置している
	* プロンプトが制御されている
	* オフラインで使える（Service Worker）


## (6) Hey, look at me, I’m a notification

### Reengagement
* 通知を送る前にユーザの行動を止めてまで送るべき内容か考える
* ユーザーをいらつかせてはいけない
* エンゲージさせる

### 良い通知の条件
* Timely: タイミング
* Precise: 正確さ
* Relevant: 意味ある内容

*例はスライド内でサンプルとともに解説*

### 使うには
* Chrome
	* 今はGCMを使ってください、となっている
	* これは将来的にきちんとWeb Push APIに対応する
* Firefox
	* Web Push APIに対応済み

### 通知に関するプロンプト
* 送っていいか聞くだけではユーザは判断できない
* 自分のフライト情報？ディスカウント？アップグレード？
* 何に関する情報でどんな条件で通知するかを明示した上で、承諾したユーザにのみ通知を出す
* サイト内に解除の導線も用意

## (7) Putting the Progressive in Progressive Web Apps

* [一番最初のWebページ](http://info.cern.ch/hypertext/WWW/TheProject.html)

### ユーザ体験を損ねないことが重要
* Googleのサンタアプリ
	* 2014年 位置情報の許可を求めるとみんな拒否を押す
	* 2015年 GeoIP, language, GeoLocationの組み合わせで位置情報を推測するようにした
* Google+
	* フルスクリーンでメッセージを表示するとユーザの69%が離脱
* PWAのAPIを使うにしても表示の仕方やプロンプトの出し方などをしっかり考えないといけない
* アプリケーション内のスピナーにすれば、アプリケーションの責任となる
* Facebookはブラー画像を用意するようにした、裏で読み込んでいる


## (8) SUUMO における Progressive Web Apps の活用事例

### 導入の背景
* スマホアクセスが増えてきた

### PWA導入に向けてやったこと
* SSL対応
* LocalStorageのhttp, https同期
* 全画面、リソースをhttpsへリダイレクト
* 被リンクの書き換え

### 導入効果
* ホーム画面からWebAppとして立ち上げても、LocalStorageは共有される
* ホームスクリーンを使っているユーザはCVRが1.2倍(118%)に
* 検索サービスなので、オンライン環境は必須だが、ServiceWorker対応により表示の高速化に成功
	* 0.8475 ms => 0.2019 ms（約4倍に）
* Chrome50 Payload対応により、プッシュ配信時に動的項目を入れることが可能に
* 支払いシミュレーションへの応用
	* [SUUMO住宅ローンシミュレーション](https://suumo.jp/edit/simulator/)
	* アプリとして成り立つ
	* Polymerを利用

## (9) Better mobile experience with AMP

### AMPとは
* [Accelerated Mobile Pages Project](https://www.ampproject.org/)
* 静的ページの高速化
* サイトの起動時間が3秒以上だと40%のユーザが断念してしまう
* 変更が少ない静的画面まで、開発者が高速化対応をする必要があるのか、という課題から生まれた

### AMPがなぜ速いのか
* 速いのではなく「遅くさせない」
	* カスタムエレメンツ
	* JSON-LD以外のjs禁止
	* CSSの読み込みも原則禁止
	* object, form, inputなども禁止
	* などなど

### 導入に必要なステップ
* AMP HTMLを作成する
* Validatorを通す
	* AMPのValidatorはChromeに搭載されている
		* URLに `#development=1` を付けてコンソールを開く
* 該当ページのlinkタグで、amphtmlを定義する
* Search Consoleで観察
	* 取り込みまでちょっと時間差がある

### AMPの現状
* 既に報道機関のサイトなどで採用
* 表示側は、はてブアプリ(iOS/Android)が対応している

### AMPとPWAの組み合わせ
* amp-install-serviceworker
* AMPページにService Workerを登録

### その他 | Chrome Custom Tabsの紹介
* WebViewと同様の使い方ができる
* Webページの読み込み速度を改善

## 所感
* PWA, SSL化, 高速化, AMPについての動向を実例を交えながら知ることができました
* オフラインアクセスや通知はサービスによって相性があるので、上手く取り入れていきたいと思います
* 会場はかなり満員に近かったです
	* 空調などにも気を使ってくださり、ありがとうございました
* ネイティブの英語にはついていけず、同時翻訳が必須でした
	* ただ、Pete LePage氏の英語は日本人に合わせてくれていたのか、とても聞き取りやすかったです
* 機会があればまた参加したいです