AMP/PWA をどこで/いつ使うか

某所で使った資料の公開版

---

## 用語整理

- PWA: ネイティブアプリのようなUXを提供するための機能群
- SPA: JSで遷移するシングルページアプリケーション
- AMP: 後述
- PWAMP: AMPで流入させてPWAを起動する形式
- MFI: モバイルファーストインデックス

[いまさら聞けないPWAとAMP](http://qiita.com/edwardkenfox/items/4c0b9550ffa48c1f0445)

[アメブロ2017: Isomorphic Web Appの進化編](https://developers.cyberagent.co.jp/blog/archives/9001/)

----

## AMP とは

- イニシャルビューのためのHTMLの特殊なサブセット
    - GoogleにホワイトリストされたHTML属性しか使えない
    - GoogleにホワイトリストされたJSプラグインしか使えない
    - CSSはHEADに全部書く
- AMP仕様を満たすと、Googleがキャッシュして、モバイルの検索流入ではそのキャッシュを使う
- HTTPS必須
- 必ずしも全ページをAMPに対応する必要はない

----

## PWA: ServiceWorker の機能

- リソースの先読み
- オフライン対応
- プッシュ通知

合法ローカルプロキシ
IE11/Safari が未対応

----

## ServiceWorker が安心して使える時期

https://webkit.org/status/

![](https://i.gyazo.com/dac37efd970e5ce0c515c5cf7780111a.png)

予想だと1~2年後
(Appleとしては 「ネイティブっぽいアプリ」は AppStore と競合する)

----

## AMP: 非技術者向け説明

- モバイル検索からの流入時、静的なページを高速に表示できる
- 専用のカルーセルで表示されてSEOに有利 (MFI後、さらにメリットがありそう)
- ニュース系は更に高い優先度で表示できる https://support.google.com/news/publisher/answer/40787?hl=ja 

----

## AMP の Google側の思惑

- document.write などで日に日に重くなるモバイル広告どうにかしたい
- ブラウザにとってのレンダリングのベストプラクティスを強制

-------

## Google 以外?

[日本のYahoo!検索がAMPサポートを表明、日々5,800万のYahoo!検索ユーザーがAMPページにアクセスすることに](https://www.suzukikenichi.com/blog/yahoo-japan-is-said-to-support-amp/)

-----

## 国内の採用事例

- 食べログ
- 楽天レシピ
- はてなブログ
- ゾゾタウン
- アメブロ
- etc

レシピ界のCookpad以外は対応している

-----

## AMPの効果

- [クリック率25%↑ 再訪問23%↑ 新規ユーザー増加などAMPの成果事例 などSEO記事まとめ10+3本](http://web-tan.forum.impressrd.jp/e/2016/10/14/24082)
- [滞在時間50%↑、PV3.1倍、直帰率75%↓――AMP+PWAで楽天レシピが大成功! #IO17JP](https://www.suzukikenichi.com/blog/from-amp-to-pwa-progressive-web-amps/)

----

## AMP: 使ってみた感想

- [AMP Validator Addon](https://chrome.google.com/webstore/detail/amp-validator/nmoffdblmcmgeicmolmhobpoocbbmknc?hl=ja) が必須
- 特殊な WebComponents を使ったプログラミング
- ReactもjQueryもない、ホワイトリストの中での縛りプレイ
- 既存リソースの再利用より、たぶん専用のHTML作ったほうが速い
- アド周りの制約が強く、普通のビジネスではそこが鬼門になりそう
- アクセス解析での追跡が難しくなる
- ライブラリは割と無節操に増える

https://ampbyexample.com
https://github.com/ampproject/amphtml

----

## amp-bind

JSのような一部動的な要素の埋め込み

- amp-bind: jsonとmustacheテンプレートをバインドする
- amp-list: json を食わせるとそのリストを展開する。事前にwidth/height が確定している必要がある
- amp-form: 動的なフォームを作成する
- amp-live-list: amp-listのポーリングできる版

-----

## AMP: 現実的な用途

- ランディングページ
- ニュース
- 応募フォーム

用意されたプラグインで〜が可能か？という縛りプレイ
セッション周りの制約が厳しい https://github.com/ampproject/amphtml/blob/master/spec/amp-cors-requests.md 

-----

## AMPとPWAの種類

----

### AMP to Web

モバイルの検索流入からの入り口にAMPを表示し、その後モバイルWebに遷移。よくあるやつ。

-----

### Full AMP

PCでもMobileでも同一のAMPコンテンツを表示する。
(canonical で常に自分自身を指す)

-----

### AMP with PWA

AMPの機能 + ServiceWorker のプッシュ通知や先読みを行う
用途: ニュースサイト等

------

### AMP to PWA

PWAMPとも。
一旦AMPを返しといて、裏側で次のページで必要なアセットを先読みする。2ページ目以降のアセットが多いSPAでの効果が大きい。

----

### (mizchiの)結論

- ぶっちゃけ KPI 次第
- Full AMP (+ プッシュ通知): スクラッチなら実装が簡単だが、機能の縛りが強い。メディア系などで要件がしばれるなら
- AMP to Web: 導入が簡単。1ページ目がとりあえず Google の AMP Cacheになる。とりあえずやってみるならコレ
- AMP to PWA: 恩恵を受けるのがAndroid Chormeのみ。SW有無に関わらず、べき等にするためのフローがやたら複雑。Safariが対応するまで、iOS優勢な国内でやる恩恵は薄い。現在では技術的な自慢の側面が強い。
- AppShell/Add to Home Screen: 最初からネイティブアプリを作らないと割り切った場合。現状は、ネイティブ開発リソースを持たない貧者の技術。競合する技術はReactNative。SafariのSW対応以降に選択肢になる、かも。

----

## AMP を今やるべきか  

- 改善が見込めるかは完全に要件とKPI次第なので、とにかく試して考えるフェーズ。まずモバイル向けランディングページなどで実験的に。
- AMP それ自体にメリットがあるかはともかく、その派生や周辺機能が AMP 前提だったりなので、何かしら経験値ためておく必要があり、周辺数値をとっておく必要がある。

---

## 痛みのない設計の例

- 外部流入の部分は Full AMP + プッシュ通知
- 2ページ目以降の管理ページは PWA/SPA

----

## おわり