某所で使った資料の公開版
用語整理
- PWA: ネイティブアプリのようなUXを提供するための機能群
- SPA: JSで遷移するシングルページアプリケーション
- AMP: 後述
- PWAMP: AMPで流入させてPWAを起動する形式
- MFI: モバイルファーストインデックス
アメブロ2017: Isomorphic Web Appの進化編
AMP とは
- イニシャルビューのためのHTMLの特殊なサブセット
- GoogleにホワイトリストされたHTML属性しか使えない
- GoogleにホワイトリストされたJSプラグインしか使えない
- CSSはHEADに全部書く
- AMP仕様を満たすと、Googleがキャッシュして、モバイルの検索流入ではそのキャッシュを使う
- HTTPS必須
- 必ずしも全ページをAMPに対応する必要はない
PWA: ServiceWorker の機能
- リソースの先読み
- オフライン対応
- プッシュ通知
合法ローカルプロキシ
IE11/Safari が未対応
ServiceWorker が安心して使える時期
予想だと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ページにアクセスすることに
国内の採用事例
- 食べログ
- 楽天レシピ
- はてなブログ
- ゾゾタウン
- アメブロ
- etc
レシピ界のCookpad以外は対応している
AMPの効果
- クリック率25%↑ 再訪問23%↑ 新規ユーザー増加などAMPの成果事例 などSEO記事まとめ10+3本
- 滞在時間50%↑、PV3.1倍、直帰率75%↓――AMP+PWAで楽天レシピが大成功! #IO17JP
AMP: 使ってみた感想
- AMP Validator Addon が必須
- 特殊な 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