PWA 対応戦略と現実解 / PWA strategy and realistic solution

2018年8月23日に開催された Bonfire Frontend #2 https://yj-meetup.connpass.com/event/97695/ の「PWA 対応戦略と現実解」のセッション資料です。

Transcript

1. PWA 対応戦略と現実解
   Bonfire_Frontend #2
   Shogo Sensui (@1000ch)
   

   View Slide

2. Shogo Sensui
   (@1000ch)
   Software Engineer
   Merpay, Inc. / Mercari, Inc.
   

   View Slide

3. 「信用を創造して、なめらかな社会を創る」
   

   View Slide

4. Progressive Web Apps
   先進的な Web アプリを目指す標榜
   

   View Slide

5. みなさんどうやって
   PWA 対応していますか？
   とりあえずの Service Worker? Workbox?
   

   View Slide

6. Progressive Web Apps Checklist
   Baseline
   ● HTTPS でホストされている
   ● レスポンシブである
   ● 全ての URL がオフラインでも動作する
   ● メタデータが配信されている
   ● 3G 環境でも高速にロードできる
   ● クロスブラウザで動作する
   ● 全てのページに URL がある
   ● etc…
   Advanced
   ● インストールを不当に要求しない
   ● キャッシュファーストである
   ● ロード時にページがガタつかない
   ● 戻ったときにスクロール位置も復帰する
   ● 全画面モードでもシェアしやすい
   ● オフライン時にそれを伝えている
   ● プッシュ通知を適切に配信している
   ● プッシュ通知の管理 UI を提供している
   ● etc...
   

   View Slide

7. HTTPS
   Service Worker
   High
   Performance
   Cache First
   Push
   Notification
   Works on offline
   Cross Browser
   Web App
   Manifest
   Installable
   Responsive Web
   PWA Dependency Tree
   

   View Slide

8. まずは基本となるこの3つ
   Secure, High Performance, Installable
   

   View Slide

9. 何はともあれ、まずは HTTPS 化
   ● Web の HTTPS 化は避けて通れない
   ○ ユーザーの意識に関わらず「安全である」ことは最も重要
   ○ Service Worker をはじめ、Web の様々な機能が HTTPS 前提になりつつある
   ○ 「HTTP でも良い」という考えは、もはや牧歌的
   ○ ブラウザ UI での警告、Google のページランクにおける不利、 etc
   ● PWA というコンテキストにおいて
   ○ 「安全な Web ページ」の達成はもちろんのこと
   ○ PWA の基盤となる Service Worker を使う上での前提条件
   ● 既存の大規模 HTTP ページの場合は…
   ○ Yahoo! JAPAN、はてな、アメブロなどを見習う
   

   View Slide

10. パフォーマンスに関して
    ● まずはロードパフォーマンスを最適化する
    ○ ユーザーの体験順序・対コスト効果の両面
    ○ ランタイムパフォーマンスは、 (比較的)問題になりにくい
    ● パフォーマンス最適化による恩恵
    ○ コンバージョンの向上
    ○ アクセシビリティの向上
    ○ SEO における優位性
    ● HTTPS 化が済んでいればやることは数手
    ○ Service Worker で静的アセットをまるっとキャッシュする
    ○ 結合していたファイルをバラして HTTP/2 化する
    ○ 超速本の2章、3章、8章、9章を読む
    

    View Slide

11. Web App Manifest の導入
    ● パフォーマンスを充分に最適化してからで良い（と、思っている）
    ○ パフォーマンスが悪い Web ページをインストールしたくない …よね
    ● HTTPS 化が済んでいれば、あとは簡単
    ○ 規定サイズの Web ページのアイコンを用意する
    ○ manifest.json ファイルを用意して で参照する
    ○ PWACompat: the Web App Manifest for all browsers
    ● インストールバナーの表示は計画的に
    ○ Changes to Add to Home Screen Behavior
    

    View Slide

12. 基本ができたらあと2つ
    Offline (Cache-First), Engaging
    

    View Slide

13. キャッシュファーストとオフライン
    ● 静的アセットは優先的にキャッシュを参照する
    ○ Service Worker の fetch イベント + Cache API
    ○ HTTP Header の Cache-Control: Immutable
    ○ ロードのパフォーマンスだけでなく、インフラへの負荷も減る
    ● 余力があればオフラインでも利用できるように
    ○ 適用できるかは Web アプリケーションそのものの性質に依存する
    

    View Slide

14. Web Push でエンゲージメント
    ● ユーザーにとって必要な情報を通知する
    ○ この前提がないと通知を送るどころか許可してもらえない
    ○ その情報がユーザーにとって価値があるかどうか
    ● Web Push もあくまで付加的な機能として捉える
    ○ 様々な不確定要素がつきまとう
    ■ ブラウザの実装状況、パーミッションの設定状況
    ■ そもそも許可してもらえるかわからない
    ○ あると便利だけど、なくても価値を提供できる設計に
    ● FRESH! での導入例
    ○ FRESH! における Web プッシュ通知機能 〜機能設計編〜
    ○ FRESH! における Web プッシュ通知機能 〜実装編〜
    

    View Slide

15. ここまで出来たら
    たぶん(?)アプリと遜色ない
    あとは残りのチェック項目を実践していくだけ
    

    View Slide

16. まとめ
    ● 依存関係と対費用効果をよく考える
    ○ 技術要件において、どんな依存関係があるか
    ■ HTTPS → Service Worker + Web App Manifest
    ○ サービス要件おいて、何をやって何をやらないか
    ■ オフライン対応は必要なのか
    ■ プッシュ通知は適しているか
    ● 実装しておしまいではなく、運用をよく考える
    ○ PWA としてメンテナンスし続ける必要がある
    ■ 特にパフォーマンス、オフライン、 Web Push あたり
    ○ それぞれを配慮できる開発者知識と組織体制が必要
    

    View Slide