AMP
PWA

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

More than 1 year has passed since last update.

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



用語整理


  • PWA: ネイティブアプリのようなUXを提供するための機能群

  • SPA: JSで遷移するシングルページアプリケーション

  • AMP: 後述

  • PWAMP: AMPで流入させてPWAを起動する形式

  • MFI: モバイルファーストインデックス

いまさら聞けないPWAとAMP

アメブロ2017: Isomorphic Web Appの進化編



AMP とは


  • イニシャルビューのためのHTMLの特殊なサブセット


    • GoogleにホワイトリストされたHTML属性しか使えない

    • GoogleにホワイトリストされたJSプラグインしか使えない

    • CSSはHEADに全部書く



  • AMP仕様を満たすと、Googleがキャッシュして、モバイルの検索流入ではそのキャッシュを使う

  • HTTPS必須

  • 必ずしも全ページをAMPに対応する必要はない



PWA: ServiceWorker の機能


  • リソースの先読み

  • オフライン対応

  • プッシュ通知

合法ローカルプロキシ

IE11/Safari が未対応



ServiceWorker が安心して使える時期

https://webkit.org/status/

予想だと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の効果



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



おわり