1 of 16

PWA 対応戦略と現実解

Bonfire Frontend #2

Shogo Sensui (@1000ch)

2 of 16

Shogo Sensui

(@1000ch)

Software Engineer

Merpay, Inc. / Mercari, Inc.

3 of 16

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

4 of 16

Progressive Web Apps

先進的な Web アプリを目指す標榜

5 of 16

みなさんどうやって

PWA 対応していますか？

とりあえずの Service Worker? Workbox?

6 of 16

Progressive Web Apps Checklist 📝

Baseline

  • HTTPS でホストされている
  • レスポンシブである
  • 全ての URL がオフラインでも動作する
  • メタデータが配信されている
  • 3G 環境でも高速にロードできる
  • クロスブラウザで動作する
  • 全てのページに URL がある
  • etc…

Advanced

  • インストールを不当に要求しない
  • キャッシュファーストである
  • ロード時にページがガタつかない
  • 戻ったときにスクロール位置も復帰する
  • 全画面モードでもシェアしやすい
  • オフライン時にそれを伝えている
  • プッシュ通知を適切に配信している
  • プッシュ通知の管理 UI を提供している
  • etc...

7 of 16

PWA Dependency Tree

HTTPS

Service Worker

High Performance

Cache First

Push Notification

Works on offline

Cross Browser

Web App Manifest

Installable

Responsive Web

8 of 16

まずは基本となるこの3つ

Secure, High Performance, Installable

9 of 16

何はともあれ、まずは HTTPS 化🔒

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

10 of 16

パフォーマンスに関して 🚅

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

11 of 16

Web App Manifest の導入

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

12 of 16

基本ができたらあと2つ

Offline (Cache-First), Engaging

13 of 16

キャッシュファーストとオフライン

  • 静的アセットは優先的にキャッシュを参照する
  • 余力があればオフラインでも利用できるように
    • 適用できるかは Web アプリケーションそのものの性質に依存する

14 of 16

Web Push でエンゲージメント

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

15 of 16

ここまで出来たら

たぶん(?)アプリと遜色ない

あとは残りのチェック項目を実践していくだけ

16 of 16

まとめ

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