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


用語整理

  • 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

おわり

Sign up for free and join this conversation.
Sign Up
If you already have a Qiita account log in.